The Contextualised Enterprise: Connecting Agentic Reasoning to Governed Execution

Most enterprise AI discussions are about one of two things. Either a model can reason across messy information, or a transaction system can enforce rules without exception. This note is about the join between them. Useful reasoning is no use if it cannot reach the systems that act, and fast action is dangerous if nothing connects it to the evidence that justified it.

The thesis is modest: useful reasoning and accountable execution need a continuous, inspectable path between them. That is a proposed synthesis from the Contextual Agentic Enterprise (CAE) framework. It is not an industry standard, it does not say every failure has a single cause, and it does not describe a platform that already exists.

Two lenses see different halves of the same decision

The first lens is contextual and agentic reasoning. It asks what evidence is permitted for this purpose, what the business means by its own terms, what has changed and what action might be worth proposing. It tolerates ambiguity and produces proposals.

The second lens is deterministic execution and systems of record. It asks who is acting, under whose authority, against which current state, under which rule, and what the system will do exactly once. It tolerates no ambiguity and produces effects.

Either lens alone fails in a recognisable way. Reasoning without execution control produces confident proposals nobody can safely accept. Execution control without context produces strict systems that cannot see the business meaning behind a request. The CAE proposal is that each lens hands the other something specific. Reasoning hands over a proposal with its basis. Execution hands back verified current state, a decision and a record.

This is the same division the site describes elsewhere as a deterministic shell around probabilistic reasoning. The new element here is the connecting path: how context becomes a proposal, how the proposal meets the system of record, and what evidence survives.

Contextualisation means making meaning, ownership and limits explicit for a purpose

Enterprise contextualisation, as used here, is making the relevant business meaning, relationships, ownership, evidence, constraints and permitted actions explicit for a particular purpose. The words that follow are easy to blur, and the architecture depends on keeping them apart.

• Raw data is not a supported claim. A supplier status field is data. “This supplier is active as at the stated time, according to this system” is a claim with a source and a time.
• A semantic model is not an ontology, a knowledge graph or working context. A semantic model names business concepts. An ontology states formal relations between them. A knowledge graph stores instances. Working context is what one agent receives for one task. A Context Contract declares what that task may receive; it is the least of these four and the most often missing.
• A declared process is not observed work. The approved procurement process and what people and systems actually did on Tuesday are different records.
• A credential is not a mandate. An API key shows a caller can reach a system. It does not show the business authorised this action by this actor.
• A proposal is not a decision, and a decision is not an effect. A model may propose. A person or a rule decides. Only the system that owns the record commits.
• A snapshot is not current state. Context assembled at 9.00 am describes 9.00 am. The commitment happens later, against whatever is true then.

The CAE reading is that all six distinctions must be visible at the point of commitment, not only in design documents.

A mixed estate is the starting point, and replacing it is not a prerequisite

Real organisations hold legacy systems, modern software-as-a-service products, APIs, batch jobs, documents, data platforms, identity services and people who know where the exceptions live. Figure 1 shows the shape this note works with: a mixed estate, a discovery step that makes its context explicit, a model of that context specific to the organisation, a choice of technology that fits each piece of work, a controlled effect and evidence.

Text description of Figure 1. Six bands read from top to bottom. The estate sits first, with no replacement implied. Discovery makes the work, owners and constraints explicit. The context model records meaning, ownership and evidence for this organisation. A choice of technology follows, and “no change” is a legitimate answer. The effect passes through the system of record. Evidence and measurement return to discovery.

The practical consequence is that none of these steps requires a wholesale replacement, a knowledge graph or an agent runtime. Useful systems of record stay. The context model can begin as a short register for one workflow.

An agent is justified only when the work needs reasoning, and many tasks do not

