standard · v0.01

Docs Governance

Contributor guidance for writing and maintaining wiki.x1 documentation without drifting from QTM OS architecture.

private active assigned qtm-os

Docs Governance

Purpose

Define how future contributors should write and maintain pages in wiki.x1.

The goal is disciplined knowledge governance: precise architecture, truthful implementation status, private-first publication posture, and no drift from canonical QTM OS source material.

Architectural role

Docs governance protects wiki.x1 from becoming marketing copy, speculative architecture, or stale implementation lore.

A page should help a reader understand what exists, what is assigned, what is conceptual, what is partially implemented, and what is live.

Required frontmatter

Every docs page must include frontmatter compatible with the content schema:

title: "Page Title"
slug: "/section/page-slug"
description: "Short description of the page."
visibility: "private"
status: "draft"
implementation_state: "conceptual"
version: "v0.01"
layer: "architecture"
domain: "qtm-os"
tags: ["qtm-os"]
last_updated: "2026-04-20"

Allowed visibility values:

  • private
  • internal
  • partner
  • public

Allowed status values:

  • draft
  • active
  • canonical
  • planned
  • archived

Allowed implementation_state values:

  • conceptual
  • assigned
  • partially_implemented
  • live

Required section structure

Most pages should keep the wiki page structure unless there is a strong reason not to:

  • Purpose
  • Architectural role
  • What it governs
  • What it does not govern
  • Relationships to other layers
  • Current status
  • Future direction
  • Guardrails
  • Related pages

This structure keeps pages comparable and makes boundaries easier to audit.

Status discipline

Use status to describe document authority, not implementation.

  • draft: unfinished or exploratory
  • active: useful for current work
  • canonical: authoritative system truth
  • planned: intended direction or future work
  • archived: historical context

Do not mark a page canonical unless it is aligned to a durable source of truth.

Implementation-state discipline

Use implementation_state to describe runtime or system realization, not how polished the doc feels.

  • conceptual: idea or architecture exists but no live behavior is claimed
  • assigned: architectural role is assigned but implementation may not exist
  • partially_implemented: some relevant implementation exists, but the full surface/module/domain is not live
  • live: active behavior exists and is backed by real implementation

Do not describe a namespace as live because the domain is owned. Ownership is not implementation.

Source-of-truth discipline

Canonical pages must be aligned to their saved source material.

For domain architecture and namespace strategy, the current source of truth is the saved Planck architecture document:

DOMAIN_ARCHITECTURE_AND_NAMESPACE_STRATEGY_v0.04.md

When source material changes, update the corresponding wiki page deliberately. Do not rewrite canonical terms into looser language if the wording carries architectural meaning.

No-drift rules

Future edits must preserve these core invariants:

  • os.x1 remains the master system shell
  • canonical namespace spine remains os.x1 → membership.x1 → ip.x1 → assets.x1 → acquisition.x1
  • assets.x1 remains the canonical asset namespace; do not introduce assets.xen
  • operator.x1 remains the canonical executable actor
  • jobs.xen remains governed live work availability and assignment, not a detached job board
  • task state does not replace job state
  • ServiceEvent completion does not equal settlement capture
  • settlement remains separate from execution completion and record truth
  • Omni remains advisory/non-executing unless implementation changes explicitly and truthfully

Writing standards

  • Prefer precise system language over broad product language.
  • Keep QTM architecture terminology consistent.
  • Distinguish public naming from internal runtime behavior.
  • Mark future direction as future direction.
  • Use examples only when they clarify architecture.
  • Avoid claims such as live, automated, public, enforced, or governed unless the system actually supports them.

What it governs

  • Contributor expectations for wiki.x1 pages
  • Frontmatter completeness
  • Status and implementation-state discipline
  • Source alignment for canonical pages
  • Guardrails against invented runtime capability

What it does not govern

  • It does not change runtime behavior.
  • It does not publish pages.
  • It does not replace canonical architecture pages.
  • It does not authorize new modules, surfaces, or namespaces.

Relationships to other layers

Docs governance works with visibility policy and publication workflow. It protects canonical architecture pages, constitutional pages, and future public docs from semantic drift.

Current status

Active contributor guidance for wiki.x1. It describes editorial and governance process only.

Future direction

As the wiki matures, this page may reference review roles, source-sync checks, publication gates, or automated validation. Those should only be added when the workflow exists.

Guardrails

  • Do not invent implementation reality.
  • Do not paraphrase away architectural specificity.
  • Do not collapse conceptual, assigned, partially_implemented, and live.
  • Do not flatten governance, execution, record, and settlement layers.
  • Do not let public readability weaken system truth.