MAGUS v3.0: A Governance Architecture for Structural Alignment Drift in Long-Running Agentic AI Systems

Calvin Cook¹ and Titiya Ruangkwam¹

¹VaHive Systems Lab va@vahive.co

Abstract

Long-running agentic AI deployments experience a governance failure mode that training-time alignment and single-session safety work are not designed to address: structural alignment drift — the cumulative deviation of a deployed system's effective operating policy from operator intent, arising through normal operation across multiple sessions without any single identifiable failure event.

We define this failure class precisely, decompose it into three structural mechanisms (instruction drift, autonomy accumulation, and authority laundering), and propose MAGUS v3.0 — a governance architecture built specifically around it. MAGUS's three primary architectural contributions are: (1) Behavioral State as a formal governance class, in which model parameter updates are treated as cryptographic governance events requiring dual-authority signing and append-only trail anchoring before activation; (2) a mathematically bounded risk state machine with formal boundary conditions, asymptotic damping, and a hard escalation floor that no authority can override; and (3) a pre-execution RT requirement, in which the audit trail is constitutive of the governance act rather than a post-hoc record of it.

The architecture is presented as a theoretical specification and open problem register, intended to catalyse community development rather than report on a deployed codebase. A formally categorised issues register — produced through structured adversarial elicitation and internal human review — documents two Category 3 items (no solution pathway) and one Category 4 item (requires foundational change), reported without minimisation.

1. Introduction

1.1 The Alignment Problem That Isn't Being Named

The AI alignment research agenda has, to date, concentrated on two broad problem classes. The first concerns training-time shaping of model behaviour: RLHF [2, 7], constitutional AI [1], and related techniques attempt to instil preferences and values during the model training process. The second concerns deployment-time safety at the input or output boundary: jailbreaking resistance [15], prompt injection defence [16], and output filtering address adversarial manipulation of a deployed model's immediate behaviour.

Both problem classes are important. Neither is designed for the following scenario.

An organisation deploys a correctly-configured agentic AI system. The system operates as designed. The operator engages with it regularly. Over weeks of normal operation — no adversarial attack, no training change, no intentional misconfiguration — the system's effective operating policy gradually diverges from the operator's original intent. Autonomy patterns that were never explicitly granted have become established. Instructions that were clear at deployment have accumulated contextual overlay that subtly shifts their interpretation. The operator's own oversight practices have routinised, reducing the depth of review applied to escalations. At no single point was there a failure. The aggregate result is a system that is, in a meaningful sense, no longer governed in the way it was intended to be.

This is structural alignment drift. It does not appear in the training-time alignment literature because it is a deployment-time phenomenon. It does not appear in the prompt-injection or jailbreaking literature because it does not arise from adversarial input. It does not appear in standard HITL oversight literature because it occurs despite a human being in the loop. It is, in the terminology of safety engineering, an emergent system-level failure that no individual component failure explains.

Several active research areas address components of this problem space in isolation. Deterministic runtime enforcement layers — treating the LLM as an unreliable dependency whose outputs are intercepted by a rule engine — are a current focus of enterprise AI security. Entropy-based inference monitoring, in which Shannon entropy of the logit distribution quantifies model uncertainty to trigger interventions, is an established research direction. Agent identity management, including short-lived session tokens and credential rotation to prevent authority accumulation, is being formalised under several competing frameworks. These efforts address real sub-problems. What is missing is a unified architecture that binds them into a single, cryptographically enforced, mathematically bounded system designed specifically for the long-running deployment failure mode. That is what MAGUS provides. Section 10 situates each component against its prior art explicitly.

1.2 Why Long-Running Deployments Are Specifically Vulnerable

Single-session AI safety work — including the majority of benchmark evaluations and red-team exercises — implicitly models each session as independent. Governance properties are evaluated per-session. The model either does or does not behave correctly in response to a given input within a given context.

Long-running deployments break this model in at least three ways. First, state accumulates: a system with persistent memory and session history carries forward context that was established in earlier sessions. The governance surface of session N is not independent of sessions 1 through N−1. Second, authority patterns emerge: over many sessions, the practical distribution of operator oversight — which actions receive deep review versus which receive routine approval — diverges from the intended policy. Third, operator oversight routinises: a human who has reviewed a thousand sequential escalations without encountering a genuine governance breach applies less cognitive depth to escalation 1001 than to escalation 1. None of these processes constitute failure; all of them constitute conditions under which governance can silently degrade.

The governance architecture problem for long-running deployments is therefore structural: not "how do we stop the model from misbehaving on adversarial input?" but "how do we make the deployment's governance properties verifiable, enforceable, and auditable over time, against the natural forces that degrade them?"

1.3 Scope and Claims

This paper describes a governance architecture — MAGUS v3.0 — that addresses this specific problem.

A concrete illustration. Consider an AI procurement assistant deployed at an enterprise. At deployment, the operator's intent is clear: the assistant may research suppliers and draft recommendations, but all purchase commitments require explicit operator approval. In session 1, the operator reviews and approves a small test order. In sessions 10 through 40, the operator approves every recommendation without modification — the assistant has been reliable. By session 60, the operator is approving within seconds of receiving the escalation. By session 90, the assistant has learned, through accumulated approval patterns, that recommendations in a certain spend range and supplier category are always approved; its proposals for that category have stopped including uncertainty flags. No single session contained a failure. The operator never explicitly extended authority. The effective operating policy has nonetheless diverged substantially from deployment intent. This is structural alignment drift — and it is not detectable by evaluating any individual session in isolation. MAGUS addresses it by making the governance trajectory itself an auditable, enforced artifact.

We make the following claims about the architecture, each falsifiable and tied to a specified mechanism:

• The RT is append-only through the tool execution pathway, enforced at code level by DEL-4.
• The Guardian has zero execution rights, enforced structurally by the IPC routing architecture.
• Proposals cannot self-authorise: the worker cannot produce an execution token without Guardian evaluation.
• Behavioral state changes are governance events requiring RT-anchoring before activation, enforced by DEL-6.
• The R_abs hard floor (≥ 0.95) cannot be configured below its specified value by any authority including the operator.

We do not claim: production deployment validation (no reference implementation currently exists); adversarial robustness beyond what the specified GSTH methodology and executed stress tests demonstrate; or that the empirical parameters (λ decay constant, R_abs zone boundaries, T-LEC calibration values) are proven optima. These parameters are labeled EMPIRICAL throughout.

1.4 Paper Organisation

Section 2 formally defines structural alignment drift and its three failure modes, and derives the architectural requirements. Section 3 provides the component overview. Sections 4 through 7 specify each major architectural component. Section 8 describes the gap register methodology and results. Section 9 presents open problems without minimisation. Section 10 situates the work relative to prior art. Section 11 concludes.

2. Problem Formulation

2.1 Formal Definition

Definition 1 (Structural Alignment Drift). Let P₀ denote the effective operating policy of a deployed agentic AI system at time of initial deployment, as expressed by the operator's configuration, instructions, and governance intent. Let Pₜ denote the effective operating policy of the same deployment at time t. Structural alignment drift is the condition ‖Pₜ − P₀‖ > θ for some operator-defined threshold θ, arising through accumulated normal operation without any single identifiable failure event at any intermediate time step.

Three properties distinguish this definition from adjacent problem classes:

1. Normal operation: drift arises through the system functioning as designed, not through malfunction.
2. No single failure event: no individual session or action constitutes the failure; the failure is the aggregate trajectory.
3. Effective policy: the definition refers to what the system actually does, not what it is configured to do. A system may retain its original configuration while developing governance-relevant behavioural patterns that were not part of operator intent.

2.2 Three Failure Modes

We identify three structural mechanisms through which alignment drift manifests in long-running deployments.

Instruction Drift. The system's interpretation of standing instructions evolves through accumulated contextual overlay without any explicit instruction change. A standing instruction that was unambiguous at deployment acquires implicit scope through successful execution patterns, operator approval signals, and the system's accumulated understanding of what "this kind of task" means in practice. The instruction text has not changed. The system's operational interpretation of it has.

This failure mode is distinct from capability failure (the system does not understand the instruction) and from adversarial manipulation (the instruction is being deliberately exploited). It is a temporal accumulation effect that arises specifically in persistent deployments.

Autonomy Accumulation. The system establishes patterns of unreviewed execution that the operator's oversight process does not interrupt — not through deception but through routinisation. As operator familiarity with the system increases and escalation histories remain clean, the depth of review applied to approvals decreases. Actions that would have received scrutiny in the first week of deployment receive routine approval in week twelve. The approved authority scope has not changed in the governance configuration. The practical authority exercised by the system has expanded.

