Control, Execution, And Config Doctor¶

How a run is governed from submission to result — and why it cannot drift.

This is the heart of the platform: the governed path that turns a submission into a defensible result. Every step is explicit, recorded, and inspectable. Available today.

Why A Control Plane¶

The control plane is the durable source of truth for intake, governance, dispatch, and execution state. It exists so the platform can answer, for any result:

• what was submitted
• what was resolved
• what was approved or blocked
• what actually ran
• what evidence backs the result
• whether the result is ready to serve

Crucially, it is operational, not computational. It governs execution; it never changes the deterministic mathematics.

The Run Lifecycle¶

stateDiagram-v2
    [*] --> SubmissionReceived
    SubmissionReceived --> TranslationReady
    TranslationReady --> ConfigDoctorOpen: readiness gate
    TranslationReady --> RunRequested: gate not required
    ConfigDoctorOpen --> ConfigDoctorFinalized
    ConfigDoctorFinalized --> RunRequested
    RunRequested --> BundleResolved
    BundleResolved --> DispatchQueued
    DispatchQueued --> JobRunning
    JobRunning --> JobCompleted
    JobCompleted --> ResultsServed
    JobCompleted --> [*]

Each transition is recorded in an authoritative run registry — your complete operational history of what ran and when. Available today.

Config Doctor — Readiness You Can Trust¶

Config Doctor is a platform capability, not a utility. It sits between submission and execution and tells you — before you spend compute — whether a run is ready, and if not, exactly why and how to fix it. Available today.

flowchart LR
    A[Submission] --> B[Config Doctor]
    B --> C[Run approval]
    C --> D[Execution]

It performs:

• readiness assessment
• configuration validation
• missing-input detection
• scope-compatibility assessment
• deterministic repair recommendation
• launch governance

And it returns a clear, actionable outcome:

A defining rule: Config Doctor may recommend; it may not self-approve. Repair recommendations are deterministic, and approval stays a governed human decision.

Approvals And Waivers¶

Runs pass through explicit readiness evaluation, approval, and — where warnings are accepted — a recorded waiver with rationale. Nothing material executes on an implicit decision. Available today.

Execution¶

Once approved, a governed run bundle is resolved and dispatched asynchronously to isolated deterministic compute. The result returns with its evidence and is loaded into your analytical truth. Available today.

What This Means For You¶

• No surprises at runtime. Config Doctor catches readiness problems before they cost you a failed run or a wrong number.
• Every result is defensible, because the decision trail — submitted, validated, approved, executed, evidenced — is recorded.
• The maths stays trustworthy, because the control plane governs execution without touching the calculation.

Where The Platform Is Today¶

The full lifecycle — intake, Config Doctor, readiness, approvals, dispatch, execution, and the run registry — is available today. Reusable run templates and scheduling as first-class APIs are on the roadmap — see Capability Maturity And Status.