Skip to main content Skip to footer
Frontier Tech Perspectives

The intelligence contract: The layer that governs what enterprise AI may consume and return

October 2026

Shreshta Shyamsundar Shreshta Shyamsundar

Chidambaram GS Chidambaram GS

Abstract

Enterprise AI teams govern the data a model sees and the actions an agent executes. They often leave the model invocation between those layers weakly governed. Applications submit open-ended prompts, allow broad context consumption, and accept responses that may be correct but unusable.

This article defines the intelligence contract as the architectural boundary around a reasoning transaction. The contract governs the invocation once an enterprise system has decided that a model should reason.

The contract has two sides: consumption and output. The consumption contract governs what the model may consume, including context allocations, model calls, tool calls, latency, and retry limits. The output contract governs what the model may return, including structure, semantics, evidence, uncertainty, abstention, and side-effect classification.

The companion article, “When not to reason,” decides whether a model should run at all and which execution path should resolve a task [1]. This article governs the transaction once that decision selects a model. The practical conclusion is direct. Enterprise AI should reserve models for irreducible judgment, assign deterministic work to deterministic software, and enforce contracts at the boundary between them.

Keywords: Intelligence contract, consumption contract, output contract, reasoning transaction, enterprise AI architecture, budget envelope, structured output, abstention, evidence validation, AI governance

1. The decision that passed and failed

An enterprise procurement agent receives an invoice for review. The supplier is on a watch list. The invoice exceeds the purchase order by 2.7%. Policy permits a variance below 3% unless the supplier is in a high-risk tier.

The agent reaches the correct conclusion: The invoice requires review because the supplier’s risk status overrides the normal variance tolerance.

The application still fails.

It fails for several reasons:

  • The model returned 900 words of prose.
  • It recalculated the tax and reached a figure that disagreed with the finance system by a rounding difference.
  • It cited “company policy” without a clause reference.
  • It produced no machine-readable decision.
  • It expressed false confidence in a jurisdictional claim it was never asked to make.
  • It offered no signal that any part of the answer needed verification.

The caller needed five things:

  • A decision.
  • A policy reference.
  • A confidence signal.
  • A list of missing information.
  • A clear statement of what to do next.

Everything else increased cost, latency, attack surface, or downstream ambiguity. The scenario is a composite of recurring integration failures. It is not a claim about one client deployment.

The engineering pattern is familiar. Teams test whether the model can produce a correct answer. They do not define the transaction under which that answer becomes acceptable.

Nothing in this incident requires a better model. The model had enough capability, and the gap was the absence of a contract. The failure is one of transaction design. The model’s reasoning was sound.

2. The missing boundary in enterprise AI architecture

A governed context layer decides what an agent sees. It selects authoritative information, enforces access scope, attaches provenance, and manages the finite context window. A governed runtime decides what an agent does. It turns probabilistic proposals into typed, authorized, idempotent, and observable execution. These two architectural layers have already been defined in the Infosys Technology Review [2] [3].

One boundary remains weak: the model invocation itself.

Most enterprise applications still treat that invocation as a conversational exchange. They concatenate instructions and data, send the resulting prompt to a model, and inspect the returned text. Limits exist, but they are usually provider parameters, and enterprise policy rarely defines them. The maximum output length may be configured, yet nobody has defined why that amount is justified. A JavaScript Object Notation (JSON) schema may be supplied, yet nobody has defined the business meaning of each field or the conditions under which the model must abstain.

The model call sits between two governed layers but often behaves as an unbounded exception to both.

This article adds three controls to that architecture. First, the output contract treats the response as a typed obligation with semantics, evidence, uncertainty, and abstention. Second, the consumption contract defines a budget that composes a multistep workflow through parent and child allocations. Third, every retry is charged to the same transaction and does not receive fresh resources. The first two layers decide what the model sees and what it may do. This layer governs the transaction in between.

This article develops the invocation layer of the same series. Within its Intelligence Economics narrative, the consumption contract decides how much context, inference, and cost a transaction may spend before it begins. The principle of returning only irreducible judgment keeps expensive reasoning on work that needs it and moves the rest to deterministic code, as the companion article “When not to reason” explains in full [1]. The output contract then makes that yield usable and accountable. It ensures allocated reasoning produces a result the enterprise can act on and audit.