Discovery produces a context model, and the model supports an honest choice among options. In order of increasing autonomy they are: no change; process improvement; deterministic automation; analytics; AI assistance for a person; and bounded agentic work. An agent is justified when three things are true. The work needs interpretation of unstructured or changing evidence. A wrong proposal can be caught or reversed at acceptable cost. And the effect can be bounded by an authority the system of record enforces. If a clear rule would do, use the rule.

Reusable, verified context may reduce repeated discovery and integration effort across several pieces of work. That is a benefit hypothesis requiring measurement, not a proven saving, and it will not suit every organisation.

Established ideas help here when used in proportion. Snowden and Boone’s Cynefin framework distinguishes problem types and suggests different responses; it is a sense-making aid, not a procedure. Conway observed that systems tend to mirror the communication structure of the organisations that build them, which is a reason to treat team boundaries as part of the context model. Evans’s bounded contexts give a way to keep a term such as “supplier” precise within one domain. Nothing in this note depends on any of them being universal.

Nor does it follow that process notation, relational databases or deterministic services “collapse” under complexity. They are excellent at what they are for: stable, repeatable, auditable transitions. The proposal is that they keep that job.

The dual-lens architecture puts a gateway between proposal and effect

Figure 2 shows the two lenses and the path between them.

Text description of Figure 2. Three zones read top to bottom. In the reasoning zone, a Context Contract limits what is activated, the agent reasons, and a proposal is produced with its basis. In the gateway zone, identity is established by the server, a policy decision is made on trusted inputs, a person reviews when the policy requires it, and any approval is bound to the exact action. In the execution zone, the system of record rechecks current state, commits, and issues a receipt. Evidence is recorded before and after the action, and outcomes return to context.

Three properties matter more than the boxes. First, complete mediation: every effect path passes the gateway, as Saltzer and Schroeder put it, every access to every object must be checked for authority. A prompt instruction or a user interface that can be bypassed is not a gateway. Second, the model is never a source of trusted facts about itself. It cannot assert that its signature, delegation, approval or freshness check succeeded. Third, the system of record has the last word on current state, because only it knows what is true when the commit happens. This is consistent with the zero trust principle in NIST SP 800-207 that access decisions use current context rather than assumed trust.

A fictional procurement walkthrough shows where each lens acts

Illustrative scenario: a fictional composite written to make the point concrete. It does not describe a real organisation, and its figures are not reported outcomes.

Harbourline Facilities, an invented building-services firm, runs maintenance for water-treatment plants. A planner needs impeller kits for scheduled pump work. The firm keeps money in integer minor units, so 1,860,000 means AUD 18,600.00. The thresholds below are example configuration, not policy.

Figure 3 draws the same sequence for the permitted path and the main exceptions.

Text description of Figure 3. The agent proposes. The gateway authenticates the actor, checks delegation and evaluates policy. Within the limit it passes the action to the system of record. Above the limit it escalates, and a manager’s approval must match the action digest. The system of record rechecks supplier status and budget, reserves budget with a conditional update, commits and returns a purchase order number. If the reply is lost, the caller reads status by the idempotency key rather than repeating the commit.

Three variants are worth stating. In the permitted path the 1,860,000 request is inside the 2,000,000 limit, the supplier is active, policy v7 is current and 2,400,000 remains in the budget line, so the action commits. In a denied path the same request arrives after the supplier is suspended, so it is denied for that reason alone. In an escalated path a standing order of 3,200,000 exceeds the delegated limit, so it is escalated. A manager approves, and the approval records the digest of that exact order. If someone later edits the quantity, the digest no longer matches and the commit is denied.

Two harder cases concern time. If two planners each request 1,860,000 against a remaining budget of 2,400,000 at once, exactly one can win; the other must be told the budget changed. And if the commit succeeds but the reply is lost, the caller has an unknown result. It must not guess. A status read by the same idempotency key discovers the outcome, and a retry with that key replays the stored result rather than committing again.