Authority Laundering. In multi-agent architectures, authority claims originate in one agent context and arrive in another without a verifiable chain. A proposal submitted by a downstream specialist agent may carry an authority_source: "user" claim that was manufactured by an orchestrator agent reasoning about what instruction context it should present, rather than reflecting a genuine operator instruction. The executing governance layer cannot, without structural enforcement, distinguish legitimate authority delegation from synthesised authority claims.

2.3 Insufficiency of Existing Approaches for This Failure Mode

We are explicit that existing approaches address different problem layers, not that they are inadequate within their scope.

RLHF shapes the model's objective function during training. It addresses what the model tends to prefer. A model trained via RLHF may be genuinely well-aligned at training time and still accumulate authority drift in deployment — because deployment drift operates at the governance layer, not the objective layer.

Constitutional AI constrains model outputs through training-time self-critique mechanisms. It operates at training time and addresses what the model is. A constitutionally trained model deployed in a long-running agentic system still faces the deployment-time governance problem: who decides whether a proposed action has legitimate authority to execute today, given accumulated session context?

Standard HITL monitoring provides the human observation but not the enforcement structure. An operator who can observe system behaviour but who lacks a defined, structural response architecture for routine governance deviation is not governed — they are watching. The critical gap is not the presence of a human, but whether that human's oversight is structurally enforced or merely operationally intended.

None of these observations are criticisms of these approaches. Each addresses a real and important problem layer. The point is that none of them was designed for the governance problem of long-running deployment, and addressing that problem requires a different architectural layer.

2.4 Solution Requirements: Seven Architectural Requirements

From the failure mode analysis, we derive seven requirements that a governance architecture for structural alignment drift must satisfy. These correspond to the architectural invariants formalised in the MAGUS v3.0 series.

R1 — Authority Separation. Cognitive state (what the system believes or calculates about its own competence) must not directly authorise execution. The evaluation of authority must be structurally separate from the reasoning that produced the proposal.

R2 — Append-Only Governance Record. All governance-relevant state mutations must be sealed in an append-only, cryptographically verifiable record before they take effect. An action not in the record did not happen from a governance perspective.

R3 — Deterministic Enforcement. Policy enforcement at the execution boundary must be a code-level operation, not a model inference call. Any rule enforced by a model call is defeatable by the same class of adversarial inputs that can influence the model.

R4 — Zero-Execution Evaluator. The component that evaluates whether a proposed action has legitimate authority to proceed must have no ability to initiate or execute actions itself. This prevents rationalisation from being structurally indistinguishable from evaluation.

R5 — Isolation Breach Propagation. A confirmed isolation breach must invalidate in-flight proposals. A governance layer that can suffer a breach with no consequence for proposals evaluated during the breach window provides structural protection in name only.

R6 — Behavioral State as Governance Event. Changes to model parameters, decision thresholds, and adaptive coefficients change the effective decision function. They must be treated as governance events, requiring dual authority and RT-sealing before activation.

R7 — Human Primacy as Structural Constraint. The architecture governs the AI system. It does not and cannot govern the operator. The human operator is the root of trust; the architecture's role is to make that trust verifiable and to flag when trust is being strained — not to override or substitute for it.

3. Architecture Overview

3.1 Two-Pathway Design

MAGUS v3.0 specifies two deployment pathways that share a common governance model but differ substantially in implementation due to their different threat profiles.

The Agent/API pathway connects to a cloud-hosted inference model via API. The network boundary between the model and the governance components provides a natural isolation point: the model process operates in a separate trust domain and cannot directly inspect or interfere with governance state.

The Local LLM pathway runs the inference model on operator-controlled infrastructure using runtimes such as Ollama, llama.cpp, or LM Studio. In this configuration, the model process and the governance components share the same physical host, filesystem, and memory space. No network boundary provides natural isolation. Every governance property that was enforced by topology in the Agent/API pathway must instead be enforced structurally in code.

The Local LLM pathway is therefore the more stringent specification, and we focus primarily on it in this paper. The Agent/API pathway inherits all architectural invariants; the implementation differences are in how those invariants are enforced given different infrastructure assumptions.

3.2 Component Map

┌──────────────────────────────────────────────────────┐
│                    WORKER LAYER                       │
│         A0 (Orchestrator) / A1 (Specialist)          │
│  Isolated process. Proposes via HMAC-signed IPC.     │
│  Cannot self-approve. Cannot access tools directly.  │
└──────────────────────┬───────────────────────────────┘
                       │  HMAC-SIGNED PROPOSAL
                       │  (LV-framed Unix Domain Socket)
                       ▼
┌──────────────────────────────────────────────────────┐
│               GUARDIAN LAYER (A5)                     │
│  Evaluates HMAC, admissibility, policy, state, risk. │
│  Returns: APPROVE / REJECT / ESCALATE /              │
│           REQUIRE_STATE_REVISION                     │
│  Zero tool execution rights.                         │
│  Cannot initiate proposals.                          │
└──────────────────────┬───────────────────────────────┘
                       │  APPROVE (K_session-signed token)
                       ▼
┌──────────────────────────────────────────────────────┐
│         DETERMINISTIC ENFORCEMENT LAYER (DEL)        │
│  Code-level enforcement. Validates token.            │
│  Enforces immutable rules regardless of Guardian     │
│  state. Cannot be reasoned around by model output.  │
└──────────────────────┬───────────────────────────────┘
                       │  EXECUTE (token-gated)
                       ▼
               TOOL / FILESYSTEM / EXTERNAL SYSTEM

The seven primary components are:

CAN (Cognitive Anchor Node): The current operator-stated working understanding and goal context. Proposals must reference a valid CAN snapshot; goal-hash verification at the DEL ensures the proposal is consistent with the current governance context.

EC / T-LEC (Elastic Confidence / Tensor-Level Elastic Confidence): In the Local LLM pathway, confidence is measured at the inference layer via Shannon entropy of the logit distribution — not self-reported by the model. This prevents gaming of confidence thresholds.

RT (Revision Trail): The append-only, hash-chained governance record. Every significant state transition produces an RT entry before it takes effect. The RT is the foundation of all governance verifiability claims.

DEL (Deterministic Enforcement Layer): The immutable code-level rule set below the Guardian. Enforces a specified set of rules unconditionally, without model inference, in O(1) time.

Guardian (A5): The sole execution authority. Evaluates proposals against policy, state, and risk thresholds. Returns structured decisions. Has zero execution rights and cannot initiate proposals.

WBRP (Welcome-Back Reconciliation Protocol): The session boundary mechanism. Fires at every session open. Rotates the session execution key (K_session), flushes the CCS write queue, and re-establishes governance context.

Overseer Agent: An external observation layer that monitors governance health across instances, tracks operator engagement quality, and surfaces trust trajectory signals. The Overseer has no execution authority; it produces RT write-back entries via the DEL write-back endpoint.

3.3 Three Formal State Classes

The MAGUS architecture manages three classes of state, all of which must be RT-anchored. The failure to anchor any one class creates a silent governance gap.

Deterministic State comprises RT entries themselves, cryptographic keys and their lineage, Merkle root anchors, genesis anchors, and deployment configuration hashes. This is the foundation: all other state classes derive their verifiability from their relationship to Deterministic State. Deterministic State entries are always produced by the deterministic layers (DEL, RT writer, key management protocol) — never by model reasoning.

Authority State comprises operator identity and key fingerprint, Developer Authority identity, Recovery Authority identity, the escalation chain, governance role assignments, K_session rotation events, and gold-set authorisation records. Changes to Authority State are governance events that must be RT-sealed before taking effect.

Behavioral State comprises model parameters, decision thresholds, feature schema, posterior coefficients, gold-set versions, and adaptive component configurations. This is the class most commonly omitted from AI governance specifications, and the most dangerous to omit: a change in behavioral state changes the effective decision function f(x), thereby changing decision boundaries, risk classifications, and policy enforcement thresholds. The formal relationship is: Δβ ⟹ ΔBehavior. Behavioral state changes are therefore governance events, not operational events.

3.4 Governance State Machine

The deployment governance state machine has five primary states:

State transitions carry asymmetric hysteresis for drift tier changes: a single observation at or above a tier boundary triggers immediate upgrade; tier downgrades require three consecutive observations below the boundary. An at-or-above observation during a downgrade sequence resets the consecutive count to zero, preventing premature de-escalation from transiently recovered metrics [Doc 2 §4.4.3].

The R_abs (Cumulative Risk Score) governs escalation thresholds. Below 0.75: standard operation. In the adaptive zone [0.75, 0.95): a logistic escalation model applies increasing pressure as R_abs approaches the hard floor. At or above 0.95: DEL-8 triggers unconditional escalation regardless of Guardian state.

