Documentation policy — what stays public

Public-documentation disclosure policy

Every document in docs_public/ must satisfy these rules. An automated guard script enforces them mechanically; this page is the human-readable version.

Never appears in public docs

1. Code and configuration — code blocks, file names, directory paths, API routes, environment variables, command lines.
2. Protocol mechanics — the specific cryptographic and scripting techniques used to commit, lock, transfer, or settle assets. Public language stays at the level of "Bitcoin-enforced", "client-side validated", "settled in one transaction".
3. Key and wallet internals — key formats, derivation schemes, signing flows, storage layouts.
4. Security research — findings, attack surfaces, threat-model details, audit contents, test-infrastructure specifics. We publish our security posture, never our security homework.
5. Unreleased roadmap detail — features are described as directions, not as specifications a competitor could build from.
6. Internal identifiers — project codenames, ticket/plan IDs, internal doc titles.

Always appears

1. Plain-language explanations a non-engineer can finish.
2. Honest status — what is proven, what is testing-only, what is not yet built.
3. Risk framing — every product document names its own risks.
4. The compliance model — curated venue, neutral protocol, eligibility gates.

If in doubt

Leave it out, link to the public contact path, and mark the question for the internal docs. The internal set loses nothing by this collection existing; the public set loses its purpose the moment it leaks.