Every policy library of any age contradicts itself somewhere. A board policy says one thing, a later circular narrows it, an operating procedure was written before either and never updated, and a programme directive adds an exception for a group nobody else remembers. People working inside the organisation navigate this every day, mostly without noticing. They know which document "really" applies.
A system does not know. When Amatola Bursary Agency, the fictional agency in this series, converted its eligibility rules into a register, the first automated completeness check found eleven pairs of rules that could both apply to the same case and give different answers. The numbers are illustrative; the experience is not. The moment rules become explicit, their conflicts become visible.
That is good news, because the alternative is worse. An AI assistant given the whole policy library will also meet those conflicts. It will resolve them, case by case, according to whichever text seems most relevant to that case. It will not tell anyone it did so.
Three kinds of conflict
Not every conflict is the same problem. It helps to separate three kinds.
Conflicts the hierarchy settles. Two rules come from instruments at different levels. A circular from the programme head says applicants with a pending appeal elsewhere are ineligible; the board-approved policy sets out the eligibility criteria as a closed list, and a pending appeal is not on it. The higher instrument prevails, and the circular is either brought into line or withdrawn.
Conflicts an exception settles. Two rules come from the same level, but one is written as a specific exception to the other. The policy sets an income threshold for everyone, then says the threshold does not apply to applicants who are wards of the state. The specific provision governs the cases it was written for. Legal drafting is full of this general-rule-plus-exceptions structure, which is why tools such as Catala build their logic around it, as Part 1 noted.
Genuine ambiguity. Neither the hierarchy nor an exception settles it. Two provisions at the same level were written at different times for different purposes, and they disagree. Here there is no correct answer to compute. Someone with authority has to decide.
Precedence is data
The first kind of conflict is the easiest to automate, but only if precedence is recorded rather than remembered.
Each rule in Amatola's register carries the level of its source instrument, as described in Part 2. The rules engine can then detect when two applicable rules at different levels disagree and apply the higher one. More usefully, the register can flag the conflict to the owner of the lower instrument, because a circular that contradicts the policy it sits under is a defect, not a feature.
Two cautions apply. First, a lower instrument may legitimately add detail the higher one does not cover. That is not a conflict, and an over-eager check will flag it anyway. The test is whether both rules apply to the same case and give incompatible outcomes. Second, "later prevails over earlier" is a principle, not a universal rule. Whether a later instrument at the same level displaces an earlier one depends on what it says and the authority under which it was made. Encode the specific supersession recorded in the register, not a general assumption.
Exceptions belong next to the rule they modify
The second kind of conflict is often not a conflict at all. It is an exception that was written in a different document from the rule it modifies, so the two look contradictory when read separately.
The fix is structural. In the structured policy, each exception is attached to the rule it modifies, with its own conditions and its own source. In the decision table, the exception appears as rows with higher priority than the general rule, and the table records which source created each row. When the engine applies an exception, the case file cites both the general rule and the exception, so anyone reading the reasons can see why the general rule did not apply.
This matters for AI assistance in a specific way. If the assistant is asked to explain an outcome, it should receive the rule trace from the engine, including the exception that fired. Left to read the documents itself, it will often find the general rule first and explain the outcome wrongly.
Ambiguity must stop the line
The third kind of conflict is where most systems fail. Genuine ambiguity has no computable answer, so the system has to stop and ask.
At Amatola, the rules engine returns a distinct result for this case: not "eligible" or "ineligible", but "unresolved conflict", with the rules involved. The case is held, the applicant is told it needs further review, and the conflict goes to the policy owner. The owner decides, the decision becomes an interpretation record (Part 1), and the next case with the same pattern is resolved automatically.
Three design points make this work.
The engine must be allowed to say it does not know. Many systems are built so that every input produces an outcome. That pushes ambiguity into whatever default the developer chose. An explicit "cannot decide" result is a control, not a failure, a point made more generally in Guardrails are a stack, not a switch.
The assistant must not paper over it. If a model sees two conflicting provisions and is asked for a recommendation, it will usually give one, with a confident explanation. Amatola's design forbids the assistant from producing an eligibility recommendation at all; it can only summarise the case and the rules the engine reports. When the engine reports a conflict, the assistant's job is to describe the conflict clearly for the human reviewer.
Escalation needs a service level. A held case is a person waiting for money to study. The escalation path has a named owner, a target turnaround and a fallback when the owner is unavailable. Otherwise "escalate" becomes a polite word for "lose".
Find conflicts before applicants do
Conflicts are cheapest to resolve before any case meets them. Amatola now runs three checks whenever a rule changes:
| Check | What it finds |
|---|---|
| Overlap test | Pairs of rows in the decision tables that can both match the same inputs with different outcomes |
| Gap test | Combinations of inputs that no row matches |
| Hierarchy test | Lower-level rules that contradict a higher-level rule on the same inputs |
All three can run against the decision tables without any AI involved. A model can help generate unusual input combinations to probe the tables, as long as the check itself is deterministic. Part 7 places these checks inside a wider testing approach.
What the organisation learns
The conflict register turned out to be useful beyond the decision system. It showed Amatola's leadership where its policy drafting process was weak: most conflicts came from circulars issued quickly to deal with a problem and never reconciled with the policy. That led to a simple change. No circular affecting eligibility can now be issued without a check against the rules register, and the circular is entered into the register before it takes effect.
This is the pattern across the series. Making rules machine-readable is not only about letting systems apply them. It forces the organisation to see, for the first time, whether its rules are coherent. The Jev decision layer series reaches a similar conclusion from the AI side: narrow decision services work only where the surrounding rules are clear.
Next: Part 4, Every automated recommendation needs a case file. All parts are on the series page.
How CloudNala can help
CloudNala helps teams find and resolve the conflicts in their policy libraries before an automated system meets them. We build the precedence model and the overlap, gap and hierarchy checks against your decision tables, design the "cannot decide" path and its escalation service level, and set the boundary for what an assistant may say when rules disagree. We work with your policy owners and legal advisers, and we do not give legal opinions.
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