oracle.x1

Purpose

oracle.x1 is the intake and structuring layer for QTM OS. Oracle’s job is to receive raw requests, validate and structure them into governed job packets, and route them upstream into the execution spine. It is the entry point for all work that flows into the system.

Oracle does not execute work. It does not assign operators. It does not govern. It captures, structures, and hands off.

Current implementation

The current Oracle implementation is qtm-x1 — a Cloudflare Pages application backed by a Cloudflare D1 database. qtm-x1 handles the following:

Admin-authenticated intake form for capturing service requests
Request normalization and storage in D1 (requests table)
Job packet construction (v0.02 schema with grouped sections: request, task, routing, intelligence, economics, actor, handoff)
Staging of outbound job packets in D1 (planck_jobs table)
Bridge to Planck via POST /api/system/intake (fire-and-forget, non-blocking)
Admin pipeline views: /pipeline, /pipeline/jobs, /pipeline/handoffs

Architectural role

Oracle sits at the upstream boundary of the execution spine, immediately before Planck:

External request
  → Oracle captures + structures
    → Job packet constructed
      → Planck task created (governance queue)
        → Execution spine continues in Planck

Oracle is the only system that writes to the intake boundary. Planck does not accept unstructured input — it requires a validated, governed packet that Oracle produces.

What Oracle does

Accepts raw requests (structured intake form, admin-only)
Normalizes requests into canonical form
Constructs job packets with routing, surface, and context metadata
Persists packets locally (D1) for audit and retry
Forwards packets to Planck for governance and assignment

What Oracle does not do

Oracle does not assign operators
Oracle does not approve or review work
Oracle does not create ServiceEvents
Oracle does not produce Records or Signals
Oracle does not determine pricing or settlement
Oracle does not have execution authority over any downstream state

Relation to Planck

Planck receives Oracle’s job packets via the system intake endpoint (POST /api/system/intake). Once a packet lands in Planck:

Planck creates an admin-audience Task (status: open)
The task enters the governance queue at /admin/desk/tasks
Admin reviews, approves, and assigns an operator
The execution spine continues entirely within Planck

Oracle’s role ends at handoff. From that point forward, the packet is Planck’s responsibility.

Relation to Omni

Omni is the intelligence and observation layer. It reads signals, records, and system state to produce recommendations. Omni does not receive Oracle packets directly — Omni observes what happens after execution completes. Oracle and Omni operate in different zones of the execution timeline.

Relation to this wiki

This wiki documents Oracle’s architecture and role. It is not a runtime component. Changes to Oracle’s behavior are reflected in qtm-x1 source code, not in this document.

Job packet schema (v0.02)

Oracle produces job packets with the following top-level structure:

Field	Description
`id`	Job ID (`job_*`)
`request`	Normalized request fields (`id`, `surface`, `created_at`)
`task`	Task metadata (`id`, `title`, `description`, `status`)
`routing`	Routing context (`surface`, `operator_slug`)
`intelligence`	Omni context and signal references
`economics`	Pricing, settlement scope
`actor`	Operator targeting context
`handoff`	Handoff state and destination

v0.01 flat-field aliases (surface, status at root) are supported for backward compatibility.

Current status

Active. qtm-x1 is deployed to Cloudflare Pages. The Oracle → Planck bridge (/api/system/intake) is implemented. Local job packet staging in D1 is operational. Admin pipeline views are live.

The intake boundary is not yet open beyond admin-authenticated creation. Future direction includes structured intake paths for external origination (MLS, operator request, agent-originated).

Guardrails

Oracle is a boundary system. Do not extend its scope into execution.
The job packet schema is versioned. Do not break v0.01 aliases while v0.02 deploys.
Bridge calls to Planck are fire-and-forget. Oracle does not block on Planck’s response.
Runtime enforcement is in Planck, not in Oracle.