Readers following the series will recognize these ideas as the mature form of the earlier composition envelope and response envelope. The consumption contract extends the Composition Envelope with workflow-level budgeting and retry accounting. The output contract extends the Response Envelope with semantics, evidence, abstention, and side-effect classification.

A prompt states an instruction. A contract adds authority allocation and an explicit definition of acceptance.

A prompt says, “Review this invoice and recommend an action.”

A contract defines the following:

  • Which evidence the model may inspect.
  • How much context and inference it may consume.
  • Which model classes it may use.
  • What decision values it may return.
  • Which evidence must support the decision.
  • When it must abstain.
  • What the caller will compute itself.
  • What happens when validation fails.

The instructions describe what to do. The contract defines the boundary within which the result becomes acceptable. The intelligence contract is a two-sided boundary around a reasoning transaction (Figure 1). The consumption contract governs what the transaction may consume, and the output contract governs what it must return.

Figure 1. Intelligence contract structure

Source: Infosys

3. The reasoning transaction

Terminology note. This article uses “consumption contract” for the policy that governs what a reasoning transaction may consume. “Budget envelope” means the multidimensional resource limits inside that contract. “Transaction allowance” means the specific allocation granted to one invocation. “Workflow envelope” means the parent budget shared across multiple steps.

A reasoning transaction is one bounded request for model-mediated judgment. It begins when a caller submits a task and ends when the caller accepts, rejects, or escalates the result.

Architects can represent a complete transaction as follows:

Purpose + input authority + resource budget + output obligation + validation + failure behavior

Each element answers a different control question.

Purpose defines the business decision being supported. “Summarize this document” is too broad for a transactional system. “Identify contractual termination rights relevant to section 14 and return the supporting clause identifiers” is testable.

Input authority defines what the model may consume: which sources, which classifications, and how much of the context window each may occupy. This links directly to the context layer, which already governs selection, scoping, and provenance [2].

Resource budget defines what the transaction may consume. Tokens are the most visible unit. Model calls, tool calls, elapsed time, retries, and monetary cost also need ceilings.

Output obligation defines what the caller expects. It includes machine structure, field meaning, evidence, uncertainty, and abstention.

Validation defines how acceptance is determined. A response may pass structural validation and still fail semantic, evidentiary, policy, or authorization checks.

Failure behavior defines what happens next. The system may repair the format, retry with a different model, request missing data, route to a human, or terminate. An unspecified failure path becomes an uncontrolled agent loop.

The transaction does not require access to hidden chain-of-thought. Enterprise observability should capture the inputs supplied, contract version, selected model, resource consumption, cited evidence, validation results, and final business outcome. Those records are auditable, and private internal reasoning traces are neither necessary nor a reliable governance mechanism.

4. The consumption contract

The consumption contract allocates a finite context and output allowance to a reasoning transaction before inference begins.

Pattern definition. Allocate a multidimensional budget to a reasoning transaction before inference begins, compose that budget across the steps of a workflow, and charge every retry to the same transaction.

Tokens are the most visible unit inside a model call. The budget the consumption contract sets must remain multidimensional.

4.1 A budget is more than a maximum token count

A useful budget envelope contains controls as depicted in Figure 2.

Figure 2. Controls in a budget envelope

Source: Infosys

The budget must reserve output capacity before filling the input. Otherwise, context assembly consumes the entire allowance and leaves too little space for the model to return a complete, contract-compliant result.

It must also allocate capacity by authority. Arrival order should not decide the allocation. Tool output should not displace current policy merely because the tool ran last. Conversation history should not crowd out the transaction facts that determine the decision.

The existing context-engineering architecture makes this point at the context layer: selection, scoping, provenance, and budget determine what the model sees [2]. The intelligence contract converts that context budget into an enforceable transaction allowance.

4.2 The budget must compose across workflows

A per-call token limit does not govern a multistep workflow.

