QTM OS — Domain Architecture and Namespace Strategy v0.04

Purpose

Define the structural role of QTM Network domains so the ecosystem grows as a coherent operating, intelligence, indexing, governance, identity, operator, workflow, workforce, rights, assets, transfer, and agent network rather than a scattered collection of apps, brands, undeployed names, and disconnected narratives.

This strategy exists to ensure:

• primary domains have clear and durable roles
• namespace expansion does not create architectural drift
• product, protocol, data, index, operator, workflow, workforce, intelligence, rights, asset, transfer, and agent layers remain distinct
• public-facing domains and internal-use domains are intentionally separated
• future verticals can be added without renaming the entire system
• domain ownership compounds into architectural clarity rather than brand chaos
• newly acquired strategic namespaces are classified by real architectural function
• naming remains subordinate to canonical runtime truth and governance

This is not a marketing document.
It is a system-architecture document for namespace governance.

Core Principle

A domain is not just a URL.

Inside QTM, a domain is a namespace anchor for one of the following:

• umbrella network identity
• operating environment
• desk/workspace layer
• operator identity and participation layer
• workflow and process logic layer
• intelligence and orchestration layer
• agent infrastructure layer
• index and publication layer
• governance and protocol layer
• identity, credentials, and directory layer
• vertical surface layer
• participation and value-rail layer
• access and entitlement layer
• rights and licensing layer
• asset and value-object layer
• transfer and expansion layer
• research/media/community layer
• workforce entry, capability, selection, and execution layer
• reserve/experimental layer

Therefore:

• not every owned domain should become a standalone product
• each primary domain should have one dominant architectural purpose
• secondary uses must not conflict with the primary role
• domains should be assigned by system function first, branding second
• ownership of a domain does not imply that the corresponding module is implemented
• a namespace may function as a brand anchor, product entry point, governed namespace, or future tokenized control primitive, but it must be explicitly classified

Namespace Design Goals

The namespace strategy should optimize for:

1. Clarity

Users, partners, operators, and future institutions should understand what each major domain is for.

2. Layer separation

Operating, identity, workflow, workforce, agent, data, intelligence, governance, index, access, rights, asset, and transfer layers should not collapse into one namespace unless intentionally designed.

3. Expandability

New surfaces and verticals should be able to plug in without forcing a rebrand.

4. Governance

Data, index, trust, operator, workflow, workforce, rights, asset, transfer, and agent layers should have distinct homes.

5. Durability

The namespace should still make sense when QTM expands beyond freight into broader economic surfaces.

6. Reality discipline

The document must distinguish between:

• owned strategic namespaces
• architectural intent
• current implementation reality
• future module or surface direction

Namespace Classification Model

Every primary domain should be classified as one or more of the following:

1. Brand anchor

A domain that serves as a durable public-facing system or product identity.

2. Product entry point

A domain that acts as the front door for a specific product, layer, or participant class.

3. Governed namespace

A domain that maps to a real architectural role inside QTM OS and is expected to remain subordinate to runtime truth, policy, records, and canonical state.

4. Future tokenized control or rights primitive

A domain that may later function as a tokenized, registrable, transferable, or rights-bearing namespace object, but should not be treated as fully active economic infrastructure until implemented through governed system logic.

A domain may serve more than one of these roles, but one role must remain dominant.

Canonical Namespace Spine

QTM OS now recognizes a canonical namespace spine for system-level expansion and economic coordination.

This spine does not replace the broader layer model.
It provides a higher-order coordination sequence across system identity, access, rights, value, and transfer.

Canonical sequence

OS → Access → Rights → Assets → Transfer

This sequence represents:

• the system
• who can enter
• what rights they can use
• what value is governed
• how ownership or control can move

These namespaces are strategic architectural anchors and naming primitives.
Ownership does not imply full implementation.
Implementation must remain governed by the existing execution spine, module readiness, policy rules, and documented system reality.

os.x1

Role

Master system namespace.

Purpose

Top-level system identity, coordination layer, and parent namespace for product and economic logic.

Architectural meaning

os.x1 answers what system the participant is inside.

Classification

• brand anchor
• governed namespace
• future tokenized control primitive

membership.x1

Role

Access and entitlement namespace.

Purpose

Govern membership levels, participation classes, privileges, gated surfaces, feature access, premium intelligence access, and future governance or partner eligibility.

Architectural meaning

membership.x1 answers who is allowed to be what inside the ecosystem.

Classification

• product entry point
• governed namespace
• future rights/control primitive

ip.x1

Role

Rights and licensing namespace.

Purpose

Govern licensing, protected methods, templates, knowledge access, branded frameworks, playbooks, educational rights, and future royalty or rights-distribution logic.

Architectural meaning

ip.x1 answers who owns knowledge and who is allowed to use it.

Classification

• product entry point
• governed namespace
• future tokenized rights primitive

assets.x1

Role

Asset registry and value namespace.

Purpose

Govern digital and physical asset registration, ownership state, asset visibility, treasury mapping, record-linked assets, and future tokenized asset structures.

Architectural meaning

assets.x1 answers what is valuable, what exists as a recognized economic object, and who controls it.

Classification

• product entry point
• governed namespace
• future tokenized value primitive

acquisition.x1

Role

Transfer, expansion, and deal-flow namespace.

Purpose

Govern acquisition workflows, operator transfer, rights transfer, asset transfer, succession logic, regional expansion, and strategic opportunity routing.

Architectural meaning

acquisition.x1 answers how value, ownership, rights, and control move through the system.

Classification

• product entry point
• governed namespace
• future tokenized transfer/control primitive

Relationship Between Canonical Spine and Broader QTM Layers

The canonical namespace spine does not eliminate the larger architectural map.

Instead:

• os.x1 sits above and across the larger QTM namespace model as the umbrella system shell
• membership.x1, ip.x1, assets.x1, and acquisition.x1 formalize the economic and participation backbone inside the broader architecture
• existing domains such as qtm.x1, planck.x1, desk.x1, operator.x1, workflow.x1, omni.x1, and governance.x1 remain necessary and distinct

