The Oracle Circuit: Asynchronous Supervisor Interrupts and State Serialization¶

Version: 2.0 (SOTA 2026 Standard) Target: coreason-runtime Orchestration Engine (src/coreason_runtime/orchestration/workflows.py)

Abstract: The Undecidability Problem¶

Autonomous inference engines inevitably encounter Out-of-Distribution (OOD) data—high-entropy anomalies (e.g., a proprietary binary format or an undocumented protocol) that cannot be resolved algorithmically.

Legacy 2024-era AI systems handled OOD data catastrophically, either by entering an unbounded while loop that exhausted cloud API budgets, or by silently hallucinating a false positive to satisfy a schema parser, permanently corrupting the downstream database.

The coreason-runtime mathematically accepts that for certain payloads, the probability of autonomous success is zero (\(P(success) \to 0\)). The Oracle Circuit formalizes human intervention not as a "system failure," but as a highly engineered, asynchronous state transition within the orchestrator's Finite State Machine (FSM).

1. The Escalation FSM (The Yield Cascade)¶

Before halting execution, the TensorRouter must exhaust its compute matrix to mathematically guarantee the task is genuinely undecidable. This is modeled as a strict state transition sequence:

• State \(S_0\) (Kinetic Execution): The orchestrator dispatches the task to the Tier 0 (Bare-Metal) endpoint. If the FSM logit masker traps on an impossible structural constraint, the state transitions to \(S_1\).
• State \(S_1\) (Oracle Escalation): The payload is escalated to a Tier 2 (Cloud API) endpoint. The system executes a bounded feedback loop (\(k_{max} = 3\)). If all 3 attempts return a ValidationError, the state transitions to \(S_{yield}\).
• State \(S_{yield}\) (Deterministic Yield): The engine formally concludes that further compute expenditure will not alter the execution outcome. It raises an explicit SuspendWorkflow exception to the Temporal orchestrator, formally halting the autonomous routing loop.

2. Asynchronous State Serialization (Zero-Compute Suspension)¶

Human supervisors operate on high-latency time scales (minutes to days). If the runtime executed a standard POSIX time.sleep() while waiting for human input, it would continuously block the Python worker's event loop and consume RAM, resulting in rapid resource starvation across the Swarm.

To prevent this, the runtime relies on Temporal's event-sourced architecture to achieve Zero-Compute Suspension.

2.1 Thread Eviction and Persistence¶

When \(S_{yield}\) is reached, the orchestrator serializes the entire workflow state—including local Python variables, Directed Acyclic Graph (DAG) execution history, and memory pointers—directly into the PostgreSQL persistence layer.

The workflow is physically evicted from the Python worker's RAM. The worker node's CPU utilization drops to \(0\%\), and the thread is immediately freed to process other Swarm tasks from the kinetic queue.

2.2 The Telemetry Beacon¶

Simultaneous to thread eviction, the worker emits an asynchronous SupervisorInterruptEvent to the Telemetry Broker. This acts as a high-priority beacon, alerting the IDE that a specific workflow_id is indefinitely suspended and requires resolution by a Reasoning Engineer.

3. Signal Injection and DAG Rehydration¶

To resume the suspended workflow, the system must securely inject the human's solution back into the execution graph without losing the historical context window.

3.1 Temporal Signals (RPC Injection)¶

The human supervisor does not restart the workflow, nor do they manually edit the underlying database rows. Through the IDE or CLI, the engineer transmits a Temporal Signal—a strongly typed, asynchronous Remote Procedure Call (RPC) containing the ground-truth resolution data (the "Resolving Prior").

3.2 The Resumption Protocol¶

1. The Wake Event: The Temporal cluster receives the Signal and schedules a wake event for the suspended workflow_id.
2. DAG Rehydration: An available Python worker pulls the serialized workflow history from PostgreSQL. It rapidly replays the event ledger to perfectly rebuild the exact Python call stack in volatile memory.
3. Prior Injection: The payload contained within the Temporal Signal is injected directly into the active DAG.
4. Execution Resumption: The workflow resumes execution at the exact \(N+1\) instruction line.

The runtime proceeds as if the human's response was returned by a standard AI function call, perfectly preserving the entire context window and allowing the Swarm to continue its downstream ETL logic flawlessly.