Workforce Namespace Cluster
Purpose
Define the workforce entry, capability, selection, administration, activation, and live-work access sequence inside QTM OS.
This cluster connects upstream workforce entry flows to downstream execution without replacing operator.x1 or weakening the execution spine.
Architectural role
The workforce namespace cluster spans the Operator and Workflow layers. It governs the workforce pipeline from the moment someone enters the network, through capability assessment and role selection, to live work access.
These domains do not replace any existing layer. They extend the architecture to govern the workforce pipeline while preserving the rule that execution authority resolves through operator.x1 before live work begins.
Canonical workforce flow
The governed sequence from workforce entry to live execution is:
```text 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
Once a job is live, the flow continues:
```text jobs.xen → workflow.x1 (process state) → ServiceEvent → Record → Settlement ```
Namespace roles
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 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.
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
operator.x1
Role
Primary operator identity, activation, and executable participation namespace.
Architectural meaning
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.
Guardrails
- operator.x1 should represent the acting participant, not the workspace itself
- 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
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
```text 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
What it governs
- Workforce entry semantics
- Distinction between candidate, talent, selected participant, HR subject, activated operator, and job-eligible operator
- Transition into operator.x1 before execution access
- Relationship between workforce namespaces and jobs.xen
- Boundary between people governance and operator execution
- The workforce portion of the larger sequence from candidate to contributor to settled economic participant
What it does not govern
- It does not grant execution authority directly.
- It does not replace operator activation.
- It does not make jobs.xen a detached job board.
- It does not allow hiring.x1, talent.x1, casting.x1, or hr.x1 to bypass operator.x1.
- It does not replace the execution spine.
- It does not collapse ServiceEvent completion into settlement capture.
Relationships to other 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
The complete governed sequence in the v0.04 architecture is:
```text hiring.x1 → talent.x1 → casting.x1 → operator.x1 → jobs.xen → workflow.x1 → ServiceEvent → Record → Settlement ```
Current status
Canonical conceptual architecture. Not an active build focus in the current Planck pilot.
The current Planck runtime validates operator execution and access concepts, but the full workforce namespace cluster remains conceptual unless a page explicitly marks a portion as assigned, partially implemented, or live.
Future direction
Define schemas and workflows only after core pilot execution remains stable. Workforce documentation should preserve the distinction between workforce entry, operator activation, live work access, execution truth, record truth, and settlement state.
Guardrails
- No domain in the workforce sequence may grant execution authority directly.
- Talent or casting selection is not execution authority.
- HR governance is not operator execution.
- operator.x1 remains the canonical executable actor.
- jobs.xen must stay compatible with operator.x1 and the execution spine.
- jobs.xen is governed live work availability and assignment, not a detached job board.
- Workforce namespaces must not collapse into task, job, ServiceEvent, record, or settlement state.