The spine should be understood as a cross-layer constitutional sequence, not as a complete replacement for the full namespace stack.

Namespace Layer Model

The domain stack should be organized into ten layers.

Layer 1

Umbrella / Master Network Layer

Layer 2

Operating and Desk Layer

Layer 3

Operator Layer

Layer 4

Workflow Layer

Layer 5

Intelligence and Orchestration Layer

Layer 6

Agent Infrastructure Layer

Layer 7

Index and Publication Layer

Layer 8

Governance, Identity, Directory, and Credentials Layer

Layer 9

Vertical and Industry Layer

Layer 10

Participation, Value Rail, Economic Structure, Commerce, and Reserve Layer

Layer 1

Umbrella / Master Network Layer

Purpose

Provide the top-level identity and routing anchor for the entire QTM ecosystem.

Primary domains

qtm.x1

os.x1

qtm.x1

Role

Master network and ecosystem namespace.

Responsibilities

• primary entry into QTM Network
• top-level routing to surfaces, products, and layers
• system-wide identity anchor
• parent namespace for network and ecosystem logic

Best use examples

• qtm.x1
• qtm.x1/network
• qtm.x1/surfaces
• qtm.x1/enterprise
• qtm.x1/about

Guardrails

• do not overload qtm.x1 with every sub-product directly
• qtm.x1 should remain the umbrella, not the only namespace

os.x1

Role

Master operating-system namespace.

Responsibilities

• system-layer shell for QTM OS
• parent namespace for operating logic, access logic, rights logic, asset logic, and transfer logic
• constitutional coordination anchor for the canonical namespace spine
• umbrella system identity where appropriate

Guardrails

• os.x1 should not be treated as a justification to collapse all domains into one front end
• os.x1 defines the system shell, not every product implementation path
• os.x1 should remain aligned with actual operating-system architecture, not become a vague slogan container

Layer 2

Operating and Desk Layer

Purpose

Provide namespaces for active workflow environments, desks, and commercial execution surfaces.

Primary domains

desk.x1

planck.x1

operations.x1

desk.x1

Role

Universal desk-layer namespace for governed operator-facing workspaces.

Responsibilities

• host desk-class experiences
• support operator, admin, executive, claims, review, and vertical desks
• establish desk as a reusable architectural object

Best use examples

• desk.x1/freight
• desk.x1/admin
• desk.x1/executive
• desk.x1/claims
• desk.x1/review

Guardrails

• desk.x1 is for workflow environments, not broad public marketing pages

planck.x1

Role

Commercial/operator deployment layer for live service and vertical execution.

Responsibilities

• operator-facing rollout layer
• branded deployment environment for commercial surfaces
• service/operator execution wrapper where appropriate

Best use examples

• planck.x1/operators
• planck.x1/surfaces
• planck.x1/intake
• planck.x1/network

Guardrails

• Planck should remain distinct if it continues as the market-facing service/operator layer
• do not let it absorb the full QTM constitutional, index, or core identity role

operations.x1

Role

Operational control and workflow logic namespace.

Responsibilities

• internal or role-specific operational environments
• queue, workflow, state, and process-oriented experiences
• operational control plane views later if needed

Guardrails

• reserve for internal or advanced operator use unless a public need becomes clear

Layer 3

Operator Layer

Purpose

Provide the canonical namespace for operator identity, onboarding, activation, participation class, and executable actor status inside QTM OS. operator.x1 is the authoritative answer to who is acting in the system.

Primary domain

operator.x1

Role

Primary operator identity, activation, and executable participation namespace.

operator.x1 defines the canonical actor capable of taking on assigned work, claiming jobs, and executing within the governed workflow. It is the terminal state in the workforce entry sequence and the persistent identity throughout the execution spine.

Responsibilities

• operator onboarding
• operator activation state
• operator profile pages
• operator role/type classification
• operator participation across surfaces
• operator status and readiness
• operator-linked credentials and verification hooks
• canonical executable actor identity in the system
• future operator economy participation
• operator access state across the network

Best use examples

• operator.x1/join
• operator.x1/profile/[slug]
• operator.x1/activate
• operator.x1/network
• operator.x1/status
• operator.x1/credentials

Guardrails

• operator.x1 should represent the acting participant, not the workspace itself
• do not overload operator.x1 with desk workflow pages that belong under desk.x1
• operator.x1 should answer who is acting, not where they act
• operator.x1 is not the recruiting or hiring namespace — hiring.x1 governs workforce entry
• operator.x1 is not the talent representation namespace — talent.x1 governs capability legibility
• operator.x1 is not the work availability namespace — jobs.xen governs live work
• operator activation is the terminal step in workforce entry, not the beginning of it

Distinction from workforce-adjacent domains

operator.x1 is not weakened or replaced by the workforce namespace cluster. It is the governing identity through which all workforce entry ultimately resolves before live execution begins.

Layer 4

Workflow Layer

Purpose

Provide the canonical namespace for workflow logic, state models, process templates, automations, and execution flows across QTM surfaces.

Primary domain

workflow.x1

Role

Primary workflow-state, process, automation, and execution-logic namespace.

Responsibilities

• workflow templates
• state models
• intake → job → service event → record flow definitions
• approval chains
• escalation logic
• automation rules
• reusable workflow packs by surface
• workflow runtime logic and visual maps
• process-specific operating documentation

Best use examples

• workflow.x1/templates
• workflow.x1/states
• workflow.x1/approvals
• workflow.x1/automations
• workflow.x1/runtime
• workflow.x1/freight

Guardrails

• workflow.x1 should govern process models and flow definitions
• it should not become a generic project-management front end unless explicitly workflow-centric
• workflow.x1 should answer how work moves, not who performs it or where it is worked

Workforce Entry, Capability, Selection, and Execution Architecture

Cross-Layer Workforce Namespace

Position in layer model

