surface · v0.01

Auto Detailing

Auto Detailing surface documentation within wiki.x1, the private-first knowledge layer for QTM OS.

private active partially_implemented auto-detailing

Auto Detailing

Purpose

Auto Detailing is the first concrete service surface documented in wiki.x1 as a real QTM OS surface rather than a placeholder architecture page.

This page describes how the auto-detailing surface fits inside the QTM OS execution envelope, what is currently implemented in the Planck runtime, what remains partial, and what should not be implied before it exists.

The canonical execution spine for this surface is:

Actor → Request → Job → ServiceEvent → Record

In the broader governed OS envelope, admin governance and settlement remain adjacent layers:

Request → Task → Assignment → Job → ServiceEvent → Record → Settlement

The detailing surface must not collapse those layers. Task state is governance state. Job state is executable work state. ServiceEvent state is execution truth. Record state is durable outcome truth. Settlement state is economic state.

Architectural role

Auto Detailing is a surface-specific execution workflow that runs inside the universal QTM OS envelope.

The surface uses:

  • operator.x1 as the canonical executable actor identity
  • jobs.xen as the governed live work availability and assignment layer
  • workflow.x1 as the process logic and state model layer
  • desk.x1 as the workspace where operator execution is surfaced
  • ServiceEvent as the execution runtime container
  • SurfaceRecord as the durable execution outcome
  • Settlement as a separate economic mirror where payment/collection state exists

The current runtime identifies this surface as:

surface_slug: auto-detailing
runtime spec: surface-runtime-spec-v0.01
runtime status: active

The surface runtime declares that claim is required, ownership is assigned, the execution record is the ServiceEvent, payment timing is independent, and completed jobs should remain visible.

What it governs

  • Auto-detailing surface identity and execution posture
  • Operator claim requirement before execution begins
  • Assigned-operator ownership for execution
  • ServiceEvent-based execution truth
  • Detailing evidence requirements
  • Detailing lifecycle labels and operator-facing execution phases
  • Record composition after ServiceEvent completion
  • The boundary between detailing execution and settlement state

The current detailing runtime declares these lifecycle phases:

queued → claimed → arrived → in_progress → evidence → complete

The current evidence contract requires at least one item in each required category:

  • arrival
  • before
  • after

These categories are detailing-specific. They should not be generalized into every surface unless that surface runtime explicitly defines the same evidence contract.

What it does not govern

  • It does not grant execution authority outside operator.x1 activation and operator access rules.
  • It does not make task assignment equal executable work by itself.
  • It does not replace jobs.xen as the live work availability and assignment layer.
  • It does not replace workflow.x1 as the process-logic layer.
  • It does not replace desk.x1 as the workspace layer.
  • It does not make ServiceEvent completion equal settlement capture.
  • It does not make job completion equal payment completion.
  • It does not imply full managed payment rails, payout records, processor reconciliation, or wallet behavior.
  • It does not define the execution workflow for other surfaces such as freight, landscaping, events, or astrology.

Relationships to other layers

operator.x1

operator.x1 remains the canonical executable actor. A technician or operator may only execute work through the operator identity and access model. Workforce entry, task routing, or assignment context does not replace operator.x1.

jobs.xen

jobs.xen represents governed live work availability and assignment. For auto-detailing, executable work should appear only after a governed request has become a Job. jobs.xen must not be treated as a detached public job board.

workflow.x1

workflow.x1 owns process logic. The detailing sequence is a surface workflow mapped into Job and ServiceEvent behavior; it is not a new universal state machine.

desk.x1

desk.x1 is the workspace layer. Operator desk and jobs pages surface queued, active, and completed work, but the desk does not replace ServiceEvent truth or settlement state.

ServiceEvent

ServiceEvent is the execution runtime container associated with the auto-detailing Job. Job claim establishes operator ownership of execution. The ServiceEvent lifecycle progresses as execution occurs: evidence is attached to the ServiceEvent, and completing the ServiceEvent composes the SurfaceRecord.

Record

SurfaceRecord represents durable execution outcome truth. It is generated from completed ServiceEvent data and should remain distinct from both job state and settlement state.

Settlement

Settlement is economic state. Existing settlement endpoints and payment-state fields exist, but managed payment and payout behavior from the detailing managed-payments spec remains planned or future unless explicitly implemented elsewhere.

Current status

Auto Detailing is partially implemented in the Planck runtime.

