Model-agnostic by design, independent by construction

State is more than a snapshot

Architectures are usually drawn as if a decision reads a current value and acts on it. Enterprise state does not behave that way. A decision reads a trajectory: the balance that was true when the data was extracted, the promise that was made two steps earlier, the approval that expires in an hour, the case status that another team updated while the request was in flight.

Consider two payment requests that arrive at the same service. Both are for the same amount, both from the same account, both authorized by the same customer. In the first, an earlier transfer settled before this request was submitted, so the available balance is now below the amount. In the second, the earlier transfer is pending and will not settle, so the funds are available. Every field visible to the proposing system is identical. The only difference is the path each request took to get here, and the path is what determines whether the payment is permitted.

An architecture that models state as a snapshot cannot represent that difference. It can read the current balance, but not the sequence of commitments that produced it, and it cannot tell whether the figure it just read is the figure the decision was formed over. This is why the state a decision rests on has to be supplied deliberately, with its sources, timestamps and versions, rather than assumed from whatever the model happened to receive.

Why the decision boundary is a separate layer

There is a tempting alternative to a separate boundary: put the checks inside the agent, the model wrapper or the workflow that proposes the action. It is cheaper, it has access to everything the proposer has, and it requires no new deployment. It also fails for a structural reason rather than a technical one: a component cannot independently assess its own entitlement to act.

When the check lives inside the proposer, three things follow. The check inherits the proposer's assumptions about state. The permission it enforces is whatever the proposer has access to, which is usually broader than what the decision requires. And the record of what was decided is written by the same component that wanted the outcome, which makes it a justification rather than evidence.

The separation is the control. Everything else in this architecture — the gateway, the state binding, the record — exists to make the separation enforceable.

The AnantDecision layer

AnantDecision is where proposals are formed: it brings decision intelligence to the state it can see, and produces a proposed action with whatever reasoning and confidence the method supports. It is a first-class component of the platform, and it is optional at the assurance boundary.

That last point is the important architectural one. The boundary does not require the proposal to come from AnantDecision, or from anything built by this platform. An agent framework, a rules engine, a gradient-boosted model behind an internal API, or a human case worker all produce proposals that pass through the same evaluation, because the question the boundary asks — is this action permitted on this state — does not depend on how the proposal was produced.

Where AnantDecision is in use, it is also where the enterprise's decision logic becomes explicit: the factors a decision turns on, the thresholds it respects and the explanation it carries. That explicitness is what makes later behavioral testing possible, because a decision method that cannot state what it depends on cannot be tested for whether it moves when those things change.

Multiple decision engines, one boundary

Enterprises do not standardize on one way of making decisions, and they should not have to. Pricing and eligibility suit rules. Fraud detection suits models. Complex cases suit agentic workflows. Operational decisions suit deterministic domain logic. The architecture accommodates all of them by keeping the boundary neutral about what produced the proposal.

This is also what makes heterogeneous deployments governable. A single boundary produces a single class of decision record, so decisions made by five different technologies can be replayed, audited and analyzed in one place rather than five.

The proposed decision

What crosses the boundary is a structured proposal: the action, the parameters, the entity it concerns, the amount or severity where relevant, and the context the proposer believes applies. The boundary treats all of it as a claim to be evaluated, not as a fact to be trusted.

Making the proposal a well-defined object rather than a free-text intention is what allows assurance to be deterministic. A proposal that arrives as prose has to be interpreted before it can be evaluated, and every interpretation step is a place where the meaning of the action can shift. A structured proposal carries enough for the boundary to decide, and enough for the record to be replayed later without re-deriving what the system meant.

It also fixes where the model's confidence belongs. Confidence is an attribute of the proposal — useful evidence about the proposer's own expectations — and never a substitute for the conditions the boundary evaluates.

The AnantVerify layer

AnantVerify is the boundary. It receives the proposal, reads the state the decision depends on, attaches and checks evidence, evaluates authority, applies the behavioral expectations established through Decision Transformation Testing, consults coverage and runtime policy, and returns a verdict.

Architecturally it has three properties that matter more than any implementation detail. It is a service, so it can be placed in a path rather than embedded in a caller. It is deterministic with respect to its inputs, so the same proposal on the same state returns the same verdict — which is what makes replay meaningful. And it is evaluated at the moment of execution rather than at the moment of planning, which is what makes it a control rather than a prediction.

