Runtime Truth

The system follows a strict, ordered path. Every piece of work starts at the same place and ends at the same place. Nothing can skip a step.

Actor → Request → Intake → Task → Job → ServiceEvent → Record → ⭐ Signal

Step by step

1. Actor makes a request

Someone submits a service request — through a web form, an operator-managed intake page, or another entry point. The request contains the basic information about what they need.

2. Intake

The request becomes an Intake. This is the governed entry point. The intake object is structured and stored. It is not yet executable work — it is a request waiting for review.

3. Task

The intake creates a Task. This is the governance step. A human reviews the task, approves it, and assigns it to an operator. Until this happens, no job exists. There is no execution without a deliberate handoff.

4. Create Job — the execution boundary

An admin or operator explicitly creates a Job from an assigned task. This is a deliberate, one-way action. It cannot happen automatically.

The Job is the bridge between governance and execution. Before Create Job, work is in review. After Create Job, work is in execution.

5. Job

The Job is a queued, assigned unit of work. The operator can see it in their Desk. The job carries all the context from the original request.

6. ServiceEvent

The operator claims the job and begins work. This creates a ServiceEvent — the active execution container.

The ServiceEvent tracks:

Whether work has started
Evidence captured (photos, notes)
Stage progress
Completion state

7. Record

When the ServiceEvent is completed, the system creates a Record. This is the permanent, sealed record of what happened. It cannot be retroactively changed.

The Record is the system’s source of truth for that job. It captures the full execution — the operator, the surface, the outcome, the evidence.

8. ⭐ Signal

After a new Record is created and sealed, the system may emit a ⭐ Signal. This is a trust signal derived from the execution. It is not a rating, not created by the customer or operator, and not manually triggered. It is emitted by the system automatically based on verified execution.

Where governance happens

Governance happens before the Job is created.

Request → Intake → Task ← governance zone
                          ↓
                       Create Job ← explicit boundary
                          ↓
                    Job → ServiceEvent ← execution zone

Admin reviews tasks. Operators act on jobs. These two zones are separated by the Create Job action.

Where execution happens

Execution happens inside the ServiceEvent, after a Job has been created and claimed. The operator’s Desk shows the active job. The Jobs surface is where execution steps happen: starting work, capturing evidence, completing the service.

Where trust is created

Trust is created after execution completes.

ServiceEvent → Record → ⭐ Signal

The ⭐ Signal can only exist after a Record. The Record can only exist after a completed ServiceEvent. There is no shortcut.

Key distinctions

Task vs Job

A Task is a governance object — it exists for review and approval. A Job is an execution object — it exists for doing work. A task can exist without a job. A job cannot exist without a task that was approved and explicitly promoted.

ServiceEvent meaning

The ServiceEvent is not just a container — it is the execution truth. What happens inside the ServiceEvent (evidence captured, stages completed, outcome recorded) becomes the basis for the Record.

Record as source of truth

The Record is the final, authoritative account of what happened in a job. It is derived from the ServiceEvent but persisted independently. Other systems — like the trust signal layer — read from the Record, not from the ServiceEvent directly.

Guardrails

Preserve the distinction between planned, partial, and live.
Task state is not job state. Job state is not ServiceEvent state.
ServiceEvent completion does not equal settlement capture.
Record is durable execution truth. Do not replace it with a weaker framing.