This section defines domains that span Layers 3 and 4 (Operator and Workflow) and connect upstream entry flows to downstream execution. These domains do not replace any existing layer. They extend the architecture to govern the workforce pipeline — from the moment someone enters the network, through capability assessment and role selection, to live work execution.

jobs.xen

Role

Governed work and execution namespace.

Responsibilities

• public and internal job discovery
• work intake
• operator-visible work access
• assignment and routing into the execution spine
• claimable work where allowed
• proof-backed job progression
• future payout and settlement visibility
• job-linked participation and work-state visibility

Architectural meaning

jobs.xen governs live work once an eligible actor is admitted into the system. It sits downstream of workforce entry and upstream of record and settlement layers. jobs.xen is not a job board detached from the execution spine — it is the work availability and assignment layer within the governed network.

Position in the execution chain

operator.x1 (actor identity) → jobs.xen (live work) → workflow.x1 (process state) → ServiceEvent → Record → Settlement

Guardrails

• do not position jobs.xen as a generic job board detached from execution truth
• jobs.xen must remain compatible with assignment, workflow state, evidence, settlement, and record logic
• jobs.xen should extend execution, not replace operator identity or desk/workspace logic
• jobs.xen is the live work layer; desk.x1 is where that work is performed — do not collapse these

hiring.x1

Role

Workforce entry and recruiting namespace.

Responsibilities

• applicant intake
• recruiting funnels
• join flows
• workforce acquisition campaigns
• intake for operators, technicians, contractors, or specialists
• pre-approval pipeline into the network

Architectural meaning

hiring.x1 governs entry into the workforce side of QTM OS. It exists upstream of operator activation and live execution. A person enters through hiring.x1 before they become a recognized operator.x1 actor.

Guardrails

• hiring.x1 should not be treated as the canonical operator record
• hiring.x1 governs admission, not execution identity
• do not let hiring.x1 absorb operator.x1 responsibilities after activation

talent.x1

Role

Capability and talent-representation namespace.

Responsibilities

• talent profiles
• skills representation
• proof of work
• portfolio-linked identity
• credential and capability visibility
• discoverability of qualified people

Architectural meaning

talent.x1 answers what a person can do and what evidence supports that claim. It is the capability legibility layer — the representation of demonstrated competence that other domains (casting.x1, hiring.x1, operator.x1) may reference.

Guardrails

• talent.x1 should not replace operator.x1
• talent.x1 is about capability legibility, not canonical execution identity
• a rich talent profile does not confer execution authority — that requires operator activation

casting.x1

Role

Role-fit and selection namespace.

Responsibilities

• brief-based matching
• shortlisting
• fit-based candidate selection
• campaign, event, media, staffing, or role-specific selection
• role-to-person matching before activation into work

Architectural meaning

casting.x1 selects for a specific role or opportunity. It sits between capability visibility and live work assignment when a fit-matching step is architecturally meaningful — particularly for engagements where role specificity, creative fit, or brief-based selection is required before a person is admitted to work.

Guardrails

• casting.x1 is not the general hiring layer — use hiring.x1 for broad workforce entry
• casting.x1 is not the canonical work namespace — use jobs.xen for live work
• use casting.x1 only where role-fit selection is architecturally meaningful
• casting.x1 results in selection, not automatic execution authority

hr.x1

Role

Internal workforce governance and administration namespace.

Responsibilities

• workforce admin state
• onboarding completion tracking
• permissions and readiness review
• compliance and internal people operations
• workforce status administration
• internal records later where appropriate

Architectural meaning

hr.x1 governs internal people-state administration after entry and before or alongside active execution. It operates alongside the workforce sequence without owning any of the public-facing entry or live work layers.

Guardrails

• hr.x1 should remain mostly internal
• do not let hr.x1 replace operator.x1 as the canonical system actor identity
• do not overload hr.x1 as the public-facing recruiting domain — that is hiring.x1
• hr.x1 governs workforce administration state, not execution authority

Canonical Workforce Flow

The governed sequence from workforce entry to live execution:

hiring.x1 → talent.x1 → casting.x1 (when role-fit selection is needed) → operator.x1 → jobs.xen

Decoded:

• hiring.x1 — a person or entity enters the workforce pipeline through a recruiting or join flow
• talent.x1 — their capability, proof, and portfolio are represented and discoverable
• casting.x1 — when a specific role or brief requires fit-based selection, casting.x1 produces a shortlist
• operator.x1 — the selected and activated participant becomes a recognized executable actor in QTM OS
• jobs.xen — the activated operator accesses live work, claims assigned jobs, and enters the execution spine

Within the execution spine

Once a job is live, the flow continues:

jobs.xen → workflow.x1 (process state) → ServiceEvent → Record → Settlement

Supporting layers

Throughout this sequence:

• hr.x1 governs internal readiness, admin state, and compliance alongside every stage
• desk.x1 provides the workspace environment where active work is performed
• workflow.x1 defines how work moves through state transitions
• credentials.x1 provides verification hooks at capability and activation stages
• operator.x1 remains the canonical actor identity throughout — it does not dissolve into any downstream work layer

Bypass rule

No domain in the workforce sequence may grant execution authority directly. A person with a talent.x1 profile or a casting.x1 selection still requires operator.x1 activation before accessing jobs.xen or the execution spine.

Core Namespace Distinctions

A quick-reference summary of what each primary namespace answers.

These distinctions are not aspirational — they are the governing design intent for namespace assignment across QTM OS. When a new feature or surface is being designed, the correct namespace is the one whose question the feature answers.

Layer 5

Intelligence and Orchestration Layer

Purpose

Provide namespaces for AI assistance, orchestration, analysis, and premium intelligence systems.

Primary domains

omni.x1

intelligence.x1

insight.x1

research.x1

omni.x1

Role

Primary intelligence and orchestration namespace.

Responsibilities

• agent-facing orchestration experience
• recommendations
• summarization
• workflow intelligence
• cross-surface AI interaction
• executive and operator intelligence support

