The Governed Intelligence Cockpit

How intelligence proposes and deterministic systems decide.

This page explains the governed intelligence stack: the four layers, three operator surfaces, two registries, and one proof chain. Read this if you want to understand how Cascade routes, GE-OS governs, workers execute, DECC enforces, and receipts prove.

The Core Thesis

Models propose. Systems decide.

AI models are probabilistic. They generate proposals, suggestions, and candidate actions. They should never directly execute. Between proposal and execution, deterministic systems must route, gate, audit, and enforce. This is the governed intelligence cockpit: the operating environment that keeps probabilistic intelligence safe, auditable, and bounded.

THE GOVERNED INTELLIGENCE COCKPIT
OPERATOR SURFACES
Telegram · CLI · Dashboard · API
CASCADE ROUTER
Classify · Risk Gate · Worker Select · Route Plan
REGISTRY LAYER
Worker Registry · Session Registry · State Memory
GE-OS / CPL GOVERNANCE
12-Stage Pipeline · Hard Limits · Soft Policies · Exceptions
WORKERS (Execute in Bounds)
Deterministic · Ollama · Claude · Codex · Human · No-Action
DECC HARDWARE BOUNDARY
Final Enable · Hardware Enforcement · Receipts

1. Operator Surfaces

Tasks enter the system from three sources: human operators (Telegram, CLI, Dashboard) or automated systems (API). Everything is suspect. Origin is irrelevant. The system treats all proposals equally and gates them all the same way.

Telegram

Mobile operator interface. Commands arrive as messages. State is persistent across sessions. Replies are receipted, searchable, auditable.

CLI

Local command-line interface. Used by engineers, developers, and automation. Every command is logged, gated, and receipted.

Dashboard

Web-based control panel. Real-time state visualization, decision logs, receipt ledger inspection, audit exports.

API

RESTful endpoint. For system-to-system integrations. Request signing, rate limiting, and per-tenant isolation.

2. Cascade Router — The Control Plane

Cascade receives the task from any operator surface and decides where to route it. It is the control plane. It does not execute; it decides who should execute and under what constraints.

Classify

Parse the task. Extract intent, domain, complexity, and risk level. Is this a routine question, a code generation request, a capital decision, a hardware command?

Risk Gate

Check 10 deterministic predicates: cost, privacy, coherence, drift, freshness, thermal budget, spectral alignment, policy match, capital availability, and approval status. Binary outcome. Any failure blocks the action.

Worker Select

Choose the cheapest worker that can handle the task. Try deterministic engines first (fast, zero LLM cost). Then Ollama (local inference, low latency). Then Claude or Codex (higher cost, richer reasoning). Last resort: human approval or no-action.

Route Plan

Execute the task with the selected worker, under the constraints and cost budget from the risk gate. Track every step. If the worker fails, escalate to the next worker or deny with explanation.

3. Worker and Session Registry — The Process Table