A local mock of those two cases was run for this note. With two concurrent requests, one committed and one was denied for budget; a retry returned the stored purchase order; a retry with the same key but a different request was rejected; and after a lost reply the status read found one effect and the retry created no second row. That demonstrates the logic only. It does not show how any particular ERP, workflow engine or payment provider behaves, and a successful response from a mock proves nothing about a production transaction. A workflow service that advertises execution guarantees does not, by itself, give exactly-once business effects across the systems it calls.

The policy gate decides on trusted inputs and fails closed

A policy engine answers a question; it does not execute or undo anything. The gateway supplies verified inputs: tenant, actor, action, resource, amount and currency, the authoritative limit, the action digest, the policy version, approval expiry and the current time. Types and missing fields are validated before evaluation. The model supplies none of these as facts.

The result contract is application-level: permit, deny or escalate, each with reasons. Rego does not return “escalate” natively, so the application defines it. The example is written as one adapter around that decision contract. Other policy engines would need their own adapter, and passing the tests in one engine says nothing about another.

OPA and Rego. An unsatisfied rule in Rego is undefined, not false, and a built-in error does not stop evaluation unless strict mode is requested. A REST query for an undefined decision returns success with no result. So the contract has a default of deny, and the caller treats a missing or errored result as deny. A compact core:

default decision := {"outcome": "deny", "reasons": ["undefined"]}

deny_reasons contains "budget_exceeded" if
    input.action.amount_minor > input.state.budget_remaining_minor

deny_reasons contains "approval_digest_mismatch" if {
    input.approval
    input.approval.digest != input.action.digest
}

needs_approval if input.action.amount_minor > input.actor.delegation.limit_minor

The full policy has fourteen denial reasons. It was checked with opa check --strict and tested with opa test on OPA v1.21.4: 22 of 22 tests passed. OPA v1.22.0 was released on 29 October 2026 and the tests were not re-run on it. To confirm the tests could fail, three deliberate breakages were introduced one at a time (removing the self-approval rule, removing the digest check, disabling the budget check). Each was caught by exactly one test. The matrix covers wrong tenant, missing or unverified identity, empty input, wrong action, unsupported currency, negative, fractional and string amounts, exceeded limit, changed digest, same requester and approver, stale policy, expired approval, expired delegation and changed supplier or requisition state.

A policy engine cannot enforce what it is never asked. Concurrent budget use, duplicate requests and unknown results are not policy questions. They belong to the system that owns commitment, as the previous section showed. Enforcement also has to sit on every effect path, including batch jobs and administrator tools, or the policy is advice.

Evidence is a lifecycle, not one object

The Minimum Action-Evidence Bundle (MAEB) is the CAE term for the smallest verifiable set of information needed to evaluate one consequential action. It is an author-proposed design construct. A common mistake is to treat it as a single record created at one moment. The path has at least two records with different truth conditions.

The intent and authorisation record exists before the action and is immutable. It captures the exact proposed payload, its digest, the policy version and decision, the actor and delegation, any approval and the context basis. It says what was authorised, not what happened. The execution receipt exists after the attempt. It records the outcome (committed, denied, cancelled, failed or unknown), the downstream identifier if one now exists, and a link to the first record by identifier and digest. Neither record can pretend to be the other. A blocked action has no success receipt, and a downstream transaction identifier cannot appear before the transaction exists.

Making a record verifiable needs care at four points.