Best use examples

• omni.x1
• omni.x1/desk
• omni.x1/briefings
• omni.x1/recommendations
• omni.x1/assist

Guardrails

• Omni should be the intelligence layer, not the raw data layer or public index layer
• Omni is the face of intelligence, not the entire agent substrate

intelligence.x1

Role

Premium intelligence product namespace.

Responsibilities

• higher-order intelligence dashboards
• premium analysis
• partner intelligence products
• intelligence subscriptions later

insight.x1

Role

Lighter-weight insight and executive-summary namespace.

Responsibilities

• executive summaries
• interpretive memos
• business insight outputs
• lighter-weight intelligence publications

research.x1

Role

Deep research and methodology publication namespace.

Responsibilities

• white papers
• methodology notes
• sector studies
• institutional research outputs
• deeper long-form intelligence work

Layer 6

Agent Infrastructure Layer

Purpose

Provide the governed multi-agent infrastructure namespace that powers agent identity, role taxonomy, runtime control, execution boundaries, and future multi-agent participation.

Primary domain

agents.xen

Role

Primary agent infrastructure namespace.

Responsibilities

• agent registry
• agent role taxonomy
• runtime identity
• policy and permissioning
• orchestration primitives
• audit and execution boundaries
• agent lifecycle state
• future agent deployment, marketplace, or participation logic

Best use examples

• agents.xen/registry
• agents.xen/runtime
• agents.xen/policies
• agents.xen/roles
• agents.xen/logs
• agents.xen/deployments

Architectural distinction

• omni.x1 = the intelligence and orchestration experience
• agents.xen = the governed agent substrate beneath it

Guardrails

• agents.xen should not be positioned as a consumer-facing mascot brand
• agents.xen should govern many agents, not imply one monolithic assistant
• sensitive agent actions must still route through governance, workflow, desk state, and approval rules

Layer 7

Index and Publication Layer

Purpose

Provide a dedicated namespace for QTM Index and economic publication outputs.

Primary domain

index.x1

Role

Public or partner-facing index, sub-index, and methodology publication namespace.

Responsibilities

• headline QTM Index
• sector sub-indexes
• corridor and mode sub-indexes
• methodology summaries
• publication archives
• economic pulse dashboards
• confidence and coverage disclosures

Best use examples

• index.x1
• index.x1/methodology
• index.x1/sectors
• index.x1/corridors
• index.x1/publications

Guardrails

• index.x1 should publish index outputs, not host raw operational workflow
• it should be downstream of governed data and methodology, not a raw signal sandbox

Layer 8

Governance, Identity, Directory, and Credentials Layer

Purpose

Provide namespaces for the constitutional, policy, trust, identity, verification, registration, and discoverability logic of QTM Network.

Primary domains

governance.x1

credentials.x1

directory.x1

identity.xen

registrar.x1

standard.x1

audits.x1

contract.x1

governance.x1

Role

Primary governance, rights, policy, and network rules namespace.

Responsibilities

• data rights frameworks
• visibility rules
• publication protocols
• participant rights
• governance models
• access and policy documents

Best use examples

• governance.x1/data-rights
• governance.x1/visibility
• governance.x1/index-policy
• governance.x1/network-rules

credentials.x1

Role

Verifiable credentials and capability-proof namespace.

Responsibilities

• credentials
• certifications
• role proofs
• access-linked credentials
• future earned rights or status proofs

directory.x1

Role

Participant and network directory namespace.

Responsibilities

• operator discovery
• participant listings
• network topology views
• role directories
• vertical directories

identity.xen

Role

Future identity and trust infrastructure namespace.

Responsibilities

• identity graph
• trust-linked identities
• participant resolution
• verification architecture
• network identity systems

registrar.x1

Role

Registration and canonical record-entry namespace.

Responsibilities

• registration systems
• record issuance
• role registration
• asset/participant registration later

standard.x1

Role

Standards and specification publication namespace.

Responsibilities

• runtime specs
• event dictionaries
• classification specs
• protocol docs
• adapter contracts

audits.x1

Role

Auditability and verification namespace.

Responsibilities

• audit reports
• process verification
• record integrity outputs
• compliance summaries later

contract.x1

Role

Frameworks for rights, obligations, agreements, and machine-readable policy later.

Guardrails

• governance and identity domains should not be treated as generic marketing destinations
• legal and contract namespaces should not imply legal infrastructure beyond what actually exists

Layer 9

Vertical and Industry Layer

Purpose

Provide namespaces for industry-specific surfaces and sector expansion.

Primary domains

freight.x1

industry.x1

freight.x1

Role

Primary logistics and freight surface namespace.

Responsibilities

• Freight Broker Desk
• freight portals
• shipper/carrier/driver experiences
• logistics event and signal collection
• first major real-economy operating surface

Best use examples

• freight.x1
• freight.x1/shipper
• freight.x1/driver
• freight.x1/broker
• freight.x1/intake

industry.x1

Role

Sector and industry navigation namespace.

Responsibilities

• industry map
• NAICS-oriented sector views
• vertical navigation
• sector intelligence
• classification-linked exploration

Secondary vertical reserve examples

These are not core yet, but structurally valuable:

• contractor.x1
• events.x1
• booking.x1
• property.x1
• rental.x1
• clinic.x1
• retail.x1
• farms.x1
• aero.x1

Guardrails

• vertical domains should launch only when backed by real surface logic
• do not create standalone products just because the domain exists

Layer 10

Participation, Value Rail, Economic Structure, Commerce, and Reserve Layer

Purpose

Provide future-facing namespaces for contribution accounting, value accrual, settlement, commerce, graph/network infrastructure, and broader ecosystem participation. This layer also defines the economic structure primitives for access, rights, assets, transfer, settlement, operator-linked commerce, and trust across QTM OS.

Primary future-facing domains

qtm.xen

qtm.xnt

treasury.xen

payments.xen

credit.xen

escrow.xen