Why assurance is not part of the proposer

The failure mode of an embedded check is not that it is malicious; it is that it agrees. It is written by the same team, deployed on the same schedule, and given the same view of state, and it evaluates the proposal using assumptions that were derived from the decision method it is checking. When the underlying assumption is wrong, both components are wrong in the same direction, and the check adds confidence rather than protection.

Independence has a second, more practical benefit: the boundary can be changed without redeploying the AI. Policy limits, approval thresholds, required evidence and coverage restrictions live at the boundary, so a change in governance takes effect on the next decision rather than on the next model release. That is the difference between a control that responds in days and one that responds in quarters.

The third is accountability. A decision record produced by an independent component states what was true at the boundary — the state observed, the evidence attached, the authority found, the verdict returned. A record produced by the proposer states what the proposer believed, which is a different artifact with a different value in a review.

The execution gateway

The gateway is where the architecture stops being advisory. It is the component through which the consequential action actually leaves the enterprise — the payment instruction, the order release, the case closure, the configuration change, the isolation command. It consumes the verdict and the approval context, and it acts only on a verdict that permits action.

Two properties make it a gateway rather than a step. Completeness: there must be no route to the action that bypasses it, including operational tooling, bulk operations and administrative interfaces. Freshness: it must verify that the state it is about to act on still matches the state the verdict was issued for, because between evaluation and execution the world is allowed to move.

In practice this means the gateway is narrow and unambitious. It does not interpret policy, score risk or retry intelligently. It verifies a verdict and an approval, checks the binding, executes, and reports the outcome back. Everything interesting has already been decided upstream, which is what makes the component small enough to be trusted with the last step.

State binding and time-of-check to time-of-use

Any architecture with a gap between evaluation and execution has a window in which conditions can change. The window is short, which is precisely why it is dangerous: it is short enough to be ignored in design and long enough to matter in production, and the failures it produces look inexplicable because every component behaved correctly for the state it saw.

State binding closes the window by attaching a reference to the evaluated state — a version, a fingerprint, a set of observed values with timestamps — to the verdict, and requiring the gateway to verify that reference before acting. If the state has moved in a way that is material to this decision, the binding fails and the correct response is re-evaluation, not execution.

This is the same discipline concurrency control applies to shared resources, applied to decisions. The alternative — evaluating a decision and then acting on whatever the state happens to be a moment later — means the enterprise's assurance describes a situation that no longer exists, and the action it authorizes is unassured by construction.

The inputs to a verdict

A verdict is a function of six inputs, and each has an owner. Keeping those owners distinct is what stops the boundary from becoming a monolith with an opinion about everything.

Nothing in this table is the model's opinion of itself. That is the design: the boundary's authority comes from the fact that every input it reasons over belongs to a system or function that is accountable for it independently.

Evidence and authority as architectural inputs

Evidence and authority are frequently treated as runtime lookups — read the document, check the role — which works until a decision is questioned and the enterprise has to show what was relied on. Making them architectural inputs means they are gathered deliberately, with provenance, version and timestamp, and carried into the record.

For evidence, that means the boundary knows which artifacts support the proposal, where each came from, whether it was current at decision time, whether its scope covers this jurisdiction and case, and whether anything contradicts it. For authority, it means the boundary evaluates the proposal against delegations, limits, conditions and their validity — rather than against the credentials of the caller.

The practical effect is that both become inspectable rather than inferred. An enterprise can answer which evidence supported a decision and which authority permitted it without reconstructing either from logs, and can answer the inverse question — which decisions rest on a source that has since been found unreliable — as a query rather than an investigation.

Where Decision Transformation Testing fits

Decision Transformation Testing is not a runtime component; it is the process that gives the runtime something worth enforcing. It establishes, for a decision class, what must not change the decision and what must, then expresses those expectations as conditions the boundary applies.

Its architectural footprint is therefore two-sided. Offline, it produces the invariants, material sensitivities and boundary expectations for a decision class, along with the coverage record of what has been tested. At runtime, those expectations are applied to each proposal, and the coverage record determines what may happen when a case falls outside tested regions — allow, hold, escalate, or refuse to automate at all.