• The bytes that are hashed must be exact. A digest is of bytes, not of meaning. RFC 8785, the JSON Canonicalization Scheme, defines one serialisation: UTF-8, properties sorted by UTF-16 code units, ECMAScript number formatting, no insignificant whitespace, and no Unicode normalisation. It requires input free of duplicate property names and built on the I-JSON constraints, so large or precise numbers are safer as strings. Sorting keys alone is not JCS. A conforming implementation should be used and tested against its constraints. For this note a conforming implementation could not be obtained in the environment used, so canonicalisation is described and not demonstrated.
• The digest and signature fields stay outside what they cover. The payload is hashed first without its own digest and signature fields; the envelope then carries the digest, signature and key reference. Both payload and envelope are versioned.
• Sign once, with the right mode. Pure Ed25519, as RFC 8032 specifies, signs the message itself, so the payload bytes are signed rather than a pre-computed digest. Hashing and then signing the digest with pure Ed25519 creates a different, incompatible object. A short check with fixed payload bytes confirmed that changing the amount or the tenant invalidated the signature, and that a signature over the payload does not verify against its digest string. ECDSA behaves differently across libraries: some hash internally and some expect the caller to supply a hash, so each should be read.
• Say what a signature supports. A signature supports integrity of those bytes and attribution to a key the verifier trusts, under stated assumptions. It does not show that the source facts were true, that the business authority was correct, that every path was mediated, or that the signer cannot repudiate the act in every legal setting. A hardware-based attestation, if used, has its own trust and verification model and is a separate claim.

Transparency logs add tamper evidence, not confidentiality or ordering by themselves

A transparency log such as Sigstore’s Rekor can make later alteration of logged entries detectable. Its fit for enterprise action evidence needs assessing, not assuming. Rekor is signature-transparency infrastructure. The public instance is public, so customer payloads, identities, documents and sensitive metadata must not go to it. Even a digest can leak through guessing or correlation. Confidential evidence belongs in an access-controlled store, and an organisation that wants a transparency log has to consider a private deployment, its running cost, retention, disclosure and trust roots. Nothing in this work submitted anything to a public log.

Several things are easy to conflate and should be verified separately: the signature, the signer’s identity and the issuer the verifier will accept, an inclusion promise or proof, an authenticated checkpoint, consistency between checkpoints and a trusted timestamp. With Cosign, verify-blob with a bundle, an expected certificate identity and an expected issuer is the documented route for blob signatures. A log identifier or an HTTP success status is not verification. In Rekor v2, which became generally available in October 2025 and supports the hashedrekord and dsse entry types, signed entry timestamps are replaced by timestamps from an RFC 3161 authority. Version 1 is in maintenance mode.

Two limits shape the design. An inclusion proof shows an entry is in the log at some tree state; a checkpoint carries no time. In version 1 the integrated time came from the log’s own clock, which the documentation describes as not externally verifiable. At best an external timestamp shows that something existed by a given time. So an inclusion proof alone does not prove logging happened before a business effect. If anchoring before commit is a requirement, the gateway must enforce it as a verified prerequisite, record the sequence and still recheck mutable state at commit. A log and an ERP cannot be made atomic merely by calling them one after another.

Figure 4 separates the two records and marks the confidentiality boundary.

Text description of Figure 4. The intent record is written first and is immutable. The commit boundary sits between it and the execution receipt. The receipt is written afterwards with a truthful outcome and a link to the first record. A dashed line separates full records, which stay in an access-controlled store, from the minimal material that might be anchored in an optional transparency log after assessment.

The outage policy must be explicit. Where anchoring is required, the gateway fails closed before an effect when the log is unavailable. Where a deferred design is separately approved, a durable outbox queues publication and the record honestly says “evidence pending”. A committed effect is never relabelled “failed” because a later publication timed out. The design also has to handle an invalid proof or checkpoint, a wrong signer, stale trust roots, an altered payload, a crash after commit, a duplicate entry and key rotation.

Reconstructing a decision later needs the retained inputs, the policy and model versions and external receipts. That is different from re-running the action.

Operating this takes people, boundaries and recovery plans

A descriptive maturity model can help a discussion as long as it is not mistaken for a destination. Four stages are proposed: fragmented, where context lives in people and scattered systems; integrated, where systems exchange data but meaning stays implicit; semantically contextualised, where meaning, ownership and evidence are explicit for chosen work; and bounded and governed execution, where agents propose and a gateway and systems of record commit under explicit authority. This is a CAE discussion aid, not independently validated, and most organisations should not aim to reach autonomous operation everywhere. A stage is a property of a piece of work, not of the whole firm.

