Regulation as data: reading rules with software, and keeping people in the decision

The problem is accumulation

Rules rarely arrive together. A determination is issued in one year, a directive amends it in another, a notice sets fees in a third, and a memorandum between two supervisors adds a coordination duty. Each instrument is sensible alone. Read side by side, they overlap, they sometimes conflict, and the cost of finding out falls on the firm and on the supervisor’s small team.

We call this build-up sludge. It has three shapes: horizontal overlap between instruments of the same date, vertical accumulation where a later rule layers onto an earlier one, and time-layered build-up where old requirements survive after the reason for them has gone. A supervisor wants to know about all three before drafting the next rule.

What software is good at

Reading is a task for which software suits a corpus of public instruments. It compares thousands of paragraphs, groups similar obligations and proposes pairs worth a human’s attention. This is a large saving of time for a team with a flat headcount, and it is the reason regulators elsewhere invest in supervisory technology.

Software is poor at the other half of the job. It does not know which overlap is intended, which conflict a supervisor has already resolved, or what the political history of a clause is. A tool which presents its output as a decision therefore misleads. A tool which presents it as a lead is useful.

Three rules which make a finding trustworthy

The first rule is one finding, one citation. Each finding must quote its source provision exactly, and the quotation is then checked against the stored text by machine. If the words do not match, the finding does not reach a reader. This removes the failure which damages trust fastest in language tools, an invented or paraphrased quotation presented as a fact.

The second rule is honest coverage. A report states how many documents were examined out of how many were available, so a reader knows when a finding rests on a sample. A claim of completeness is made only when completeness was verified.

The third rule is a human gate. A named expert approves, refines or rejects each finding before anything is published. Confidence in a finding comes from the verified evidence behind it, never from the model’s own estimate of itself. A finding with no verified citation carries no confidence at all.

People stay in the decision

The draft Data Protection Bill on file gives a person the right not to be subject to a decision significantly affecting them based solely on automated processing, without their views being considered (section 11). Where automation is allowed, the controller must offer human intervention, the chance to state a view and the chance to challenge the decision (section 11(3)). Section 8(4) adds a right to know the reasoning behind processing whose results are applied to a person.

Those provisions are drafted for decisions about individuals, but the principle fits supervision too. A rule-reading tool should help an expert reach a view and should leave the view with the expert. The Bill is a draft, so this note describes a standard to build toward, not a duty in force.

Three analyses a supervisor runs

A rule-reading tool supports three distinct jobs. The first is sludge detection across a corpus of instruments: horizontal overlap, vertical accumulation and time-layered build-up. The second is a pre-rulemaking check, in which a draft instrument is compared with the existing corpus before publication, so a drafter learns of an overlap or conflict while it is still cheap to change. The third is a cross-border gap analysis between two frameworks, with a harmonisation score between 0.0 and 1.0 and a classification of each divergence.

Each analysis ends in a finding. A finding states a claim, quotes the provisions it rests on, and gives a confidence figure computed from the verified citations. A bounded loop lets the tool correct itself, for example when a quotation fails the check, and stops after a set number of attempts. If it still fails, the tool reports the failure, not a confident guess.

Coverage and the approval gate

Two features separate a dependable tool from a clever one. The first is coverage disclosure. Each report states how many documents were examined out of the total in the corpus, and where a complete sweep was run, it says so explicitly. A reader of a finding then knows whether silence on a point means nothing was found or nothing was examined.

The second is a hard approval gate. A finding waits for a named expert to approve, refine or reject it, and the wait survives a restart of the system. Nothing publishes in the meantime. The gate matters because errors in regulatory language are costly: a wrongly reported conflict wastes a supervisor’s time, and a missed one lets a harmful overlap persist. A human who owns the conclusion is the only reliable control.

Governing the tool itself

A tool which reads regulation for a regulator is an AI system, and it deserves the controls it helps others design. It needs an inventory entry with an owner and a purpose, a classification before it is deployed, and oversight proportionate to the risk. It needs logs which record what went in, what came out and what the human did. It needs a way to switch it off without a software release, and a fallback path which does not depend on it.

The corpus helps. Regulatory instruments are public documents, so confidential supervisory data is kept out of the tool by design, not by policy. This choice removes a whole class of confidentiality risk and lets the tool serve several supervisors from one corpus. It also keeps the tool honest about its job, which is to help an expert read, and never to replace the expert’s judgement.

One duty, three clocks

A single duty shows how accumulation works. Reporting a security incident appears in PSD-12 for payment system participants, with a 24 hour preliminary report to the Bank and an impact report within a month. It appears again in the draft Data Protection Bill for personal data breaches, with a 72 hour notice to the authority. NAM-CSIRT’s guidelines add a third clock: inform NAM-CSIRT within five hours of classifying a major incident. Each instrument is sensible alone. A firm reading all three needs a table to see which clock starts when, and a supervisor drafting the next rule needs the same table to see what already exists. Software builds this table from the texts in minutes, and a human then decides which overlaps are intended.

What this means for organisations in Namibia

A supervisor evaluating supervisory technology should ask four questions of any vendor. How is each quotation checked against the source? How does the tool state its coverage? Who approves a finding before it leaves the building? What does the tool do when it finds nothing?

A firm should expect its regulators to use such tools, and should keep its own register of obligations by source and date. When a supervisor’s tool and a firm’s register disagree, the quotation decides.