Event Coordination

Purpose

Event Coordination documents a coordination-heavy QTM OS surface where the delivered value is the organized execution of a time-bound event across client requirements, vendor activity, schedule context, and operator follow-through.

This page validates that the wiki governance model can describe a multi-actor surface without collapsing scheduling, messaging, vendor activity, or admin governance into execution truth.

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 Event Coordination 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

Event Coordination is a surface-specific coordination 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 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 truth container associated with the Job
• 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: event-coordination
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

• Event-coordination surface identity and execution posture
• Operator claim requirement before event coordination execution begins
• Assigned-operator ownership for execution
• ServiceEvent-based coordination truth
• Event-specific lifecycle labels and operator-facing execution phases
• Record composition after ServiceEvent completion
• The boundary between coordination activity and settlement state

The current event-coordination runtime declares these lifecycle phases:

queued → claimed → arrived → in_progress → complete

The current runtime labels these phases as:

Queued → Confirmed → On Site → Active → Complete

The current runtime evidence contract is coordination-specific:

required_categories: []
optional_categories: []
min_per_category: 0

That means the runtime does not require physical-service photo evidence categories for completion. Operator UX may refer to setup or milestone photos as coordination context, but the runtime contract currently does not require photographic evidence for this surface.

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 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 scheduling equal execution truth.
• It does not make messaging equal workflow logic.
• It does not make vendor participation equal operator.x1 execution ownership.
• It does not make ServiceEvent completion equal settlement capture.
• It does not make job completion equal payment completion.
• It does not imply live vendor-management, messaging, calendar, dispatch, contract, or payout systems unless separately implemented and governed.
• It does not define the execution workflow for other surfaces such as auto-detailing, automotive advisory, freight, landscaping, or astrology.

Relationships to other layers

operator.x1

operator.x1 remains the canonical executable actor. An event coordinator or operator may coordinate multiple people, vendors, venues, or time-bound activities, but the current execution owner is still the assigned operator.x1 actor.

jobs.xen

jobs.xen represents governed work availability and assignment. For Event Coordination, executable coordination work should appear only after a governed request has become a Job. jobs.xen must not be treated as a detached job board.

workflow.x1

workflow.x1 owns process logic. Event Coordination may involve schedules, vendors, arrival, setup, live activity, and closeout, but those concepts must map into the surface workflow rather than becoming a separate hidden state machine.

desk.x1

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

ServiceEvent

ServiceEvent is the execution truth container associated with the Event Coordination Job. Job claim establishes operator ownership of execution. The ServiceEvent lifecycle progresses as coordination occurs, recording event 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 task state, job state, scheduling notes, messages, and settlement state.

Settlement

Settlement is economic state. Existing settlement endpoints and payment-state fields exist, but settlement capture is not the same as event coordination delivery, ServiceEvent completion, Job completion, or Record creation.

Current status

Event Coordination is partially implemented in the Planck runtime.

Implemented or currently represented:

• public/operator request entry for the event-coordination surface
• event intake packet structure with contact, asset/event details, request details, preferred timing, condition notes, and access notes
• submit path that treats event-coordination 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 association with the Job during operator execution
• event-coordination runtime registration
• event runtime evidence contract with no required categories
• event-specific lifecycle labels in operator admin/jobs UX
• 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
• event lifecycle visibility across all operator UX surfaces
• read-only settlement visibility across all relevant surfaces
• complete operator-facing explanation of event execution phases
• broad reusable surface-workflow scaffolding across multiple surfaces

Planned or not live:

• full vendor roster management
• live messaging or dispatch system
• calendar or scheduling engine as execution truth
• multi-operator execution ownership for one event Job
• event contract management
• payout orchestration for vendors or subcontractors
• regulated payment rails or settlement automation beyond existing records/endpoints

Implementation state

The wiki frontmatter marks this page as:

implementation_state: partially_implemented

That classification is intentional.

The Event Coordination surface has real Planck runtime behavior, including an active runtime registration and event-specific lifecycle labels, but full multi-actor coordination tooling, vendor management, messaging, calendar execution, and payout orchestration are not fully live.

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

Future direction

Future Event Coordination documentation should map each operator-visible coordination phase to ServiceEvent behavior without collapsing schedules, messages, vendors, or admin tasks into execution truth.

Potential future work should remain explicitly classified until implemented:

• clearer operator UX for confirmed, on-site, active, and complete stages
• runtime-config-driven lifecycle presentation
• optional event milestone evidence model if implemented later
• richer record and settlement visibility
• vendor or role coordination docs that preserve operator.x1 as current execution owner
• clearer public boundaries around what event coordination 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 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 event execution state.
• Do not make scheduling equal execution truth.
• Do not make messaging equal workflow logic.
• Do not make vendor participation equal operator ownership.
• 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 event coordination.
• Do not describe vendor management, dispatch, calendar, contract, payment, payout, or settlement automation as live unless implemented.
• Do not invent customer, operator, vendor, payment, or settlement capabilities that are not implemented.

Execution Example

A concrete Event Coordination job moves through the system like this:

1. Actor submits Request

   A client submits an event coordination request through an operator surface. The request may include contact details, event or asset details, requested service area, preferred days, preferred window, condition notes, and access 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 event execution state.

3. Assignment occurs

   An admin assigns the approved governance task to an event coordinator/operator. Assignment records who should receive the handoff. Assignment still does not start execution and does not assign every vendor, staff member, or role that may participate in the real-world event.

4. Job is created

   An explicit Create Job handoff turns the approved and assigned request into a Job. The Job is the executable event coordination 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 coordination occurs.

6. ServiceEvent begins

   The ServiceEvent becomes the execution truth container for the event coordination work. It carries the surface identity, operator identity, job reference, service scope, event context, payment fields where applicable, and completion outcome.

7. Coordination occurs

   The assigned operator coordinates the event context. Other real-world actors may be involved, such as a client contact, venue contact, vendor, staff member, or attendee-facing role. In the current runtime, those roles do not become separate executable actors unless separately implemented. Scheduling and messaging support coordination, but neither one is execution truth by itself.

8. ServiceEvent completes

   The operator completes the ServiceEvent when the event coordination work is delivered or closed. ServiceEvent completion represents execution completion for the event coordination 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:

Coordination roles that may exist in the real-world event context:

Related pages

• Execution Spine
• Canonical Namespace Spine
• Domain Architecture and Namespace Strategy
• Surface Runtime Model
• Records and Service Events
• Economic Structure Layer
• operator.x1
• jobs.xen
• workflow.x1
• desk.x1
• Settlement