This is what keeps testing and control from drifting apart. The same artifact that records what was tested determines what is enforced, so a decision class cannot be granted autonomy in a region where nobody has ever looked at how it behaves.

Coverage and runtime policy

Coverage answers how much of a decision space is known. Runtime policy answers what is permitted right now. Both constrain the same decision, and they fail in different ways when they are missing — a system with policy and no coverage enforces rules it cannot show are safe, while a system with coverage and no policy knows a great deal and applies none of it to the specific action in front of it.

Architecturally, coverage is a property of the decision class and runtime policy is a property of the moment. Coverage is slow-moving: it grows as transformations, regions and interactions are tested, and it should be visible to anyone setting autonomy limits. Runtime policy is fast-moving: it can be changed in an hour in response to an incident, and the change takes effect on the next decision without touching a model.

Keeping them separate is also what makes the autonomy question answerable. A decision class may run autonomously where coverage is documented and policy permits it, escalate where coverage is thin, and hold where the state itself is not good enough — all enforced by the same boundary, on the same request, without the proposing system knowing any of it happened.

Human approval as an architectural component

Human review is usually drawn as a person outside the system. Architecturally it is better modeled as a component with inputs and outputs: it receives an escalated decision with the conditions that caused the escalation, it produces an approval or a refusal with the authority attached, and the gateway treats that output exactly as it treats an automated verdict.

Modeling review this way fixes a common failure. An approval that exists as a message in a queue, or as a flag on a case, cannot be verified at execution — the gateway cannot tell whether it applies to this action, this amount and this state, or to a materially different request that has since changed. Making the approval an artifact with scope, limit and expiry lets the gateway check it, and lets the enterprise replay it.

It also makes the limits of human review visible by construction: if the reviewer does not receive the state the decision rests on, or cannot refuse, or is not given the specific question to answer, the architecture shows it. Those gaps are hard to see in a policy document and obvious in a component diagram.

The integration plane: REST and gRPC

The boundary is reachable over the protocols enterprise systems already speak. REST covers the majority of integrations: request-response evaluation from an application, a workflow engine or a service, with the verdict returned in the response and the decision record retained by the boundary.

gRPC covers the cases where evaluation is on a hot path and the overhead of a text protocol matters — high-volume transaction processing, low-latency execution paths, and service-to-service calls inside the same environment. Both surfaces evaluate the same proposals against the same conditions and produce the same verdicts; the choice is an engineering one, not a governance one.

Because the boundary is placed in the path rather than beside it, integration work is mostly about the state side: identifying which sources the decision depends on, wiring them so that the boundary can read them, and declaring for each how the decision treats its currency, absence and disagreement.

The runtime API pattern

The intended call shape is deliberately simple, and its simplicity is what makes it adoptable. A caller submits a proposed decision; the boundary reads the state it needs, evaluates, and returns a verdict with the conditions that produced it. There is no requirement that the caller understands why, only that it obeys what it receives.

Where the enterprise prefers, the call can be inverted: the interrogating system asks the boundary to evaluate and then continues internally. Both shapes exist because the right answer depends on who owns the execution path, and neither changes what the boundary evaluates or what it records.

Event-driven integration

Some decisions are not triggered by a request but by a change: an amount crossing a threshold, a shipment delayed, a sensor threshold breached, a claim status updated, an approval expiring. In these cases the boundary is invoked in response to the event, using the event as part of the state and the systems of record as the rest of it.

Event-driven integration is where state currency becomes architecturally visible, because the event carries a timestamp and the decision has to reconcile it against the state it reads. A decision formed five minutes after the event it responds to is a different decision than one formed immediately, and the boundary should be able to express that difference rather than assume it away.

It is also where duplicate and out-of-order delivery become assurance questions rather than plumbing questions: the same obligation applied twice, or applied before the event that should have preceded it, is a decision-permission problem — and the temporal transformations in Decision Transformation Testing exist because of exactly these shapes.

Agents pass through the same boundary

An agent that calls tools is a proposer with a broader repertoire than a single model: it can read, write, transact and trigger. Architecturally the important consequence is volume rather than novelty. Where a conventional integration proposes one decision per transaction, an agent may propose several per task, each with different authority requirements and different consequences.

