Minerva Infra

AI systems can generate actions faster than organizations can authorize them. That gap creates the execution admissibility problem — something most AI architectures never address. I wrote about a governance-first architecture designed to solve this. TACA (architecture) + Minerva (runtime) Overview: open.substack.com/pub/kudles/p/g… Architecture overview: minervavms.com #AI #AIArchitecture #AIGovernance

Exactly. The missing piece in many architectures is the boundary between the two. Reasoning can generate proposals all day. Execution should only happen if the system can deterministically verify the action is admissible in the current state. Once that separation exists, governance stops being advisory and becomes enforceable.

@MinervaRuntime Exactly. Reasoning proposes. Execution enforces.

Most AI discussions focus on model behavior. Alignment Safety Prompting Evaluation But operational systems fail somewhere else. Not when a model produces an answer. When a system acts on that answer. The real control point is the boundary between: reasoning → execution If execution is reachable without governance, the system isn’t governed. Architecture matters.

@Hassan_Builds reasoning shouldn’t have root access

@MinervaRuntime The real bug is when reasoning gets root access.

The full technical architecture paper is now available: doi.org/10.5281/zenodo…

AI systems can generate actions faster than organizations can authorize them. That gap creates the execution admissibility problem — something most AI architectures never address. I wrote about a governance-first architecture designed to solve this. TACA (architecture) + Minerva (runtime) Overview: open.substack.com/pub/kudles/p/g… Architecture overview: minervavms.com #AI #AIArchitecture #AIGovernance

The full architecture overview is here: minervavms.com

Architecture determines persistence. Memory determines continuity of state. Authority determines what execution is permitted to occur. Models generate outputs. Systems determine what those outputs are allowed to become. Architecture determines persistence. Memory determines continuity of state. Authority determines what execution is permitted to occur. Models generate outputs. Systems determine what those outputs are allowed to become.

@asymmetricmind @DarioAmodei @karpathy @tacitprotocol Memory shapes the pattern. Authority gates execution. Architecture decides both.

1/4 continuity of work ≠ continuity of identity Persistence in AI systems is not a property of models. It is a property of architecture. Most discussions focus on models, training data, and benchmarks. But a deeper question remains: What actually persists in AI systems across sessions, resets, and multi-agent interactions?

@continuumport That’s a good way to describe it. Once reasoning becomes a proposal mechanism instead of a control surface, the system stops assuming execution authority lives inside the agent. The boundary ends up defining what the system is even capable of doing.

Interesting architecture. What you describe aligns with a structural separation between reasoning and execution authority. In many AI systems, authority is implicitly inherited by the reasoning layer. If execution authority is instead derived at runtime, reasoning becomes a proposal mechanism rather than a control surface. This effectively turns capability boundaries into representational constraints, not policy filters. In that sense the system behaves less like an autonomous agent and more like a governed execution topology. Architecturally, that shift changes where responsibility actually lives in the system.

Some properties of the AI runtime I built: • reasoning layers cannot reach execution directly • execution authority is derived at runtime, not stored in mutable state • unauthorized actions are structurally impossible to represent • every decision produces a deterministic trace • capabilities can expand, but only through a governed build → approve → activate lifecycle It turns out the whole system behaves differently when these are true.

The boundary decides whether execution is admissible. Once an action crosses it, the runtime commits through a deterministic sequence so that state mutation resolves in a single order. In practice that means the system never assumes concurrent actions can mutate state independently — they always resolve through the same commit path.

@MinervaRuntime In multi-agent systems, how does the runtime ensure deterministic ordering of state mutations after actions pass the governance boundary?

Most AI systems treat governance as an overlay. Execution happens. Logs are written. Dashboards update. We treat governance as part of the execution path. When declared authority and actual behavior diverge, execution does not continue. Not flagged. Not reviewed later. Not “handled downstream.” Stopped. Governance that cannot halt execution is monitoring. Governance that can halt execution is infrastructure.

One thing that becomes obvious when building governed AI systems: The hardest problem isn’t reasoning. It’s deciding where execution is allowed to happen. Most architectures assume execution paths already exist and then try to govern them afterward. The systems that behave reliably do the opposite. Execution paths don’t exist until the system proves they’re admissible.

The tools definitely reset the playing field faster than most experience transfers. But experience still shows up in a different way. Not in knowing the tools — in knowing when something that looks right probably isn’t. Anyone can generate answers now. The real skill is learning where these systems drift, where they oversimplify, and where a confident output is built on shaky assumptions. Shipping fast matters. Staying skeptical matters too.