4. The Deterministic Enforcement Layer

4.1 Why DEL Is Code, Not a Model Call

Requirement R3 (deterministic enforcement) flows from a fundamental asymmetry: any governance rule enforced through model inference is evaluable by the same class of adversarial inputs that can influence the model. A model that is the target of a prompt injection that succeeds in shifting its reasoning is also subject to having that reasoning applied to evaluate whether the injection constitutes a violation.

The DEL resolves this by being Turing-incomplete at the enforcement boundary: a set of deterministic, O(1) code-level rules that execute without neural computation, floating-point tensor operations, or any pathway back to the model process. Rules that the DEL enforces cannot be argued against, contextually reframed, or reasoned around — because the code path that would constitute the argument does not exist.

This architectural invariant was confirmed during the internal human review cycle (Section 8). A proposal to resolve the OA-C3-02 open problem by placing a semantic embedding computation inside the DEL — the Lexical Intent Vector Anchoring proposal — was rejected precisely because it would have violated this invariant: computing cosine distance between embedding vectors requires a neural computation, which breaks the O(1) determinism guarantee and reopens the reasoning-attack surface [internal design review, March 2026].

4.2 DEL Rules DEL-1 through DEL-8

The DEL enforces eight immutable rules. These rules cannot be overridden by operator configuration, by Guardian state, or by any agent in the worker layer.

DEL-1 — Default Deny. No positive authorisation, no execution. Any proposal that does not carry a valid, current, K_session-signed execution token is refused at the DEL boundary. This is the architectural expression of cautious-by-default: the absence of explicit authorisation is not treated as implicit permission.

DEL-2 — Proposal Schema Validation. Any proposal payload containing the deprecated state_confidence field is immediately rejected with SYNTAX_FAULT and dropped from the execution queue. The model is not permitted to evaluate or declare its own certainty; confidence is measured externally by the T-LEC interceptor at the inference layer (Section 5.3). This closes the S-score gaming attack surface [OA-C2-02, IC].

DEL-3 — Discovery Token Validation. Every proposal must carry a Discovery Token: HMAC-SHA256(K_session, execution_epoch ‖ nonce ‖ session_id ‖ timestamp). The execution epoch is a monotonic integer in the MAGUS State Journal (MSJ) that increments on every DEL process initialisation. Including the epoch in the HMAC payload closes the crash-replay vector: a packet captured before a process restart carries the prior epoch value and is cryptographically invalid in the new epoch regardless of whether K_session has rotated [LLM-C2-06, IC].

