Part 1 argued that policy prose has to become explicit rules before AI can help apply it. That raises an awkward question. Once the rule exists as a decision table or a few lines of code, what makes it the rule? Not the fact that it runs. Plenty of code runs and encodes something nobody approved.
In most organisations, authority comes from a chain: an Act or a board delegates power, an instrument is approved under that power, and the instrument says what applies from when and to whom. Paper systems carried that chain implicitly. The policy binder had a cover page with a resolution number, the circular had a date and a signature, and an experienced assessor knew which version to use. A machine-readable rule needs the same chain made explicit, or it becomes an orphan: correct-looking logic with no provenance.
At Amatola Bursary Agency, the fictional provincial bursary agency we follow through this series, this showed up in an uncomfortable way. An applicant's adviser asked which version of the income rule had been applied to a refused application. The development team knew which code had run. Nobody could say, from the system alone, whether that code matched the policy in force on the application date.
What an authoritative rule record contains
Every rule in Amatola's register now carries a record. The fields are not bureaucratic decoration. Each answers a question an auditor, an appeal panel or a court could reasonably ask.
Source instrument. The specific document and clause the rule implements. Not "the bursary policy", but "Bursary Policy 2027, section 4.2". If the rule implements an interpretation, it also cites the interpretation record from Part 1.
Approval. Who approved the instrument and under what authority: a board resolution, a delegation, a ministerial approval. If the approver lacked authority to make the rule, the rule is vulnerable no matter how well the code works.
Effective dates. When the rule starts and stops applying, and to which event: the date of application, the date of decision, the start of the academic year. This is where most systems go wrong, as the next section explains.
Scope. Which programmes, applicant groups or regions the rule covers. A rule that applies to first-time applicants should not silently apply to renewals.
Supersession. Which earlier rule this one replaces, and whether the replacement is complete or partial.
Status and review. Draft, approved, in force, suspended or retired, with a review date.
Amatola keeps these records in a simple rules register: one row per rule version, with the decision table and the code version linked from the row. The format matters far less than the discipline that no rule reaches production without a complete row.
The version in force on the date that matters
Policies change. Amatola amends its income threshold most years, and occasionally changes a definition. A system that only knows the current rule will apply this year's policy to last year's application. That error is easy to make, hard to see and serious when it surfaces in an appeal.
The rule register therefore has to answer a time-bound question: which version applied on a given date to a given kind of event? An application lodged on 12 November 2026 is assessed under the rule in force then, version 2. If the same case comes back on appeal in February 2027, after version 3 took effect, the appeal is still assessed under version 2 unless an approved transitional provision says otherwise. That transitional provision is itself a rule with its own record.
Two dates are worth keeping separately. The effective date is when the rule applies in the real world. The recorded date is when the system learned about it. They differ more often than people expect: a board approves an amendment in September with effect from January, or approves a correction in March that applies backwards to February. Keeping both lets the agency answer "what did we believe the rule was on that day?" as well as "what was the rule on that day?". The first question matters when explaining an old decision. The second matters when correcting it.
Why this matters more once AI is involved
Without AI, a stale rule usually lives in one system and fails in a predictable way. With an assistant in the loop, there are more places a rule can hide.
The retrieval index. If the assistant retrieves policy text to explain or assess a case, the index may contain the old policy, the new policy and a draft amendment, all with similar wording. Unless each chunk carries its effective dates and status, the assistant may quote the draft as if it were in force. Permission-aware retrieval makes a similar point about access: the index has to carry the metadata the decision depends on.
The prompt. Teams sometimes paste a rule summary into the system prompt "to help the model". That summary is now an unregistered copy of the rule, and it will not be updated when the policy changes.
The model's own knowledge. A general-purpose model may have read an older public version of a policy, or a similar policy from another body, and fill gaps with it.
The fix is the same in each case. The rule engine applies the registered rule for the relevant date. The assistant receives the rule version and its record as context rather than inferring them. Retrieved policy text carries status and effective dates, and drafts are excluded from retrieval for live decisions. And the case file, covered in Part 4, records which version was applied, so the question that embarrassed Amatola can be answered in seconds.
Jurisdiction and delegation
Public bodies and regulated firms often apply rules from more than one source at once: national legislation, provincial regulations, their own board policy and programme-specific directives. Each source has its own authority, and some can only operate inside limits set by others. A circular issued by a programme head cannot override a board policy. A board policy cannot override the Act.
The rule record captures this through the source instrument and its level. Part 3 uses that level to settle conflicts. For now, the practical rule is simple: if you cannot name the instrument and the authority behind a rule, it should not be in production. It may be a sensible practice. It may be what everyone does. But until it is approved by someone with the power to approve it, applying it automatically is applying a rule that does not exist.
For public bodies, From PDF policy to executable government looks at the same lifecycle from the policy-maker's side, and the No AI Without Information Architecture series covers the wider job of giving content an owner, a status and a structure systems can rely on.
A checklist before a rule goes live
Before any rule goes into a live decision path at Amatola, someone other than its author confirms:
- The source instrument and clause are cited and the instrument is approved.
- The approver had authority to approve it.
- Effective dates are set, with the event they apply to.
- Scope is explicit, including who is excluded.
- Superseded versions are marked and remain available for older cases.
- Any interpretation records it relies on are approved and current.
- The decision table and code version are linked and tested against the table.
- Retrieval sources for this rule carry the same status and dates.
This is the same discipline good teams apply to software releases. Pin the version before you pin your hopes on the platform makes the case for knowing exactly which version of a dependency you run. A rule is a dependency of every decision it touches.
Next: Part 3, When rules conflict. All parts are on the series page.
How CloudNala can help
CloudNala helps teams set up a rules register that ties every executable rule to its source instrument, approval, effective dates and scope. We review how your current systems, prompts and retrieval indexes hold policy, find the unregistered copies, and design the date-aware lookup that lets any decision be explained against the rule in force at the time. We work alongside your policy and legal owners and do not give legal advice.
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