The headline is a boundary, not a product
"Trust layer" is a useful name and a dangerous one. Useful, because enterprise agents fail when identity, data access, tool permissions, calculations, definitions, evidence, validation, logging, and human approval are all left inside the prompt. Dangerous, if a reader thinks Orisdale sells a component by that name. It does not. The trust layer in this note is an architectural concept: the set of controls that must remain outside the model, enforced by the systems and the people who already own them.
The model can be fluent. Fluency is not authority. Authority is the right to see a row, call a tool, apply a formula, or treat a sentence as accepted. Those rights are granted elsewhere. The architecture places the agent runtime after governed logic and semantic context, and Enterprise AI Agents, Governed by Design states the runtime constraints. This note maps each control to an owner and an enforcement point.
- Identity and data accessThe identity owner and platform permissions.
- Tool permissionsAn allowlist. An unlisted tool is refused.
- Approved calculationsA versioned contract, controlled execution.
- Semantic definitionsWhat a term means, owned by the business.
- Evidence lineageA named record tied to a specific claim.
- Human approvalA reviewer, outside the generated paragraph.
Who owns each control, and where it is enforced
The table is a design map for a review. It is not a module list, and it is not a claim that Orisdale operates these systems for a customer.
| Control | Owner | Where it is enforced |
|---|---|---|
| Identity | The enterprise identity owner | The identity system the organization already uses. The model does not authenticate the person. |
| Data access | The data owner for that domain | Platform permissions on the governed dataset, view, or output. A prompt does not grant a row. |
| Tool permissions | The runtime owner, with the business owner of each tool | An allowlist of tools and arguments. A tool that is not listed is refused. |
| Approved calculations | The business owner of the metric | A versioned calculation contract and controlled execution of that contract. |
| Semantic definitions | The owner of the business term | Definitions the agent is allowed to read. The model does not invent a meaning at question time. |
| Evidence lineage | The owner of the source record | A named identifier that ties a claim to a specific record. A matching period is not lineage. |
| Validation | The owner of the rule, separate from the reviewer of a single case | A comparison against the approved rule. Reviewing the prompt is not this test. |
| Logging | The operator of the runtime | A record of the request, the tools, the contract version, and the result. The chat transcript is not the record of authority. |
| Human approval | The named reviewer for that decision | A review state outside the generated paragraph. The paragraph does not approve itself. |
Read the map from the outside in. A prompt that pretends to grant rows, a calculation with no owner, or lineage that is only "the model saw something relevant" leaves approval blessing a guess. Governed business logic is the calculation row. Semantic intelligence is the definition row. Neither one does the other's job.
A prompt can be versioned. It is not access control
Prompt text should be a managed artifact. Teams can store it, version it, and test whether a revision still answers the question it was written for. That discipline does not move any row in the table.
A versioned prompt can say "only use the approved variance." The data platform does not read that sentence when it decides whether a role may select a table. A tool gateway does not treat it as an allowlist. The calculation contract does not change because the prompt became more careful. Testing a prompt can show that a bad instruction was removed. It cannot show that an unauthorized tool was impossible to call.
The failure mode is a careful system prompt beside a general query tool. The prompt is then the only thing between a user and a second, unofficial close. When the prompt and the platform disagree, the platform is the control. The prompt is a request.
Two design examples
Both examples use the published synthetic finance variance proof. They are design examples. They are not logs from a running Orisdale system, and they are not customer cases. The numbers, categories, and evidence statuses below are the ones that proof already publishes. The full calculation is on the worked example.
Design example: a rejected unauthorized tool request. A person asks what happened in Field Operations for September 2026. The approved path is to read the governed result: department EX-FIELD-OPS, variance 15,000.00 USD, direction over budget, category Material, under contract orisdale-finance-variance-demo version 1.0.0. If the agent instead calls a tool that recomputes variance from raw actuals, or a tool that was never allowlisted, the boundary refuses the call before a new number is written. The refusal is enforced where tools are permitted, not by hoping the model will honor the prompt. The caller may receive the governed result or a clear refusal. They should not receive a privately recalculated substitute.
Design example: a permitted request whose narrative still needs evidence review. The agent is allowed to read the same governed fields and correctly repeats that Field Operations is 15,000.00 USD over budget and categorized Material. It then adds that the overage was caused by unplanned equipment rental. That sentence is claim C3. C3 names evidence E1. E1 exists, belongs to EX-FIELD-OPS, and belongs to period 2026-09. Its description says an equipment-rental line item is listed in the Field Operations expense detail for that period. The proof's status is "evidence linked — human verification required." Linking E1 does not establish the cause. The checker attaches the record because the claim named it. It does not read the description and decide that the line item explains the variance. Human confirmation on every causal assessment in the proof is "not recorded." A permitted tool call produced a reviewable packet. It did not finish the review.
Five checks that are not the same check
Teams collapse these into "the answer was grounded." The finance proof keeps five checks apart.
Retrieval relevance. A record shares a department and a period. That match does not link the record. Same-department records are ignored unless the claim names them.
Numeric agreement. The sentence matches a computed field by exact equality. Field Operations at 15,000.00 USD over budget, and the Material category, are this kind of check. Human confirmation is "not applicable."
Linked evidence. The claim names an identifier, and every named record exists for that department and period. C3 names E1, so the status is "evidence linked — human verification required." If any named record is missing or belongs elsewhere, the status is "unsupported: evidence reference not usable," and nothing is linked.
Causal support. The proof never reports a cause as supported. It does not read free text for meaning. Causal support is a person's judgment after a link exists.
Human confirmation. A recorded reviewer decision. Until then, causal confirmation stays "not recorded."
Claim C5, "The Corporate G&A overage was caused by consulting fees," names no evidence. The status is "unsupported: no claim-linked evidence." The numeric result can still be agreed: 2,000.00 USD over budget, 3.3333 percent, Management attention.
What failure handling has to do
A control that only warns inside the paragraph has not failed safely.
An unauthorized tool request is rejected. The response does not include an approximated result from the forbidden tool. The attempt is logged with the identity, the tool name, and the contract version the caller was allowed to read. Editing the prompt afterward does not grant the tool.
A missing or unusable evidence reference leaves the causal claim unsupported. The narrative may still repeat the governed number. It may not invent a cause, and it may not treat a department-period search hit as if the claim had named it. The Energy blueprint uses the same behavior when a time code or a rate is absent: the gap stays labeled.
A failed validation is not automatically a rule problem. A returned number that does not match the approved contract can come from a stale or wrong input, an outdated rule version, an execution error, a permission that silently narrowed the data, or a comparison against the wrong period. The narrative does not explain the mismatch away in any of those cases. Investigation starts by sorting which category it is, then routes to the owner of that category: the source-system or input owner, the rule owner for a version question, the runtime operator for an execution fault, the data owner for a permission question, or the calculation owner only once the number itself is confirmed wrong. What an Enterprise AI Agent Needs in a Business Logic Contract covers that contract. Human-in-the-Loop AI covers what the person is asked to decide once a packet is allowed to exist.
Where to go next
Start with the control that is currently only a sentence in a prompt. If that sentence is doing the work of identity, access, tools, or the calculation, move it to the system that can enforce it. The architecture, the agent runtime, and the finance proof are the next reads.