Operating it requires shared stewardship of the context model, domain boundaries that match accountable teams, tenant isolation, people who can read policy and evidence, a recovery plan for unknown results, and a named owner for each decision. The option to keep the current system is always on the table.

Measure outcomes, effort and cost together and keep the trade-offs visible

Measure outcome quality, rework, exception burden, delivery lead time, context reuse, human effort, model and infrastructure cost, incidents and recovery. Compare similar work over a stated period, treat small samples cautiously, and record uncertainty. The cost of reasoning is only one line; the cost of the gateway, evidence storage, review time and operating the context model belong beside it. This note offers no benchmark or saving, because none was measured.

What this does not establish

The architecture is a proposal. It has not been deployed or validated in a customer environment. The Rego policy ran in a sandbox against invented inputs. The commit simulation was a local mock. JCS was described, not demonstrated. The maturity stages are a discussion aid. Whether shared context reduces effort is a hypothesis. A real programme would need organisation-specific review of architecture, security, privacy, legal, regulatory, operational, safety, accessibility, commercial and governance matters, with the appropriate approvals.

Key takeaways

• Reasoning proposes and systems of record commit; the architecture is the continuous, inspectable path between them.
• Context is made explicit for a purpose, and six easily blurred distinctions, from data versus claim to snapshot versus current state, must be visible at commitment.
• Choose an agent only when the work needs interpretation, errors are catchable and the effect can be bounded by enforced authority; many tasks need a rule or no change.
• A policy engine decides on trusted inputs and must fail closed. Concurrency, duplicates and unknown results belong to the system that owns commitment.
• Evidence is a lifecycle: an immutable intent record before the action and a truthful receipt after it, with exact bytes, one signature in the right mode and clear limits on what a signature or log proves.
• A transparency log adds tamper evidence only after an assessment of confidentiality, sequencing and outage behaviour.

Sources and further reading

• Open Policy Agent, Policy Language and CLI documentation; release v1.21.4, the version tested.
• Rundgren, A., Jordan, B. and Erdtman, S. (2020) “JSON Canonicalization Scheme (JCS)”, RFC 8785.
• Josefsson, S. and Liusvaara, I. (2017) “Edwards-Curve Digital Signature Algorithm (EdDSA)”, RFC 8032.
• Sigstore, “Rekor v2 is now generally available”, 10 October 2025; and the Sigstore documentation for Cosign and bundles.
• Snowden, D. J. and Boone, M. E. (2007) “A Leader’s Framework for Decision Making”, Harvard Business Review, November.
• Conway, M. E. (1968) “How Do Committees Invent?”, Datamation, April.
• Evans, E. (2003) Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley.
• Rose, S. et al. (2020) “Zero Trust Architecture”, NIST SP 800-207.
• Saltzer, J. H. and Schroeder, M. D. (1975) “The Protection of Information in Computer Systems”, Proceedings of the IEEE.
• Stripe, “Idempotent requests”, API reference. One provider’s documented behaviour, not an endorsement.
• Jena, J., Dalal, S. and Tishkin, D., “The Idempotency-Key HTTP Header Field”, Internet-Draft, version 08, 22 October 2026. A work in progress.
• PostgreSQL Global Development Group, “Transaction Isolation”, PostgreSQL 18 documentation. One database’s behaviour, cited as an example.
• Related on this site: Why Enterprise AI Needs a Deterministic Shell, Evidence-First Decision Records, Context Is Not a Prompt and the Contextual Agentic Graph.

The book develops this ground at length

The book The Contextual Agentic Enterprise treats deterministic, probabilistic and agentic systems, enterprise knowledge and organisational memory, and transaction authority in the system of record in its own chapters. More about the book.

This article is part of CAE Field Notes, a series accompanying the book, The Contextual Agentic Enterprise.