Publication Workflow
Purpose
Define how wiki.x1 documentation moves from private drafting toward intentional public release.
This is governance and process guidance. It does not imply that automated publication filtering, public deployment, or access control is already implemented.
Architectural role
wiki.x1 is private-first. Publication is a staged act, not a side effect of writing a page.
The workflow protects canonical architecture, source-of-truth discipline, implementation-state accuracy, and confidentiality while still allowing selected QTM OS documentation to become public later.
What it governs
- Movement from draft to active documentation
- Promotion to canonical status
- Review for public-facing publication candidacy
- Final public status discipline
- Separation between private wiki truth and public documentation output
Publication stages
1. Draft
A draft page may be incomplete, exploratory, or awaiting source alignment.
Requirements:
- frontmatter status should be draft unless the page is clearly ready for active use
- visibility should usually be private
- implementation_state must not overstate runtime reality
- unclear claims should be marked as proposed, planned, or conceptual
2. Active
An active page is usable for current work.
Requirements:
- terminology aligns with QTM OS architecture
- no known contradiction with canonical docs
- implementation reality is clearly classified
- links to relevant canonical pages are included where useful
3. Canonical
A canonical page defines durable architecture or governing system truth.
Requirements:
- source-of-truth material is identified or clearly represented
- language preserves architectural specificity
- execution spine, namespace spine, and runtime boundaries are not weakened
- conceptual, assigned, partially_implemented, and live distinctions are preserved
- future changes should be deliberate and reviewed
4. Public-facing publication candidate
A publication candidate is a page being prepared for possible external release.
Requirements:
- private implementation details are removed or intentionally excluded
- public wording does not invent implementation reality
- status and implementation_state remain truthful
- partner/public audience assumptions are clear
- page links do not expose private-only routes or sensitive internal context
This stage may be represented by frontmatter visibility changing to partner or public, but that metadata alone does not publish the page.
5. Public
A public page is intentionally approved for external documentation.
Requirements:
- visibility is public
- content has been reviewed for source truth, confidentiality, and implementation accuracy
- the public deployment mechanism intentionally includes it
- the page does not imply live runtime behavior unless that behavior exists
What it does not govern
- It does not implement authentication.
- It does not implement build-time public filtering.
- It does not automatically publish pages.
- It does not override canonical architecture.
- It does not allow marketing language to replace system truth.
Relationships to other layers
Publication workflow depends on the visibility and status policy. It is constrained by docs governance and the canonical domain architecture.
Public pages should be downstream from private source-of-truth pages, not casual rewrites that drift from them.
Current status
Active process guidance. There is no automated publication pipeline in this repo yet.
Future direction
A future implementation may add build-time filtering by visibility, private authentication, partner-specific export, or a separate public deployment target. Those would be implementation changes and should be documented when built.
Guardrails
- Public release must be intentional and staged.
- Do not mark pages public just because the content is polished.
- Do not publish canonical private architecture by accident.
- Do not weaken source terminology for public readability if doing so changes meaning.
- Do not imply automation that does not exist yet.