System Status
What this wiki is
wiki.x1 is the knowledge and doctrine layer for QTM OS. It documents the architecture, execution rules, domain namespaces, and design principles of an evolving governed operating system for service-based work.
This wiki is not the runtime system itself. A page existing here does not mean the described system behavior is live. The wiki documents what is running, what is being built, what is planned, and what is long-term architecture direction — and it distinguishes between all of these.
How to read page status
Every page in this wiki carries status labels in its header. Here is what each label means:
| Status | Meaning |
|---|---|
| Live | Active behavior exists and is backed by a real running implementation. |
| In Development | Some implementation exists; the full described scope is not yet active. |
| Planned | The architectural role is defined; implementation does not yet exist. |
| Conceptual | Architecture or idea exists as design; no live behavior is claimed. |
| Doctrine | A constitutional rule, system principle, or operating belief. May or may not have corresponding live implementation. |
| Deprecated | Historical context only. Does not govern current decisions. |
| Architecture Thesis | Long-term intended direction. Not a current product claim. |
These labels are separate from the page’s visibility level (private, internal, partner, public) and its document authority (draft, active, canonical, planned, archived). A canonical page can describe a conceptual system. A live runtime feature can still have incomplete documentation.
What is live
The following components have working pilot implementations.
Oracle intake system Admin-authenticated intake layer. Captures service requests, structures them into governed job packets, and routes them into Planck. Deployed on Cloudflare Pages with a D1 database. Admin-only access at this time.
Planck pilot runtime The deployed execution engine for QTM OS runtime validation. Handles the flow from request intake through task governance, job creation, operator-side execution, ServiceEvent management, record composition, and trust signal emission. Deployed on Cloudflare Pages Functions with R2 storage.
Admin Governance Desk The administrative control plane for task review, operator lifecycle management, access state management, and system health visibility. Includes the Omni advisory panel in read-only, observation mode. Pilot implementation running inside Planck.
Core surfaces in pilot state Several service surface types — including auto-detailing and others — are in active pilot use. Evidence requirements are enforced at the surface level. Surface depth and coverage vary.
What is in development
The following components have partial implementation but are not fully active across their intended scope.
Operator-facing surfaces Surface runtime configurations are defined and evidence requirements are enforced. Surface coverage and depth are partial. Not all documented surfaces are in active pilot use.
Omni intelligence layer Omni can observe system state — tasks, jobs, service events, records, access states — and present summaries to administrators. This observe-and-report behavior is partially implemented inside the Admin Desk. Agent coordination features (sub-agent orchestration, Decision Packets) are assigned architecture but are not yet live.
⭐.x1 trust signal
The execution-derived trust signal schema is defined at SIGNAL_STAR_v0.01. Signal emission after record completion is partially implemented in the Planck runtime. Broader routing eligibility, discovery display, and suppression or revocation workflows are planned but not yet built.
What is planned architecture
The following components have defined architectural roles but no working implementation yet.
mls.x1 — listing and discovery layer Governed listing, discovery, and intake-conversion namespace. Schema defined. No live listings, discovery surface, or intake-conversion flow implemented.
Settlement module Economic closure layer that governs payment capture eligibility, settlement state, and payout flows. The distinction between execution completion and settlement capture is a core system invariant. The settlement module itself is a placeholder — no live settlement logic is implemented.
Billing module Subscription visibility and payment state layer. Placeholder architecture. No live billing logic implemented.
Workforce namespace cluster hiring.x1, talent.x1, casting.x1, and hr.x1 are defined architectural namespaces with documented roles. None have working implementations. They govern the intended path from workforce entry through capability representation, role selection, and operator activation.
Operator identity and commerce layers shop.xen (operator commerce), membership.x1 (access and entitlement at scale), and related operator participation layers are defined but not implemented.
POS layer / Universal Payment Router A point-of-sale and payment routing architecture layer is in the planned domain stack. Its intended role is to route, accept, normalize, and record multiple payment methods and currencies, connected to ServiceEvent and settlement records. No working implementation exists. This is planned architecture only.
What is architecture thesis
The following concepts appear in the wiki’s architectural documentation as intended long-term direction. They describe where the system is designed to go. They are not current product claims.
Full economic coordination stack The wiki documents how assets.x1, acquisition.x1, ip.x1, and related namespaces could form a governed economic coordination system over time — governing access, rights, value objects, transfer, and settlement as a closed-loop system. This describes the intended architecture, not current functionality. None of these namespaces have live economic infrastructure.
Tokenized namespace primitives Several namespaces are classified as potential future tokenized control or rights primitives (os.x1, membership.x1, ip.x1, assets.x1, acquisition.x1). This is an architectural classification for future design possibility. No tokenization has been implemented. These are not active economic instruments of any kind.
Treasury, payment rail, and escrow namespaces treasury.xen, payments.xen, and escrow.xen are reserved namespaces in the architecture. Their intended future roles are treasury accounting, settlement rail orchestration, and conditional transfer release respectively. None have been implemented. No financial infrastructure exists behind these names.
Multi-agent infrastructure agents.xen is a reserved namespace intended to govern agent registry, role taxonomy, runtime identity, and lifecycle state for a future multi-agent layer. It is not implemented. Omni sub-agent coordination (CEO agent, COO agent) is assigned architecture and is not live.
Important financial, legal, and public interpretation notice
Nothing in this wiki should be interpreted as any of the following:
- a live financial product or service
- a payment processing system or payment rail
- a bank, custodian, or regulated financial institution
- an escrow service
- a securities offering of any kind
- an investment product, fund, or pooled capital vehicle
- an offer to manage public or private capital on behalf of others
- a live cryptocurrency, digital asset, or token system
- a regulated money services business
The economic, settlement, treasury, escrow, and tokenized namespace concepts described in this wiki are architectural reservations and design documentation only. Implementing any of these as live financial infrastructure would require explicit legal, regulatory, and governance steps that have not occurred and are not implied by the existence of this documentation.
QTM OS is an operating system for governed service-based work. Its payment and settlement concepts describe how execution evidence should connect to economic settlement — not a standalone financial infrastructure product.