Key facts.
- Moffatt v. Air Canada (2024 BCCRT 149) held a company liable for its chatbot's wrong answer, which an engineer turns into a concrete control, an approval gate and a logged decision, not a sentence in a policy.source
- ISO/IEC 42001:2023 defines an AI management system with documented controls, roles and tests precisely so requirements can be assigned and operationalized not left abstract.source
- On WebArena, the strongest agent completed 14.41% of realistic web tasks versus a 78.24% human baseline, so an ungoverned agent acts wrongly often enough to need controls built in.source
Why does a policy document fail to reach the build?
Policy describes outcomes. Engineers need mechanisms. "The agent must not take irreversible action without human approval" is real. But which actions count? Where exactly does the gate sit? Who approves? How do you prove the gate can't be bypassed? None of that is in the policy. Until a governance owner and an engineer sit together and answer those questions, nothing gets built. That's where governance disappears. The teams that ship run the translation as an explicit exercise. Each clause becomes a control with an owner and an acceptance test. "Be compliant" becomes a set of checks that pass or fail in CI.
A better model doesn't fix this. WebArena is the evidence. The best agent gets real tasks right about one time in seven. It will try things outside its intended scope regularly. That's not a model quality problem you can wait out. The boundary has to be in a control the engineer wrote. Not in the model's judgment. The governance that reaches production was specified exactly the way engineers specify everything else: inputs, outputs, tests that pass or fail.
What does a translated requirement look like?
Three examples. "Human oversight for high-risk decisions", actions in category X route to an approval queue. Agent blocks until approved. Test proves an unapproved action never executes. "Auditability", every decision writes a structured log line. Test asserts it's present and parseable. "Stay within scope", tool permissions are enumerated. Anything not on the list is denied by default. Test proves denied tools are unreachable. Each one is now buildable. A reviewer can check it. That's the entire point of the translation.
| Policy language | Engineering control with a test |
|---|---|
| "Maintain human oversight" | Approval gate on category-X actions; test blocks unapproved execution |
| "Ensure auditability" | Structured decision log per run; test asserts presence and schema |
| "Operate within scope" | Deny-by-default tool allowlist; test proves denied tools unreachable |
Each rule chained across steps fails unless it is a control with a test; a stronger model will not wait out the math, so the rule lives in code before you build. (arXiv:2307.13854)
The Pattern Intelligence Layer is where the translated controls live and are enforced. Approval gates, decision logging and scope boundaries are expressed at the pattern level. What governance asked for and what engineering built are the same artifact, checked the same way. Reliability at the pattern level is how a governance requirement survives the trip from the policy author to the person who ships.
Frequently asked questions
Why not just give engineers the compliance document?
Because a document describes an outcome, not a mechanism. Until each clause becomes a control with an owner and a test, nothing concrete gets built.
Who owns the translation?
A governance owner and an engineer together. One knows the requirement, the other knows the system; the control they agree on is the deliverable.
How do you know it worked?
Every translated control has an acceptance test that passes or fails in CI. If it cannot be tested, it has not been specified clearly enough But .