Ask a licensing official how a renewal decision is made and you will rarely get a single document. You will get the provincial Act, its regulations, a municipal zoning by-law, two circulars about trading hours, a delegation of authority, an internal checklist that was last updated three years ago, and the practical knowledge of the two people who have done the job longest. The rule that is actually applied is a composite of all of these, and most of it has never been written down in one place.
That is the material any "machine-readable government" programme has to work with. The idea is simple to state: translate a defined set of rules into a form software can read, so AI can help officials apply them consistently and cite exactly what it relied on. The work is not simple, and the most important design choice is the one people skip: who is allowed to say what the rule means.
This part uses the running example from Part 1: the Thukela Provincial Licensing Authority, a fictional provincial body that issues liquor trading licences and event permits.
The model must not be the source of the rule
The tempting shortcut is to give a large language model the PDFs and ask it to answer questions about eligibility. It works surprisingly well in a demonstration. In production it creates three problems.
The model's interpretation is not stable. Ask the same question with different wording, or after a model update, and the answer can change. There is no version of "the rule" to point to.
The interpretation is not owned. If the model decides that "within 500 metres of a school" is measured along the road rather than in a straight line, nobody with authority approved that reading.
The interpretation is not testable. You can test outputs, but you cannot inspect the rule the model applied, because there is no rule, only a probability distribution over plausible answers.
For a public body, those are not quality issues. They are legitimacy issues. An administrative decision has to rest on a rule that an authorised person adopted, and the reasons have to show which rule it was. So the core principle of this series, explored more technically in The model should not be the law, is that the model reads and cites the rule; it does not author it.
One rule, four forms
It helps to separate four forms a rule can take.
Prose is the gazetted text. It is the only form that is law, and it is written for people, with all the ambiguity and cross-referencing that implies.
Structured policy pulls out the conditions, defined terms, thresholds, exceptions and references, with each element linked back to the clause it came from. This is where interpretation first becomes explicit.
Decision tables express the rule as inputs and outcomes: if the premises are within the prohibited distance and no exemption applies, the renewal cannot be granted. Policy owners can read and sign off a decision table in a way they cannot sign off code.
Executable rules are the same logic as a versioned service with automated tests, which a case-management system or an AI assistant can call to check a case and receive a result with the rule version and clause references attached.
The authority runs one way. The executable form must match the decision table, the decision table must match the structured policy, and the structured policy must match the prose. When they disagree, the prose wins and the downstream forms are corrected. The OECD's work on rules as code argues for publishing an official machine-consumable version alongside the natural-language text. Whether or not a South African body publishes it, the same discipline applies internally.
Not every rule should be encoded
Thukela's first instinct might be to encode its entire licensing framework. That would be a mistake. A good encoding candidate has four properties:
| Property | Encode | Leave for human judgement |
|---|---|---|
| Determinacy | Clear thresholds, dates, lists and conditions | Standards such as "suitable", "reasonable" or "in the public interest" |
| Volume | Applied hundreds or thousands of times | Applied rarely, case by case |
| Stability | Changes occasionally, through a formal process | Changes often through informal practice |
| Consequence of error | Errors are detectable and reversible | Errors are hard to see or hard to undo |
Rules with open standards can still be partly encoded. The system can gather the evidence relevant to "suitable premises", flag what is missing and present it to the official, while the judgement itself stays human. That partial encoding is often where most of the value sits, because it removes the clerical work without pretending to automate discretion.
Interpretation becomes a governed decision
Encoding forces questions that were previously answered silently. Does the 500-metre distance rule apply to a school that has closed? To a crèche? When the regulation says "on the date of application", is that the date the form was submitted or the date the fee cleared?
Each of those questions needs an answer, and the answer needs an owner. In Thukela's design, every encoding decision becomes a short interpretation record: the clause, the question, the options considered, the chosen reading, the reason, the policy owner who approved it and the date. Some of those records will reveal that officials have been applying the rule differently for years. That is uncomfortable and valuable. The programme has surfaced an inconsistency that applicants were already experiencing.
Where the text is genuinely ambiguous and the stakes are high, the interpretation record should go to legal advisers, and some questions may need a formal policy decision or an amendment. An encoding project that does not budget for those decisions will either stall or quietly substitute an engineer's judgement for the policy owner's.
Versions and effective dates are not optional
Public rules change, and decisions have to be assessed against the rule that applied at the time. A licence renewal lodged in March and decided in May may need the March version of a trading-hours rule if the regulation says so.
This means every encoded rule needs a version, a start date, an end date where it has been superseded, a link to the instrument that changed it, and a record of who approved the change. Case records must store the version they were assessed against. Without that, the authority cannot answer the most basic question an appeal will ask: which rule did you apply? The Machine-Readable Policy series covers provenance, effective dates and supersession in detail, and when rules conflict covers precedence and mandatory escalation.
Testing the encoding against the law
Every condition and exception in the encoded rule should have test cases: at least one that passes, one that fails, and one at each boundary. Those tests are written from the prose, ideally by someone other than the person who encoded the rule, and they are approved by the policy owner.
The best source of additional tests is history. Cases that were overturned on internal appeal or review show where practice and law diverged. Feeding them into the test suite turns past mistakes into a permanent guard against repeating them. Part 3 builds this into a full evaluation harness for the AI service that sits on top.
Where the AI fits
With an encoded rule in place, the AI's role becomes narrower and safer. In Thukela's target design, the AI assistant:
- reads the application and attached documents and extracts the facts the rule needs;
- flags missing or inconsistent evidence and drafts a request for it;
- calls the rule service with the extracted facts and receives a result with clause and version references;
- drafts a recommendation and reasons that cite those references; and
- highlights anything the rule service could not decide, such as an open standard or a conflict.
The official sees the extracted facts, the rule result, the references and the draft reasons, and decides. If the AI extracted a fact wrongly, the official can see it, because the facts are shown separately from the conclusion. That separation of extraction, rule evaluation and drafting is what makes the system reviewable. It also connects to a broader point made in the No AI Without Information Architecture series: an AI system is only as dependable as the structure of the information beneath it.
What this costs, and who does it
The work is mostly not engineering. For a single service, expect a policy owner who can make interpretation decisions, a business analyst who can structure policy, an engineer who can build and test the rule service, legal advice on the ambiguous clauses, and the time of experienced officials who know how the rules are really applied. The engineering is the smaller part.
That cost is the honest price of a machine-readable service. It is also an investment that pays out beyond AI: a clear, versioned, tested rule base improves consistency, training, auditing and appeals even if the AI step is later replaced or removed.
Start this week
- Pick one high-volume decision and list every instrument that governs it, including circulars and internal checklists.
- Ask two experienced officials to explain the rule separately, and record where they differ.
- Draft a decision table for the clearest conditions and ask the policy owner to sign it.
- Start an interpretation record for every question the table raised.
- Collect ten overturned or disputed cases and check whether the table would have decided them correctly.
Next: Part 3, The government AI evaluation harness. All parts are on the series page.
How CloudNala can help
CloudNala helps public bodies take one service from PDF rules to a structured, versioned and tested rule base. We work with your policy owners and experienced officials to map the governing instruments, surface inconsistent interpretations, draft decision tables for sign-off and design the rule service and evidence model an AI assistant would rely on, so that the authority for each rule stays with the people entitled to hold it.
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.
Start a Digital Discovery Sprint or write to us at consult@cloudnala.co.za