Implemented or currently represented:

  • public/operator request entry for the detailing surface
  • admin governance path from intake review to task approval, assignment, and explicit job creation
  • operator-scoped job claim flow
  • ServiceEvent creation or resolution during job claim
  • ServiceEvent evidence attachment
  • runtime-driven evidence validation for required categories
  • ServiceEvent completion
  • SurfaceRecord composition from completed ServiceEvent data
  • job completion guarded by completed ServiceEvent
  • completed job visibility in operator job views
  • settlement/payment record endpoints and payment-status fields as a separate economic layer

Partially implemented:

  • surface runtime configuration as an enforcement input
  • detailing lifecycle visibility across all operator UX surfaces
  • read-only settlement visibility across all relevant surfaces
  • complete operator-facing explanation of each detailing execution phase
  • broad reusable surface-workflow scaffolding across multiple surfaces

Planned or not live:

  • full managed payment rails for detailing
  • payout records
  • payout eligibility engine
  • admin payout hold/release flow
  • processor webhook reconciliation
  • wallet, balance, or ledger systems; these are explicitly not part of the current detailing model

Implementation state

The wiki frontmatter marks this page as:

implementation_state: partially_implemented

That classification is intentional.

The auto-detailing surface has real Planck runtime behavior, but the full surface-specific execution UX, managed payment model, payout model, and reusable multi-surface workflow system are not fully live.

The current implementation should be described as partially implemented, not merely conceptual and not fully live.

Future direction

Future detailing documentation should map each operator-visible execution phase to ServiceEvent behavior without hardcoding detailing assumptions into generic admin task language.

Potential future work should remain explicitly classified until implemented:

  • clearer operator UX for arrival, before, in-progress, after, closeout, and completion stages
  • runtime-config-driven evidence and lifecycle presentation
  • richer record and settlement visibility
  • managed payment and payout extensions only after the detailing payment model is implemented safely

Execution Example

A concrete auto-detailing job moves through the system like this:

  1. Actor submits Request

    A customer submits an auto-detailing request through an operator surface. The request enters QTM OS as intake data. This does not create executable work by itself.

  2. Task exists for admin governance

    The request appears as a governance task for review. The task belongs to the admin/governance layer. It can be reviewed, approved, assigned, and closed, but it is not the detailing execution state.

  3. Assignment occurs

    An admin assigns the approved governance task to an operator such as the detailing operator. Assignment records who should receive the handoff. Assignment still does not start execution.

  4. Job is created

    An explicit Create Job handoff turns the approved and assigned request into a Job. The Job is the executable work container. At this point the operator can see queued work in the operator desk/jobs context.

  5. Operator claims Job

    The operator.x1 actor claims the queued Job. Claiming establishes operator ownership of execution and moves the Job into active execution context. The ServiceEvent is the execution container associated with that Job, and its lifecycle progresses as execution occurs.

  6. ServiceEvent begins

    The ServiceEvent becomes the execution runtime container for the detailing work. It carries the surface identity, operator identity, job reference, service scope, evidence, payment fields where applicable, and completion outcome.

  7. Evidence is attached

    The operator attaches detailing evidence to the ServiceEvent. The current auto-detailing runtime requires at least one item in each required category: arrival, before, and after.

  8. ServiceEvent completes

    The operator completes the ServiceEvent after required evidence is present. ServiceEvent completion represents execution completion for the surface workflow. It does not mean settlement has been captured.

  9. Record is created

    Completing the ServiceEvent composes a SurfaceRecord. The Record is durable execution truth derived from the completed ServiceEvent.

  10. Settlement remains separate

Settlement/payment state is tracked separately as economic state. Payment status or amount collected may be recorded where existing fields support it, but settlement capture is not the same as ServiceEvent completion, Job completion, or Record creation.

Mapped to the surface execution spine:

Spine layerAuto-detailing example
Actoroperator.x1 actor claims and executes the detailing job
Requestcustomer detailing intake/request
Jobexecutable detailing work container created by explicit handoff
ServiceEventexecution runtime where evidence and completion are recorded
Recorddurable SurfaceRecord composed from completed ServiceEvent

Guardrails

  • Preserve Actor → Request → Job → ServiceEvent → Record as the surface execution spine.
  • Preserve Request → Task → Assignment → Job → ServiceEvent → Record → Settlement as the broader governed OS envelope.
  • Preserve operator.x1 as the canonical executable actor.
  • Preserve jobs.xen as governed live work availability and assignment, not a detached job board.
  • Preserve workflow.x1 as process logic and desk.x1 as workspace.
  • Do not make admin task state the detailing execution state.
  • Do not make ServiceEvent completion equal settlement capture.
  • Do not make payment capture equal job completion.
  • Do not describe managed payments, payout records, or processor reconciliation as live until implemented.
  • Do not generalize detailing-specific evidence categories to other surfaces.
  • Do not invent customer, payment, operator, or settlement capabilities that are not implemented.