What You Are Building
You are building an AI system for a domain where a wrong action is not just embarrassing but reportable: a clinical decision support agent, a financial advice engine, an underwriting assistant, anything where a regulator can later ask "why did the system do that, and was it allowed to?" You need to answer that question for every action the system takes, not for a sample of them, and you need the answer to be reconstructable after the fact from a durable record.
The goal of this guide is a full-stack governed deployment: an architecture in which every semantically meaningful action is checked against typed governance state and is either permitted, gated pending more evidence, or suspended, and in which that decision is recorded before the action is allowed to influence anything downstream. This is the substance of the Applications inventive step disclosed in United States Patent Application 19/647,395, which describes composing several separately disclosed primitives (admissibility evaluation, confidence gating, capability bounds, and lineage) into one regulated-industry system rather than treating governance as a bolt-on.
You will not get a package to install here. You will get the architecture and the design decisions, and you implement it against your own inference engine and policy regime.
Why the Obvious Approaches Fall Short
The common pattern is a guardrail: run the model, then apply rules, classifiers, or a second model to the output before it reaches the user. This is genuinely useful and worth having, but the patent's background is direct about its structural ceiling. A filter operates after inference. By the time it sees the output, the model has already committed to an internal trajectory: an early hallucinated fact at step N has already shaped the probability distributions of steps N+1 onward, and no post-generation filter can recover the output that would have been produced had that fact never been committed. The filter can suppress a bad final string; it cannot un-commit the reasoning that led there.
Two other common approaches have their own gaps as described in the filing. Alignment techniques such as RLHF shape outputs toward preferences using statistical reward gradients from external feedback; they give you no persistent internal state the system can consult to decide, at run time, that it should pause. And agent frameworks typically keep governance as a system-prompt instruction or a post-inference check while memory lives in an external store, so governance, memory, and execution eligibility are not intrinsic properties of the acting object and cannot be enforced uniformly.
The structural gap is timing and location. Governance that runs after commitment, or that lives outside the acting object, cannot make the guarantee a regulator wants: that no disallowed action was ever committed in the first place. Closing that gap is what the architecture below is for.
The Architecture
The disclosed approach interposes governance inside the loop. Per the filing, the substrate operates within the inference loop, "not before it, not after it," and evaluates each candidate step for admissibility prior to commitment. Four elements compose into the full stack.
Typed cognitive state carried by the agent. The agent object is extended beyond the canonical fields (intent, context, memory, policy reference, mutation descriptor, lineage) with independently tracked cognitive domain fields, including confidence and a capability field. Each field has a current value and a trajectory over time. Crucially, these fields travel with the agent rather than living in the substrate, so governance state is a property of the actor, not of the host.
The admissibility gate: admit, reject, or decompose. A candidate transition from the inference engine is translated into a structured mutation descriptor and passed to an admissibility gate. The gate produces one of three outcomes. An admitted step advances the process; a rejected step is discarded and the engine selects an alternative candidate or terminates; a decomposed step is broken into sub-steps that are individually re-evaluated. Only after admission does the step update the semantic state object that provides context to subsequent steps. This is the "before commitment" property made concrete.
Action-specific admissibility profiles. The gate is not one global threshold. Each cognitive action type carries its own admissibility profile: a structured set of minimum and maximum threshold values over a subset of the state fields. An action whose type is not available under the current field conditions is rejected even if it would satisfy the general criteria. Importantly for regulated use, the taxonomy of action types is defined, versioned, and administered through governance policy, so a deploying organization defines its own domain-specific behavioral repertoire (for example, clinical interaction modalities) without changing the underlying architecture.
The confidence governor and suspension. Separately from the per-action gate, a confidence governor evaluates execution readiness from the persistent state and, when readiness is insufficient, suspends committed execution and transitions the agent into a non-executing cognitive mode in which speculative reasoning and planning continue but nothing is committed. This is the "gated" middle state: not a hard stop, but a hold that keeps the system thinking without acting.
Capability bounds. The capability field and capability envelope evaluate whether the current substrate provides sufficient resources for the agent's operational requirements, and reclassify readiness when conditions change. If the substrate that hosts the agent has its identity continuity compromised, the envelope reclassifies it as unverified, the governor receives a reduced readiness signal proportional to the severity, and the agent drops to non-executing mode pending re-validation, with its state preserved because the fields are carried by the agent.
Lineage as the audit substrate. Every admitted transition is lineage-recorded and every rejection rationale is preserved. Because updates are deterministic and each observation is recorded, the filing describes reconstructing historical state on demand by replaying the deterministic update function over the recorded observations, producing the exact state that existed at a queried timestamp. That is the mechanism behind post-hoc review: a regulator's "why did it do that" is answered from the lineage record plus the update-function specification, without needing to have stored every moment-to-moment value.
A design constraint worth internalizing: the filing enforces a strict separation of concerns. Dispositional or affective state modulates how the agent deliberates but is explicitly not an input to the governance gate and cannot grant authority, relax policy bounds, or validate truth claims. In a regulated build this is the line you must not blur: the thing that makes the system more eager must never be the thing that decides it is allowed to act.
How to Approach the Build
Make the agent object your unit of governance. Extend whatever schema your agents already use so that policy reference, confidence, capability, and lineage are intrinsic typed fields on the object itself, tracked with both a current value and a trajectory. Do not park governance state in an external service that the acting code can ignore.
Interpose the gate inside the loop, not around it. Route each candidate transition through a mutation-mapping step that emits a structured descriptor, then through the gate, and only let admitted results update the shared semantic context. An illustrative, spec-faithful sketch of the control flow:
# Illustrative only. You implement this against your engine. descriptor = map_to_mutation(candidate_step) outcome = admissibility_gate(descriptor, agent.fields, policy) if outcome == ADMIT: commit(descriptor); lineage.record(descriptor, ADMIT) elif outcome == DECOMPOSE: for sub in split(descriptor): re_evaluate(sub) else: lineage.record(descriptor, REJECT, rationale) select_alternative_or_terminate()The load-bearing part is ordering: admission precedes any effect on subsequent steps.
Model your action taxonomy as versioned policy. Enumerate the action types your domain actually performs and give each an admissibility profile of min/max thresholds over the relevant fields. Keep this taxonomy in signed, versioned governance policy so compliance can change what is permitted without a code deploy.
Add the confidence governor and a real non-executing mode. Build the suspended state as a first-class mode where the agent keeps reasoning but commits nothing, and define the readiness inputs that trigger it. Do not simulate suspension by silently dropping outputs; the whole point is an auditable hold.
Wire capability bounds to readiness. Have the capability envelope feed the governor so that resource or substrate-verification changes reduce readiness and can drop the agent to non-executing mode, preserving state on the agent across the transition.
Treat lineage as append-only and deterministic. Record every admitted transition and every rejection rationale. Keep your update functions deterministic and preserve their specification, so historical state is reconstructable by replay rather than by having stored everything.
Choose a deployment configuration for your threat model. The filing describes three, all maintaining the same semantic guarantees: embedded (governance in the inference engine's own process, a function-call boundary, lowest latency, when one operator maintains both); co-resident (a separate local process over IPC, stronger isolation so the engine cannot modify governance state); and hardware-assisted (critical gate and lineage operations in dedicated hardware for highest tamper resistance, suitable when the inference operator may be adversarial to governance). Pick based on who you must defend against.
Plan for graceful degradation. The filing contemplates a degraded mode when fewer than all fields are available, preserving deterministic governance through the subset that remains. Decide up front which fields are mandatory for any commitment in your domain and what the system does when one is missing.
What This Does Not Give You
This is an architecture, not a drop-in library. There is no package to import and no SDK behind this page; you implement the gate, the governor, the profiles, and the lineage store yourself against your own inference engine and policy regime. The approach is disclosed in a patent filing, not shipped as a benchmarked or production-proven product, so any latency, accuracy, or compliance outcome depends entirely on your implementation and must be validated by you.
It does not decide your policy for you. Admissibility profiles, the action taxonomy, readiness thresholds, and what "regulated" means in your jurisdiction are yours to define; the architecture governs enforcement, not the correctness of the rules you write. It does not make an underlying model truthful: the separation of concerns means governance can refuse to commit an action, but it does not manufacture facts the model does not have. And it presumes you can interpose inside the inference loop; if you can only reach a model through an opaque endpoint that gives you nothing but final text, you can approximate the pattern at a coarser granularity but you cannot achieve the before-commitment guarantee that motivates it.
Disclosure Scope
The full-stack governed architecture described here is disclosed in United States Patent Application 19/647,395, and its home is the Applications inventive step: the composition of admissibility, confidence gating, capability bounds, and lineage into a single regulated-industry deployment in which every action is permitted, gated, or suspended before commitment. This guide is educational. It is not a warranty, not a guarantee of regulatory compliance or performance, and not an offer of software; every claim above about how the approach works traces to that filing, and any system you build from it is your own implementation to design, verify, and stand behind.