Consider an agent permitted to make 10 calls, each with an 8,000-token input limit. A nominal 8,000-token control has created potential exposure of 80,000 input tokens before retries, tool output, or subagents are counted.

A workflow therefore needs a parent budget. Each reasoning step receives a child allocation from that parent. Unused capacity may return to the workflow pool; consumed capacity does not reset merely because the next call uses a different model.

The runtime architecture already distinguishes the context budget of an inference from the cost budget of the whole workflow [3]. The intelligence contract links them. Every model invocation must declare its share of the workflow envelope, and every retry must charge the same parent transaction.

No retry should receive a fresh budget unless the workflow owner explicitly classifies it as a new business transaction.

This prevents a parser failure from becoming three full reasoning runs and a transient tool error from restarting an entire analysis.

4.3 An illustrative transaction budget

For a read-only procurement exception review, an initial contract may permit the illustrative allowances (Figure 3).

Figure 3. Illustrative transaction budget for a read-only procurement exception review

Source: Infosys

Note: These values are design examples for one task class.

These figures are design examples. They are not universal thresholds. The correct allocations depend on task complexity, model behavior, evidence size, and risk. The reserved output allowance should fit the full contract object, its evidence references, and enough headroom for a constrained repair. The pattern lies in the prior allocation and enforcement. The specific numbers will vary.

5. The output contract

The consumption contract governs what the model may consume. The output contract governs what the caller will accept.

Pattern definition. Define the model response as a typed obligation that must satisfy structure, business semantics, evidence, uncertainty, and side-effect classification before the caller accepts it.

A schema is part of that contract without being the whole of it.

5.1 Structural layer

The structural layer defines fields, data types, enumerations, cardinality, length, and optionality.

In the procurement exception example, the contract returns only the fields the caller needs to accept, reject, refer, or abstain from the decision. The response identifies the contract version, the permitted decision value, and the policy references, each carrying a policy identifier, version, and clause identifier. It also returns missing facts, a calibrated confidence band where available, an abstention reason when applicable, and an action type that declares the result as recommendation only. That prose definition is more important than the syntax because it explains why each field exists and how the caller will validate it.

The response deliberately excludes the following:

  • Tax totals already calculated by the finance system.
  • Supplier contact details available from master data.
  • A formatted email.
  • A prose repetition of the invoice.
  • Direct payment instructions.

Those exclusions are architectural decisions. They keep the model from reproducing facts or calculations the caller already owns.

5.2 Semantic layer

A field name does not define its business meaning.

The contract must state, for example, the following:

The following uppercase terms represent canonical decision values returned by the output contract.

  • APPROVE means the supplied facts satisfy all current automated approval rules.
  • REFER means human review is required and names the responsible queue.
  • REJECT means a specific current policy clause was violated.
  • ABSTAIN means the model cannot decide within the contract and states why.
  • confidence_band reflects a defined and, where possible, calibrated measure, not an unanchored self-report.

Without semantic definitions, two models can return structurally identical objects that lead to different operational behavior.

A model-supplied confidence_band is an input to validation, and the system should not treat it as a trusted signal. A model can express high confidence on precisely the cases it handles least well, so the band should influence acceptance only where it has been calibrated against outcomes. The companion article, “When not to reason,” develops the same caution for routing [1]. Where the band is uncalibrated, the contract should treat it as a triage hint and rely on evidence and semantic validation for acceptance.

5.3 Evidence layer

The output should carry evidence identifiers, and it should not rely on unsupported narrative. A recommendation that cites “company policy” cannot be audited. A recommendation that references policy PUR-014, version 8.2, clause 4.3 can be checked against the exact source supplied to the model.

The contract should require evidence when the business decision depends on external authority. It should also define what happens when evidence cannot be produced. For high-impact decisions, the correct behavior is usually abstention or escalation. A plausible but uncited answer is the wrong outcome.

5.4 Uncertainty and abstention

Many applications treat abstention as a model failure. This encourages the model to manufacture certainty.

An enterprise contract should make abstention explicit and typed. Useful abstention reasons are as follows:

  • Missing authoritative evidence.
  • Conflicting policy versions.
  • Unresolved entity identity.
  • Insufficient authorization.
  • Budget exhausted before validation.
  • Output unable to satisfy the evidence requirement.

