This page documents the architecture as it operates in production: the four-object lifecycle, the state-transition primitive, the compile-time/runtime split that makes deterministic adjudication TEE-resident while preserving access to probabilistic inference, the inherited architectural properties of a Notenic deployment, the failure-mode response stack, the category-level distinction from middleware, sidecar, and embedded governance, and the patent and standards posture underpinning the intellectual property.
The State-Transition Authority™
Notenic instantiates governance as an isolated, ephemeral runtime — bound to the agent's operational transition surface, structurally external to the agent application runtime, populated by session-scoped governance artifacts that hold no presence beyond the session itself.
A zero-trust runtime architecture, underpinned by:
Governance infrastructure built for the modern enterprise and safety-assured autonomy.
Notenic is an independent control plane that compiles a deterministic governance authority for every session at the moment a session begins, delivers it into the customer execution boundary, and adjudicates every proposed operational state transition against it. The model proposes; the GRE determines whether the proposal acquires authority.
AIPCP
Policy is authored in the cloud, resolved through Priority Band Resolution, compiled into a session-scoped GRA, and delivered into the customer execution boundary at session start.
AISPM
The active governance posture is bound to the session, version-pinned to the GRA the session was provisioned against, and reconstructable from the certification chain at any later point.
AIDR
Detection of session compromise, governance divergence, or unauthorized transition attempts triggers the AgentSafe™ Managed Autonomy response stack — configured in policy, executed by the GRE.
Loss Prevention
DLP
Data movement is governed at the operational transition surface. No payload reaches a system of record without an admissibility verdict from the GRE and an execution verification verdict from ExeVerify.
WFM
Every proposed transition is evaluated against the workflow scope the GRA has compiled for the session. Transitions outside scope are refused; transitions requiring escalation are routed to the configured human authority.
Notenic is the only purpose-built governance architecture for industries where autonomous system failure carries regulatory, legal, financial, or operational consequence. It operates as a runtime dedicated exclusively to governance — not as a layer added to something else.
Ephemeral governance runtimes for autonomous systems.
An independent control layer comprising four canonical objects. Each has a defined, non-substitutable identity, a distinct set of responsibilities, its own lifecycle, and a precise interface to the artifacts adjacent to it.
Notenic Governance
Cloud
Authoring · Compilation · Certification
The persistent control plane. Hosts policy authoring, versioning, validation, and approval. Compiles the session-bound GRA at session initiation. Retains the certification lineage and attestation records produced by every governed session. Multi-tenant by customer; never by session.
Properties: Multi-tenant by customer. Never multi-tenant by session.
Responsibility: Policy authoring (Policy Bundles, Policy Manuscripts, attached policy documents, Ingress references). Versioning, validation, review. Resolution of overlapping Policy Bundles via Priority Band Resolution at session compilation. Compilation of the resolved governance payload into a GRA. Cloud-side mTLS authority over outbound deliveries.
Interface: Remote orchestration, resolution, and provisioning invoked at session initiation. Compiles canonical policy into the GRA at session initiation. Emits attestation metadata bound to the resulting artifact.
Lifecycle: Initialized invocation only. Does not adjudicate governed state transitions or ingest/receive client content at runtime.
Governance Runtime Artifact
Compiled Authority
The session-scoped, signed, immutable runtime image of the customer's resolved governance authority. Carries the adjudication structure, role authority bindings, mapped workflow, escalation configuration, and the deterministic logic the GRE traverses at runtime. Single-use, uniquely serialized, retired at session close.
Properties: Deterministic. Cryptographically signed. Uniquely serialized at compile time such that no two artifacts share recoverable structure, even when built from identical policy inputs.
Responsibility: The resolved adjudication payload, including policy bindings (Entity Binding, Mapped Workflow Assignment), escalation configuration (Policy Bundle Escalation Protocol), and authority graph for the specific session.
Interface: Transmitted from the Cloud to the client boundary by exactly one Capsule. No replication. No multi-delivery. Instantiated as the active GRE at the execution boundary.
Lifecycle: Session-scoped. Compiled per session. Never reused. Retired forever at session termination.
Governance Runtime Capsule
Secure Transport
The cryptographic transport that delivers the compiled GRA from the Cloud to the client execution boundary. Carries integrity verification, provenance attestation, and ephemerality guarantees. Collapses immediately after delivery — no residual presence after instantiation.
Properties: Mutual TLS with session-locked certificates. Maximum 48-hour validity. Non-transferable across sessions or environments.
Responsibilities: Integrity verification of the GRA in transit. Attestation of provenance. Cryptographic seal between Cloud and client boundary. Ephemerality enforcement.
Interface: Constructed at session start; secure carrier bound to single GRA bundle. Carries no payload other than its bound GRA.
Lifecycle: Collapsed after GRA instantiation. No residual presence after delivery.
Governance Runtime Environment (GRE™)
Instantiated Authority — The State-Transition Authority™
The session's active governance runtime. Instantiated from the GRA inside the customer execution boundary, inside a hardware-backed trusted execution environment. Adjudicates every proposed transition against the GRA's deterministic structure. Verifies every executable payload against the adjudicated proposal. Destroyed at session close — zero persistence by architectural property.
Properties: TEE-resident, enclave-isolated. Cryptographically signed attestation generation per state transition. Does not host its own inference engine. Does not read or retain client content.
Responsibilities: Deterministic adjudication against the GRA's resolved adjudication structure. Probabilistic inference leveraged via Inference Under Authority when runtime interpretation is required. State-transition admissibility determination at each proposed inference-to-consequential transition, response engagement, and escalation condition.
Interface: GRA instantiates as GRE. GRE active as session authority GRA. Structurally external to the agent runtime. Bound to the agent's operational transition surface, not to its process, network position, or execution context.
Lifecycle: Active for the session lifecycle. Destroyed at session termination. Zero persistence by architectural property.
At session start, multiple policy bundles may apply to the active agent and workflow. Notenic resolves conflicts deterministically through Priority Band Resolution and compiles the resolved authority into a single GRA for the session.
No inference-originated or inference-directed action can read from or write to a system of record outside the bounds of the active session's policy, assigned role authority, or workflow scope.
This is the single sentence the entire architecture is built to deliver. Every object, every membrane, every adjudication, every certification exists to make this statement true.
The Operational State Transition is the architectural primitive. Admissibility is not a probability. It is a determination.
The discrete moment at which probabilistic inference attempts to become a consequential action against a system of record. It is defined by four components.
Notenic does not govern model outputs. It does not govern prompts. It does not govern session transcripts. The unit Notenic governs — the architecturally fundamental object — is the operational state transition: the discrete moment at which a probabilistic inference-driven decision becomes a proposed change against an external system of record.
This is the structural difference from every governance class that operates on language or content. A state transition is not a turn of dialogue. It is not a tool invocation considered in isolation. It is the constitutional boundary between probabilistic inference and consequential action.
The Proposing Inference Model
Identity, role, and authority lineage at session start — the actor whose cognition is producing the proposed action.
The Proposed Operational State Change
What action, against what system, with what payload, under what scope — the consequential intent attempting to commit.
The Workflow Position & Classification
Where in the procedural sequence the transition is being attempted — not just what the action is, but where it sits in the work.
Governance Posture & Session Authority
Active evaluation of what the GRA has compiled as admissible for this session, against this workflow, for this agent, in this role.
The GRE evaluates each proposed transition against the GRA's resolved adjudication structure before the transition is permitted to commit.
The collective set of state transitions that occur throughout the software application lifecycle is what we call the operational transition surface. The GRE is bound to this surface — not to the agent's process, not to its inference engine, not to its tool registry. The binding is functional, not topological: the GRE has authority over the transition surface regardless of where the agent's reasoning, planning, or tool invocation logic lives, and regardless of which model is performing the agent's inference.
This is the architectural position that distinguishes the Notenic GRE from every other class of governance.
Middleware-class governance is bound to the agent's process. Sidecar governance is bound to the routing surface. Embedded governance is bound to the context window. Only the GRE is bound to the transition surface itself — the architectural primitive that determines whether inference becomes consequence.
Two independent membranes. Two different risks. One uncompromised authority.
Notenic governance is not a single point of evaluation. It is two independent membranes that govern two architecturally distinct risks. Each derives its verdict independently. Neither trusts the other to have done its job correctly. Together they make it structurally impossible for a proposed action to reach a system of record outside the bounds of the active governance posture.
Membrane 01 — Proposal Admissibility (the GRA): Determines whether an inference-originated proposal is eligible to acquire execution trajectory. Evaluates the proposal against active policy, role authority, workflow scope, operational state, and certification requirements. Outputs: ALLOW, BLOCK, ESCALATE, REVISE. Every decision produces a cryptographically signed certification event — regardless of outcome.
Membrane 02 — Execution Verification (ExeVerify): Notenic governance is not a single point of evaluation. It is two independent membranes that govern two architecturally distinct risks. Each derives its verdict independently. Neither trusts the other to have done its job correctly. Together they make it structurally impossible for a proposed action to reach a system of record outside the bounds of the active governance posture.
Single-pass governance assumes adjudicated equals executable. That assumption is unsafe — the path between proposal and execution introduces mutation, translation, expansion, time-of-check-to-time-of-use drift, and object substitution. Dual-membrane governance eliminates these risks by structural design, not by additional inspection.
The model infers freely. Notenic governs whether inference becomes consequence.
Because the GRE operates on the operational transition surface — outside the agent's runtime, outside its trust boundary, outside its compromise envelope — enforcement intensity is differentiable by the consequentiality of the transition under evaluation. This is not a feature of the GRE; it is a property of the position the GRE occupies. Middleware-class governance applies enforcement uniformly because it lacks the architectural position to do otherwise. The intensity gradient is what becomes available when governance is structurally bound to the surface where consequence is decided.
Tier 1 — Operational transition surface: The architectural locus the GRE binds to. The lifecycle of state transitions an application produces by running — not a sequence of events, but the layer at which every transition between operating states is exposed for adjudication.
Tier 2 — Governance intensity gradient: Behavioral constraints shape the agent's option space; refusal logic narrows the decisional surface; and the full adjudication stack engages at the consequential transition. Intensity rises as the proposed transition approaches commit. The GRE has absolute authority at the moment that determines whether reasoning becomes consequence.
Every technical evaluator examining the Notenic architecture arrives at the same fundamental question:
If governance operates outside the agent runtime, and the model cannot see or access the policy, then what mechanism actually evaluates whether a proposed transition is admissible?
This is the central technical question of the entire category. Static policy text cannot adjudicate a transition by itself; something must perform the adjudication. And whatever performs it must do so without re-introducing the trust boundary problems the rest of the architecture is designed to eliminate. The architecture is built around a deliberate split: probabilistic reasoning happens at compile time, in the Cloud; deterministic adjudication happens at runtime, in the GRE.
At compile time in the NGC
The Cloud has full inference capacity available. This is where the interpretive work happens — policy, role, intent, scope, and goal are resolved into a deterministic adjudication structure. The hard work of interpreting what policy means for a given session happens before the session begins, in the layer where unbounded inference is available and no runtime constraints apply.
Part 1 of 2
Part 2 of 2
At runtime in the GRE
The GRE traverses the compiled structure carried by the GRA. No interpretation is performed at runtime — only evaluation against an artifact that has already resolved the interpretive work. This is what makes the GRE TEE-resident, ephemeral, and execution-local at sub-50ms. Deterministic traversal of a compiled structure fits inside a hardware-backed enclave. Probabilistic reasoning at runtime, in a TEE, does not.
Not every proposed transition can be fully pre-resolved at compile time. For those, the GRE consults probabilistic reasoning at runtime — through the agent's own inference resource, under Notenic's authority, in a form the model cannot interpret as governance.
Inference under Notenic authority. Opaque to the model.
The GRE does not host its own inference engine. It leverages the agent's own inference resource — the same model running the agent — as a queried resource under Notenic's authority. The queries the GRE issues are model-opaque by construction: the model performs the reasoning the GRE requests, but cannot identify the queries as governance queries, cannot interpret their purpose, and cannot recognize the structure of the adjudication being performed.
The model supplies inference capacity. Notenic supplies inference authority. The model becomes a resource the GRE consults, not a runtime the GRE lives in.
This inversion is what makes the rest of the architecture coherent. No second inference engine. No co-located trust boundary. Structural injection immunity — there is no policy surface inside the agent runtime to compromise. And a runtime that remains deterministic in its decisions even when probabilistic reasoning is consulted in its inputs.
Inherited architectural properties.
Not assembled configurations.
Structurally external authority The GRE's authority is not inheritable from the agent's process, network position, or execution context. Trust-boundary independence is constitutive of the deployment model.
Model-opaque governance Policy logic is inaccessible to the inference engine by architecture. The model cannot map, retrieve, or manipulate the authority governing it - achieved through the inference-under-authority pattern, not prompt engineering hygiene.
Zero-content operation Notenic processes and retains no client content to govern. Governance evaluates state transitions and execution scope, never payload content. The system cannot leak what it does not ingest.
Zero-persistence by architecture The GRE is destroyed at session termination. Memory is scrubbed. No residual state survives the session. Zero persistence is not an optional configuration; it is an architectural absolute.
Single-use, uniquely serialized Every GRA is compiled fresh, instantiated once, collapsed, and retired permanently. Cryptographic serialization at compile time ensures no two artifacts share recoverable structure - even when built from identical policy inputs.
Chain of custody by construction Because the governance artifact is never handled across boundaries and never persists, the chain of custody is structurally indivisible. ISO-22095 compliance follows as a property of how the architecture operates - not as a process to be managed.
Attestation by construction Every adjudication decision and every execution verification emits a cryptographically signed certification event, chain-linked per session. Seven-year SOX-aligned retention. Past sessions are forensically reproducible on demand, under audit conditions, years after they have closed.
Execution-local performance Sub-50ms per transition evaluation for standard policy graphs. Evaluation and adjudication is execution-local; no external IP traversal per call. Latency is a property of where the GRE runs, not of how the policy graph is sized.
TEE-resident enclave execution The GRE runs inside a hardware-backed trusted execution environment. Policy logic is isolated from application memory. Protected against inspection, modification, or exfiltration at runtime - including by processes running on the same host.
mTLS with session-locked certs All Cloud-to-runtime communication uses mutual TLS with certificates bound to session identity. Maximum 48-hour certificate validity. Non-transferable across sessions or environments.
These properties are structural guarantees. They emerge from how the architecture operates, not from how the operator configures it. Most products in the category approach a subset of them, and almost always achieve them through deeply nested operational compromise.
Properties Notenic's architecture exists to preserve across every deployment in any environment.
- Inference may propose authority. Inference may not create authority.
- Authority acquisition requires GRE adjudication.
- Authority is session-bound, transition-specific, non-portable.
- Operational State remains owned by the System of Record.
- Governance State remains owned by the GRE.
- Consequence may only materialize through an Acceptance Gate.
- Execution must remain materially aligned with the adjudicated transition.
- No inference-originated proposal may acquire consequential authority outside active governance posture, assigned role authority, certified workflow scope, and GRE adjudication.
Notenic adapts to the system of record. Three patterns cover the enterprise field.
Where authorization is delegated to an identity provider, Notenic mints short-lived, transition-scoped credentials at the moment of certification. No standing credential is stored; the guarantee is cryptographic and enforced at the system itself.
Where the write path can carry policy, the same guarantee is enforced through a native extension. The model's authorized intent is the only thing that can commit.
Where a system cannot be extended, a Notenic-fronted broker isolates the single required credential in one controlled place and enforces the same checks before any write.
Keep your orchestrator, your models, and your execution environment. Notenic routes through an endpoint change, not a re-architecture.
Inside the Client VPS/VPC boundary.
Dual-membrane interception closes the window every other architecture leaves open — the gap between adjudication and execution.
When the external LLM returns a proposed action, the Notenic SDK intercepts the payload before it reaches the orchestrator's compilation layer. The Governance Runtime Artifact (GRA) evaluates the proposed intent against the assigned operational policy, role authority, and the authorized workflow sequence.
If a supply chain attack or sandbox escape compromises the orchestrator, an adversary could inject malicious bytecode or unauthorized API parameters at this stage. Even if the initial intent is approved, the execution layer is structurally prohibited from striking the System of Record directly. The orchestrator must compile the intent into an executable payload.
This self-referential verification loop operates completely independent of external dependencies or static schema synchronization. The actual matching of the proposed intent to the compiled output occurs strictly in-VPC, within the client's secure execution perimeter. The Notenic Cloud Control Plane does not ingest, inspect, or persist any part of the execution payload, system prompts, or proprietary data.
Architecture briefing available for qualified evaluators.
Certain implementation details and architectural mechanisms are intentionally abstracted. Detailed specifications, technical deep-dives, reference architecture documentation, and integration walkthroughs are available under NDA for CTOs, CISOs, and enterprise security teams conducting formal evaluations.
Everything that happened. Provably.
Notenic emits a complete, signed, hash-chained transition record per session. Forensic reproducibility on demand, under audit conditions, years after the session has closed.
Decentralized Governance Management
The Governance Cloud lets domain experts author and maintain policy directly. Governance evolves at the pace of the business, not at the pace of engineering capacity.
- Policy management is centralized in the cloud.
- Governance rules are written by the people who own it (no code / low code).
- External systems are connected via ingress.
- Enforcement is local, ephemeral, and structurally external to the agent it governs.
- Governance ownership is decentralized across the organization.
Monitor System Status & Events
Real-time telemetry of session relay events—with live status across Sessions Relayed, Excessive Drift Events, Poisoned Context Events, and Session Certs Revoked. Every state transition is sequenced and cryptographically confirmed.
- Certified sessions show governing status in real time.
- Revoked sessions are immediately flagged and isolated.
- Drift detection events create an auditable relay record.
Session Activity Log
Turn-by-turn governance log for every session. From routine state transitions to critical events and HITL escalations, Notenic renders every event observable across the agentic workflow. Certified forensic evidence artifacts are compiled and cryptographic seals applied at session termination.
- Every event observable across the agentic workflow.
- Real-time observability across network, session, and decision-level events.
- Single-pane view for system performance and compliance posture.
Session Posture Audit
Workflow-level posture audit trail. Every workflow step is certified, sequenced, and attributed to a deterministic policy or structural priority band—producing the exact evidence package required for compliance review, legal defense, or regulatory investigation.
- Accounts for 100% of workflow decisions, from session start to session end.
- Logs admissability across policy enforcement and HITL override events.
- Every workflow state attributable to an enforced policy, a best practice, or HITL authority.
A mathematical measure of workflow complexity versus compute capability.
Most AI governance platforms ask: what did the model output? Notenic’s structural governance runtime asks a more fundamental question: is the assigned compute resource structurally capable of resolving this level of task complexity?
The Notenic K-coefficient (Kappa) functions as a dynamic measure of structural task complexity against inference capability. It produces a deterministic evaluation of whether an assigned model possesses the optimal parameter scale for the target workflow. When a mismatch is detected (e.g., an under-parameterized model assigned to a high-complexity task), Notenic intervenes before the session produces a consequential error. Similarly, when an opposing mismatch occurs (an over-parameterized model executing a low-complexity task), Notenic intervenes to enforce compute economics.
Architecture briefing available for qualified evaluators.
This page documents Notenic's architecture at the depth appropriate for public disclosure. The full specification — the complete adjudication structure, the encoding mechanism that renders inference queries model-opaque, the Acceptance Gate cryptographic primitives, the dual-membrane independence proofs, the reference deployment patterns across regulated industries — is available to qualified evaluators under NDA through the Technical Architecture Briefing.