constitutional · v0.01

System Entities

Canonical entity definitions for the QTM OS execution chain: Actor, Request, Intake, Task, Job, ServiceEvent, Record, and downstream Signal.

private active partially_implemented qtm-os

System Entities

These are the core objects in QTM OS. Every piece of governed service work is expressed through these entities in sequence.

Actor

What it is: The person or business initiating a request.

Role in the system: The actor is the starting point of the execution chain. They are external to the system: they make a request, but do not govern or execute it.

Relationship to other entities: An Actor creates a Request. They do not create Tasks, Jobs, or ServiceEvents directly.

Request

What it is: The raw expression of a service need, submitted through an intake channel.

Role in the system: The request is converted into an Intake object when it enters the system. It captures what was asked for, by whom, and from which channel.

Relationship to other entities: A Request becomes an Intake. It is the upstream source from which all downstream objects are derived.

Intake

What it is: The structured, governed entry point for a service request inside QTM OS.

Role in the system: The Intake stores the request in a structured format and creates a Task for review. It is the first object that exists inside the system’s boundaries.

Relationship to other entities: An Intake creates a Task. A Job later references the Intake to carry forward the original context. The Intake state is updated as the request moves through the system.

Task

What it is: A governance object representing a request that needs to be reviewed, approved, and assigned.

Role in the system: Tasks manage the decision of whether and to whom work should be assigned. They exist in a governance zone before any execution happens.

Two kinds of tasks exist:

  • Operator-audience tasks — tasks where the operator governs their own incoming requests
  • Admin-audience tasks — tasks governed by the network’s admin team

Relationship to other entities: A Task is created from an Intake. When approved and assigned, an authorized governance actor explicitly creates a Job from the task. The Task does not become a Job automatically.

Job

What it is: An approved, queued unit of work assigned to an operator.

Role in the system: The Job is the bridge between governance and execution. It is created deliberately. Once a job exists, it appears in the operator’s queue and is ready to be claimed and executed.

Relationship to other entities: A Job is created from a Task. A Job produces one ServiceEvent when the operator begins execution. The Job carries forward context from the original Intake.

ServiceEvent

What it is: The active execution container for a job. It tracks what happens during the actual work.

Role in the system: The ServiceEvent is where execution lives. It holds the current stage of work, the evidence captured by the operator, and the final outcome. It is execution truth.

Relationship to other entities: A ServiceEvent is created from a Job. When completed, it produces a Record. The ⭐ Signal, when emitted, is derived from the ServiceEvent and its Record.

Record

What it is: The permanent, sealed account of what happened in a completed job.

Role in the system: The Record is the system’s durable source of truth for an execution. It is created from the completed ServiceEvent and persisted durably. Nothing downstream of the Record can change what it contains.

Relationship to other entities: A Record is derived from a completed ServiceEvent. It is linked to the Job, the Intake, and the operator. It is the prerequisite for a ⭐ Signal.

⭐ Signal

What it is: A system-emitted trust attribution object derived from completed, recorded execution.

Role in the system: The ⭐ Signal converts sealed execution truth into portable, attributable trust context. It is not a rating, review, score, or ranking mechanism.

Relationship to other entities: A ⭐ Signal is downstream of Record. It must trace back to a Job, ServiceEvent, and Record, and it cannot exist before the Record exists.

Guardrails

  • Preserve the distinction between Request, Intake, Task, Job, ServiceEvent, and Record.
  • A Task does not become executable work until a Job is explicitly created.
  • A ServiceEvent is execution truth; a Record is durable execution truth.
  • ⭐ Signal remains downstream of Record and advisory only.