The architecture handles this by making the boundary per action rather than per agent session. Every consequential action the agent wants to take is evaluated on its own, against its own authority and its own state, so a limit that permits reading a record does not thereby permit modifying one, and a permitted modification does not imply permitted deletion.

This is the difference between granting an agent access and granting an agent authority. Access is configured once and applies to everything the credentials reach. Authority is evaluated per decision, which is what allows an agent to be capable of an action and still be prevented from taking it.

Integrating existing AI systems

Most enterprises already have models in production, agents in pilots and workflows that have accumulated their own permission logic. The architecture is designed to be added to that state rather than to replace it: the existing system keeps producing proposals, and the boundary is inserted where those proposals would otherwise become actions.

In practice the work is a sequence. Identify the decision classes that reach execution. Map the state each depends on and the sources that own it. Declare the authority each requires. Establish the behavioral expectations and the coverage that justifies the autonomy in force. Then place the boundary in the path, starting with the class whose consequences are highest.

Nothing in that sequence requires retraining a model, changing a prompt or rewriting an agent. It requires the enterprise to state, for each class, what it has never had to state before — which is the actual deliverable of the architecture.

Integration without replacement

The architecture deliberately has no ambition to become the system of record for anything it touches. State stays with the systems that own it, identity stays with the identity provider, execution stays with the systems that execute, and governance stays with the functions accountable for it. The boundary contributes one thing: the verdict and its record.

This is a design constraint with a practical purpose. A control layer that requires replacing core systems will not be deployed in a consequential path, and a control layer that accumulates ownership of the state it evaluates becomes a single point of failure for every decision that depends on it.

It also makes the architecture reversible. Because the boundary reads from systems and returns verdicts, it can be scoped to one decision class, one business unit or one jurisdiction, and it can be removed from a path without dismantling the systems behind it. Controls that cannot be removed are rarely approved.

Deployment models

The boundary is placed according to three constraints, in this order: where the state lives, where the action executes, and what the enterprise is permitted to do with its data. Everything else — managed service, container platform, bare metal — follows from those.

These are not tiers of the product, and they are not mutually exclusive. One enterprise routinely runs several at once: a managed deployment for customer-facing decisions, a private one for regulated workloads, and an edge instance close to industrial equipment, all producing the same class of decision record.

Deployment reference model

In every model, the same four elements have to exist and have to be reachable from the boundary: the state sources a decision class depends on, the systems that execute its actions, the identity provider that establishes who is calling, and the policy and evidence the boundary evaluates against. Deployment changes where those elements are, not what the boundary does with them.

The last question is the one that decides the architecture in restricted environments. Where policy and evidence cannot be pulled, they are distributed as signed artifacts and updated on a controlled cycle, and the boundary's behavior is verifiable against the version it holds.

Restricted and air-gapped environments

Air-gapped deployments are the case that tests whether the architecture is genuinely self-contained. Nothing may call out, so every input the boundary needs — policy, evidence, coverage, authority data — arrives by controlled transfer and is held locally, with versions the enterprise can attest to.

Two consequences follow. Decision records accumulate locally and are exported on the enterprise's cycle rather than streamed, so the record format has to be complete enough to be meaningful when it arrives days later. And the boundary's behavior has to be verifiable offline, which is possible precisely because a verdict is a deterministic function of the inputs the enterprise provides.

This is also where the separation from the proposing system pays off most clearly. In an environment where nothing can be observed from outside, the decision record produced at the boundary is often the only artifact that shows what the enterprise's automated systems were permitted to do, on what state, under whose authority.

Security by architecture, not by convention

Security in this architecture is not a set of settings applied after deployment. It comes from where the boundary sits and what it is capable of doing: the boundary is a service, callers are authenticated, its own access to systems of record is scoped to reading what a decision needs, and its ability to act on the enterprise is limited to returning a verdict.

That last property is worth stating plainly. The boundary does not execute consequential actions. It has no credentials for the payment system, the order system or the change system. Its output is a verdict that another component consumes, which means the compromise of the boundary is a control failure rather than an unrestricted ability to act.

The same principle applies to its access to state. The boundary reads what a decision class requires and nothing beyond it, so the blast radius of a misconfiguration is bounded by the decision classes it serves rather than by the enterprise's data estate.

JWT, SSO and SAML

