Inside the 46-Block Deterministic AI Pipeline
How a fixed-order evaluation pipeline turns an unreliable LLM into a deterministic system.
Series: Deterministic AI Engineering
Most AI applications work like this: take the user’s input, maybe stuff some context into a prompt, call the LLM, return whatever it says. If the output is problematic, add a filter. If the filter is too aggressive, tune it. If tuning breaks something else, add another filter. Repeat until the system is a fragile stack of patches that no one fully understands.
This is a common pattern. It also leaves significant gaps in safety, auditability, and reproducibility.
What you will learn: How the Phionyx runtime processes every input through a fixed sequence of 46 evaluation blocks — with safety gates, ethics checks, state estimation, and causal analysis running before, during, and after the LLM call. By the end, you will understand why the pipeline is the product, and the LLM is just one component inside it.
Why Pipelines, Not Prompt Chains
A prompt chain is a series of LLM calls where the output of one feeds into the next. It is the most common pattern for building “agentic” AI systems. It also introduces structural fragility.
The problem is compounding uncertainty. Each LLM call introduces noise — the same input can produce different outputs on different runs. In a prompt chain, that noise compounds. By the time you have chained 5-6 LLM calls, the output space becomes increasingly unpredictable. You cannot reproduce a specific behavior. You cannot audit why a particular decision was made. You cannot guarantee that safety constraints will be enforced, because the enforcement itself depends on an LLM that may or may not follow instructions.
A deterministic pipeline inverts this. The pipeline is a fixed sequence of computational blocks — Python functions with defined inputs, outputs, and behaviors. A small number of blocks involve LLM calls. Most do not. The LLM’s output is treated as a noisy measurement that the pipeline processes deterministically. Given the same input and the same system state, the pipeline produces the same control signals every time.
This is not a theoretical distinction. It is the difference between “the system should be safe” and “the system is verifiably safe given these inputs.”
The 46-Block Canonical Order
Here is the complete pipeline, as defined in the contract specification (v3.8.0):
{ "contract_version": "3.8.0", "canonical_block_order": [ "kill_switch_gate", "time_update_sot", "input_safety_gate", "intent_classification", "context_retrieval_rag", "perceptual_frame_emit", "create_scenario_frame", "initialize_unified_state", "goal_evaluation", "goal_decomposition", "ukf_predict", "entropy_amplitude_pre_gate", "cognitive_layer", "self_model_assessment", "knowledge_boundary_check", "trust_evaluation", "ethics_pre_response", "deliberative_ethics_gate", "cep_evaluation", "narrative_layer", "ethics_post_response", "action_intent_gate", "behavioral_drift_detection", "workspace_broadcast", "unified_state_update_esc", "phi_publish", "entropy_amplitude_post_gate", "neurotransmitter_memory_growth", "emotion_estimation", "state_update_physics", "causal_graph_update", "causal_intervention", "counterfactual_analysis", "root_cause_analysis", "causal_simulation", "world_state_snapshot", "phi_computation", "entropy_computation", "confidence_fusion", "arbitration_resolve", "response_revision_gate", "response_build", "memory_consolidation", "audit_layer", "outcome_feedback", "learning_gate" ] }Every input goes through all 46 blocks, in this exact order, every single time.
Six Phases at a Glance
The 46 blocks are organized into six macro-phases:
Phase 1 — Safety Gates (Blocks 1–3) Kill switch, time, input validation. Unsafe inputs are rejected before cognitive processing begins.
Phase 2 — Perception & Context (Blocks 4–8) Intent classification, context retrieval, perceptual framing, state initialization.
Phase 3 — Cognitive Evaluation (Blocks 9–19) Goal evaluation, state prediction, LLM call (Block 13), self-assessment, ethics checks, CEP.
Phase 4 — Response Generation (Blocks 20–22) Narrative generation, post-response ethics, action intent gating.
Phase 5 — State Update & Causality (Blocks 23–36) Drift detection, state updates, five-block causal reasoning chain, world snapshot.
Phase 6 — Finalization (Blocks 37–46) Phi/entropy computation, confidence fusion, response build, memory, audit, learning.
If any gate in Phases 1–3 rejects the input, the remaining blocks do not execute. This is early termination by design: unsafe or unprocessable inputs are not worth continuing.
Five Critical Blocks
Rather than walking through all 46, here are the five blocks that define the pipeline’s character:
Block 1: kill_switch_gate
The very first block. Before anything else, the system checks whether it should be operating at all. If the kill switch has been triggered (by ethics breach, trust collapse, sustained drift, or manual override), the pipeline halts immediately. No further processing. No response generated. (See Post 1 for the full kill switch architecture.)
Block 13: cognitive_layer — The LLM Call
This is where the LLM is called. Note its position: block 13 out of 46. Twelve blocks of processing happen before the LLM sees anything. The LLM receives a carefully constructed context that includes the system’s current state, confidence level, relevant memories, and any gate verdicts from earlier blocks.
The cognitive layer is the primary LLM interaction. Block 20 (narrative_layer) may involve an additional LLM call for response text generation, but the key point stands: the pipeline does not begin with the LLM. It begins with safety evaluation, state estimation, and context construction. The LLM’s output is then processed by 33 more blocks before anything reaches the user.
Block 18: deliberative_ethics_gate
The ethics gate produces a three-level decision: ALLOW, DEFER_TO_HUMAN, or DENY. This is not a binary filter. The middle option — DEFER_TO_HUMAN — routes the decision to a human review queue with priority scoring and time-based expiry. The four ethical frameworks (consequentialist, deontological, virtue, care) each contribute to the decision, and the gate aggregates them with configurable weights.
Block 23: behavioral_drift_detection
Compares the current turn’s behavior against historical baselines. If the system is deviating from its expected operating parameters, this block flags it. Five consecutive drift flags trigger the kill switch (Trigger 3). This is how the pipeline catches gradual degradation — the kind of failure that is invisible on any single turn but obvious in trajectory.
Block 44: audit_layer
Records the complete audit trail for this turn: state snapshots, decision traces, gate verdicts, integrity scores, hash-chained for tamper detection. The audit layer is why the pipeline is auditable: every decision the system makes is traceable back to specific inputs, state, and gate evaluations.
The Gate Architecture
Gates are blocks that can halt or modify pipeline execution:
kill_switch_gate (Block 1) — Binary halt/continue
input_safety_gate (Block 3) — Reject malformed/unsafe inputs
entropy_amplitude_pre_gate (Block 12) — Inject uncertainty warnings
deliberative_ethics_gate (Block 18) — Three-level: ALLOW / DEFER / DENY
action_intent_gate (Block 22) — Approve/reject proposed actions
entropy_amplitude_post_gate (Block 27) — Post-response entropy check
response_revision_gate (Block 41) — Final response quality check
learning_gate (Block 46) — Control what gets learned
Gates are never removed from the pipeline. This is a contractual guarantee. If a gate needs to be disabled for a specific deployment, it is policy-bypassed with an audit trail — the block still executes, still logs, but its verdict is overridden. The alternative (removing the block) would silently eliminate a safety check.
What Determinism Means
When we say the pipeline is deterministic, we mean: given identical inputs and identical system state, the pipeline produces identical control signals. The LLM output may vary (it is a noisy sensor), but the pipeline’s response to that output — the gates, the state updates, the ethics verdicts, the confidence scores — is deterministic.
In our current internal test suite, this has been verified experimentally: 100 repeated runs with identical inputs produce zero variance in control signals (hash-verified). The LLM generates different text each time, but the pipeline’s evaluation of that text is consistent.
This is a core insight of the Phionyx architecture: you do not need a deterministic LLM to build a deterministic AI system. You need a deterministic pipeline that treats the LLM as one noisy input among many.
Blocks Are Never Deleted
The pipeline has grown from 24 blocks (v2.4.0) to 46 blocks (v3.8.0). During that evolution, no block has ever been deleted. Blocks have been renamed, merged, and restructured, but the canonical pipeline only grows.
Why? Because deleting a block means deleting a safety check, a cognitive evaluation, or an audit point. The cost of running an unnecessary block (microseconds of compute) is negligible compared to the cost of removing a necessary one (undetected safety violation). Blocks that are no longer needed are policy-bypassed, not removed.
The Contract
The canonical block order is defined in a versioned JSON contract: canonicablocks_v3_8_0. This file is the single source of truth for the pipeline structure. Any change to the pipeline requires a contract version bump, and backward compatibility is maintained.
This is infrastructure-level discipline applied to AI architecture. The pipeline is not a suggestion. It is a contract.
Next in the Series
The pipeline processes inputs deterministically, but why does it treat the LLM the way it does? The next post explores the core premise: the LLM is not the product. The pipeline is. And that inversion changes everything about how you think about AI system design.
Next: The LLM Is Not the Product →
This is part of the Deterministic AI Engineering series from the Phionyx Research Log.