market.xen

shop.xen

graph.xen

nodes.xen

data.xen

membership.x1

ip.x1

assets.x1

acquisition.x1

qtm.xen

Role

Future native economic participation or utility namespace.

qtm.xnt

Role

Future network participation / access / native rail namespace.

treasury.xen

Role

Treasury and value management namespace.

payments.xen

Role

Settlement and payment rails namespace.

credit.xen

Role

Contribution credit or network credit namespace.

escrow.xen

Role

Conditional settlement and trusted release namespace.

market.xen

Role

Future market/exchange/discovery layer.

shop.xen

Role

Operator commerce and merchandise layer.

Responsibilities

• operator-linked storefronts
• built-in merchandise and product sales
• audience monetization
• branded commerce attached to operator identity
• optional commerce modules embedded into surface and operator pages
• product, order, payment, and fulfillment coordination later
• future commerce participation tied to QTM OS records and settlement

Architectural meaning

shop.xen is a governed commerce layer that can operate in multiple modes:

• as a standalone storefront namespace
• as an operator-attached commerce module
• as a network-linked commerce surface across QTM OS

It extends operator execution into operator commerce while also supporting public-facing storefronts.

Standalone storefronts must remain compatible with operator identity, records, fulfillment, and settlement.

This prevents shop.xen from becoming a detached or ungoverned marketplace while still allowing it to function as a public commerce entry point.

Guardrails

• shop.xen should not replace core service execution
• operator commerce should remain subordinate to operator identity, audience, and fulfillment logic
• initial implementation should prefer embedded operator storefronts over a generalized open marketplace

graph.xen

Role

Graph intelligence and relationship topology namespace.

nodes.xen

Role

Node/network infrastructure namespace.

data.xen

Role

Future data infrastructure, APIs, schemas, and technical data-governance layer.

Economic Structure Layer

Purpose

Provide explicit system primitives for economic participation, ownership, rights, value objects, transfer, settlement, operator commerce, and trust across QTM OS.

This layer answers:

• who is allowed to participate
• what they are allowed to use
• what they control
• how value changes hands
• how ownership and settlement affect future system state
• how operator execution can extend into governed commerce

Canonical Economic Stack

membership.x1

Role

Access and entitlement layer.

Responsibilities

• membership state
• participation tier
• access control
• entitlement gating
• network privileges
• feature and surface access
• future governance eligibility
• future partner or institutional participation classes

Architectural meaning

membership.x1 answers who is allowed to be what inside the ecosystem.

ip.x1

Role

Rights and knowledge-control layer.

Responsibilities

• IP registry
• licensing logic
• playbook and template rights
• usage permissions
• educational and knowledge access rights
• brand and method rights
• future royalty or rights-distribution logic

Architectural meaning

ip.x1 answers who owns knowledge and who is allowed to use it.

assets.x1

Role

Canonical asset and value-object layer.

Responsibilities

• asset registry
• value-object classification
• physical and digital asset representation
• ownership state
• record-linked assets
• operator-linked assets
• future collateral, treasury, or tokenized asset structures

Architectural meaning

assets.x1 answers what is valuable, what exists as an economic object, and who controls it.

acquisition.x1

Role

Transfer and expansion layer.

Responsibilities

• acquisition workflows
• transfer of ownership or control
• operator acquisition
• regional or territory expansion
• book-of-business transfer
• rights transfer
• asset transfer
• opportunity routing

Architectural meaning

acquisition.x1 answers how value, ownership, rights, and control move through the system.

Economic Support Stack

These are not the core four primitives, but they make the economic architecture concrete and enforceable.

contract.x1

Agreement and obligation layer.

Used for:

• rights terms
• licensing terms
• transfer conditions
• operator obligations
• structured machine-readable policy later

registrar.x1

Canonical registry and issuance authority layer.

Used for:

• canonical registration
• issuance
• activation of registered economic objects
• participant and asset registration
• source-of-truth registry state

register.x1

Registration-action layer.

Used for:

• participant registration flows
• asset registration flows
• rights or membership registration requests
• public or operator-facing registration UX

titles.x1

Ownership-title layer.

Used for:

• title representations
• control proofs
• linked ownership instruments
• future title-transfer logic

deeds.x1

Assignment and deed layer.

Used for:

• deed-like ownership assertions
• transfer evidence
• conditional assignment instruments
• proof of delegated or transferred control

escrow.xen

Conditional transfer and release layer.

Used for:

• pending transfer states
• conditional release
• settlement holds
• milestone or approval-based release logic

payments.xen

Settlement rail layer.

Used for:

• payment-state mapping
• settlement orchestration
• payout flows
• future multi-rail settlement routing

credit.xen

Credit and contribution accounting layer.

Used for:

• internal economic standing
• future network credit logic
• contribution-linked value state
• deferred or conditional value accounting

treasury.xen

Treasury and reserve layer.

Used for:

• reserve accounting
• held-value state
• treasury visibility
• ecosystem-level reserve logic later

merchant.x1

Commercial payment-acceptance layer.

Used for:

• operator-facing merchant tooling
• payment acceptance modes
• managed vs own-rail participation
• commerce-facing payment coordination

pos.x1

Point-of-sale and transaction-origin layer.

Used for:

• transaction capture
• service-linked point-of-sale events
• operator checkout or in-field payment workflows
• bridge between execution and settlement

portfolio.xen

Economic position and grouped-value layer.

Used for:

• grouped asset views
• operator or participant positions
• economic summaries
• active rights, assets, and transfer visibility

audits.x1

Verification and integrity layer.

Used for:

• audit outputs
• record integrity
• transfer verification
• settlement auditability
• economic state verification

ratings.x1

Trust and performance signal layer.

Used for:

• trust scoring
• performance history
• participation quality
• future eligibility logic

status.x1

State and standing layer.

Used for:

• participant state
• asset state
• transfer state
• membership or rights status outputs

Canonical Economic Objects

QTM OS economic coordination should recognize the following canonical object classes.