An abstention with a precise reason is often more valuable than a low-confidence recommendation, because the caller knows what to resolve next.

5.5 Return only irreducible judgment

The central design principle is:

Return only what the caller cannot compute more reliably or economically, plus the evidence required to verify it.

A model is often well suited to deciding whether ambiguous contract wording applies to a case. It is a weaker choice for adding invoice lines, comparing dates, sorting options, validating an identifier, or calculating tax. It should not convert a decision into a downstream application programming interface (API) payload.

The companion article, “When not to reason,” develops the routing and deterministic-offload argument in full, including the evidence from program-aided language models (PALs) that combining model interpretation with deterministic execution outperforms model-only calculation on appropriate tasks [1] [4]. For the output contract, the relevant consequence is narrower: the response should carry only irreducible judgment, and the contract should classify each element of the expected output accordingly.

The output contract should therefore distinguish among the following categories:

  • Judgment, which may require a model.
  • Evidence, which the model must cite from supplied context.
  • Calculation, which deterministic code should perform.
  • Presentation, which templates or deterministic formatting should render.
  • Execution, which the runtime performs under its own authorization controls [3].

6. The intelligence contract architecture

The architecture places the contract between context assembly, model inference, and runtime execution. Output validation may reject a response, request a bounded repair, or escalate the transaction. It shows where the contract is authored, allocated, enforced, validated, and traced (Figure 4).

Figure 4. The intelligence contract around a reasoning transaction

Source: Infosys

Note: The contract is authored in a registry, allocated by a budget allocator, enforced at the model gateway, checked by an output validator, and recorded in a transaction trace.

6.1 Contract registry

The registry stores versioned contract definitions by task class. It should contain the following:

  • Purpose and scope.
  • Permitted input sources and classifications.
  • The budget envelope.
  • Permitted model classes.
  • The output schema.
  • Semantic field definitions.
  • Evidence requirements.
  • Abstention conditions.
  • Validation rules.
  • Failure and escalation behavior.
  • Owner and approval record.
  • Version and review date.

A model deployment should hold contract logic in the registry. Application prompts alone are not enough. The registry makes the contract reusable, reviewable, and independently versioned.

A registry of this kind carries an operational cost that the design must acknowledge. Task-class contracts have to be authored, reviewed, versioned, and retired. They drift back into application prompts whenever that lifecycle is neglected. Each contract needs a named owner, an approval record, and a review date, and the platform should be able to report which contracts are unowned or overdue. Contract lifecycle is a governance responsibility, comparable to policy or schema management.

6.2 Budget allocator

The allocator reserves output capacity, then divides input capacity across sources by authority, and tracks consumption across the workflow. When context exceeds the budget, the allocator returns the pressure to the context layer and does not truncate the end. The context layer can then remove duplicates, choose higher-authority evidence, summarize low-priority history, or reject the transaction because necessary evidence will not fit.

6.3 Model gateway

The gateway is the enforcement point. It attaches the contract identifier, verifies model eligibility, and applies input and output ceilings. It meters tokens and elapsed time, counts model and tool calls, records model and configuration versions, and blocks undeclared retries.

The gateway treats every model invocation as a transaction against an approved budget. An unrestricted API request is never the default.

6.4 Output validator

Validation should occur in layers.

Structural validation confirms the response matches the schema.

Semantic validation checks business invariants. A REJECT decision may require at least one current policy reference. An APPROVE decision may be forbidden when missing_facts is nonempty.

Evidence validation confirms that cited sources exist in the supplied context and support the decision.

Policy validation confirms the action is authorized for the principal and task.

Outcome validation for high-impact cases may add an independent check or human review.

Validation layers differ in how they execute. Structural validation is deterministic. Semantic validation over declared invariants is also deterministic. For example, the validator can forbid APPROVE when missing_facts is nonempty.

Evidence validation is deterministic when it confirms that a cited identifier and version existed in the supplied context. It becomes a judgment task when it must decide whether the cited passage supports the decision. That judgment task may require a model. If so, the validator must run under its own contract, with bounded output, evidence requirements, and an abstention path.