Callers are identified using the mechanisms the enterprise already operates. JWT carries identity and claims for service-to-service calls and API integrations. SSO provides the interactive path for the people who work with decisions, conditions and escalations, so access follows the same lifecycle as the rest of the enterprise's applications. SAML federates with an existing identity provider where that is the established mechanism.

The architectural point is that identity is an input, not an authority. Being an authenticated caller establishes who is asking; it says nothing about which decisions that caller may make. The two questions are asked separately and answered by different systems, which is what prevents an identity integration from silently becoming a permission grant.

Where the enterprise already has a strong identity program, this architecture inherits it rather than duplicating it. There is no second directory, no parallel role model, and no separate credential store to keep in step.

User management, roles and permissions

User management covers the people who configure and operate the boundary: who may define our conditions and limits, who may change them, who may review an escalation, and who may see the decision record. Roles and permissions are the mechanism, and they are deliberately scoped to the boundary's own functions rather than to the enterprise's business roles.

This keeps two kinds of permission from being confused. Administrative permission governs what a person may configure in the platform. Decision authority governs what a decision may be permitted to do in the enterprise. A platform administrator is not, by virtue of that role, an approver of claims, and an approver of claims does not need administrative rights.

Where an organization wants a single view of both, the business authority continues to come from the systems and governance that own it — the boundary evaluates it as an input rather than maintaining its own parallel copy.

Authentication is not decision authority

This is the most common architectural error in enterprise AI, and it is usually invisible because the two coincide during development. A service holds credentials that reach a tool, so it can call the tool; the fact that it can call the tool is treated as proof that it may. Capability is not permission, and the gap between them opens exactly when the system is trusted with more.

Decision authority has a different shape from authentication. It is scoped to a decision class, limited by amount or severity, conditional on approvals, time-bound and revocable, and it belongs to an accountable owner rather than to a runtime environment. None of those properties can be expressed by a credential, which is why they are evaluated as conditions rather than configured as access.

A caller that is authenticated has proved who it is. It has not proved that this action is permitted, and only the second question decides whether the action executes.

Service-to-service security

The boundary is read by proposing systems and read by gateways, which means its service-to-service surface is where the enterprise's trust decisions actually live. Each caller is authenticated, scoped to the evaluation it may request, and unable to request an evaluation it has no business asking for.

Calls carry the context needed to evaluate the decision and nothing that would let a caller influence the outcome. A caller supplies the proposal and the context it believes applies; it does not supply the state, the evidence or the authority, because a caller that can supply those can manufacture its own verdict.

Where a gateway receives a verdict, the reverse applies: it verifies the verdict's provenance and its state binding rather than trusting a message that claims a decision was permitted. The security of the last step is what makes the whole path meaningful.

Multi-agent architectures

Once agents cooperate, decisions acquire a composite structure: one agent plans, another retrieves, a third executes, and a fourth verifies. Each may hold different authority, and the enterprise's obligation attaches to the union of what they do rather than to any single agent's behavior.

Placing the boundary at each action rather than on the pipeline is what keeps this tractable. The state of the broader task does not need to be modeled for assurance to work; each proposed action is evaluated against the authority of the actor proposing it and the conditions on the state it touches. The composite decision is then auditable because its parts are recorded individually.

It also handles the failure that is specific to agent cooperation: two agents each acting within their own authority while the combined effect exceeds what either was granted. Where a sequence is known in advance, the boundary evaluates the sequence as a condition; where it is not, agreement is bounded by per-action limits rather than by the belief that cooperating agents will not exceed them.

Human plus AI architectures

In most enterprises the operative architecture is a mixture: automating systems propose, people decide, and sometimes people propose while systems decide. The boundary does not care which party is on which side, because both are evaluated as proposals and both are recorded as decisions.

The benefit of using one boundary for both is that the organization gets a single standard. If a machine action is required to satisfy state, evidence and authority conditions, then a human action of the same class should satisfy them too — not because the person is suspect, but because the enterprise's entitlement to act does not depend on who proposed.

It also produces an honest escalation path. When a decision is escalated, the human receives the conditions that caused it, the evidence in conflict, the authority required and the specific question to answer. The decision still passes back through the boundary on the way to execution, with the approval attached, so nothing about the escalation weakens the control.

Where each component can fail safely