Membership

Represents access state, participation class, and entitlement level.

Right

Represents permission to use, access, license, benefit from, or restrict a capability, method, or economic object.

Asset

Represents a unit of value, control, claim, or recognized economic relevance.

Opportunity

Represents a pending or potential economic action such as acquisition, assignment, licensing, or transfer.

Position

Represents a participant’s standing across access, rights, assets, transfers, and historical activity.

Ownership and Control Model

Each economic object should define, where applicable:

• owner
• controller
• beneficiary
• visibility scope
• transferability
• registration state
• settlement state where relevant

Ownership may be:

• individual
• organizational
• shared
• delegated
• conditional
• pending
• escrowed

QTM OS should distinguish between:

• ownership
• control
• benefit
• visibility
• execution authority

These are not always the same.

Economic Service Events

Economic coordination is expressed through ServiceEvents and related economic state transitions.

Economic event classes include:

Access Events

• membership_granted
• membership_upgraded
• membership_revoked
• membership_suspended

Rights Events

• right_granted
• right_revoked
• right_licensed
• right_expired

Asset Events

• asset_created
• asset_registered
• asset_linked_to_record
• asset_updated
• asset_locked
• asset_released

Transfer Events

• acquisition_initiated
• acquisition_reviewed
• acquisition_approved
• acquisition_rejected
• asset_transferred
• rights_transferred
• operator_transferred
• territory_transferred

Settlement Events

• payment_authorized
• payment_captured
• payout_created
• payout_released
• escrow_funded
• escrow_released
• treasury_allocated

These events should be modeled as governed economic state transitions, not informal notes.

Record-Linked Asset Rule

Assets should be linked to records whenever possible.

Examples:

• a completed job record may define a service-performance asset
• a route history may define an operational asset
• a customer history may define a relationship asset
• a licensed template may define a rights-bearing asset
• a body of governed execution may define an acquisition-relevant asset

This ensures that economic objects emerge from provable system history rather than unsupported claims.

QTM OS should prefer record-linked assets over abstract, ungrounded asset assertions.

Extended Economic Spine

The execution spine remains foundational:

Actor → Request → Job → ServiceEvent → Record

v0.04 extends that logic into economic coordination:

Actor → Request → Job → ServiceEvent → Record → Membership / Right / Asset State → Transfer / Settlement → Updated Record / Updated Position / Updated System State

This means:

• execution creates records
• records can define assets
• rights can attach to assets or participants
• transfer changes ownership or control
• settlement changes economic state
• updated state re-enters the system as new truth

This creates a closed-loop governed economic system rather than a one-time workflow engine.

Relationship to Existing Layers

The Economic Structure Layer integrates with the rest of QTM OS as follows:

• operator.x1 defines who participates as the canonical executable actor
• jobs.xen defines what live work is available, assigned, or claimable
• desk.x1 defines where work is performed
• workflow.x1 defines how work moves
• hiring.x1 defines how people enter the workforce
• talent.x1 defines what capability participants can demonstrate
• casting.x1 defines how participants are selected for specific roles
• hr.x1 defines how workforce state is governed internally
• governance.x1 defines rules and permissions
• credentials.x1 defines trust and capability proofs
• directory.x1 defines discoverability and participant listing
• registrar.x1 defines canonical registration and issuance
• audits.x1 defines integrity review
• agents.xen may participate only under governed boundaries
• omni.x1 may interpret, recommend, or assist, but does not override governance or ownership state
• os.x1 provides the parent system shell across these economic primitives

Economic coordination must remain subordinate to governance and runtime truth.

Canonical vs Support Domain Rule

Not every economic domain is a core primitive.

The core strategic primitives are:

• os.x1
• membership.x1
• ip.x1
• assets.x1
• acquisition.x1

The core economic primitives are:

• membership.x1
• ip.x1
• assets.x1
• acquisition.x1

Support domains exist to make the core stack enforceable, trustworthy, and operable.

Support domains include:

• qtm.x1
• planck.x1
• desk.x1
• operator.x1
• workflow.x1
• governance.x1
• contract.x1
• registrar.x1
• register.x1
• titles.x1
• deeds.x1
• escrow.xen
• payments.xen
• credit.xen
• treasury.xen
• merchant.x1
• pos.x1
• portfolio.xen
• audits.x1
• ratings.x1
• status.x1
• shop.xen

This distinction must be preserved so the architecture does not collapse into domain sprawl.

Namespace Guardrails for Economic Domains

Rule 1

Economic domains must correspond to durable architectural roles, not temporary narratives.

Rule 2

Core primitives should remain few and stable.

Rule 3

Support domains should enforce or operationalize the stack, not compete with it.

Rule 4

No economic object should be treated as fully active until it has the required registration, governance, and state integrity.

Rule 5

Settlement domains should not imply live regulated financial infrastructure beyond what is actually implemented.

Rule 6

Ownership claims should prefer record linkage, registration, and auditability over unsupported declaration.

Rule 7

Economic state must remain governed by the execution and record model, not by detached speculative abstractions.

v0.02 Architectural Implication

With the introduction of the Economic Structure Layer:

QTM OS is no longer only a governed execution environment.

It becomes a governed economic coordination system where:

• execution produces records
• records can define value objects
• value objects can carry rights
• rights and assets can transfer
• settlement can update state
• updated state becomes new system truth

This is the transition from workflow software toward infrastructure.

v0.03 Architectural Implication

With the integration of the Workforce Namespace Cluster:

QTM OS now governs the full arc from workforce entry to economic settlement.

The complete governed sequence is:

hiring.x1 → talent.x1 → casting.x1 → operator.x1 → jobs.xen → workflow.x1 → ServiceEvent → Record → Settlement

This means:

• the network can govern how people enter
• it can represent what they are capable of
• it can select them for specific roles
• it can activate them as executable operators
• it can route live work to them
• it can govern execution, evidence, records, and settlement