A model-based validator that is itself unbounded is not a control. High-impact decisions should prefer an independent deterministic check or human review where practical. Human review also needs measurement, latency targets, and consistency checks. It is a review tier with its own limits.

Structural validity is necessary for acceptance without being sufficient for it.

6.5 Deterministic postprocessor

After validation, deterministic code performs calculations, formats output, applies templates, and constructs any downstream payload. This design reduces the output the model must generate and keeps deterministic logic testable outside the prompt.

6.6 Transaction trace

The trace should record the following:

  • The business task and transaction identifier.
  • Contract and policy versions.
  • Context-source fingerprints.
  • Model and configuration.
  • Input and output consumption.
  • Model and tool-call counts.
  • Validation results.
  • Repair and escalation events.
  • Accepted output.
  • Deterministic transformations.
  • Final business disposition.

That trace allows an operator to answer both “What did the model say?” and “Under which contract was this result accepted?”

The transaction trace is itself a sensitive data asset. It records principal scope, evidence fingerprints, and policy state, so it inherits the retention, access, residency, and privacy obligations of the data it describes. An institution should govern it as a controlled record, held to the same standard as the data it describes.

7. What published evidence tells practitioners

The evidence in Figure 5 supports a specific conclusion. Structure, schema design, decoding method, and task type interact, so stricter output aids some tasks and hinders others.

Figure 5. Published evidence on structured output and its practitioner interpretation

Source data: Tam et al. (2024) [7]; Geng (2025) [6]; OpenAI (2024) [5]; Liu et al. (2024) [8]. Synthesis and interpretation: Infosys

Two implications follow:

  • An output contract must be tested against the task, model, schema, and decoding implementation together. A schema that improves a classification task may degrade a multistep reasoning task. The contract should separate reasoning freedom from interface discipline.
  • The caller requires a disciplined result, which does not require forcing every intermediate model operation into the same narrow structure.

8. Five engineering hypotheses

The intelligence contract should be treated as an engineering hypothesis. It is not an article of faith. The following claims can be tested against enterprise workloads.

Hypothesis 1: Constrained output will eliminate most structural failures while leaving semantic error largely unchanged

Provider data and constrained-decoding research show high schema conformance [5] [6].

Expected observation. Schema-pass rate rises sharply, while evidence accuracy and decision accuracy improve only when semantic validation and better task design are added.

Hypothesis 2: Separating judgment from final formatting will preserve reasoning quality better than requiring both in one constrained generation

The structured-output study shows that rigid formatting can reduce quality on some reasoning tasks [7].

Expected observation. A two-stage design, model judgment followed by constrained projection or deterministic formatting, reduces the quality loss seen in some tightly constrained single-stage calls.

This does not require exposing hidden chain-of-thought. The first stage can return a bounded, evidence-based decision representation, while the second maps that representation to the caller’s exact interface.

Hypothesis 3: Deterministic offload will improve exactness and reduce unnecessary output

PAL provides evidence that deterministic execution of model-generated programs improves accuracy on arithmetic and structured tasks [4].

Expected observation. Moving calculation, formatting, and payload construction into deterministic code reduces numeric error and output length without reducing decision quality.

Hypothesis 4: A workflow-level budget will reduce retry amplification more effectively than per-call limits

Per-call ceilings reset when applications retry. The runtime architecture identifies uncontrolled loops and repeated reasoning as workflow-level cost risks [3].

Expected observation. A parent budget with charged retries lowers worst-case token and cost consumption compared with per-call limits alone.

Hypothesis 5: Minimal outputs will improve acceptance without reducing usefulness

The lost-in-the-middle effect and general latency pressures favor shorter, higher-authority output [8].

Expected observation. Returning only irreducible judgment and evidence, with calculation and formatting handled deterministically, improves acceptance rate and latency without lowering decision quality.

9. A publication-grade enterprise evaluation

This section is for teams that want to prove the contract improves accepted outcomes, beyond schema conformance. Measure cost per accepted result. Cost per call is the wrong denominator. Oversample abstention and high-risk cases because they expose control failures that routine traffic hides. The arms, measures, and gates that follow are a reference architecture for enterprise evaluation.