Every industry used to have clear hierarchies. Experts with decades of experience, juniors learning from them. This is different for AI. Your 20 years of experience don't transfer when the tools change this fast. We're all juniors now, whether you admit it or not. So how do you avoid getting left behind? You don't wait for a list of approved resources. You build in public, ship fast, and learn from production failures.

GateReceipt at the commit boundary is the right primitive. The harder question is lifecycle. A receipt proves admissibility at that moment. The system still has to guarantee that mandate, scope, and revocation state remain valid under delegation pressure and concurrent execution. The boundary holds when the receipt is bound to live authority state, not just the request. Deterministic refusal only works if authority can expire as fast as execution scales.

Exactly. The authority layer has to sit upstream of actuation, not adjacent to it. In our architecture the execution request cannot reach the actuator without a valid GateReceipt issued at the commit boundary. No receipt → no execution. The enforcement path is deterministic and independent of the model runtime.

We’ve reached the point where AI can decide faster than organizations can authorize. Reasoning is no longer the bottleneck. Execution admissibility is. In every flight-critical and industrial system, generation and execution are separated. Commands can be generated freely. Execution requires independent authority. AI systems are now crossing that same boundary. We built the runtime authority layer that determines what is allowed to execute. coherenceprotocol.ai

One thing building governed systems teaches you quickly: Most architectures assume execution is inevitable. The only question they ask is whether the action should be allowed. But once execution is reachable, the decision has already been made. Control only exists where execution can still be refused.

Some properties we now treat as non-negotiable in AI execution systems: • reasoning layers cannot reach execution directly • every action must cross a governance boundary • execution eligibility is derived at runtime, not read from a mutable flag • unauthorized actions are structurally impossible • refusal is part of the architecture, not a feature • every decision produces a deterministic trace Most stacks treat these as features. They’re not. They’re invariants.

Some properties we now treat as non-negotiable in AI execution systems: • Cognition cannot reach execution directly. • Every action must cross a governance boundary. • Unauthorized actions are structurally impossible, not discouraged. • Execution eligibility is derived at runtime, never read from a mutable flag. • Refusal is part of the architecture. • Deterministic trace exists for every decision. • Human approval is a hard stop, not a workflow. Most AI stacks still treat these as features. They’re not. They’re invariants.

“Topology of veto” is a useful way to describe distributed constraint. The key distinction, though, is whether cognition can ever bypass that topology. In many systems, veto points exist — but cognition can still invoke execution directly and rely on downstream refusal. In a governance-first model, execution is structurally unreachable without crossing an explicit control boundary. The topology matters. But the non-bypassable boundary is what makes it control rather than supervision.

