A growing number of organisations want AI to help staff apply their own rules. A bursary agency wants help checking applications against its eligibility policy. An insurer wants claims assessed against policy wording. A bank wants credit applications checked against its lending policy. A municipality wants permit applications checked against its by-laws. The pitch is usually the same: load the policy documents into an assistant, let it read each case, and have it recommend an outcome.
That pitch skips a step. A policy document is written for people. It assumes a reader who knows the organisation, asks a colleague when a sentence is unclear and uses judgement when two clauses pull in different directions. A system cannot do any of that reliably, and a language model that appears to do it is making choices nobody approved. The result can look right for months and still be impossible to defend when someone asks why their application was refused.
This series is about the layer that has to exist before AI can help apply rules safely: policy expressed in a form that is authoritative, versioned, testable and traceable, with a case file for every recommendation and an appeal path built in. It is the technical companion to Rewiring Government for the AI-Native Era, but the mechanisms apply equally to banks, insurers, medical schemes and any organisation whose decisions have to be explained. Throughout, we follow Amatola Bursary Agency, a fictional provincial agency that funds tertiary study. Its policy, rules, cases and figures are illustrative.
The sentence that looked precise
Amatola's bursary policy contains this sentence: "Applicants from households earning under R350,000 a year qualify for full funding." It reads as clear. It has a number in it. A developer could turn it into a line of code in a minute.
Now try to compute it for a real applicant. Which household? The one on the application form, the people in the same dwelling, or the people who financially support the student? Gross or net income? Income from all sources, including grants and informal earnings, or only salaried income? Earned in which year: the last tax year, the last twelve months, or the year of study? What happens when a parent has died during the year, or when the student lives with a grandmother but is supported by an uncle?
Each of those questions has an answer somewhere in the agency. Some are in a policy note. Some are in an email from the programme manager in 2023. Some exist only in the heads of three long-serving assessors who apply them consistently because they trained each other. None of them is in the sentence.
When Amatola's first AI pilot read the policy and assessed cases, the assistant answered those questions too, case by case, based on whatever the surrounding text and the applicant's documents suggested. It was usually reasonable. It was also inconsistent between similar cases, and when a reviewer asked why one applicant's income had been counted net and another's gross, there was no answer except that the model had read the situation differently.
That is the core problem. Interpretation did not disappear when the assistant arrived. It moved from a known group of trained people into an unrecorded, unrepeatable process.
Four forms of the same policy
It helps to separate four forms in which a rule can exist: prose policy, structured policy, decision tables and code. Part 2 of Rewiring Government for the AI-Native Era introduces them for a licensing authority, including which rules are worth encoding at all. This series stays at the technical layer: what each form must contain for a system to apply it and for someone to defend the result.
Prose policy states intent and is read with judgement. Its ambiguity is sometimes deliberate, leaving room for cases the drafters did not foresee, which is exactly why a system cannot execute it.
Structured policy defines the terms, lists the conditions, attaches each exception to the condition it modifies and records every interpretation decision with an owner and a date. The test is that two analysts reading it would compute the same answer. It plays the same role for a rule that a specification plays for software, as argued in The specification is the control surface.
Decision tables are where completeness can be checked: is there a row for every combination of inputs, and do any rows overlap with different outcomes? The Decision Model and Notation (DMN) standard published by the Object Management Group is one widely used way to express this layer, with a graphical notation for how decisions depend on input data and business knowledge, and an expression language detailed enough to execute.
Code is versioned, tested against the decision table and run by the system. Nobody edits it to handle a difficult case. If a case is difficult, the structured policy changes first, with approval, and the code follows.
The most important arrow in that picture is the first one. Going from prose to structured policy is interpretation. It decides what the organisation's rules mean in practice. Every later step is translation, and translation can be checked: does the decision table say what the structured policy says, and does the code produce what the decision table says? Interpretation cannot be checked mechanically. It has to be owned.
This is not a new idea, and that helps
Governments have been working on this problem for years under the label "Rules as Code". The OECD's Observatory of Public Sector Innovation set out the idea in its 2020 working paper Cracking the Code: Rulemaking for humans and machines: drafting machine-consumable versions of rules alongside the human-readable versions, rather than leaving every implementer to translate the prose independently.
Open-source tools exist for different parts of the job. OpenFisca describes itself as a free and open-source engine for writing rules as code and is used to model tax and benefit rules and simulate the effect of reforms. Catala, a language developed by researchers at Inria and Microsoft Research, is designed to translate statutory text into executable code using default logic, the general-rule-plus-exceptions structure that legislation often follows. Its authors evaluated it on French family-benefit rules and a section of the US tax code, and reported finding a bug in an official implementation along the way.
None of these is a prerequisite. A bursary agency can do useful work with a well-kept spreadsheet of decision tables and a small rules service. The point is that the problem is well understood, and that the answer people keep arriving at is the same: separate the rule from the reasoning about the case, and make the rule explicit.
Where a language model does fit
None of this means a language model has no role. It can propose candidate conditions and open questions from the prose, extract facts from scanned applications, suggest edge cases the decision table misses, and draft plain-language reasons from the rule engine's trace. Each of those outputs is reviewed by a person before it counts. Part 6 sets out that split of duties in detail.
What a model should not do is decide what "household" means on the day it reads an application. That decision belongs in the structured policy, approved once, applied consistently, and changed only through a controlled process. The Jev decision layer series makes a related argument for typed decisions: narrow, inspectable outputs are what make AI usable in business software.
The interpretation register
The single most useful artefact Amatola produced in its first month was not code. It was an interpretation register: a list of every question the policy sentence left open, with the answer, the reason, the owner who approved it and the date.
| Field | Example (illustrative) |
|---|---|
| Reference | D-02 |
| Policy clause | Bursary Policy, section 4.2 |
| Question | Is household income gross or net? |
| Decision | Gross income from all sources, including grants |
| Reason | Consistent with the means test used by the referral partner; avoids rewarding unverifiable deductions |
| Approved by | Policy manager, 15 Sep 2026 |
| Review date | September 2027, with the annual policy review |
Writing the register surfaced three things. Two long-serving assessors had been answering one question differently for years. One "rule" that everyone applied was not in any approved document and had to go to the board. And a question nobody had considered (how to treat a student who is their own household) turned out to affect about one application in forty. Those numbers are illustrative, but the pattern is common: the first honest attempt to make policy computable is also the first audit of whether the organisation agreed with itself.
The register is also what makes the later parts of this series possible. Rules can only be versioned if the interpretations they rest on are recorded. Appeals can only be fair if the reasons trace back to approved interpretations rather than to whatever a model inferred.
Signs your policy is not ready for AI
Before connecting an assistant to a policy library, check for these signs:
- Assessors disagree on similar cases, and nobody can say which of them is right.
- Important rules live in emails, circulars or training slides rather than in an approved instrument.
- The policy has been amended, but older versions are not kept alongside the effective dates.
- Nobody can name the person who decides what an ambiguous clause means.
- Refusal letters cite the policy in general terms rather than a specific condition.
- The same policy is implemented in two systems, and they occasionally give different answers.
Any one of these means AI will automate an argument the organisation has not settled. That makes the argument faster and harder to see.
Start with one rule
Do not start by converting a whole policy manual. Pick one decision that is frequent, consequential and mostly rule-based. For Amatola it was the household income test. Then:
- Extract the operative sentences and list every open question.
- Answer each question with the person who owns the policy, and record it in the interpretation register.
- Write the structured rule and a decision table, and have someone who did not write them check that they agree.
- Collect thirty past cases with known correct outcomes and test the table against them.
- Only then let a model help with extraction and explanation around that rule.
The work in steps 1 to 3 usually takes days, not months. It is also the work that turns a pilot from "the assistant seemed to get it right" into "here is the rule, here is who approved it, and here is the evidence it was applied". Part 2 deals with what makes a rule authoritative once it exists.
Next: Part 2, The rule must be authoritative before the agent can help. All parts are on the series page.
How CloudNala can help
CloudNala helps organisations take one consequential decision from policy prose to an explicit, tested rule. We work with your policy owners to extract the operative clauses, run the interpretation sessions and build the register, express the rule as a decision table and a small rules service, test it against past cases, and then design where AI can safely help with extraction and explanation around it. We do not give legal opinions; we make sure your systems apply the rules your organisation has actually approved.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Decision Review or write to us at consult@cloudnala.co.za