A useful test of an architecture is what happens when each part of it fails. This one is designed so that the failure of any single component reduces the enterprise's capability rather than its control.

The right answer for a control is fail-closed, and it has to be stated rather than assumed. Each row above is a design decision that can be verified in an environment, which is the point of writing it down.

Decision replay in the architecture

Replay is a property the architecture has to be designed for, not a feature added afterwards. Because a verdict is deterministic with respect to its inputs, it can be reconstructed — provided the inputs were captured rather than merely used.

That means the record carries the proposal, the state as observed with source and version, the evidence set with provenance, the authority resolved, the expectations and policy applied, the verdict and its conditions, and the state binding. Replaying the decision is then a matter of re-evaluating the same inputs, and comparing the result to what was originally returned — which detects drift in policy and behavior over time, not just at the moment of an incident.

Lineage is the same record read backwards: from a decision to the sources, policies, evidence and authority that produced it. When a source is found unreliable or a policy is revised, lineage turns the question of what was affected into a query rather than a project.

Decision observability is not system observability

Conventional observability watches components: latency, errors, saturation, throughput, traces. All of it remains useful, and none of it answers whether a decision should have been permitted. A perfectly healthy system can take an action it had no authority to take, with no anomaly anywhere in the telemetry.

Decision observability watches the boundary instead: verdict distributions by class, the conditions that most often hold or escalate, coverage against the decisions actually taken, the state sources that were unavailable, the conflicts that appeared, and the overrides operators applied. These are the signals that tell an enterprise whether its assurances still describe the decisions it is making.

The two views are complementary and should be kept distinct, because they are consumed by different people for different reasons: platform reliability for the engineering function, decision conditions for the risk, assurance and operations functions.

Outcome feedback

The final architectural loop is the shortest to describe and the longest to run. Outcomes — settled payments, delivered orders, resolved cases, contained incidents, reversed actions, customer complaints — return to the decision record, which makes them available as evidence for future assurance.

What that buys is a system that learns about its own decision surface rather than about its model's accuracy. A verdict of allow followed by an adverse outcome is a case whose conditions were insufficient, whether or not the model was wrong. A hold followed by an operator override that turned out to be correct identifies a condition that was too strict. Both are inputs to coverage, not just to a scorecard.

Feedback also has to be closed with restraint. Outcomes are noisy, some appear months late, and attributing a downstream loss to a single decision is often an assumption rather than a finding. The architecture's role is to keep the link between the decision and its outcome available, so the enterprise can reason about it with the record in front of it.

The six-layer reference architecture

Read from the bottom up, the architecture is six layers. Each has a narrow responsibility, and the boundaries between them are what allow any one of them to be changed without invalidating the others.

The ordering is not a hierarchy of importance. It is a dependency order: assurance cannot be meaningful without state it can verify, and outcome feedback cannot improve anything unless the decision and its conditions were recorded in the first place.

Architecture principles

The following principles are the decisions this architecture makes, stated so that an implementation can be checked against them rather than judged on taste.

From systems of record to systems of decision

Enterprise architecture has spent thirty years making systems of record coherent: one authoritative source per fact, reconciled, governed, integrated. That work answered where the enterprise's facts live. It did not answer what the enterprise is permitted to do with them, at machine speed, repeatedly, without a person in the loop.

That is a different category of system, and it has different properties: it is evaluated per action rather than per record, it is authoritative about permission rather than about facts, and its output is a decision with a record rather than a state with a history. The decision layer is the system of decision alongside the systems of record.

Enterprises that build this layer get a specific and unglamorous benefit: they can state what their automated systems are permitted to do, show that the conditions were satisfied when they acted, and account for the result. The architecture in this document exists to make that statement true by construction rather than by policy.

Why this architecture matters

Every enterprise that puts AI into a consequential path faces the same three questions: what is it allowed to do, on what basis, and how would we know. The shape of the architecture is what determines whether those questions have answers that hold up on a bad day.

A model-centric architecture answers them with training, evaluation and monitoring, and discovers the gap the first time a decision is questioned. A decision-centric architecture answers them at the boundary, continuously, with a record — and lets the model stack evolve underneath it without invalidating the controls around it.

Enterprises do not need a more capable system. They need to know what their capable systems are permitted to do, on what state, under whose authority, and how to show it.