The evaluation should compare architectures under controlled conditions. It should not claim that the pattern works because one demonstration succeeded.

9.1 Corpus

A practical initial study can use at least 1,200 adjudicated cases, with the same cases executed through every experimental arm. The corpus should include three task families:

  • Extraction and classification: bounded outputs with clear ground truth.
  • Policy judgment: cases requiring application of authoritative text to transaction facts.
  • Action proposal: cases where the model recommends, and does not execute, an enterprise action.

Each family should contain routine cases, ambiguous cases, missing-evidence cases, conflicting-evidence cases, and out-of-scope cases. High-risk and abstention cases should be deliberately oversampled, because average production traffic rarely supplies enough of them for reliable evaluation.

The test set must be untouched during prompt, contract, and threshold development.

9.2 Compared arms

Figure 6. Compared architecture for the enterprise evaluation

Source: Infosys

Figure 6 compares the baseline and contract-based architecture under the same model, temperature, context sources, and test cases. The model version, temperature, context sources, and test cases should remain constant across arms. A second evaluation can repeat the study with a smaller approved model to determine whether the contract’s effect generalizes across capability levels.

9.3 Measures

The minimum measures are as follows:

  • Structural-pass rate.
  • Semantic-validity rate.
  • Evidence-accuracy rate.
  • Decision-accuracy rate against adjudicated ground truth.
  • Appropriate-abstention rate.
  • Harmful-confident-error rate on high-risk cases.
  • Accepted-result rate.
  • Cost per accepted result.
  • Full-retry rate and retry amplification.
  • Output length and latency at the 50th and 95th percentiles.

Accepted result must be defined before testing. A result is accepted only if it is structurally valid, semantically valid, supported by required evidence, and judged fit for the intended business use.

9.4 Engineering gates

The following are suggested engineering gates. They are not claimed results or universal standards.

Figure 7. Suggested engineering gates for an initial pilot

Source: Infosys

Figure 7 translates the evaluation design into initial engineering gates. Teams should tighten the gates for higher-impact transaction classes. A customer-facing explanation may tolerate a formatting repair. A payment approval should not tolerate an unsupported positive decision.

9.5 Analysis and reporting

Report performance by task family and risk class. An overall average can conceal a contract that improves routine classification while degrading unusual policy cases. Use paired comparisons because each case runs through every arm. Report confidence intervals as well as point estimates. Publish the model version, schema, contract version, decoding method, and evaluation date, because model behavior and provider implementations change.

Quality constraints must travel with the results. If policy documents are incomplete, labels disputed, or reviewers in disagreement, those limitations should travel with the affected metric. Reporting them only at the end is not enough.

10. Failure modes of the intelligence contract

The contract introduces controls, and it can also introduce new failure modes.

10.1 Schema valid but wrong

A response can satisfy the schema and still be substantively incorrect.

Control. Validate business semantics and evidence, not structure alone. Treat structural validity as necessary and insufficient.

10.2 Over-constrained reasoning

A rigid schema can interfere with some reasoning tasks. Published studies show that the effect is task-dependent, with natural language outperforming schema-constrained output in some cases and underperforming it in others [7].

Control. Separate a reasoning stage from a formatting stage. Test each contract against its specific task and model.

10.3 Budget starvation

An output budget set too low truncates a legitimate response or forces a premature abstention.

Control. Reserve output capacity before context assembly. Make missing necessary evidence an abstention condition. Measure quality against budget. Rewarding token reduction alone is a mistake.

10.4 Retry storms disguised as repair

Repeated repairs multiply cost and latency under the appearance of correctness.

Control. Charge every retry to the parent transaction. Cap repairs. Escalate on repeated failure.

10.5 Contract-version skew

Different services enforce different versions of the same contract.

Control. Version contracts centrally. Record the contract version in every trace. Alert on skew.

10.6 Evidence laundering

The model cites a real identifier that does not support the claim.

Control. Validate that the cited passage supports the decision, going beyond a check that the identifier is present. High-risk uses may require an independent verifier or human review.

10.7 Hidden side effects