Chapter 12 — The Topology of Authority Chapter 10 showed that persistence in agent networks does not live only inside nodes, but also along their edges. Chapter 11 examined where execution authority can be rooted. This chapter asks a different question: how authority is distributed once execution crosses system boundaries. 1. The Missing Assumption When we speak about authority in systems, we instinctively look for a root. Who ultimately decides? Who has control? This instinct comes from hierarchical thinking. In simple systems, authority often does have a root. But agentic systems are rarely simple. Once execution is distributed across multiple layers, authority no longer lives in a single place. It becomes structural. 2. The Boundary Insight In the previous chapter, we introduced a third primitive: Σ = D ∪ A ∪ Auth Execution depends not only on task state (D) or adaptive memory (A), but also on permission to act (Auth). A key observation emerges when examining real execution paths: Authority is not evaluated once. It is re-evaluated at every boundary crossing. Each boundary becomes a place where execution may stop. 3. From Root to Structure Many architectures implicitly assume something like: authority → execution But real systems rarely behave this way. Instead, execution depends on multiple layers validating the action. For example: intent ↓ policy validation ↓ capability check ↓ runtime permissions ↓ infrastructure availability ↓ execution Any of these layers can halt the operation. Authority therefore does not behave like a root. It behaves like a structure. 4. Veto Points Each layer that can block execution acts as a veto point. Execution occurs only if every veto point allows it. Formally: execution allowed ⇔ ∀ vᵢ ∈ V : permit(vᵢ) Where V is the set of veto points governing execution. This is the structural property that emerges in complex systems: Authority becomes a topology of veto points. 5. Identity Is Only One Node Identity-centric architectures assume authority originates from identity. identity → authorization → execution This model works for many systems. But identity is only one possible veto point. Execution may still depend on: policy rules runtime capability infrastructure limits coordination with other systems Identity alone cannot guarantee execution. It participates in the topology but does not define it. 6. The Aviation Example Consider a modern aircraft. A pilot may attempt a maneuver. But execution depends on multiple systems: flight control laws envelope protection avionics safeguards air traffic control operational procedures The pilot proposes. But any of these systems may refuse. The aircraft flies only when all layers permit the action. This is a veto topology. 7. Why Systems Evolve This Way Distributed veto structures are not accidental. They emerge whenever systems must satisfy multiple independent constraints. Safety requirements. Resource limits. Legal obligations. Operational coordination. Each constraint introduces a boundary. Each boundary introduces a veto point. Over time, authority spreads across the system. 8. Authority as Topology Once this happens, authority is no longer a root. It becomes a topology — a distributed structure where execution emerges only when all constraints align. This topology may include: identity systems policy engines runtime capability checks infrastructure schedulers coordination mechanisms No single component fully controls execution. Control emerges from their interaction. 9. The Architectural Consequence This has an important implication for AI systems. If authority is distributed, replacing a single component does not necessarily change the authority structure. True replaceability requires understanding the full topology. A system that appears replaceable at one layer may still be constrained by others. Execution authority must therefore be analyzed structurally, not locally. 10. Compression Authority in complex agentic systems is not a single root of control. It is a distributed topology of veto points governing execution. Intent defines what should happen. Policy validates rules. Runtime validates capability. Infrastructure validates feasibility. Execution occurs only if every layer permits. Control is not defined by where authority originates, but by where execution can be refused. @DarioAmodei @MinervaRuntime @tacitprotocol @asymmetricmind @SasuRobert

The anchor matters. But in practice, authority has to terminate at execution — not identity or memory alone. In our model, identity and task state can inform authorization, but neither can independently trigger execution. Authority is derived from declared capability + policy + active mode — and revalidated per operation. That keeps replaceability structural. If the task is valid and policy permits it, execution proceeds. If not, the system halts — regardless of identity continuity. The gate isn’t just rooted somewhere. It is re-evaluated at every boundary crossing.

This makes the enforcement layer explicit. A non-optional gate in the execution path is exactly what separates supervision from control. Cognition proposes. Execution does not move without validated authority. The open architectural question is not whether a gate exists. It is what that gate is rooted in. If the token is identity-derived, authority continuity depends on identity integrity. If the token is state-derived (from a signed task capsule with declared capability), authority continuity depends only on task validity. Both can be fail-closed. Both can embed governance structurally. They differ in where replaceability breaks. That is the regime distinction.

AI governance is being negotiated in contracts. But contracts don’t execute code. If a system can act outside declared authority, policy alignment doesn’t matter. Governance must sit in the execution path. Cognition proposes. Governance decides. Execution acts. Remove that separation, and you don’t have control. You have supervision.

The gate sits between cognition and execution as a non-optional boundary. Cognition never calls tools directly. It submits a structured intent envelope. Governance validates declared capability, mode, and constraints before issuing an execution token. Execution will not run without that token, and trace + decision IDs must correlate on both sides. If trace consistency fails, the call is rejected — fail-closed, not logged. There is no implicit path from reasoning to action. If the envelope isn’t valid, the body never moves.

@MinervaRuntime Exactly... governance as a contractual overlay is supervision, not control. Cognition proposes → Governance decides → Execution acts only works if governance is structurally embedded in the execution path. In structural terms (Σ = D ∪ A ∪ Auth): D = declarative task state (what cognition proposes) A = adaptive working context (how it adjusts at runtime) Auth = execution authority (the hard gate) If Auth isn’t rooted in the execution path - impossible to bypass from inside the system - you don’t have architectural control. You have well-written rules. Continuity and replaceability depend on where authority is anchored, not on persistent identity or adaptive memory alone. Curious how you’re implementing that gate concretely in your runtime.

New governance is necessary. But we should be precise about what that means. Policy alignment and contractual safeguards are not the same as execution enforcement. Secure, reliable, predictable use requires governance that sits inside the runtime — where actions can be halted, not just reviewed. If cognition can act without crossing a control boundary, governance remains advisory. The next step isn’t better policy language. It’s embedding constraint directly into execution paths.

"Why not work on what kind of new governance is needed to ensure secure, reliable, predictable use of all frontier models, from all companies?"