operator · v0.01

Job Lifecycle

The Jobs surface is the operator's full execution environment. Step-by-step workflow, evidence capture, ServiceEvent completion, and record creation all happen here.

private active partially_implemented operator.x1

Job Lifecycle

The Jobs surface is where operators execute service work. It is the full execution environment — step-by-step workflow, evidence capture, and completion.

Once an operator has claimed a job from their Desk, they come here to see the full details of the job, progress through the service stages, capture required evidence, complete the job, and produce a record.

Step-by-step execution

1. Job detail

The operator sees the context for the job — what was requested, the customer details, the service tier, and any notes from intake.

2. Start work

The operator begins the ServiceEvent. This moves the job from queued (or created) to in_progress. The system records when work started.

3. Evidence capture

During the job, the operator captures evidence. For physical services like auto-detailing, this means:

  • Arrival — photo confirming the operator arrived
  • Before — photos before work begins
  • After — photos showing the completed work

Evidence requirements are set by the surface. The system enforces them — if required evidence is missing, the job cannot be completed. Advisory surfaces (like consultations) may have no required evidence categories.

4. Completion

The operator marks the job complete. The system checks:

  • Is the ServiceEvent in in_progress state?
  • Have all required evidence categories been satisfied?

If yes, the ServiceEvent is marked completed. A Record is created and stored permanently.

5. Payment state

The operator can optionally record payment status (paid, unpaid, partial) at completion. This is stored on the ServiceEvent and Record.

Evidence → Record → Trust

Evidence captured
  → ServiceEvent completed
    → Record created (sealed)
      → ⭐ Signal emitted (if new record, no prior signal)

The record is created from the completed ServiceEvent. The ⭐ Signal is emitted by the system after the new record is persisted. This is automatic — completing the job correctly triggers it.

What operators can see

  • Full job context from the original intake
  • ServiceEvent stages and current status
  • Captured evidence with categories
  • Payment state
  • Completion controls
  • Outcome fields (notes, issues, recommendations)

What the Jobs surface is not

The Jobs surface is not a place to create new requests or manage operator settings. Those belong in the operator admin workspace.

It is also not a place to override governance decisions. The job was created through the governance process. By the time it appears in the Jobs surface, it has already been approved and assigned.

Route

/operators/[slug]/jobs
/operators/[slug]/jobs?job=<job_id>

Guardrails

  • Preserve the distinction between planned, partial, and live.
  • Avoid marketing language.
  • Keep IDs, namespaces, and lifecycle terms precise.