QTM OS becomes a complete lifecycle governance system — from candidate to contributor to settled economic participant.

v0.04 Architectural Implication

With the integration of the canonical namespace spine:

os.x1 → membership.x1 → ip.x1 → assets.x1 → acquisition.x1

QTM OS now has an explicit cross-layer constitutional sequence for system identity, access, rights, value, and transfer.

This means:

• os.x1 defines the parent system shell
• membership.x1 defines participation class and access depth
• ip.x1 defines rights, licensing, and knowledge control
• assets.x1 defines recognized value objects and ownership state
• acquisition.x1 defines governed transfer, expansion, and deal-flow pathways

Taken together with the workforce and execution spine, QTM OS is no longer only a workflow engine or even only an economic coordination system.

It becomes a governed operating architecture capable of coordinating:

• workforce entry
• executable identity
• live work
• workflow state
• record creation
• rights
• assets
• settlement
• transfer
• updated system truth

This is the transition from modular operating software toward constitutional economic infrastructure.

Recommended Near-Term Use

In the near term, this economic layer should guide:

• managed vs operator-owned payment logic
• rights and template access logic
• operator participation classes
• asset-linked service history
• transfer-aware growth paths
• future acquisition and expansion surfaces
• operator-linked commerce and merchandise modules

This layer should not delay current OS stabilization.

It should clarify the architecture while implementation continues on auth, workflow integrity, operator flow, payment behavior, and runtime reliability.

Namespace Governance Rules

Rule 1

No namespace may introduce a parallel execution model outside QTM OS invariants.

Rule 2

All operational implementation remains subordinate to the canonical execution spine:

Actor → Request → Job → ServiceEvent → Record

Rule 3

Naming does not override system truth.

A domain name cannot imply runtime capability, ownership integrity, settlement finality, regulatory status, or governance validity unless those exist in implemented system logic.

Rule 4

Namespaces must map to real architectural roles.

A namespace may represent:

• a layer
• a module
• a surface
• a product shell
• a governance layer
• a rights container
• an asset container
• a transfer surface

It must not exist as a permanent architectural orphan.

Rule 5

Economic namespaces must remain governed by policy, registration, records, and auditable state.

Rule 6

Tokenized interpretation of a namespace must remain subordinate to canonical registration, ownership, control, and system-state logic.

Rule 7

Public naming, internal modules, and tokenized namespace interpretation must remain aligned.

Rule 8

Support domains must operationalize or enforce the core stack, not compete with it.

Rule 9

Domains that imply law, sovereignty, finance, custody, or regulated activity must not be treated as implemented legal or financial infrastructure unless explicitly built and governed as such.

Rule 10

Workforce domains must remain distinct from each other and from operator identity.

• hiring.x1 governs entry — it does not grant execution authority
• talent.x1 governs capability representation — it does not replace operator identity
• casting.x1 governs role-fit selection — it does not govern live work
• hr.x1 governs internal admin state — it does not absorb public-facing recruiting
• jobs.xen governs live work — it does not govern the workspace or the actor identity
• operator.x1 remains the canonical system actor regardless of which workforce domains a participant has passed through

Current Status Framing

The following status classes should be used whenever domains are discussed:

Owned

The domain is owned or controlled.

Assigned

The domain has a defined architectural role.

Planned

The domain is expected to become part of a future module, layer, or surface.

Partially implemented

Some relevant logic exists in the system, but the full domain-aligned product or module is not yet live.

Live

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

Ownership does not imply:

• live product status
• live economic infrastructure
• live rights infrastructure
• live regulated payment or settlement rails
• live transfer capability
• live governance enforcement
• live tokenized asset behavior

This distinction must be preserved in all future planning documents.

Primary Domain Assignments

These are the strongest core-stack domains and their recommended dominant roles.

qtm.x1

Master umbrella and network root

os.x1

Master operating-system shell and parent system namespace

omni.x1

Intelligence and orchestration experience layer

planck.x1

Commercial/operator execution layer

index.x1

Index and publication layer

freight.x1

First major vertical/economic surface

desk.x1

Universal desk/workflow environment

operator.x1

Operator identity, activation, and canonical executable participation layer

workflow.x1

Workflow-state, process, automation, and execution-logic layer

jobs.xen

Live work, assignment, and execution access layer

agents.xen

Governed multi-agent infrastructure layer

governance.x1

Constitution, policy, rights, and governance layer

industry.x1

Industry navigation and sector intelligence layer

credentials.x1

Credential, proof, and trust-linked capability layer

directory.x1

Participant/network directory layer

intelligence.x1

Premium intelligence and analysis layer

membership.x1

Access and entitlement layer

ip.x1

Rights and knowledge-control layer

assets.x1

Canonical asset and value-object layer

acquisition.x1

Transfer and expansion layer

Secondary Domain Assignments

These are strong near-future namespaces, but not core-stack anchors yet.

research.x1

Research and institutional reporting

insight.x1

Executive insights and summaries

operations.x1

Operational control and workflow systems

standard.x1

Specifications and standards

audits.x1

Audit and verification views

contractor.x1

Future contractor/service surface

hiring.x1

Workforce entry and recruiting namespace — governs applicant intake, join flows, and pre-approval pipelines into the operator network

talent.x1

Capability and talent-representation namespace — governs talent profiles, skills representation, proof of work, and discoverability of qualified participants

casting.x1

Role-fit and selection namespace — governs brief-based matching, shortlisting, and fit-based candidate selection for specific roles or opportunities

hr.x1

Internal workforce governance and administration namespace — governs workforce admin state, onboarding completion, readiness review, and internal people operations

events.x1

Future event and hospitality surface

booking.x1

Booking and reservation workflows

property.x1

Property and asset coordination surface

ratings.x1

Performance and trust rating systems

registrar.x1

Canonical registration and issuance layer

shop.xen

Operator commerce and merchandise layer

Reserve Domains

These should be preserved strategically, but not pushed into active architecture unless needed.

High-value reserve

