wiki.x1
Purpose
wiki.x1 is the Knowledge Layer for QTM OS: the private-first documentation and knowledge-governance system for constitutional docs, architecture docs, domains, surfaces, modules, standards, changelogs, and future public documentation.
This wiki exists to preserve architectural truth. It should help a reader understand what is canonical, what is draft, what is conceptual, what is assigned, what is partially implemented, and what is live without inventing implementation reality.
Start here
If you are orienting yourself in QTM OS, start with these pages:
- Execution Spine: the frozen execution boundary across Request, Task, Assignment, Job, ServiceEvent, Record, and Settlement.
- Canonical Namespace Spine: the constitutional namespace sequence os.x1 -> membership.x1 -> ip.x1 -> assets.x1 -> acquisition.x1.
- Domain Architecture and Namespace Strategy: the canonical v0.04 source-aligned map of QTM domains and namespace roles.
- Workforce Namespace Cluster: the distinction between hiring.x1, talent.x1, casting.x1, hr.x1, operator.x1, and jobs.xen.
- Economic Structure Layer: the relationship between records, rights, assets.x1, transfer, settlement, and operator commerce.
- Visibility and Status Policy: how to read page visibility, document status, and implementation state.
- Docs Governance: how future pages should be written without drifting from canonical architecture.
Architectural role
wiki.x1 stands outside Planck execution code. It documents QTM OS; it does not operate QTM OS.
The wiki is intentionally private-first. Public documentation may later be derived from selected pages, but public release is a staged governance act, not a side effect of writing or polishing a page.
How the wiki is organized
Use the sidebar as the main map.
| Section | Role |
|---|---|
| Constitution | Invariant system rules: execution spine, namespace spine, runtime truth, governance rules, and system boundaries. |
| Architecture | Canonical architecture specs for domains, modules, surfaces, records, ServiceEvents, access, governance, workforce, and economics. |
| Domains | Namespace pages for qtm.x1, os.x1, wiki.x1, planck.x1, omni.x1, operator.x1, workflow.x1, jobs.xen, shop.xen, and related domains. |
| Surfaces | Surface-specific documentation for current and future operating surfaces. |
| Modules | Module-level docs for Omni, Desk, Operator, Workflow, Jobs, Access, Billing, Settlement, Commerce, Identity, Registry, and Audit. |
| Operators | Operator onboarding, activation, access state, desk behavior, job lifecycle, evidence expectations, records, and history. |
| Workforce | hiring.x1, talent.x1, casting.x1, hr.x1, operator transition, and jobs.xen workforce context. |
| Standards | Naming, event classes, economic objects, record-linked asset rules, visibility/status policy, publication workflow, docs governance, and domain governance. |
| Public | Staged public-documentation candidates and public-facing summaries. |
| Changelog | Versioned architecture deltas and release notes. |
| Glossary | Canonical vocabulary and system terms. |
How to read a page
Each page carries frontmatter that tells you how much authority and implementation reality it claims.
Visibility
- private: default working knowledge; not intended for outside release.
- internal: usable inside QTM operating contexts after internal review.
- partner: shareable with selected partners after scope, confidentiality, and implementation-truth review.
- public: intentionally prepared for public release.
Public visibility is not automatic publication. A page marked public still requires the publication workflow and a future publishing mechanism before it becomes externally available.
Document status
- draft: unfinished, exploratory, or not yet reviewed.
- active: usable for current work but still evolving.
- canonical: durable system truth or authoritative architecture.
- planned: intended direction or future work.
- archived: historical context, not current authority unless referenced by a current canonical page.
Implementation state
- conceptual: architecture or idea exists, but no live behavior is claimed.
- assigned: architectural role is defined, but implementation may not exist.
- partially_implemented: some relevant implementation exists, but the full domain, surface, or module is not live.
- live: active behavior exists and is backed by real implementation.
Document status and implementation state are separate. A canonical page can describe a conceptual namespace. A live runtime feature can still need documentation cleanup. Do not collapse these fields.
Canonical docs vs reference docs
Canonical docs define durable system truth and must stay aligned to saved source architecture. Reference docs explain, summarize, or support work, but they do not override canonical pages.
For domain and namespace strategy, the current source of truth is:
DOMAIN_ARCHITECTURE_AND_NAMESPACE_STRATEGY_v0.04.md
The corresponding wiki page is Domain Architecture and Namespace Strategy.
What it governs
- QTM OS constitutional documentation
- Domain and namespace strategy
- Surface and module documentation
- Operator, workforce, standards, and glossary references
- Visibility and publication readiness for future public docs
- Documentation governance for canonical and non-canonical pages
What it does not govern
- It does not execute jobs.
- It does not mutate QTM OS runtime records.
- It does not replace Planck, qtm-core, or qtm-os repositories.
- It does not make planned, assigned, or partially implemented systems live.
- It does not authorize public release by itself.
Current status
Private-first knowledge system scaffold with canonical architecture pages aligned to QTM OS v0.04 source material. Build-time public filtering and authentication are not implemented yet.
Future direction
Selected pages may later be prepared for public release through visibility review, publication workflow, and a build or deployment mechanism that filters public content intentionally.
Guardrails
- Do not treat documentation as runtime truth.
- Do not mark planned layers as live.
- Do not paraphrase away architectural specificity.
- Do not invent capabilities that do not exist.
- Preserve conceptual, assigned, partially_implemented, and live distinctions.
- Preserve canonical architecture terms exactly where they carry system meaning.
- Keep private-first posture until publication tooling and review process exist.