index.x1

Architectural meaning

index.x1 is the canonical registry, resolver, and mapping namespace for QTM OS. It records where namespaces live, where surfaces route, what operators or modules own a path, and what identifier resolves to which record, spec, or runtime object.

wiki.x1 defines what things mean. index.x1 resolves where things live.

What index.x1 is

index.x1 is a resolution layer. It does not carry semantic definitions. It holds and serves the mapping between identifiers, paths, owners, and system locations so that humans and agents can discover the correct system object without consulting execution-layer state.

The namespace is private-first in this repo. Resolution entries may be derived from reviewed index.x1 pages, but publication and runtime promotion remain deliberate acts, not side effects of writing a page.

Primary functions

  • Maintain the canonical mapping from namespace identifiers to system locations
  • Record which operator or module owns a given path or domain
  • Resolve where a surface routes within the QTM OS runtime model
  • Point identifiers to their corresponding record, spec, or runtime object
  • Provide a stable lookup interface for both human readers and agent processes

What it governs

  • Namespace-to-location mappings
  • Surface routing records
  • Domain and path ownership assignments
  • Identifier-to-object resolution entries
  • Discovery interface for QTM OS system objects

What it does not govern

  • It does not define what a namespace means. That is wiki.x1.
  • It does not execute jobs or coordinate work. That is planck.x1.
  • It does not advise or interpret. That is omni.x1.
  • It does not mutate runtime state.
  • It does not replace or override records held in execution-layer namespaces.
  • It does not make draft or planned systems live.

Relationship to wiki.x1

wiki.x1 carries definitions, architectural intent, and system knowledge. index.x1 carries mappings, locations, and resolution records.

Reading a wiki.x1 page tells you what a namespace is and how to interpret it. Reading an index.x1 entry tells you where that namespace lives and what it points to.

These two layers are complementary and non-overlapping. Neither replaces the other.

Relationship to other namespaces

NamespaceRelationship
wiki.x1Defines meaning; index.x1 resolves location — the two layers do not overlap
planck.x1Runtime execution layer whose paths index.x1 may map
omni.x1Advisory layer that may query index.x1 for resolution
operator.x1Operator namespace whose path and domain ownership index.x1 tracks
desk.x1Command surface whose routing records index.x1 may carry
workflow.x1Process namespace whose paths index.x1 may reference

Example uses

  • Resolving which operator or module owns a specific domain or surface path
  • Looking up the canonical location of a record type within the runtime model
  • Determining where a surface routes before executing a workflow
  • Providing an agent with a stable, authoritative lookup for a system identifier
  • Auditing path and domain ownership across QTM OS namespaces

Current status

Active namespace page in the Domains sidebar at /domains/index-x1. The page records architectural intent for index.x1; the resolution and registry runtime remains governed future work.

Guardrails

  • index.x1 records where things are, not what they mean.
  • Do not introduce semantic definitions here; those belong in wiki.x1.
  • Preserve the distinction between planned, partial, and live.
  • Avoid speculative implementation claims.
  • Keep identifiers, paths, and ownership records precise.