Part of the Decision Assurance series.
A tier-one investment bank that takes AI governance seriously ends up in the same place.
The team moves from documents to code. Policies become rules. Rules become services. Decisions are evaluated programmatically.
This is a real step forward.
It is still not enough.
The promise
Policy-as-code solves a clear problem.
Instead of interpreting a document, the rules engine evaluates a rule. Instead of relying on human judgement alone, decisions are checked against defined criteria.
Procurement gains consistency, repeatability, and speed.
A decision is no longer arbitrary. It is evaluated.
The assumption
Once policies are expressed in code, the system is governed.
If every decision is evaluated against policy, then governance is enforced. If governance is enforced, it can be demonstrated.
Where it breaks
A policy engine evaluates a decision at a point in time.
The engine does not preserve that moment.
The gap
Take a vendor approval workflow at a UK investment bank.
On Monday, March 4th, a Cyprus-based payment processor is submitted as a Tier-2 supplier with a £1.2m three-year contract value. The procurement system runs Vendor Policy v2.3 against the application: financial thresholds (debt-to-equity below 1.8), jurisdictional rating (Cyprus rated medium under the bank's geopolitical schedule), and internal exposure limits (less than 4% of single-vendor concentration in the payments segment).
All criteria pass. The decision is recorded: approved. The supplier is onboarded into the AP system within seventy-two hours.
Six months later
The policy has changed.
Thresholds have tightened — debt-to-equity is now 1.5. Jurisdiction ratings have been updated; Cyprus has moved from medium to medium-high. Exposure limits have shifted under the new third-party risk framework.
Policy v2.3 is no longer active. Policy v2.6 is now in force.
The question
A PRA review asks why this supplier was approved.
The rules engine can re-evaluate the supplier today. It can run the same input through Policy v2.6. It can show what would happen now.
What it cannot show
The procurement system cannot show, with certainty:
- the exact rule set that was in force at the moment of approval
- the precise thresholds that were applied
- the context that surrounded the decision
- whether the decision complied with governance at that time
The evaluation happened.
The evidence did not persist.
The time problem
These engines are designed to evaluate, not to preserve.
Rules change. Versions move. Services are redeployed.
The system optimises for the next decision, not for proving the last one.
The independence problem
Even when versioning exists, it remains internal.
The same policy engine that evaluated the decision is responsible for reconstructing it.
A system describing its own behaviour is not independent proof. It is procedural reconstruction.
The illusion of control
From the outside, the system looks governed. Policies exist in code. Evaluations are consistent. Decisions are traceable.
Most systems optimise for traceability, but that still does not produce proof.
Traceability shows that something happened. It does not prove why it happened under the conditions that existed at the time.
The moment of scrutiny
The gap only appears when a specific decision is questioned.
Not the policy in general. Not the system in aggregate.
One decision. One moment. One policy version.
The shift
A governed system does not just evaluate decisions. It captures them.
Policy frameworks fail at intent. Policy-as-code fails at preservation.
At the moment they are made:
- Input
- Policy
- Context
- Outcome
- Version
- Timestamp
- Signature
Bound together as a single artefact.
What changes
When the PRA letter arrives — why was this supplier approved? — the procurement system does not re-evaluate. It retrieves.
No reconstruction. No re-running of rules. No dependency on what the system looks like today.
The decision stands on its own.
Decision ID: RCP-VND-78124
Status: Verified
Closing
Policy-as-code enforces decisions.
It does not prove them.
When a decision needs to defend itself — in front of a regulator, a court, or an internal risk committee — enforcement is not enough.
You need evidence.
You need proof.
Continue reading
- [The problem isn't policy. It's proof.] → /blog/the-problem-isnt-policy
- [From archaeology to proof] → /blog/from-archaeology-to-proof
- [Explainability is not proof] → /blog/explainability-is-not-proof