The registry layer tracks available workers (what compute they have, what permissions, what cost model), active sessions (who is logged in, what state they're holding, what multi-turn conversations are in progress), and session memory (embeddings, patterns, feedback from prior decisions).

Worker Registry

Catalog of available execution engines: deterministic Python, Ollama instances, Claude API accounts, Codex Sovereign, external APIs, human approvers. Each has metadata: cost per call, latency, failure rate, permissible domains, resource limits.

Session Registry

Active sessions. User identity, login time, permissions, current task, state variables, conversation history. Multi-turn coherence depends on this.

Memory Layer

Embeddings of successful task completions (pattern memory), learned failure modes, spectral signatures of anomalies, user preferences, historical feedback. Accelerates subsequent similar tasks.

Status: Worker/Session Registry scaffold shipped; 95 registry tests passing; no session launcher or live worker execution yet.

Implemented scaffold only. Live Telegram session launch, TeamPlan, and worker execution remain future phases.

4. GE-OS and CPL — Governance Law

GE-OS is the Governed Execution Operating System. It enforces a 12-stage mandatory pipeline for every action. CPL (Governance Policy Language) is the syntax for writing hard limits, soft policies, and exceptions. Governance is not a library; it is the kernel.

12-Stage Pipeline

Every execution follows: (1) Request arrives, (2) Session lookup, (3) Identity verification, (4) Permission check, (5) Risk assessment, (6) Cost cap check, (7) Coherence gate, (8) Policy LSM evaluation, (9) Approved worker dispatch, (10) Execution, (11) Receipt emission, (12) Cleanup. No shortcuts. No exceptions in the pipeline itself (exceptions are handled at the policy layer).

Hard Limits

Immutable thresholds that never change at runtime: max simultaneous sessions, max cost per operation, max thermal budget, max capital committed. Violate a hard limit and the entire system shuts down, not just the operation.

Soft Policies

Tunable rules that evolve: approval thresholds, cost budgets per domain, freshness windows, spectral drift tolerances. Change soft policies. Never change hard limits.

Exceptions

Rare, explicit, audited overrides. An exception says "this operation violates soft policy X, but I (the human) approve it for reason Y." Exceptions are logged, timestamped, cryptographically signed, and reviewed monthly. Not a back door. A trap door with an alarm.

5. Workers — Execution (in Bounds)

Workers are the actual compute engines. They are chosen and bounded by Cascade. They execute under the constraints set by GE-OS. They do not make routing decisions. They do not bypass gates. They execute or they fail, and both outcomes are receipted.

Deterministic

Python functions, symbolic logic, decision trees. Cheapest, fastest, zero external calls. Used for classification, data transformation, simple logic.

Ollama

Local LLM inference (7B models, open source). Low latency, no external API calls, runs on GPU. Good for domain-specific tasks, private data, and cost-sensitive applications.

Claude / External LLM

Closed-model APIs (Claude, Gemini, GPT). Higher cost, richer reasoning, higher latency. Used when local models can't handle the complexity.

Codex Sovereign

DSL compiler that emits to FPGA frames, state machines, REST endpoints, mesh frames. Used for complex governance rules, hardware commands, multi-target orchestration.

Human

Escalation to a human operator. Used when cost is high, stakes are uncertain, or the system is unsure. The human is the final authority.

No-Action

Deny the request. Return a reason: cost exceeds budget, policy violation, risk too high, approval denied, etc. Still receipted. Still auditable.

6. DECC — Hardware Enforcement Boundary

DECC is the Deterministic Execution Control Circuit: an FPGA that owns the final enable line. Software proposes; silicon decides. For use cases where the stakes are highest (medical implants, nuclear plant controls, aerospace autonomy), DECC enforces the final gate in hardware where software cannot override it.

Hardware Attestation

Every execution proposal is cryptographically signed and verified in silicon. Proposal includes: task, worker, cost, duration, risk gates. Hardware checks the signature, evaluates the gates, and decides go/no-go.

Measured Latency

12.77ms from proposal to hardware disable, if the gate fails. Known, measured, independent of software scheduler jitter. Real-time constraint satisfaction.

Enable Line

A single-pin output from the FPGA. Go=+3.3V, no-go=0V. Drives the load enable on the main power supply, or a solenoid kill switch, or a motor contactor. No software can override once the FPGA has decided.

7. Receipts — Tamper-Evident Proof

Every decision is recorded in an immutable, hash-chained receipt ledger. Not a log file that can be edited. Not a database that can be rolled back. A cryptographic proof chain that shows exactly what happened, in order, with no gaps.

Receipt Chain

Each receipt includes: timestamp, user, task, Cascade route, worker, cost, decision (allow/deny/escalate), duration, hash of previous receipt (forward-chaining). Signed with HMAC. Cannot be forged, reordered, or deleted without breaking the chain.

Replay

Any decision can be replayed: given the task and the receipt, re-run the same gates and verify the outcome was correct. Useful for audits, compliance reviews, and incident investigation.

Audit Export

Export receipts for regulatory review (SOC2, ISO 27001, FDA SaMD, etc.). Timestamped, cryptographically signed, complete. Chain of custody provable.

8. Why This Matters

Probabilistic systems for novelty. Models are good at generating ideas, translations, summaries, and insights. They should be allowed to do that.

Deterministic systems for execution. Anything that affects the real world—a trade, a medical decision, a motor command, a person's livelihood—must go through deterministic gates, be gated, be audited, and be undeniable.

Humans are always final. The cockpit is for safety and transparency. The human operator remains the final authority. Escalation is always available. No decision is irreversible without human consent.

Governance is the moat. Competitors can clone applications. They cannot replicate this stack. It takes years to build, capital to certify, and discipline to operate. It is defensible.

Ready to build on the stack?

See how our products apply this architecture to your domain.