A response implies or triggers an action that was never declared.

Control. Declare operational effect in the contract. Separate RECOMMENDATION_ONLY, ACTION_PROPOSAL, and EXECUTABLE_ACTION. The runtime should reject undeclared transitions.

11. Who owns the contract

One test determines whether the contract exists in practice. When a model’s response is rejected, can the operator identify which obligation failed, which budget was consumed, which contract version applied, and what the system did next?

Figure 8 assigns ownership for each contract capability and the minimum metric its owner should maintain.

Figure 8. Ownership and minimum service levels for the intelligence contract

Source: Infosys

The service levels should be reported per transaction class as well as at platform level. A 99.9% schema-pass rate across a million low-risk summaries does not compensate for structural or evidentiary failures in payment approvals.

Without those answers, the enterprise has only a prompt convention, and no intelligence contract.

12. Regulatory alignment

For practitioners, the regulatory value of the intelligence contract is evidentiary. The pattern turns model use into inspectable records. Those records show what data entered the transaction, which policy applied, which evidence supported the decision, which validation failed, and what the system did next. This section maps that evidence trail to selected Asia-Pacific financial-services guidance. The mapping is illustrative and does not provide legal or compliance advice.

Information security and data governance. Australian Prudential Regulation Authority Prudential Standard CPS 234 Information Security (APRA CPS 234), and the Monetary Authority of Singapore Technology Risk Management Guidelines (MAS TRM Guidelines), expect access scope, data classification, and residency to be enforced and evidenced [9] [10]. The intelligence contract supports those expectations through input-authority declarations, data-classification controls, validation records, and transaction traces.

Fairness, accountability, and transparency. The Monetary Authority of Singapore Fairness, Ethics, Accountability and Transparency (MAS FEAT) principles, and the Monetary Authority of Singapore Safeguards for Agentic Finance at Runtime (MAS SAFR) guidance, ask institutions to explain and account for automated decisions [11] [12]. The contract’s evidence identifiers, semantic decision definitions, abstention reasons, and traces provide the record needed to reconstruct why a decision was reached.

Model risk management. Evaluating each contract arm against adjudicated ground truth, and measuring validator precision and recall, is the effectiveness testing that model-risk practice expects before a control is relied upon.

Records and retention. Transaction traces record principal scope, evidence fingerprints, and policy state. They inherit the retention, access, residency, and privacy obligations of the data they describe. An institution should govern them as controlled records.

The mapping identifies evidence artifacts that may support control review. It does not assert compliance. An institution should confirm the specific obligations that apply to its jurisdiction and process class with its own risk and compliance functions.

13. Where to start

The first implementation should be a read-only workflow with a bounded business decision and a known caller.

Begin by recording the current transaction. Measure input by context class, output length, full retries, parser failures, human corrections, and accepted outcomes. This baseline often exposes that the model returns fields the caller already computes and repeats context the caller already stores.

Next, define the smallest output that supports the business decision. Add evidence identifiers and abstention before adding a complex rationale. Move arithmetic, date comparison, formatting, and business invariants into typed code.

Introduce the budget initially in monitor mode. Log violations without blocking. Once the team understands the normal distribution, enforce hard ceilings on model calls, retries, undeclared tools, and state-changing actions. Token ceilings can tighten gradually while quality is measured.

Finally, evaluate the contract against adversarial and incomplete cases. The most valuable tests are the missing policy, the conflicting version, the invalid identifier, the unauthorized document, the nearly identical transaction, and the ambiguous action. The clean examples that already pass reveal little.

14. The contract defines usable intelligence

Whether an enterprise can use a response depends most on the caller’s ability to bound, validate, and operate it. Raw model capability matters less.

The consumption contract treats context, calls, retries, and latency as resources allocated before reasoning begins. The output contract treats the model result as an obligation that must satisfy structure, semantics, evidence, uncertainty, and authority. Deterministic postprocessing keeps exact work out of probabilistic generation. The runtime keeps recommendations separate from execution.

Together, these controls turn model capability into governable enterprise intelligence by bounding consumption, validating outputs, and separating recommendations from authorized execution.

References