Which policy was in force when the decision was made?

Imagine a supplier is put through a vendor approval workflow. The rules engine checks the application against policy, every criterion passes, and the supplier is onboarded.

Six months later, a regulator asks why that supplier was approved.

The engine can evaluate the same application again today. What the regulator is asking is different: which policy version applied at the time, which thresholds were used, what context surrounded the decision, and whether it met the requirements then in force.

Those are practical questions. Policy-as-code answers some of them and not others, and the difference is worth being precise about.

Policy-as-code answers the question it was built for

Moving from documents to code is a real step forward. Policies become rules, rules become services, and a decision is evaluated programmatically rather than interpreted from a document. Procurement gains consistency, repeatability and speed. The decision is no longer arbitrary; it is evaluated against defined criteria.

The assumption that usually follows is that once policies are expressed in code the system is governed: if every decision is evaluated against policy then governance is enforced, and if governance is enforced it can be demonstrated.

That last step is where it breaks. A policy engine evaluates a decision at a point in time. The engine does not preserve that moment.

The evaluation happened; the evidence did not persist

Take a vendor approval workflow at a UK investment bank. On Monday 4 March, 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 risk 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 as approved, and the supplier is onboarded into the AP system within seventy-two hours.

Six months later the policy has moved. Thresholds have tightened — debt-to-equity is now 1.5. 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.

Then a PRA review asks why was this supplier approved.

The rules engine can re-evaluate the supplier today, and it can show what Policy v2.6 returns. What it cannot show, with certainty, is 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, or whether the decision complied with governance at that time.

The evaluation happened. The evidence did not persist.

Re-running today’s policy does not describe yesterday’s decision

These engines are designed to evaluate, not to preserve. Rules change, versions move, services are redeployed. The system optimises for the next decision rather than for explaining the last one.

Where versioning does exist, it remains internal. The same policy engine that evaluated the decision is responsible for reconstructing it, and a system describing its own behaviour is not independent proof. It is procedural reconstruction.

From the outside the system still looks governed: policies exist in code, evaluations are consistent, decisions are traceable. But traceability shows that something happened; it does not show why it happened under the conditions that existed at the time. The gap appears only when one specific decision is questioned — not the policy in general, and not the system in aggregate. One decision, one moment, one policy version.

A governed system captures the decision as it is made

Capturing a decision means binding the input, the policy, the context, the outcome, the version, the timestamp and the signature together as a single artefact at the moment the decision is made.

When the PRA letter arrives — why was this supplier approved? — the procurement system retrieves rather than re-evaluates. No reconstruction, no re-running of rules, no dependency on what the system looks like today.

The claim is narrower than it sounds. Such a record shows what was evaluated, under which policy version, with what result. It does not establish that the inputs were true or that the policy was well designed. Those stay questions for the people reviewing the decision.

Make the later question answerable

Enforcement and proof are different properties. Policy-as-code enforces a decision. It does not, on its own, preserve the evidence that explains that decision later, in front of a regulator, a court or an internal risk committee.

A practical standard follows: a consequential decision should leave a record another person can read without rebuilding it. Start with one decision of that kind. Name the policy version it is evaluated against, capture the input, context and outcome alongside it at the moment it is made, and keep the result where a reviewer can retrieve it. A worked example of one such record is on the receipts page.