Rule 6 of 12 · Chapter II — Designing for Disclosure
Publish or circulate your protocol specification for scrutiny before you depend on it in production.
Why this rule exists
Primitives are rarely where systems break; the joins between them are. A specification that only you have read has been tested against only your assumptions, and the first outsider to read it will be someone with a motive. Reviewing on paper is also orders of magnitude cheaper than discovering a protocol flaw after it has been running against live keys for two years.
In practice
Write the protocol down as messages, states, and security goals — not as a description of your code. Then give it to people outside the project: a public repository, a standards list, a contracted reviewer, or a sister team with no stake in shipping. Hold the launch until the questions coming back are about clarity rather than about soundness, and keep the answers in the document.
When it doesn't apply
Some deployments genuinely cannot publish — classified work, or a protocol whose message formats reveal an operational posture. Then widen review as far as clearance allows and bring in reviewers who are not on the build team; the point is adversarial reading, not public hosting.