Execution Spine
Purpose
Define the strict sequential spine for QTM OS execution truth.
The execution spine is the canonical path by which a participant signal becomes governed request intake, governed intake becomes coordination work, coordination becomes explicit assignment, assignment becomes executable work, executable work becomes ServiceEvent truth, ServiceEvent truth becomes durable record, and record truth becomes eligible for economic settlement.
This is not a marketing sequence. It is the system boundary that prevents governance, execution, record, and settlement layers from collapsing into one another.
Architectural role
QTM OS execution follows a strict sequential spine:
```text Actor → Request → Task → Assignment → Job → ServiceEvent → Record → Settlement ```
The operational shorthand may begin at Request when describing the OS envelope:
```text Request → Task → Assignment → Job → ServiceEvent → Record → Settlement ```
The stronger architecture remains clear: a Task is not the execution truth. A Task governs review, coordination, approval, assignment, and governance closure. A Job is the executable work container. A ServiceEvent is the execution runtime container. A Record is durable execution truth. Settlement is the economic layer downstream from record truth.
What it governs
- Actor or system-originated request intake
- Request → Task creation as governed intake conversion
- Task review, approval, assignment, and governance handoff
- Assignment as coordination state, not executable work by itself
- Assignment → Job as an explicit human-initiated handoff where implemented
- Job as the executable work container
- Job → ServiceEvent as operator-initiated execution entry
- ServiceEvent as surface execution truth and evidence container
- ServiceEvent → Record as record composition from completed execution
- Record → Settlement as economic closure eligibility, not automatic payment truth
Source-aligned transition authorities
The current source architecture identifies these transition boundaries:
| Transition | Authority | Boundary meaning |
|---|---|---|
| Request → Task | governed submit path | Intake becomes a governance item |
| Task → Assignment | human-initiated assignment | Routing origin does not equal assignment |
| Assignment → Job | explicit create-job handoff | Assignment does not create executable work by itself |
| Job → ServiceEvent | operator-initiated claim/start path | Operator execution begins from job state |
| ServiceEvent → Record | service-event completion path | Execution truth becomes durable record |
| Record → Settlement | surface/economic settlement path | Settlement remains downstream economic state |
What it does not govern
- It does not define every surface-specific production workflow.
- It does not make task state the canonical execution truth.
- It does not allow routing metadata to equal assignment.
- It does not allow assignment to equal job creation.
- It does not allow task completion to equal job completion.
- It does not allow job completion to equal ServiceEvent completion.
- It does not allow ServiceEvent completion to equal settlement capture.
- It does not allow payment capture to replace record truth.
- It does not allow Omni, executive, admin, workforce, or commerce layers to execute work by implication.
Critical boundaries
Routing ≠ assignment
Tasks may carry routing origin metadata, such as the operator surface where an intake originated. That routing origin is not assignment. Assignment requires an explicit assignment state or action.
Task state ≠ job state
The operator desk reflects job state. It does not reflect task state. A task that is open, approved, or assigned does not appear as executable desk work until a Job exists.
Job state ≠ ServiceEvent state
A Job is the executable work container. A ServiceEvent is the surface execution runtime container. Surface execution truth is not fully represented by job state alone.
ServiceEvent completion ≠ settlement capture
A completed ServiceEvent can compose a Record. Settlement remains a separate economic state and must not be implied by completion of execution.
Relationships to other layers
Admin governance operates before and around job handoff. Operator execution begins only when an executable Job exists. Surface-specific workflows map inside Job → ServiceEvent behavior. Records preserve completed execution truth. Settlement remains downstream and economically distinct.
Omni may observe signals that correspond to transitions in the spine. It has no authority to advance, reverse, or bypass any transition.
The execution spine is compatible with multiple surfaces because surface-specific production does not rewrite the universal envelope.
Current status
Partially implemented and architecturally frozen in the Planck pilot runtime.
Current implemented reality includes request submission, task governance, explicit task-to-job bridge, job state, ServiceEvent state, evidence validation, record composition, and settlement records. Surface runtime depth remains partial and must be marked honestly per surface.
Future direction
Surface runtime configs should express ServiceEvent sequences without changing the universal spine. Additional surfaces should map their internal production stages into ServiceEvent behavior rather than changing Actor → Request → Task → Assignment → Job → ServiceEvent → Record → Settlement.
Guardrails
- Preserve routing ≠ assignment.
- Preserve task state ≠ job state.
- Preserve job state ≠ ServiceEvent state.
- Preserve ServiceEvent completion ≠ settlement capture.
- Preserve assignment ≠ job creation.
- Preserve explicit Create Job handoff where the handoff is required.
- Preserve Record as durable execution truth.
- Do not replace execution truth with a weaker task-centric framing.
- Do not collapse settlement into execution completion.