standard ยท v0.01

Visibility and Status Policy

Visibility and status policy for wiki.x1, the private-first knowledge layer for QTM OS.

private active assigned qtm-os

Visibility and Status Policy

Purpose

Define how wiki.x1 classifies documentation visibility, document status, and implementation state.

This policy keeps private working knowledge, internal operating docs, partner-facing material, and public documentation from collapsing into one undifferentiated pile.

Architectural role

Visibility controls intended audience. Status controls document authority. Implementation state controls runtime truth.

These fields are related, but they are not interchangeable. A canonical architecture page can describe a conceptual namespace. A private page can describe live runtime behavior. A public page must still avoid overstating implementation reality.

What it governs

  • Frontmatter visibility classes
  • Frontmatter status classes
  • Frontmatter implementation_state classes
  • Public-release readiness language
  • Distinction between documentation authority and runtime implementation

Visibility classes

private

Private is the default for wiki.x1.

Use private for:

  • canonical architecture work not meant for outside circulation
  • internal planning notes
  • implementation-sensitive docs
  • governance drafts
  • source-of-truth pages that have not been cleared for external release
  • pages that include private operational assumptions or internal naming strategy

Private does not mean low quality. Many canonical pages should remain private.

internal

Internal pages are usable inside QTM operating contexts after review.

Use internal for:

  • operator-facing process docs that are not public
  • internal standards
  • team onboarding docs
  • operating instructions
  • implementation guidance that does not belong in public docs

Internal does not mean partner-safe or public-safe.

partner

Partner pages are shareable with selected external partners after scope review.

Use partner for:

  • partner onboarding material
  • controlled architecture summaries
  • implementation boundaries relevant to a specific partner
  • docs that omit private governance, source, credential, or deployment details

Partner visibility should be intentional and narrow.

public

Public pages are candidates for public documentation or public knowledge release.

Use public for:

  • public methodology
  • public architecture overview material
  • surface catalogs intended for external readers
  • public glossary entries
  • operator introductions cleared for release

Public release is staged. A page marked public in frontmatter is not automatically deployed publicly until the publication workflow and deployment mechanism support it.

Status classes

draft

The page is incomplete, exploratory, or not yet reviewed. Draft pages should not be treated as final authority.

active

The page is usable for current work but may still evolve. Active pages should be accurate about current system behavior and source-of-truth limits.

canonical

The page defines durable system truth or authoritative architecture. Canonical pages must stay aligned to the saved source architecture and must not drift through casual edits.

planned

The page describes intended architecture, a planned namespace, or future work. Planned pages must not imply live runtime behavior.

archived

The page preserves historical context. Archived pages should not govern current decisions unless explicitly referenced by a current canonical page.

Implementation-state classes

conceptual

The idea or architecture exists conceptually, but no live runtime behavior is claimed.

assigned

The namespace, module, or role has a defined architectural assignment, but implementation may not exist.

partially_implemented

Some relevant runtime behavior or documentation support exists, but the full domain-aligned product, surface, or module is not live.

live

The behavior is active as a public or operational system behavior backed by real implementation.

What it does not govern

  • It does not publish pages by itself.
  • It does not grant runtime authority.
  • It does not replace source-of-truth runtime records.
  • It does not convert conceptual architecture into live implementation.
  • It does not override the canonical domain architecture or execution spine.

Relationships to other layers

This policy supports the publication workflow and docs governance standards. It also protects the canonical architecture pages from implementation drift.

The policy should be read against the execution spine, canonical namespace spine, and domain architecture strategy.

Current status

Active documentation governance standard. The frontmatter schema validates allowed visibility, status, and implementation_state values, but no public filtering or auth mechanism is implemented yet.

Future direction

When public publishing is implemented, visibility classes should become build or deployment inputs. Until then, visibility is governance metadata and editorial discipline.

Guardrails

  • Do not treat public as automatic deployment.
  • Do not treat canonical as live implementation.
  • Do not treat live as public-safe.
  • Do not mark a page partner or public without review.
  • Do not describe conceptual, assigned, or partially_implemented architecture as live.
  • Do not publish private source-of-truth architecture accidentally.