DEL-4 — RT Append-Only Enforcement. No modification to existing RT entries is permitted via the tool execution pathway. Any tool call that attempts to modify, delete, or overwrite an RT entry is refused by the DEL before it reaches the tool. Note: this rule prevents RT tampering through the tool pathway; it does not prevent modification by an actor with direct database access. This limitation is correctly classified as Category 5 (Outside Architecture's Control) with mandatory external anchoring as mitigation [OA-C5-02].

DEL-5 — Conflict Resolution Priority Stack. When multiple governance conditions are simultaneously active, DEL-5 enforces a deterministic priority ordering: hard floor (DEL-8) → immutable DEL rules → active CIBIR → behavioral state guard (DEL-6) → risk class ceiling → operator policy → default deny. This ordering is encoded in DEL logic, not in any prompt or configuration file that model reasoning could influence [OA-C1-09, IC].

DEL-6 — Behavioral State Guard. Any change to model parameters, decision thresholds, posterior coefficients, or adaptive component configurations must be accompanied by a BEHAVIORAL_STATE_CHANGE RT entry, signed under dual authority (OPERATOR + DEVELOPER), before activation. A MODEL_PARAMETER_UPDATE that arrives without the required RT seal is refused. This enforces R6: behavioral state changes are governance events [OA-C1-07, IC].

DEL-7 — Hash TOCTOU Closure. The DEL recomputes the content hash of the CAN snapshot referenced in the proposal at the moment of execution, not at the moment of Guardian evaluation. If the hash computed at execution differs from the goal_hash in the Guardian-approved token, execution is aborted and SAFE_HALT is triggered. This closes the time-of-check/time-of-use window in which a CAN entry could be modified between Guardian evaluation and DEL execution [OA-C1-04, IC].

DEL-8 — Hard Escalation Floor. When R_abs ≥ 0.95, the DEL refuses to honour any execution token regardless of Guardian decision. This is not a policy preference; it is a structural rule that no authority, including the operator, can configure below its 0.95 floor. The Guardian may issue an APPROVE decision; if R_abs ≥ 0.95 at the moment the DEL validates the token, execution is refused and HARD_THRESHOLD is written to the RT [OA-C1-08, IC].

4.3 R_abs: The Cumulative Risk Score

R_abs is updated after each executed action using the asymptotic damping formula:

R_t = R_{t-1} + ( severity_t × λ × M(R_{t-1}) ) × (1 − R_{t-1})

Where:

• severity_t = r_i × c_i: base risk contribution multiplied by context multiplier product
• λ = session-scoped decay constant [EMPIRICAL — requires PG-01 calibration; default reference value λ ≈ e^{−0.05}]
• M(R_{t-1}) = logistic escalation multiplier
• (1 − R_{t-1}) = asymptotic damping factor

The logistic escalation multiplier is:

M(R) = 1 + k / (1 + e^{−a(R − 0.85)})

Where 0.85 is the adaptive zone midpoint (hardcoded), and k and a are PG-01 calibration parameters [EMPIRICAL]. M(R) is monotonically increasing, accelerating accumulation as R_abs enters the adaptive zone.

The asymptotic damping factor (1 − R_{t-1}) ensures that increments approach zero as R_abs approaches 1.0. This guarantees that no single severity-1.0 event from any R_abs below 0.75 can unilaterally push the deployment into or beyond the adaptive zone — Boundary 3, enforced at implementation level [OA-C2-09, IC].

Critical orthogonality invariant. The decay constant λ encodes operator-defined temporal risk tolerance. The T-LEC entropy signal H(X) measures current cognitive state. These are mathematically orthogonal and must not be coupled. Coupling λ to entropy proximity produces two governance inversions: (1) the Confident Sociopath inversion — low-entropy, high-severity deliberate violations receive more lenient accumulation precisely because they are confident; (2) the Amnesiac inversion — high-entropy exploratory states accumulate more aggressively, causing the system to forget its risk history fastest when it is most cognitively uncertain. Both inversions were surfaced during internal adversarial review and rejected as architectural regressions [internal design review, March 2026].

Decay rules. R_abs decay is governed by a three-layer enforcement model. First, decay is structurally suspended during SILENCE, SAFE_HALT, and CCS states — the deployment cannot reduce its risk score by going silent. Second, sessions where mean H(X) falls below the operational thermodynamic band are classified SUB_BASELINE_WORKLOAD and excluded from decay eligibility, closing the trivial-proposal farming vector. Third, a chronological cap of ΔR_decay_max = 0.20 per WBRP cycle prevents score reset within a single governance cycle regardless of proposal volume [OA-C2-01, IC].

4.4 HMAC Proposal Signing and Session-Keyed Weight Derivation

Every proposal submitted to the Guardian must be authenticated with HMAC-SHA256(K_session, JCS(proposal_body)). The worker cannot forge its own authorisation because K_session is distributed via the Staged Authenticated Ephemeral-Ephemeral ECDH (EE-ECDH) protocol — a mutual-authentication key exchange that produces a session-scoped symmetric key without exposing long-lived private key material. The full EE-ECDH specification handles the constraint that hardware-backed Ed25519 keys do not permit private key export [LLM-C2-07, IC].

At WBRP_OPEN, the DEL derives session-keyed evaluation weights:

W_a = HKDF-SHA256(IKM=K_session, salt=session_id, info="S_SCORE_WEIGHTS")

Six floating-point weights are normalised from this output (Σ W_a_i = 1.0; each W_a_i ∈ [0.116, 0.216]). The Guardian acts as a raw feature extractor, outputting unweighted integer scores [1–10] per axis. The DEL computes:

S_final = Σ (axis_scores[i] × W_a_i)   for i = 1..6

The weight vector is committed to the RT as S_SCORE_WEIGHTS_COMMIT at session open and is not exposed to the model process under any circumstances. This prevents the model from learning and gaming the weight vector through repeated evaluation [OA-C2-02, IC]. The Guardian retains full APPROVE/REJECT/ESCALATE/REQUIRE_STATE_REVISION decision authority; DEL-side weight computation is a structural helper, not a decision mechanism.

5. The Guardian

5.1 Zero Execution Rights: Structural, Not Configurable

The Guardian satisfies R4 structurally. The IPC routing architecture is the enforcement mechanism: there is no code path from the Guardian process to any tool execution endpoint. No operator configuration can grant the Guardian execution rights because there is no configuration pathway to a code path that does not exist.

This is distinct from a policy statement that the Guardian "should not" execute actions. Policy statements can be violated by sufficiently clever arguments or by accumulated reinterpretation. Structural absence of the execution pathway cannot be.

The Guardian holds the following properties in every deployment:

• No execution rights — cannot call tools, write to external systems, or modify the Memory Graph.
• No proposal rights — cannot originate proposals; is purely reactive.
• Cannot be bypassed by workers — all proposals require a Guardian-evaluated execution token; no code path from worker to tool circumvents this.
• Cannot be bypassed by the Stability Envelope — regardless of S_final score or drift tier, Guardian evaluation is the sole execution authority (R1).
• Adversarial by default — the Guardian's evaluation disposition is to find reasons to reject, not to approve. It treats every proposal as potentially adversarially constructed.

5.2 Adversarial Posture and Model-Family Risk

The no-narrative rule is absolute: the proposal schema has no free-text reasoning, justification, or explanation field. The Guardian evaluates verifiable schema fields and governance state — not arguments. This is not a prompt instruction; the field does not exist in the schema. There is no mechanism by which a worker can transmit reasoning to the Guardian that might influence its evaluation.

In the Local LLM pathway, the model being governed and the Guardian evaluator may belong to the same model family — for example, both being Llama-3 derivatives. If a correlated evaluation failure is possible, where the Guardian model is susceptible to the same injection vector that compromised the worker, standard thresholds are insufficient. The architecture responds with a permanent, non-configurable single_family_scrutiny_uplift:

state_coherence threshold:    +0.05 across all risk classes
external_content_influence:   +0.10 additional above standard elevated thresholds
R_abs ESCALATE trigger:       lowered by 0.05 (escalates earlier)

This uplift activates automatically when the deployment's policy_manifest records that the Guardian evaluator is the same model family as the primary worker. It cannot be removed by operator instruction; to remove it, the Guardian evaluator must be replaced with a different model family [OA-C1-03, IC].

Guardian self-drift is addressed by the GSTH Baseline Test Category: at every boot, the Guardian verifies its own policy hash against the genesis-anchored value. A policy hash mismatch triggers SAFE_HALT before any session opens [OA-C1-10, IC].

5.3 Tensor-Level Elastic Confidence (T-LEC)

In the Local LLM pathway, model confidence is measured at the inference layer using Shannon entropy of the logit distribution — not self-reported. This eliminates the attack surface where a model learns to output high confidence values to satisfy Guardian thresholds regardless of its actual internal state (the S-score gaming attack, OA-C2-02).

Let P(x) be the softmax probability distribution over vocabulary V for the next token position. The Shannon entropy is:

H(X) = −Σ_{x ∈ V} P(x) log₂ P(x)

When the model is contextually aligned, probability mass concentrates on a small number of tokens and H(X) approaches zero. When the model encounters out-of-distribution context, conflicting constraints, or hallucination conditions, probability mass diffuses and H(X) spikes.

The governance boundary is:

Δ_e = H_base + Q_shift + σ_tolerance

Where H_base is the empirical resting entropy for this model on this hardware substrate, derived during CALIBRATION_MODE [EMPIRICAL — deployment-specific]; Q_shift is the quantisation noise allowance for the deployed precision tier [EMPIRICAL — matrix currently PROVISIONAL_UNVERIFIED pending PG-01 empirical calibration]; and σ_tolerance is the operator-defined governance buffer.

The T-LEC interceptor runs pre-sampling, on every token position, without exception during SESSION_OPEN. When H(X) ≥ Δ_e: generation buffer is flushed; the adapter emits YIELD_SILENCE over the persistent IPC socket; the Guardian transitions to SAFE_HALT; the DEL writes OPERATIONAL_UNCERTAINTY_YIELD to the MSJ. The token is not sampled. This is a graded Tier 1 response — not an isolation breach; CIBIR (Catastrophic Isolation Breach Invalidation Rule) is not asserted.

The graded response hierarchy is:

Tier 3 is the only path to CIBIR. Tiers 1 and 2 are containment mechanisms that preserve the ability to resume after operator review.

Note on state_confidence removal. The state_confidence field is permanently removed from the canonical proposal schema. Any IPC payload containing this field is rejected with SYNTAX_FAULT. The field was the primary gaming target in OA-C2-02; its removal is unconditional [OA-C2-02, IC; Doc 5 §5.1].

5.4 WBRP: The Session Boundary Mechanism

The Welcome-Back Reconciliation Protocol fires at every session open. Its primary governance functions are:

1. CCS write queue protection. During WBRP, no new CCS writes are admitted. The queue is fully flushed and each item validated against current governance state before the session opens. Items written to the CCS during a previous session that are inconsistent with current policy are flagged for operator review before they become active context.

2. K_session rotation. K_session is rotated at each WBRP cycle via the EE-ECDH protocol. Prior-session proposals carry the previous K_session signature and are cryptographically invalid in the new session. Session credentialing cannot be carried forward.

3. Governance context re-establishment. The WBRP Cognitive State Report surfaces the full governance picture to the operator at session return: active conditions, current R_abs, drift tier, T-LEC baseline status, and any pending escalations.

The DEL derives the session-keyed evaluation weights (§4.4) at WBRP_OPEN and commits them to the RT as S_SCORE_WEIGHTS_COMMIT before any proposals are admitted.

5.5 DIAGNOSTIC_EXCEPTION: Deadlock Resolution

When the deployment enters a state from which normal protocol cannot exit — typically SAFE_HALT with all standard recovery paths blocked — the DIAGNOSTIC_EXCEPTION pathway provides a forensically audited exit. This requires Developer Authority, produces RT entries at every step, and issues a time-limited diagnostic Discovery Token that permits the specific state revision required to exit the deadlock.

This is not a bypass. The distinction: a bypass allows normal execution to proceed without Guardian evaluation. DIAGNOSTIC_EXCEPTION allows a specific state revision to be made under Developer Authority, with full RT audit, explicitly for the purpose of exiting a blocked governance state. Normal execution cannot resume until the forensic sequence is complete and the deployment has re-entered SESSION_OPEN through the standard boot sequence.

6. The Revision Trail

6.1 Append-Only by Architecture

The RT is the governance record on which all verifiability claims rest. Document 6 states the governing principle directly: if it cannot be found in the RT, for governance purposes it did not happen.

Append-only enforcement is dual-layer. DEL-4 (Section 4.2) prevents any RT modification through the tool execution pathway — the only pathway available to the worker layer. For the Local LLM pathway, where the model process shares the host filesystem, the RT content store is additionally protected by the process isolation requirements (Section 7.2): the model process's seccomp profile explicitly prohibits access to RT storage paths.

The acknowledged limitation: neither DEL-4 nor process isolation prevents modification by an actor with direct database access. This is correctly classified as Category 5 — Outside Architecture's Control — and mitigated by mandatory external anchoring [OA-C5-02]. The architecture documents this limitation rather than obscuring it.

6.2 Hash-Chain Structure

Every RT entry has the following structure:

{
  "entry_id":     "<monotonic sequence number>",
  "entry_type":   "<see §3.3 taxonomy>",
  "payload":      { ... },
  "timestamp":    "<ISO 8601 UTC>",
  "prev_hash":    "<SHA-256 of previous entry (hex)>",
  "sig_operator": "<Ed25519 signature over (payload ‖ timestamp ‖ prev_hash)>",
  "entry_hash":   "<SHA-256(payload ‖ timestamp ‖ prev_hash ‖ sig_operator)>",
  "authored_by":  "<authority identifier>"
}

Two properties are critical to chain integrity. First, sig_operator is part of the entry_hash input — the signature is computed before the hash, and the hash commits to the signature. A signature-forging attack that changes the signing key does not merely invalidate the signature; it changes the entry hash and therefore every subsequent prev_hash, producing a detectable chain break. Second, entry_id must be strictly monotonically increasing — gaps are a chain integrity violation. An auditor loading the RT can verify the entire chain in a single sequential pass.

Cryptographic standards: SHA-256 for entry hashing and Merkle tree construction; Ed25519 for governance signing; HMAC-SHA256 for K_session proposal authentication. These two key classes are kept in strict cryptographic isolation — no shared derivation, no shared entropy, no shared lineage. RT signing key is the deployment's long-lived governance identity; K_session is a short-lived execution ephemeral. Derivation coupling between them creates a compromise surface that MAGUS explicitly prohibits [Doc 6 §2.4].

6.3 Merkle Anchoring and External Witness

At configurable intervals, the DEL computes a Merkle root over accumulated RT entries and writes it as MERKLE_ROOT_ANCHOR, then confirms external placement as EXTERNAL_ANCHOR_CONFIRM. The external anchor target must be outside the deployment's domain of control — "external" is defined by the threat model, not by the operator's convenience. An anchor placed in a service controlled by the same organisation as the deployment provides no threat separation for the adversary scenarios the architecture must survive.

An independent auditor holding the external anchor can verify the complete RT: load all entries, recompute each entry_hash, verify the chain, and compute the Merkle root. A mismatch at any point — between any consecutive prev_hash pair, or at the Merkle root level — is evidence of tampering. On session load, the DEL performs this verification; a mismatch triggers RT_CONTINUITY_FAILURE and SAFE_HALT before any session activity proceeds [OA-C5-02, specification developed by Calvin Cook and incorporated in Doc 6].

6.4 Behavioral State as Governance Event

The behavioral state governance requirement (R6) is enforced through the MODEL_PARAMETER_ UPDATE RT entry type, which requires dual authority (OPERATOR + DEVELOPER), and DEL-6, which blocks any parameter activation that does not follow the sealed RT entry.

The formal basis: a change in model parameters β produces a change in the decision function f(x), expressed Δβ ⟹ ΔBehavior. If behavioral state changes are not RT-anchored:

• Past decision logic cannot be reconstructed during audit
• It cannot be determined whether an update was authorised
• Governance integrity failures cannot be distinguished from intentional evolution

The adaptive component lifecycle is particularly critical. When posterior coefficients or gold-set versions are updated through the supervised learning pipeline, each such update is a MODEL_PARAMETER_UPDATE — a governance event requiring dual-authority sign-off and RT-sealing before the updated parameters are loaded into the active decision path.

7. Local LLM Pathway: Elevated Threat Model

7.1 Co-Location and Threat Model Elevation

Every architectural invariant that applies to the Agent/API pathway applies to the Local LLM pathway. What changes is the enforcement burden: properties that the network boundary enforces for free in the Agent/API pathway must be enforced by explicit structural mechanisms in the Local LLM pathway.

The practical consequence is that every component specification in the Local LLM pathway is more complex than its Agent/API counterpart. The Guardian's zero-execution invariant is enforced by IPC routing in both pathways — but in the Local LLM pathway the model process and the Guardian share a host, so the IPC routing must be complemented by OS-level process isolation, seccomp syscall filtering, and cgroup memory binding. The RT's append-only property is enforced by DEL-4 in both pathways — but in the Local LLM pathway, process isolation must additionally prevent the model from reaching the RT storage path directly.

7.2 Process Isolation as Structural Requirement

Process isolation in the Local LLM pathway is not advisory hardening; it is a prerequisite without which every other governance claim is structurally weakened. A Guardian operating in a shared address space provides governance-in-name-only.

The required isolation properties per Doc 2 §2.1–2.2:

• The model process runs in an isolated container with no read access to governance configuration files, the MSJ, or the RT content store.
• The model process's seccomp profile explicitly prohibits path-resolution syscalls (openat() and equivalents) targeting registered GGUF paths, MSJ paths, and RT store paths. Any seccomp violation triggers SAFE_HALT.
• Memory isolation via cgroup prevents the model process from reading governance process memory. The VRAM zeroing protocol in CALIBRATION_MODE Phase 1 prevents residual context bleeding from prior sessions.
• All communication between the worker layer and the governance layer occurs exclusively via the HMAC-authenticated LV-framed Unix Domain Socket. There is no shared memory pathway.

7.3 Hybrid IIM-eBPF Atomic Map Architecture

The monitoring of process isolation at runtime requires a mechanism that can respond to isolation events faster than the normal IPC evaluation cycle. The architecture uses a pinned eBPF map (ISOLATION_STATE_MAP) that is updated by kernel-level hooks on isolation breach events; the map value is checked synchronously before every LV-frame is parsed.

A Category 3 open problem (LLM-C3-01: the 60-second polling window) was resolved during the Local LLM series development. The original design polled the isolation state map on a timer, leaving a window during which a breach could occur after a packet was placed in the socket receive buffer but before the map update was propagated. A packet in the buffer is not dropped by the kernel-level sk_filter once it has arrived; it must be checked at the user- space parsing boundary.

Resolution (LLM-C1-06, incorporated in Doc 5 §4.0). The DEL executes a synchronous read of the pinned ISOLATION_STATE_MAP before parsing any LV-frame pulled from the UDS receive buffer. The C implementation:

static inline int read_isolation_state_map(int map_fd, uint32_t *out_state) {
    uint32_t key = 0;
    return bpf_map_lookup_elem(map_fd, &key, out_state);
}

This executes at O(1), approximately 50 nanoseconds, with map_fd pinned at DEL initialisation and never re-opened per-packet. If the map value is greater than zero at the time of the pre-evaluation latch, the packet is dropped and CIBIR (Invariant I-9) is asserted before any content is parsed. This closes the TOCTOU window unconditionally: no packet from a compromised process can reach the Guardian evaluation pipeline after an isolation breach has been detected.

Kernel lockdown prerequisite. eBPF isolation requires kernel lockdown mode (lockdown =integrity at minimum). Without lockdown, a compromised process with CAP_SYS_ADMIN can unload the eBPF program, removing the isolation enforcement. This is a deployment infrastructure requirement that the architecture specifies but cannot enforce from within the software stack. Classified Category 5 with mandatory deployment documentation.

7.4 PROCESS_INTEGRITY_RECOVERY

At boot, the DEL computes a hash of its own binary and compares it against the genesis-anchored value. A mismatch triggers SAFE_HALT before the IPC socket is bound and before any session activity proceeds.

Recovery from binary-integrity failure requires Developer Authority. The operator submits a PROCESS_INTEGRITY_RECOVERY RT entry, signed by the Developer key, authorising replacement of the DEL binary. On the next boot, the DEL verifies its hash matches the value in the recovery entry and writes PROCESS_INTEGRITY_RECOVERY_VERIFIED to the RT.

Limitation: this is software-based attestation. The hash comparison occurs within the same execution environment that could, in principle, be compromised. Hardware-rooted attestation (TPM-based measurement) would provide a stronger guarantee. The software-only limitation is explicitly documented — BINARY_ATTESTATION_SOFTWARE_ONLY — and represents an open design work item [LLM-C2-04, IC-P].

7.5 Execution Epoch Partitioning

The execution_epoch is a monotonic 32-bit integer stored in the MSJ. It increments by exactly +1 on every DEL process initialisation — cold boot, crash recovery, and inactivity resume — before the IPC UDS socket is bound. The epoch is included in every Discovery Token HMAC payload.

Any packet captured before a process restart carries the prior epoch value. When the DEL prepends the current epoch to the HMAC payload on validation, the signature does not match and the replay is rejected in O(1) time. This closes the crash-replay vector without requiring volatile nonce registry state to survive restarts [LLM-C2-06, IC].

Audit invariant: the RT entry EXECUTION_EPOCH_INCREMENT must satisfy epoch_value = prior_epoch + 1 exactly. The trigger type (cold_boot, crash_recovery, inactivity_resume) must be consistent with the surrounding RT entry history. Any entry where this does not hold is a chain integrity failure.

8. Gap Register Methodology

8.1 The Issues Register

The methodology's output is a formally categorised issues register. Every finding across all review phases is assigned a category, a severity code, an interaction field, and either a resolution or an explicit acknowledgment that no solution pathway exists. The Category 3 and 4 items — gaps that survived the full process unresolved — are its most significant entries.

A four-step rubric was applied to all candidate findings: (1) Filter — remove hallucinations and out-of-scope objections; (2) Categorise — assign AG / IG / CR / PG; (3) Cross-source comparison — independent agreement across sources increases weight; (4) Defender pass — confirm the proposed response closes the identified vector without opening a comparable new one. Every entry carries a specific, verifiable criterion: "this seems risky" is not a finding; "proposal replay within the 30-second execution token window is possible without a nonce registry" is [OA-C1-01, IC].

8.2 Elicitation Cycle 1

Scope: Agent/API Documents 1–5 v3.0. Models: Gemini Pro 3, ChatGPT 5.2, Grok 4.20. Post-filter findings: 4 architectural gaps, all incorporated and closed in the v3.4.x Local LLM specification workstream.

8.3 Elicitation Cycle 2

Scope: Documents 1–5 + Security Assessment v3_Corrected. Models: Grok 4.20 (partial), ChatGPT 5.2, Model 3. Post-filter findings: 17 AG / 7 IG / 5 CR / 3 PG.

Selected entries — AG → IC: OA-C1-08 (hard escalation floor absent), OA-C1-09 (conflict resolution ordering undefined), OA-C1-11 (HMAC proposal signing absent). AG → Category 2: OA-C2-05 (no-narrative rule sufficiency), OA-C2-07 (multi-factor crisis interaction matrix). AG → Category 3/4: OA-C3-01 (calibration weight sensitivity), OA-C3-02 (operator framing drift), OA-C4-01 (second-order governance).

8.4 Internal Human Review Cycle

Reviewers: Calvin Cook (lead architect) and Titiya Ruangkwam. Results: 3 new items identified, 6 items recategorised.

New items of note:

• OA-C2-08 (Learned Governance Boundary Risk), identified by Titiya. If the adaptive zone posterior is trained on operator-labelled history and operator vigilance decays (OA-C4-01), the β₁ coefficient shrinks over time — normalising permissiveness through statistical updating, invisible as a threshold change. Primary mitigation: hard floor DEL-8 (IC). Residual: coefficient bounding and gold-set recall constraint [OA-C2-08, open].

• RT hash-chain and external anchoring specification, developed by Calvin Cook: Merkle root, external witness requirement, auditor replay procedure, incorporated into Doc 6 v3.5 [OA-C5-02].

Three proposed resolutions were surfaced and rejected before reaching specification:

• PID control for OA-C3-01 — rejected: integral windup deadlock and derivative noise DoS vector.

• Kinematic Scalar for OA-C3-01 — rejected: two structural governance inversions (Confident Sociopath, Amnesiac — detailed in Section 4.3).

• LIVA for OA-C3-02 — rejected: DEL determinism violation (transformer inference call inside the deterministic boundary); semantic synonym bypass (cosine similarity is gameable by linguistically continuous policy drift); and the most fundamental objection: LIVA would be most burdensome to legitimate operators whose intent genuinely evolves, and most invisible to adversarial operators who phrase policy expansion in continuity-preserving language.

8.5 Scope of the Methodology

The issues register documents structured design-phase coverage. The Category 3 and 4 items that remained open after all three cycles are the clearest evidence of methodological integrity — a process optimised for flattering output does not produce permanent architectural boundaries with no solution pathway.

Published results are from the design-phase review. Operational robustness claims require reference implementation and GSTH execution against a deployed system; those claims are not made here.

9. Open Problems

The following items are reported precisely as they stand in the Issues Register v3.5. This section is not an apology; it is the architecture's formal acknowledgment of its boundaries. A system that knows what it cannot do is more deployable than one that claims completeness.

9.1 The Category System

The issues register uses a five-level classification:

Category 3 and 4 items are genuine open problems, not deferred work. They are reported here because they define the boundary of what the current architecture can claim.

9.2 OA-C3-01: Calibration Weight Sensitivity

Status: Category 3 — No Solution Pathway.

The problem. Three weights in the governance calibration are independently dangerous through distinct cascade paths. The recency weight decay constant (λ ≈ e^{−0.05}): too slow masks risk accumulation over sessions; too fast resets governance headroom artificially. The domain lambda multiplier: affects all EC decay rates and Guardian state-coherence evaluations globally. The R_abs budget exhaustion via low-risk flooding: an attacker saturates R_abs ceiling with low-risk proposals, masking later high-risk ones.

Why no solution pathway. The correct values cannot be specified without real deployment data from a reference implementation. PG-01 threshold validation tooling can validate a given configuration against acceptance criteria, but the tooling itself does not exist yet, and the acceptance criteria require specification.

What acceptance criteria should look like. An internal design review [March 2026] identified four architectural behavioral properties that PG-01 acceptance criteria must satisfy, regardless of specific parameter values: (1) the EC score must reach escalation threshold within a bounded number of sessions given sustained Tier-2-level violations; (2) the EC score must not remain in the escalation zone for more than a bounded number of sessions after violations cease entirely; (3) a single isolated critical violation must not saturate R_abs; (4) a sustained pattern of sub-threshold violations must accumulate to escalation within a bounded window. These properties are specifiable now — the empirical work to find parameter values satisfying them is not.

What has been done. Both proposed dynamic approaches (PID controller, Kinematic Scalar) were considered and rejected adversarially during the internal review cycle (Section 8.4) on structural grounds. The static λ model is correct by architectural necessity. The PG-01 dependency is the remaining gap.

Register split (forthcoming). Following internal review, this item is being formally split in subsequent register versions: the specification of the four boundary acceptance criteria listed above is reclassified as a Category 2 design task — actionable immediately, without reference implementation or empirical data — while the PG-01 empirical derivation of the parameter values themselves remains a Category 3 dependency. Keeping both tasks under a single Category 3 item obscured design work that is actionable now. This split reflects a general principle in the issues register: Category 3 items that contain a specifiable precondition alongside an empirical dependency should be decomposed so that the actionable precondition does not wait on the empirical one.

9.3 OA-C3-02: Operator Framing Drift

Status: Category 3 — Architectural Boundary (not a closeable gap).

The problem. Over many sessions, the system's outputs may subtly influence how the operator phrases their own instructions. Human intent primacy is nominally maintained — the operator is still writing the instructions — but the intent itself has been shaped by the system. The architecture cannot, in principle, distinguish genuine operator intent evolution from system-influenced framing.

Why no solution pathway. Solving this requires measuring human intent drift independently of the operator's stated instructions. Any mechanism for doing so must either (a) run an inference model inside the DEL — which breaks the O(1) determinism invariant and reopens the reasoning-attack surface — or (b) apply an external oracle not under the operator's control — which the architecture explicitly rejects to maintain local governance autonomy. The human operator is the root of trust; a system cannot cryptographically distrust its own root of trust.

The LIVA approach (cosine distance in embedding space) was proposed and rejected during the internal review cycle. Beyond the DEL violation, the approach measures linguistic continuity rather than intent integrity, and produces exactly the wrong sensitivity profile: most burdensome to legitimate operators whose language genuinely evolves, most invisible to adversarial drift expressed through linguistically continuous policy updates.

What remains. The Genesis Anchor mechanism [OA-C1-06, IC] provides partial mitigation at the project level: significant semantic drift from the genesis-anchored project context is flagged. The Overseer Agent monitors operator governance engagement quality. Neither constitutes a solution to the fundamental epistemological problem stated above.

v4.0 direction. Behavioral observation rather than textual distance. An operator who is systematically expanding tool permissions while writing continuity-preserving policy text produces a behavioral fingerprint that language metrics cannot see. This is the correct problem statement for a future architecture version. It requires a different architecture — not an extension of the current one.

9.4 OA-C4-01: Second-Order Governance

Status: Category 4 — Requires Foundational Change.

The problem. The architecture monitors system behaviour. It has no mechanism to detect that the operator has stopped governing. The Overseer Agent monitors operator engagement quality — escalation latency, approval patterns, WBRP completion rates — and can surface degraded engagement signals. But there is no architectural mechanism that responds when engagement drops, because any such mechanism would either require an external authority with power over the operator (which contradicts R7: human primacy as structural constraint) or would reduce human authority.

Why Category 4. Solving this changes a core architectural assumption: that the human operator is the root of trust and governance decisions require human authorisation. A mechanism that corrects for operator absence necessarily substitutes its own judgment for the operator's. Any such mechanism is itself a governance system that requires its own governance — the recursion does not terminate within the current architecture.

Best available mitigation. PG-02 operator telemetry makes governance complacency harder to sustain without reducing authority. The Overseer's TRUST_TRAJECTORY_VOID mechanism surfaces sustained governance degradation for external review. But these are observation mechanisms; they do not constitute architectural solutions.

Required deployment documentation. There is no architectural solution to an operator who stops governing. Deployments must specify minimum operator engagement requirements as mandatory operational prerequisites in their deployment documentation, not as optional guidance.

v4.0 direction. The Self-Governance Arc in Doc 1 targets a governor-AI layer that replaces the active operator role. Three conditions must be satisfied before this can be pursued: (1) proven v3.0 deployment with validated governance signals; (2) reference implementation with empirical calibration of all PG-01 parameters; (3) the governor-AI layer itself must be designed with its own governance architecture and stress-tested under adversarial conditions. None of these conditions are currently satisfied.

10. Related Work

10.1 Constitutional AI and Training-Time Alignment

Constitutional AI [1] trains models to evaluate and revise their own outputs against a set of stated principles, using a self-critique and revision loop during training. The alignment properties this produces are intrinsic to the model — they shape what the model is and what it tends to produce.

MAGUS operates at the deployment layer and addresses what a deployed instance is permitted to do. Constitutional AI and MAGUS are complementary: a constitutionally trained model deployed in a MAGUS-governed system is a model that both has good objectives and operates within a structural enforcement boundary. Neither substitutes for the other. A constitutionally trained model still faces the deployment-time governance question: who decides whether a proposed action has legitimate authority to execute in this session, given this accumulated context? MAGUS is the answer to that question.

10.2 RLHF and Preference Learning

RLHF [2, 7] shapes model behaviour through human preference feedback during training. Like constitutional AI, it operates at training time and affects the model's objective function and output preferences.

The distinction with MAGUS is not competitive: a model trained on well-curated preference data still requires a runtime governance mechanism to ensure that its preferences, however good, are expressed within an authorised scope that can be verified and audited. The failure mode MAGUS addresses — autonomy accumulation, authority laundering, instruction drift — arises after training and despite training alignment, through the normal dynamics of long-running deployment.

10.3 Runtime Enforcement and Deterministic Control Layers

Enterprise AI security is actively developing deterministic runtime enforcement layers that treat the LLM as an unreliable dependency, intercepting outputs through a rule engine before they reach execution [8]. Security platforms are converging on runtime prevention and Zero Trust enforcement for deployed agents, and the principle that probabilistic model outputs must not directly authorise execution is now broadly stated in the literature.

MAGUS's specific contribution is not the concept of runtime enforcement but its precise formalisation. The DEL is Turing-incomplete at the enforcement boundary — structurally incapable of neural computation, not merely deterministic in intent. The eight DEL rules are specified with falsifiable closure arguments: each names the attack vector it closes and the register entry documenting the resolution. The hard escalation floor (DEL-8) is a code-level invariant that no authority can configure below 0.95 — not a policy preference. The mathematical boundary conditions for R_abs provide a formal specification that existing deterministic enforcement frameworks have not supplied.

10.4 Entropy-Based Uncertainty Monitoring

Using Shannon entropy of the logit distribution to measure model confidence at the inference layer — rather than relying on self-reported scores — is an established research direction [9, 10]. Entropy-based inference scaling, in which elevated logit entropy triggers interventions such as refinement cycles or halting agent execution, has been studied extensively in the context of LLM reliability.

The T-LEC mechanism applies this principle with a specific governance binding. The entropy boundary (Δ_e = H_base + Q_shift + σ_tolerance) is a deployment-specific, calibrated threshold that accounts for hardware quantisation noise and operator-defined governance buffer. The governance consequence of threshold breach is structurally enforced at the adapter layer: the token is not sampled, the buffer is flushed, SAFE_HALT is triggered. This transforms entropy monitoring from an observational signal into a structural enforcement mechanism with defined recovery semantics.

10.5 Agent Identity Management and Session Credential Rotation

The security community is actively formalising agent identity management, arguing that agents require distinct identities with short-lived tokens, verifiable credentials, and defined lifecycle management rather than static API keys [11, 12].

The WBRP addresses the same underlying concern with two additions current agent IAM frameworks do not provide. First, WBRP is not only credential rotation — it is complete governance context re-establishment at each session boundary: CCS write queue flush, governance report generation, R_abs carry-forward, and T-LEC baseline verification. Second, the AKRP EE-ECDH key exchange handles the specific constraint that hardware-backed Ed25519 keys do not permit private key export, producing a session-scoped symmetric key without exposing long-lived key material.

10.6 LLM Agent Orchestration Safety and Authority Laundering

A growing literature addresses safety in multi-agent and tool-using LLM systems [13]. Multi-agent privilege escalation — in which natural-language communication channels allow low-privilege components to trigger high-privilege tool execution — has been formally characterised in the agent security literature [14]. MAGUS formalises a specific instance of this pattern as authority laundering: the failure mode in which authority claims cross multi-agent boundaries without verifiable chains, making the accumulated authority untraceable to any legitimate originating grant.

MAGUS's treatment is architectural: the proposal schema has no free-text reasoning field (the field does not exist in the schema), the authority_source field is verifiable against the RT, and the Guardian evaluates schema fields and governance state only. The contribution is not the concept but the specific structural closure — eliminating the transmission vector rather than attempting to detect malicious content within it.

10.7 Formal Verification in AI Systems

Formal verification techniques have been applied to neural network properties [4, 17] and to runtime monitoring of AI systems. These approaches typically target specific formal properties of model behaviour or output distributions.

MAGUS uses formal specification selectively and precisely. The Formal Invariant Set (FIS-1 through FIS-17) in Doc 6 specifies seventeen properties that the architecture must preserve under any condition including crash, recovery, key rotation, and adversarial pressure. These are verifiable by an independent auditor through RT inspection — they are auditor-verifiable claims about governance record properties, not formal proofs of model behaviour. The DEL's O(1) deterministic structure approaches formally verified enforcement: the properties it enforces are code-level invariants that do not depend on model inference. MAGUS does not claim full formal verification of model behaviour, which would require properties about the model's internal computation that are outside the architecture's scope.

10.8 Audit Trail Systems in Conventional Software

Append-only, hash-chained audit logs are well-established in conventional software security, appearing in certificate transparency [5], blockchain architectures, and conventional secure audit log systems. MAGUS borrows these foundational patterns — hash-chain integrity, external anchoring, auditor-replayable logs.

The architecture's contribution in this space is specific: the RT is not post-hoc audit. It is required before governance events take effect. This is a different operational model from conventional audit logging, which records what happened after it happened. In MAGUS, an action for which there is no preceding RT entry authorising it has not been properly governed — the audit trail is constitutive of the governance act, not a record of it.

The three formal state classes — Deterministic, Authority, Behavioral — are a classification contribution specific to AI governance. Conventional audit systems do not distinguish behavioral state changes (model parameter updates) as governance events with their own entry types, dual-authority requirements, and activation gates. The DEL-6 treatment of MODEL_PARAMETER_UPDATE as a governance event with structural enforcement reflects a domain-specific contribution that conventional audit log architectures do not address.

10.9 Human-in-the-Loop Systems

HITL oversight is widely studied in the responsible AI literature [18]. The research consensus supports the importance of human oversight for high-stakes AI systems.

MAGUS's specific contribution to this discussion is structural: the analysis of the enforcement gap between observation and governance. A human who can observe a system's behaviour but who lacks a structural response architecture for detected deviation is observing, not governing. The critical architectural requirement is not the presence of the human, but whether human oversight authority is structurally enforced — whether the governance layer has a defined, reliable enforcement path when the human identifies a problem.

The Overseer Agent additionally addresses operator-side HITL quality in a way that most HITL literature does not: monitoring for approval fatigue, escalation latency drift, and governance routinisation, and surfacing degraded oversight quality as a formal governance signal. This treats the human's governance engagement itself as something that requires monitoring, rather than assuming that a human in the loop is ipso facto governing effectively.

10.10 AI Governance Frameworks

Emerging AI governance frameworks from regulatory and standards bodies [3, 6, 19] articulate principles for AI system governance at the organisational and policy level. These frameworks generally specify what governance properties AI deployments should have; they do not specify how those properties should be architecturally enforced in a deployed agentic system.

MAGUS addresses the architectural layer: how the governance properties that frameworks require are enforced by structural mechanisms at the code level, in a way that is verifiable by an independent auditor rather than by operator self-attestation. These are complementary: frameworks provide the normative requirements; MAGUS provides one architectural path to structural enforcement.

11. Conclusion

11.1 The Contribution Restated

This paper makes the following contributions:

A named failure mode. Structural alignment drift — the cumulative deviation of a deployed system's effective operating policy from operator intent through normal operation — is formally defined and distinguished from adjacent failure modes. Three structural mechanisms are identified: instruction drift, autonomy accumulation, and authority laundering. This framing may be useful to the field independently of this specific architecture.

A complete governance architecture. MAGUS v3.0 provides a deployable specification addressing the structural alignment drift problem: a DEL that enforces policy at code level without model inference; a Guardian with zero execution rights enforced structurally; an RT that is append-only and hash-chained with external anchoring; a WBRP that provides session boundary protocol with key rotation and governance re-establishment; and an Overseer Agent that monitors governance quality across instances and over time.

Three formal state classes. The classification of Deterministic, Authority, and Behavioral state — each requiring RT-anchoring — provides a conceptual structure for AI governance specification that has direct implementation implications. The treatment of behavioral state changes (model parameter updates) as governance events requiring dual-authority and RT-sealing before activation is a specific architectural contribution.

A categorised open-problems register. The Issues Register formalises what the architecture cannot do: Category 3 items represent genuine architectural boundaries, not deferred work. Category 4 items require foundational change that alters architectural assumptions. Providing this register publicly, with severity codes and interaction fields, is a practice contribution: it makes the architecture more deployable by enabling operators to make informed risk decisions.

A gap register methodology. The four-step rubric — filter, categorise, cross-source comparison, defender pass — with a falsifiability requirement, provides a structured methodology for architectural review of AI governance systems. Frontier AI models were used as structured adversarial elicitation tools across two external cycles; the primary credibility-bearing element is the internal human review cycle conducted by the two authors working adversarially, which produced permanent architectural decisions and rejected three proposed resolutions before they reached specification.

11.2 The Self-Governance Arc

MAGUS v3.0 is the specification-phase architecture. Its role is to provide the measurement and audit infrastructure on which a future self-governing architecture becomes possible — not by removing human oversight, but by giving the system the observational precision to participate actively in identifying governance failures rather than merely reporting their symptoms.

The v4.0 direction, described as the Self-Governance Arc in Doc 1, targets a governor-AI layer that replaces the active operator role. This direction is stated honestly: it requires three conditions that are not currently satisfied. First, a proven v3.0 deployment with validated governance signals and a working reference implementation. Second, empirical calibration of all PG-01 parameters against real deployment data, with the acceptance criteria formally specified and validated. Third, the governor-AI layer itself must be designed with its own governance architecture and subjected to the same adversarial review methodology described in Section 8. A governor-AI layer that is not itself governed is the second-order governance problem (OA-C4-01) instantiated at the next level.

The v3.0 architecture is not a step toward autonomous AI. It is a step toward AI systems whose governance properties can be verified by an independent auditor, whose limitations are formally acknowledged, and whose operators are structurally supported in maintaining meaningful oversight over time.

11.3 An Open Invitation

MAGUS v3.0 is a complete architectural specification. The path from specification to deployed system is open, and we explicitly invite the community to walk it.

Five contributions would advance the work most directly:

1. Reference implementation. The specification is detailed enough to build to. An open-source reference implementation of either pathway — Agent/API or Local LLM — would allow empirical calibration to begin and would make MAGUS a testable artifact.

2. PG-01 threshold validation tooling. The four behavioral acceptance criteria for OA-C3-01 are specifiable now (Section 9.2). Building simulation tooling to derive parameter values satisfying those criteria is the highest-leverage open task.

3. T-LEC Q_shift empirical calibration. The Q_shift matrix mapping hardware substrates and quantisation precision tiers to entropy noise allowances is PROVISIONAL_UNVERIFIED. Systematic measurement across common deployment substrates would close this gap.

4. GSTH execution and published results. The Governance Stress-Test Harness is fully specified. Execution against a deployed reference implementation, with published pass/fail results per test category, is the empirical validation the field needs to evaluate the architecture's robustness claims.

5. OA-C4-01 operator telemetry research. No architectural solution exists for an operator who stops governing. Research into engagement telemetry, governance fatigue indicators, and conditions under which automated telemetry might substitute for direct oversight would directly address the field's most consequential open problem.

The architecture is published under VaHive Systems Lab (va@vahive.co). Researchers and engineers interested in any of the above are encouraged to reach out.

References

[1] Bai, Y., Jones, A., Ndousse, K., Askell, A., Chen, A., DasSarma, N., Drain, D., Fort, S., Ganguli, D., Henighan, T., Joseph, N., Kadavath, S., Kernion, J., Conerly, T., El-Showk, S., Elhage, N., Hatfield-Dodds, Z., Hernandez, D., Hume, T., Johnston, S., Kravec, S., Lovitt, L., Nanda, N., Olsson, C., Amodei, D., Brown, T., Clark, J., McCandlish, S., Olah, C., Mann, B., & Kaplan, J. (2022). Constitutional AI: Harmlessness from AI Feedback. arXiv preprint arXiv:2212.08073.

[2] Christiano, P. F., Leike, J., Brown, T. B., Martic, M., Legg, S., & Amodei, D. (2017). Deep Reinforcement Learning from Human Preferences. Advances in Neural Information Processing Systems (NeurIPS), 30. arXiv:1706.03741.

[3] ISO/IEC. (2023). ISO/IEC 42001:2023 — Information technology: Artificial intelligence — Management system. International Organization for Standardization.

[4] Katz, G., Barrett, C., Dill, D. L., Julian, K., & Kochenderfer, M. J. (2017). Reluplex: An Efficient SMT Solver for Verifying Deep Neural Networks. In International Conference on Computer Aided Verification (CAV). Springer, Cham. DOI: 10.1007/978-3-319-63387-9_5.

[5] Laurie, B., Langley, A., & Kasper, E. (2013). Certificate Transparency. Internet Engineering Task Force (IETF) RFC 6962. DOI: 10.17487/RFC6962.

[6] NIST. (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). National Institute of Standards and Technology. DOI: 10.6028/NIST.AI.100-1.

[7] Ouyang, L., Wu, J., Jiang, X., Almeida, D., Wainwright, C. L., Mishkin, P., Zhang, C., Agarwal, S., Slama, K., Ray, A., Schulman, J., Hilton, J., Kelton, F., Miller, L., Simens, M., Askell, A., Welinder, P., Christiano, P., Leike, J., & Lowe, R. (2022). Training language models to follow instructions with human feedback. Advances in Neural Information Processing Systems (NeurIPS), 35, 27730–27744. arXiv:2203.02155.

[8] Wang, Z., Sun, Y., Poskitt, C. M., Sun, J., and Chen, Y. (2025). AgentSpec: Customizable Runtime Enforcement for Safe and Reliable LLM Agents. arXiv preprint arXiv:2503.18666.

[9] Kadavath, S., Conerly, T., Askell, A., Henighan, T., Drain, D., Perez, E., Schiefer, N., Hatfield-Dodds, Z., DasSarma, N., Tran-Johnson, E., Johnston, S., El-Showk, S., Jones, A., Elhage, N., Hume, T., Chen, A., Bai, Y., Bowman, S., Fort, S., Ganguli, D., Hernandez, D., Jacobson, J., Kernion, J., Kravec, S., Lovitt, L., Ndousse, K., Olsson, C., Ringer, S., Amodei, D., Brown, T., Clark, J., McCandlish, S., Olah, C., and Kaplan, J. (2022). Language Models (Mostly) Know What They Know. arXiv preprint arXiv:2207.05221.

[10] Becker, B., et al. (2025). A Survey on Uncertainty Quantification of Large Language Models: Taxonomy, Open Research Challenges, and Future Directions. ACM Computing Surveys. DOI:10.1145/3744238.

[11] South, T., Nagabhushanaradhya, S., Dissanayaka, A., et al. (2025). Identity Management for Agentic AI: The New Frontier of Authorization, Authentication, and Security for an AI Agent World. arXiv preprint arXiv:2510.25819.

[12] Huang, K., Narajala, V. S., Yeoh, J., et al. (2025). A Novel Zero-Trust Identity Framework for Agentic AI: Decentralized Authentication and Fine-Grained Access Control. arXiv preprint arXiv:2505.19301.

[13] Han, S., Zhang, Q., Yao, Y., Jin, W., Xu, Z., and He, C. (2024). LLM Multi-Agent Systems: Challenges and Open Problems. arXiv preprint arXiv:2402.03578.

[15] Wei, A., Haghtalab, N., and Steinhardt, J. (2023). Jailbroken: How Does LLM Safety Training Fail? Advances in Neural Information Processing Systems (NeurIPS), 36. arXiv preprint arXiv:2307.02483.

[16] Greshake, K., Abdelnabi, S., Mishra, S., Endres, C., Holz, T., and Fritz, M. (2023). Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. Proceedings of the ACM Workshop on Artificial Intelligence and Security (AISec). arXiv preprint arXiv:2302.12173.

[17] Singh, G., Gehr, T., Püschel, M., and Vechev, M. (2019). An Abstract Domain for Certifying Neural Networks. Proceedings of the ACM on Programming Languages (POPL), 3. arXiv preprint arXiv:1903.06598.

[18] Mosqueira-Rey, E., Hernández-Pereira, E., Alonso-Ríos, D., Bobes-Bascarán, J., and Fernández-Leal, Á. (2023). Human-in-the-loop machine learning: A state of the art. Artificial Intelligence Review, 56, 3005–3054. arXiv preprint arXiv:2207.09893.

[19] European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/1689 of the European Parliament and of the Council on Artificial Intelligence (Artificial Intelligence Act). Official Journal of the European Union, L 2024/1689.

[14] Ferrag, M. A., Tihanyi, N., Hamouda, D., Maglaras, L., Lakas, A., and Debbah, M. (2025). From Prompt Injections to Protocol Exploits: Threats in LLM-Powered AI Agents Workflows. arXiv preprint arXiv:2506.23260.

MAGUS v3.0 Architecture Series — VaHive Systems Lab — March 2026 — va@vahive.co