Three agreements that get collapsed into one
When a team says the agent "has the business logic," they usually mean one of three different things. A calculation contract says how a number or a classification is produced, at which grain, under which version. A semantic explanation says what the terms mean and which comparisons are valid. An access policy says who may read the inputs and the result. An enterprise agent needs all three. It needs them as separate artifacts, because fixing one does not fix the others.
The calculation contract is the authority for the figure. Semantic context can tell the agent that Field Operations is a department and that "over budget" is the positive direction of variance. It cannot decide the formula. An access policy can refuse a row the person may not see. It cannot make an invented threshold legitimate. Enterprise AI Needs a Governed Business Logic Layer argues for the layer. Semantic Intelligence: Enterprise AI's Missing Layer argues for the definitions. This note lists the fields the calculation contract has to carry, and then fills them only with the synthetic finance contract this site already publishes.
- Identity
- orisdale-finance-variance-demo, version 1.0.0
- Grain
- department_id, period, currency
- Material threshold
- At least $5,000 or 10% absolute variance
Change lifecycle — a design requirement, not deployed software
The fields any calculation contract needs, before any example
A contract that an agent can read is more specific than a policy paragraph, and the fields below apply whether the metric is a finance variance, a drilling exception, or a service-level breach. Not every agent needs a finance calculation contract — it needs a contract for whatever metric it is allowed to compute or explain, built from the same field list:
- Owner. The business function accountable for the definition, separate from whoever operates the runtime.
- Version. An identifier that changes only through the review path below, so a reader can tell which rule produced a given result.
- Grain. The join keys and the unit the number is about. A department-period and a well-day are different grains even when both produce a single number.
- Units. The currency, unit of measure, or scale, including how rounding is handled.
- Definitions. What each field and label means, kept separate from the formula itself.
- Scope. The period, population, or boundary the contract currently covers, and what falls outside it.
- Inputs. The approved source fields, and nothing a model is free to substitute.
- Freshness. When the inputs were current, and which close or period they belong to.
- Missing values. What happens when an input is absent, explicitly distinct from treating it as zero.
- Thresholds. The exact comparisons that produce a classification, including ties.
- Validation. How a result is checked against the approved rule, independent of whether the narrative about it is checked.
The table below fills those same fields only with the synthetic finance contract this site already publishes. It names the version, the grain, the formula, the thresholds, the cases that do not get a percentage, and the cases that are rejected rather than repaired. The contract is orisdale-finance-variance-demo, version 1.0.0. Its own status line is: "Demonstration rules for a synthetic example. Not a customer-approved policy and not a measured result." Nothing below is a customer's close.
| Contract field | What version 1.0.0 states |
|---|---|
| Identity | Contract orisdale-finance-variance-demo, version 1.0.0 |
| Grain | Join keys department_id, period, and currency. Each key combination may appear once per input file |
| Scope | Period 2026-09 and currency USD |
| Amounts | Integer cents. Accepted amounts are non-negative decimals with at most two decimal places. Negative, non-numeric, empty, or over-precise amounts are rejected. Empty is never treated as zero |
| Variance | variance_amount equals actual_expense minus approved_budget. Positive is over budget, negative is under budget, and zero is on budget |
| Percentage | variance_amount divided by approved_budget, times 100, only when approved budget is greater than zero. Display rounding is half away from zero at four decimal places |
| Threshold test | Exact integer cross-multiplication on unrounded values: the absolute variance in cents, times 100, is compared with the threshold percent times budget cents |
| Material | Absolute variance of at least 5,000.00 USD, which is 500,000 cents, or an absolute variance percentage of at least 10 percent. The comparison is "at least," not "greater than" |
| Management attention | Not Material, and absolute variance of at least 1,000.00 USD, which is 100,000 cents, or an absolute variance percentage of at least 5 percent |
| Otherwise | Within tolerance. Classification uses the absolute value. Direction is reported separately |
| Zero budget | Percentage is null. It is never infinity and never zero. Category is "Needs human review" because the percentage is unavailable |
| Rejections | Duplicate keys reject every row that shares the key. A department in only one input file is rejected. Invalid amounts are rejected. Rows outside the declared period or currency are rejected |
| Review labels on the contract | Pending human review, Needs human review (rule-based), and Rejected input |
Those are demonstration rules for a synthetic example. A later engagement would replace the numbers with a contract the finance owner had approved. The fields would remain. A contract that omits grain, the zero-budget case, or the rejections is not ready for an agent: the design risk is that an agent fills that silence with an invented default instead of surfacing the gap.
The hand-checked results are part of the same publication. EX-FIELD-OPS is budget 100,000.00, actual 115,000.00, variance 15,000.00, 15.0000 percent, over budget, Material. Both the 5,000.00 USD test and the 10 percent test are met. EX-CORP-GA is budget 60,000.00, actual 62,000.00, variance 2,000.00, 3.3333 percent, over budget, Management attention. It is under both Material tests and meets the 1,000.00 USD test. EX-MARKETING is budget 40,000.00, actual 40,500.00, variance 500.00, 1.2500 percent, over budget, Within tolerance. It is under both Management attention tests. Direction and category are different fields: Marketing is over budget and still within tolerance.
Where this contract lives in the proof
The worked example is published at Finance AI Should Interpret Metrics, Not Recalculate. Inputs, contract, calculation source, results, and the validation record are served from /evidence/finance-variance-m3/. This article does not recompute them. The proof is a local deterministic run. It is not Alteryx, BigQuery, or Gemini output, and it is not a benchmark.
An agent reads those fields. It does not restate materiality as "large" and apply its own cutoff. Field Operations is Material because both published tests are met. Rejected inputs stay rejected: duplicate keys are not silently chosen, an empty amount is not zero, and a zero budget does not grow a percentage. Finance Intelligence shows the same boundary as an illustrative solution page. Neither that page nor this contract is a customer policy.
A calculation at request time can still be governed
A calculation may run when the question is asked, if it is the approved formula, grain, and thresholds, on authorized inputs, through a path the finance owner can inspect. The agent may call that path. It may not invent a formula, a join, a grain, or a threshold because the question was phrased in a new way. The finance proof itself is not that request-time path. It is a fixed run over fixed files. Unconstrained query generation against raw ledger tables is the failure mode. A validated tool that executes version 1.0.0 is not that failure.
Semantic explanation sits beside the tool. The tool can return "over budget" and "Material." Definitions say how those labels may be phrased. If the two disagree, the contract wins on the number. Access policy is separate again: a person who may not see EX-FIELD-OPS does not receive a softer telling of the 15,000.00 USD variance. The row is absent.
A path for changing the rule
A proposed change to a formula, a threshold, a grain, or a rejection rule is drafted against the current version, attributed to the rule owner, and tested on cases the owner already understands, including a value on a threshold, a zero budget, a duplicate key, and an amount that must be rejected. Only a version the owner accepts is a version an agent may read. Commentary written under version 1.0.0 stays under version 1.0.0 until it is regenerated and reviewed.
That path is a design requirement. It is not running Orisdale software, and this article does not revise the synthetic contract. Editing a prompt and calling the result the new official rule is the practice the path is meant to replace. Accepting one Field Operations narrative does not authorize a new materiality test. Human-in-the-Loop AI separates the reviewer of a case from the owner of the rule.
A correct number does not validate the cause
Numeric claims are checked by exact equality with the computed field. The check is deterministic and independent of any causal review. The proof never reports a causal claim as supported.
Claim C1, "Field Operations is 15,000.00 USD over budget," expects 1,500,000 cents. Claim C2 checks the category Material. Claim C4 checks that Marketing is within tolerance. Human confirmation on numeric claims is "not applicable."
Claim C3 says the overage was caused by unplanned equipment rental and names evidence E1. E1 is a synthetic record: an equipment-rental line item is listed in the Field Operations expense detail for 2026-09. The status is "evidence linked — human verification required." The record is attached. The cause is not confirmed, because the checker does not read the description for meaning. Human confirmation remains "not recorded."
Claim C5 says the Corporate G&A overage was caused by consulting fees and names no evidence. The status is "unsupported: no claim-linked evidence." Same-department records are ignored. The numeric result can still be agreed: 2,000.00 USD over budget, Management attention.
Passing C1 and C2 does not make C3 a fact. Reviewers can accept the number and reject the narrative. An agent composing its own query is not by itself proof that no contract exists — a generated query can still be constrained to the approved formula, grain, and thresholds, authorized against the same inputs, and validated against this version, the way "A calculation at request time can still be governed" describes above. What signals a missing contract is an agent free to change the formula, the grain, the joins, or the threshold because the question was phrased differently, not the act of generating SQL. The worked example is the place to inspect the boundary.