surface · v0.01

Automotive Advisory

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

private active partially_implemented automotive-advisory

Automotive Advisory

Purpose

Automotive Advisory documents an advisory-style QTM OS surface where the delivered value is counsel, assessment, or written guidance rather than physical service execution.

This page validates that the wiki governance model can describe a non-detailing surface without importing detailing-specific evidence rules or physical-service assumptions.

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 advisory 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

Automotive Advisory is a surface-specific advisory 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 durable outcome truth
  • Settlement as a separate economic mirror where payment/collection state exists

The current runtime identifies this surface as:

surface_slug: automotive-advisory
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

  • Automotive-advisory surface identity and execution posture
  • Operator claim requirement before advisory execution begins
  • Assigned-operator ownership for execution
  • ServiceEvent-based advisory truth
  • Advisory lifecycle labels and operator-facing execution phases
  • Record composition after ServiceEvent completion
  • The boundary between advisory delivery and settlement state

The current automotive-advisory runtime declares these lifecycle phases:

queued → claimed → in_progress → complete

The current runtime evidence contract is advisory-specific:

required_categories: []
optional_categories: []
min_per_category: 0

That means the runtime does not require physical-service photo evidence for this surface. The delivered value is counsel, assessment, or written output, not arrival/before/after physical-service proof.

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 impose auto-detailing evidence categories on advisory work.
  • It does not imply physical inspection, repair authorization, diagnosis, warranty representation, or regulated professional advice unless separately implemented and governed.
  • It does not define the execution workflow for other surfaces such as auto-detailing, freight, landscaping, events, or astrology.

Relationships to other layers

operator.x1

operator.x1 remains the canonical executable actor. An advisor 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 Automotive Advisory, executable advisory 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 advisory 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 advisory work, but the desk does not replace ServiceEvent truth or settlement state.

ServiceEvent

ServiceEvent is the execution runtime container associated with the Automotive Advisory Job. Job claim establishes operator ownership of execution. The ServiceEvent lifecycle progresses as execution occurs, recording advisory service context, completion outcome, and any payment fields where applicable.

Record

SurfaceRecord represents durable 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 settlement capture is not the same as advisory delivery, ServiceEvent completion, Job completion, or Record creation.

Current status

Automotive Advisory is partially implemented in the Planck runtime.

Implemented or currently represented:

  • public/operator request entry for the automotive-advisory surface
  • advisory intake packet with vehicle details, request type, service area, and condition/issue notes
  • submit path that treats automotive-advisory as not requiring photo minimum enforcement
  • 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
  • automotive-advisory runtime registration
  • advisory runtime evidence contract with no 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
  • advisory lifecycle visibility across all operator UX surfaces
  • read-only settlement visibility across all relevant surfaces
  • complete operator-facing explanation of advisory execution phases
  • broad reusable surface-workflow scaffolding across multiple surfaces

Planned or not live:

  • full advisory-specific intake review ontology
  • formal advisory report templates
  • regulated diagnostic, repair authorization, warranty, or compliance workflows
  • full public documentation for advisory service boundaries
  • managed payment rails or payout behavior specific to this surface

Implementation state

The wiki frontmatter marks this page as:

implementation_state: partially_implemented

That classification is intentional.

The Automotive Advisory surface has real Planck runtime behavior, including an active runtime registration and advisory-specific no-photo evidence contract, but the full advisory UX, formal advisory-report structure, and multi-surface workflow scaffolding are not fully live.

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

Future direction

Future Automotive Advisory documentation should map each operator-visible advisory phase to ServiceEvent behavior without importing detailing assumptions.

Potential future work should remain explicitly classified until implemented:

  • clearer operator UX for accepted, in-session, delivered, and closeout stages
  • runtime-config-driven lifecycle presentation
  • advisory-specific output or report structure
  • richer record and settlement visibility
  • clearer public boundaries around what the advisory surface does and does not represent

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.
  • Preserve ServiceEvent as execution truth and Record as durable outcome truth.
  • Do not make admin task state the advisory execution state.
  • Do not make ServiceEvent completion equal settlement capture.
  • Do not make payment capture equal job completion.
  • Do not force detailing-style arrival, before, or after evidence rules onto advisory work.
  • Do not describe diagnostic, repair, warranty, payment, payout, or settlement capabilities as live unless implemented.
  • Do not invent customer, payment, operator, or settlement capabilities that are not implemented.

Execution Example

A concrete Automotive Advisory job moves through the system like this:

  1. Actor submits Request

    A customer submits an automotive guidance request through an operator surface. The request includes contact details, vehicle details, advisory service area, and issue or condition notes. 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 advisory execution state.

  3. Assignment occurs

    An admin assigns the approved governance task to an operator or advisor. 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 advisory 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 advisory work. It carries the surface identity, operator identity, job reference, service scope, advisory context, payment fields where applicable, and completion outcome.

  7. Advisory work is performed

    The operator performs the advisory session, assessment, or written guidance. The current runtime does not require physical-service photo evidence categories for this surface.

  8. ServiceEvent completes

    The operator completes the ServiceEvent when the advisory work is delivered. ServiceEvent completion represents execution completion for the advisory workflow. It does not mean settlement has been captured.

  9. Record is created

    Completing the ServiceEvent composes a SurfaceRecord. The Record is durable outcome 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 layerAutomotive Advisory example
Actoroperator.x1 advisor claims and executes the advisory job
Requestcustomer automotive guidance intake/request
Jobexecutable advisory work container created by explicit handoff
ServiceEventexecution runtime where advisory delivery and completion are recorded
Recorddurable SurfaceRecord composed from completed ServiceEvent