• identity.xen
• data.xen
• graph.xen
• nodes.xen
• payments.xen
• treasury.xen
• escrow.xen
• market.xen
• media.xen
• search.xen
• travel.xen
• energy.xen
• tribe.xen
• tribe.xnt
• onlyagents.x1
• bothub.x1

Narrative / experimental reserve

• onlyagents.x1
• bothub.x1

Cautionary reserve

These may be useful later, but imply narrative or regulatory complexity:

• truth.x1
• reality.x1
• law.x1
• legal.x1
• federal.x1
• state.x1
• nation.x1
• forex.x1

Public vs Internal Namespace Rules

Public-first domains

These can be safely positioned externally early:

• qtm.x1
• os.x1
• omni.x1
• planck.x1
• index.x1
• freight.x1
• desk.x1
• operator.x1
• workflow.x1
• jobs.xen
• industry.x1
• intelligence.x1
• research.x1
• directory.x1
• hiring.x1
• membership.x1

Controlled-public domains

These should be public only with discipline:

• governance.x1
• credentials.x1
• standard.x1
• audits.x1
• shop.xen
• talent.x1
• casting.x1
• ip.x1
• assets.x1
• acquisition.x1

Internal or later-stage domains

These should generally remain internal, reserve, or delayed:

• agents.xen
• identity.xen
• data.xen
• graph.xen
• nodes.xen
• qtm.xen
• qtm.xnt
• treasury.xen
• payments.xen
• escrow.xen
• market.xen
• hr.x1

Routing and Naming Rules

Rule 1

Primary domains should represent layers, not random features.

Rule 2

New products should prefer paths under an existing architectural domain before claiming a new root domain.

Example: use desk.x1/freight before creating an entirely separate workflow product identity unless needed.

Rule 3

Vertical experiences should prefer either:

• a vertical root namespace like freight.x1 or
• a desk-oriented workspace path like desk.x1/freight

depending on whether the audience is external or operator-facing.

Rule 4

Operator experiences and desk experiences should remain distinct.

Example:

• operator.x1/profile/[slug] = who the operator is
• desk.x1/freight = where the operator works

Rule 5

Workflow logic and workspace logic should remain distinct.

Example:

• workflow.x1/freight = the process model, transitions, and automation logic
• desk.x1/freight = the actual operator workspace

Rule 6

Intelligence and agent infrastructure should remain distinct.

Example:

• omni.x1 = orchestration/intelligence experience
• agents.xen = underlying agent infrastructure and governance

Rule 7

Index and intelligence outputs should remain separate.

Example:

• index.x1 for formal index outputs
• intelligence.x1 for broader analysis products

Rule 8

Governance and data rights should not hide inside product marketing domains.

They should live under:

• governance.x1
• standard.x1
• data.xen later

Rule 9

Economic and commerce domains should extend execution, records, rights, assets, transfer, or settlement.

Example:

• shop.xen = governed operator commerce attached to operator identity and network audiences
• not a generic marketplace detached from operator execution

Rule 10

Workforce domains must remain distinct from each other and from operator identity.

• hiring.x1 governs entry — it does not grant execution authority
• talent.x1 governs capability representation — it does not replace operator identity
• casting.x1 governs role-fit selection — it does not govern live work
• hr.x1 governs internal admin state — it does not absorb public-facing recruiting
• jobs.xen governs live work — it does not govern the workspace or the actor identity
• operator.x1 remains the canonical system actor regardless of which workforce domains a participant has passed through

Rule 11

The canonical namespace spine should remain legible in all future launches:

os.x1 → membership.x1 → ip.x1 → assets.x1 → acquisition.x1

Expansion Rules

Rule 1

A new root domain should only be activated when it corresponds to a durable architectural layer, major surface, or major market-facing product.

Rule 2

If a function can live cleanly as:

• a path
• a subdomain
• or a module inside an existing domain, prefer that first.

Rule 3

Reserve domains should be cataloged, not launched impulsively.

Rule 4

Domains that imply regulation, sovereignty, law, finance, or public authority should only be activated with explicit governance and compliance intent.

Rule 5

Narrative or playful domains should never displace core architectural domains.

Examples:

• onlyagents.x1
• bothub.x1

These may be useful for campaigns, community, or future sandbox products, but not as constitutional core layers.

Rule 6

The acquisition of a strong domain should trigger architectural classification, not automatic product creation.

Recommended Initial Live Namespace Structure

A sane first structure would be:

qtm.x1

umbrella and network root

os.x1

system shell and canonical operating namespace

omni.x1

intelligence/orchestration experience

planck.x1

commercial/operator rollout

freight.x1

external freight surface

desk.x1

operator desk environments

operator.x1

operator onboarding, identity, activation, and participation

workflow.x1

workflow templates, state logic, and process automation

jobs.xen

live work, assignment, and execution access

index.x1

index outputs and methodology

governance.x1

network rules and rights

credentials.x1

credentials and proofs

directory.x1

participant discovery

intelligence.x1

premium intelligence layer

membership.x1

access and entitlement layer

ip.x1

rights and knowledge-control layer

assets.x1

asset and value-object layer

acquisition.x1

transfer and expansion layer

shop.xen

operator commerce and merchandise layer

This is already a serious architecture.

Success Criteria

This strategy is successful when:

• the domain portfolio is assigned by architecture rather than impulse
• the core stack has stable roles
• the canonical namespace spine is clearly understood
• operator and desk layers are clearly separated
• workflow is clearly separated from both operator and desk
• workforce entry, capability, selection, execution, and settlement remain legible as distinct stages
• intelligence and agent infrastructure layers are clearly separated
• future surfaces can be added without naming chaos
• access, rights, assets, transfer, governance, workflow, and settlement remain distinct
• public and internal namespace boundaries are clear
• reserve domains remain strategic assets instead of distractions
• commerce remains attached to operator identity, audience, records, and settlement rather than becoming an unrelated marketplace
• domain ownership strengthens architectural clarity instead of creating implementation drift