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.

Notenic Architecture

Absolute security — beyond constraint.

The industry spends billions attempting to train probabilistic models to govern themselves—a structural vulnerability that guarantees eventual execution drift. Notenic rejects this paradigm. By decoupling intelligence from authority, the platform enforces deterministic, hardware-backed isolation at the data-ingress membrane. Autonomous intent cannot mutate enterprise system state without explicit, real-time cryptographic permission.

Class Comparison

The fallacy of agentic self-governance.

The industry attempts to secure autonomous systems by embedding guardrails inside the reasoning engine. We secure the enterprise by locking the execution path.

Security is not a prompt, and governance is not a library. Legacy architectures—embedded prompts, in-process middleware, and cooperative sidecars—rely on the underlying model to moderate its own behavior. This is an architectural failure. If the governance mechanism shares memory with the agent, it is structurally compromised from inception.

True architectural security requires absolute physical separation. By extracting governance entirely outside the agent runtime, we strip the model of implicit authority. Every proposed state transition must clear an isolated, hardware-backed enforcement membrane before it touches your System of Record. We do not trust the model; we verify the payload.

Architectural Class Comparison In-Process
Middleware
Cooperative
Sidecar
Embedded
Prompt
Traditional
Runtime Governance
Notenic
Governance lives outside the agent runtime A separate runtime authority, not a library inside the agent.
Prevents unauthorized authority acquisition before execution Authorizes each state transition before it commits to systems of record.
No ingestion or export of user data or content Governs behavior without reading or storing client content.
Immune to prompt injection by architecture Direct and indirect injection are contained at the authority boundary. A manipulated model cannot produce an action outside policy, role, or workflow scope — even when the injection succeeds at the prompt.
Cryptographic sovereignty over key material Runs entirely inside the client VPC. No egress. Not a configuration - an architectural property.
Forensically reproducible audit evidence Cryptographically signed posture record per session. ISO-22095 chain of custody.
Class-agnostic across agent archetypes Governance is not coupled to model, provider, or deployment.
Model-portable across providers Provider migrations don’t invalidate authored policy or session evidence.
Enforces transition-level admissibility at the system of record Protocol-enforced pause points at the tool layer. Not a UI prompt.
Updates policy without redeployment Author once; updates take effect at the next session compilation.

NotenicA zero-trust runtime architecture, underpinned by:

01
Runtime Posture Verification
02
Invisible Application Exchange
03
Ephemeral Enclave Isolation
04
Zero-Persistence In-Memory Execution
05
Hash-Chained Metadata Attestation
06
Cryptographically Signed Audit Evidence
System Architecture

Relentless mediation without the architectural drag.

Achieving absolute zero-trust governance typically requires a multi-year engineering tax and a total tear-down of your stack. Notenic is built differently. We deploy as an impermeable, independent execution membrane—enforcing total state-transition authority without requiring API rewrites, massive engineering allocations, or disruption to your existing Systems of Record.

Notenic Cloud Architecture
Notenic Runtime Architecture
Deployment Properties

Inherited architectural properties.
Not assembled configurations.

Property 01

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.

Property 02

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.

Property 03

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.

Property 04

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.

Property 05

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.

Property 06

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.

Property 07

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.

Property 08

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.

Property 09

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.

Property 10

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.

Governance Invariants

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.
Integration by Capability

Notenic adapts to the system of record. Three patterns cover the enterprise field.

Delegated-auth systems

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.

Extensible platforms

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.

Legacy systems

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.

The Governance Lifecycle

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 AI Governance Architecture
NGC

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.

GRA

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.

GRC

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.

GRE

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.

Notenic Governance Cloud Control Plane UI
Multi-Membrane Verification

Intelligence proposes. The architecture disposes.

We do not rely on a binary pass/fail gate. To guarantee absolute state-transition authority, the Governance Runtime Environment (GRE) subjects every AI-generated intent to a seven-phase cryptographic gauntlet.

This is where probabilistic reasoning is forcefully converted into deterministic math. Operating entirely within a hardware-backed Trusted Execution Environment (TEE), the multi-membrane verification process executes in sub-50 milliseconds. By the time a payload is permitted to touch your System of Record, all execution ambiguity has been systematically stripped away.

01

Deterministic Intent Adjudication:

The agent’s initial execution proposal is intercepted and strictly evaluated against a mechanically enforced policy graph. This physically binds the agent’s intent to its temporally authorized role and scope, terminating unauthorized access attempts before compute is ever expended on execution compilation.

02

Cryptographic Blob Verification:

The compiled execution blob undergoes an independent, secondary physical evaluation against the authoritative constraint graph. This redundant membrane ensures that the exact code generated for execution has not deviated probabilistically from the originally approved intent.

03

Coherence Matching & Mutation Destruction:

The runtime forces a mechanical match between the cached execution proposal (Phase 1) and the compiled executable blob (Phase 2). Any contextual drift, adversarial injection, or in-flight mutation between reasoning and compilation triggers an immediate enclave collapse, instantly destroying the compromised payload.

04

Environmental Posture Triangulation:

The intended execution state is cryptographically triangulated against the actual, real-time posture of the System of Record (SoR). This ensures the agent is not hallucinating an operational reality, preventing blind state transitions against phantom variables or deprecated infrastructure.

05

Strict Schema Adherence:

The execution blob is mechanically forced through the SoR’s exact state-based JSON object framework. We do not tolerate malformed syntax, extrapolated parameters, or generative approximations. If the payload deviates by a single character from the required structural schema, it dies inside the TEE.

06

SPIFFE-Backed State Reservation:

The SoR issues a short-lived, tokenized state transition authorization utilizing SPIFFE protocols. This does not merely authorize the action; it explicitly locks and reserves the target SoR state for this specific mutation. This mathematically eliminates race conditions, preventing out-of-band state drift while the agentic loop is in progress.

07

Relativistic Posture Certification:

The overarching inference session is subjected to a continuous Relativistic K-model rating. This generates an immutable certification of the session’s behavioral posture and operational integrity from instantiation to termination, ensuring the agent did not suffer structural or logic degradation over the course of the workflow.

The Governed Promise

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 Governed Unit

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.

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?

Compile-time vs. Runtime

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.

Answer:
Part 1 of 2
Answer:
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.

The K-Coefficient

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.

Scroll