planck.x1

Purpose

planck.x1 is the pilot implementation namespace for QTM OS runtime validation. Planck is the live deployed system — the infrastructure that stores state, enforces governance, and runs every function QTM OS depends on.

Architectural role

Planck is the engine room. The operator desk, the admin desk, the governance flows, and the intelligence layer are all interfaces to things Planck manages underneath. It runs as Cloudflare Pages Functions backed by an R2 bucket (INTAKE_BUCKET).

What Planck manages

State objects

Planck stores and manages the core runtime objects:

Requests — the normalized form of an intake submission
Tasks — work items in the governance queue
Jobs — approved, assigned work units in the execution zone
ServiceEvents — active execution records
Records — sealed, durable outputs of completed work
Signals — emitted after Records are persisted; the trust layer artifact

All of these are stored as JSON objects in R2, keyed by structured prefixes.

Sessions and auth

Sessions are stored in R2 and resolved by session cookie. Operator identity is always session-derived — there is no client-supplied operator_slug that the server trusts for sensitive operations.

Module composition model

Planck follows a module composition model. The runtime is composed from distinct module families:

Module family	What it handles
Workflow	State transitions, lifecycle progression, escalation
Policy and Constraint	Eligibility checks, action gating, completion guards
Event	ServiceEvent creation, attribution, lineage
Record	Durable output construction, sealing
Governance and Audit	Review, approval, override, audit trails
Signal and Intelligence	Signal extraction from Records; Omni’s source material
Identity and Operator	Operator profiles, access state, role binding

Execution path through the runtime

Intake submitted
  → Request created
    → Task created (governance queue)
      → Task approved, assigned
        → Job created (execution zone)
          → Job claimed, ServiceEvent started
            → Evidence captured
              → ServiceEvent completed
                → Record created (sealed)
                  → ⭐ Signal emitted

What Planck enforces

Planck is the source of enforcement — not the UI. Key invariants:

Operator slug is always session-derived on write paths
Evidence requirements must be satisfied before a ServiceEvent can be completed
Signal emission only happens after a new Record is persisted (record_persisted = true)
Duplicate signals are blocked by a bucket.head() guard before writing
Operator-audience task writes are blocked if the caller’s slug does not match the task’s slug

Deployment

Functions — edge functions at /functions/ handle all API calls
Storage — R2 bucket holds all state
Frontend — Astro pages served as static assets from /dist/
Local development — wrangler pages dev dist --port 8788

Surface runtimes

Each service type (surface) has its own runtime configuration registered in src/lib/surface-runtime.ts. A surface runtime defines required_categories — evidence categories that must be captured before completion. Planck resolves the surface runtime at completion time and checks requirements.

Current status

Partially implemented. Pilot runtime active for the planck.x1 namespace including request submission, task governance, explicit task-to-job bridge, job state, ServiceEvent state, evidence validation, record composition, and signal emission.

Future direction

Additional surfaces map their internal production stages into ServiceEvent behavior. Module composition model expands as new QTM domains come online.

Guardrails

Preserve the distinction between planned, partial, and live.
Avoid marketing language.
Keep IDs, namespaces, and lifecycle terms precise.
Runtime enforcement is in Planck, not in the UI.