Nobody Has Set Your System Beside the Rules It Was Built to Apply. Three Ways to Check, Weighed.
Over the years a public body's system drifts from the orders it applies, and nobody compares the two. We weigh three ways to check what a system calculates, and look at a new Indian standard on the accuracy of the State's data.
An audit observation has reached the department. The licence system is applying a surcharge at a rate that an order withdrew four years ago.
It is doing so for renewals only.
The section issued the order and asked for the change. The IT cell finds that the change was made in the code for new licences. Nobody knew renewals were calculated somewhere else.
The paradox: The department wrote the rules and owns the system, and has never set the two side by side.
What We Found
For this article we went through the public record on how long systems that apply public rules stay in service, and on a new Indian standard of accuracy for the State’s data: the US national auditor’s July 2025 report on the most critical federal legacy systems, reporting in 2025 on a large UK public body’s system, and India’s Digital Personal Data Protection Rules, published in the gazette on 13 November 2025.
First, what we did not find: no measure, for any public system, of how far its rules differ from the orders behind them, no Indian public body on the record with this problem, and nothing from the Middle East.
Systems that apply public rules stay in service for decades. The US national auditor reported in July 2025 that the 11 most critical federal legacy systems are “about 23 to 60 years old”. Some use languages and machines that are not our kind of work. That is a long time for rules to be amended one at a time, in code nobody reads as a whole.
Replacement dates move. A large UK public body’s supplier-built system, more than 25 years old, may now run into the 2030s, later than its planned replacement, the trade press reported in 2025. That is a possibility, not a fixed date, and we make no comment on the body’s decisions. The point we take: a system expected to retire may apply its rules for years more.
In India, a standard of accuracy for the State’s processing is on the way. India’s Digital Personal Data Protection Rules, 2025, published in the gazette on 13 November 2025, cover the processing of personal data “for provision or issue of subsidy, benefit, service, certificate, licence or permit by State and its instrumentalities” (rule 5). Such processing is to be “done following the standards specified in Second Schedule”, and those standards include “reasonable efforts to ensure the completeness, accuracy and consistency of personal data”. Rule 5 is among the rules that “shall come into force eighteen months after the date of publication”: about 13 May 2027.
The rules do not reach every public body, or every duty, in the same way. The Act behind the rules, the Digital Personal Data Protection Act, 2023, makes two exceptions that matter here. Section 17(2)(a): “The provisions of this Act shall not apply in respect of the processing of personal data (a) by such instrumentality of the State as the Central Government may notify, in the interests of sovereignty and integrity of India, security of the State, friendly relations with foreign States, maintenance of public order or preventing incitement to any cognizable offence relating to any of these”. Section 17(4): “In respect of processing by the State or any instrumentality of the State, the provisions of sub-section (7) of section 8 and sub-section (3) of section 12 and, where such processing is for a purpose that does not include making of a decision that affects the Data Principal, sub-section (2) of section 12 shall not apply.” Which of these applies to a particular body is a question for its lawyers.
Our reading: a system drifts from its orders by small steps. Orders change faster than code. One rule lives in several places, on a screen, in a report and in an overnight job, and a change made in one leaves the others. The section cannot read code; the IT cell does not know every order. And a change is tried to see that it runs, not that every path follows the order.
What our review does not show: We found no measure of drift for any system, no Indian public body on the record, and nothing from the Middle East. The US figure describes federal systems far larger than our readers’. The national public body’s date is a reported possibility, and we draw nothing from it about that system’s rules. The data protection rules come into force about 13 May 2027, bind the State and its instrumentalities as stated, with the exemptions above, and say nothing about old systems or about calculations. Whether a figure a system works out, such as arrears recorded against a person, falls within the accuracy standard is a legal question we do not answer. That a body which cannot say what its system calculates will find such efforts harder to show is our reading, not the rules’ own words. The four ways a system drifts are our reasoning too.
What Waits While Nobody Has Compared the System With the Rules
The usual view is that a system follows the orders because each change was requested and closed. Our reading is that several things wait until someone reads what the system actually does.
The department cannot show that it applies its own orders. An amended order is assumed applied because a change request was closed.
Staff correct what they know is wrong, and the department never learns it. A figure known to be off is altered by hand each month, and the fault stays in the system.
Efforts on accuracy are hard to show. Where a standard asks for “reasonable efforts to ensure the completeness, accuracy and consistency of personal data”, a body that cannot say what its system calculates has little to point to. That is our reading; what the standard requires of any body is for its lawyers.
The gap we see: most bodies we write for could produce their orders. Few could produce, beside each order, the rule as the system applies it, in every place it appears, and an officer’s judgement on whether the two match. A body that holds that record can amend a rule and know the change is complete.
This is our reading of the evidence. It is not a measured market figure.
Three Ways to Check What Your System Calculates, Weighed
There are three real options. Each one is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| Trust the system, and act on audit observations as they come | The system applies few rules, rarely amended, and its figures are rarely questioned | A rule applied in two places drifts unseen, until an auditor finds it |
| A one-off audit of outputs: a sample of figures worked out again by hand against the orders | There is a specific doubt about one calculation | It finds wrong figures, not the rules behind them; a sample misses paths; it goes out of date with the next change |
| Write down what the system actually calculates, each rule traced to the code, so the body’s officers can judge it against what was intended | The system applies many rules, amended over years, and its figures decide what people pay, receive or qualify for | It costs money and officers’ time; some rules will have no order behind them; a wrong rule raises questions about past cases, which are for the body and its legal advisers |
Our recommendation: a specification of the rules the system applies, each traced to the code. The body’s own officers then decide, rule by rule, whether each is what was intended, and what to do about any that is not. We record nothing about whether a rule is right, and we do not interpret the orders. Once the rules are written and confirmed, the body’s own team may choose to add tests that report when a change alters a result; that is the team’s own work, not part of our offer here. We give no legal advice on the data protection rules or on any other.
Where You Are Now, and Where You Should Be
Before any work begins we set a benchmark: a few measures taken from your own systems, each with a target. For this issue it would look like this.
| Measure | Typical starting point | Where it should be | How it is checked |
|---|---|---|---|
| The rules the system applies | Known only from old change requests | Each rule written in plain language, as the system applies it | The specification |
| Places each rule is applied | Not known | Every place the reading finds, listed under the rule | The specification, traced to the code |
| The order behind each rule | Not linked | Named by the section that owns the rule, or marked as having none anyone can find | The body’s own record, set against the specification |
| An officer’s judgement on each rule | None | Given by the owning section: what was intended, and whether the rule matches | The body’s own record of decisions |
| Rules nobody can explain | Not known | Listed, each put before the owning section | The risk register |
The starting points above are what we expect to find; in an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a public body.
How We Work With You
- We listen: a free Reliability Review. A first conversation about what your system calculates and the orders behind it. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
- We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
- We read the system and propose: the Legacy System Specification Assessment. Here the system is the application that applies the department’s orders to work out what people owe, are paid or qualify for. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. Here the specification is the part that matters: what the system actually calculates, rule by rule. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
- If you approve, we build. For this issue our offer is narrower than a rebuild: it ends with the written rules and your officers’ decisions on them. If the body separately decides that a part should be replaced, with each rule as its officers decided it, we replace a system one module at a time while the old one keeps running. We never do a single cutover. A traceability matrix links every old function to its replacement. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
- We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.
The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.
What we do not do: we do not interpret an order, a rule or a law, and we do not decide which version of a rule is right or say that a system is correct. We do not investigate past cases, decide disputes, act as an expert witness or give legal advice, including on the data protection rules: what they require of a body is for its lawyers. Our published terms on handling cover code and system access, not citizens’ records. We do not add tests, maintain the system or run its releases. We do not work in COBOL or assembly language or on mainframes. We do not say we are empanelled with any government, and we give no advice on procurement rules. We have no published case of this work for a public body.
What changes for the business:
| Role | What they gain |
|---|---|
| Head of department | The department learns from its own officers, not from an auditor, whether its system does what its orders say. |
| Head of procurement | A system, or a change to one, can be accepted against a written list of rules. |
| Head of IT | A written record of every rule, each traced to the code, which the section that owns it has judged. |
| Head of service delivery | A rule the staff know to be wrong reaches the section that owns it, and is decided there. |
| Head of audit and vigilance | Evidence of what the system does that does not depend on the supplier’s word. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| The US national auditor (July 2025): the 11 most critical federal legacy systems are “about 23 to 60 years old”. | Some use languages and machines we do not work on. For an application on technology we read, we write down every rule it applies. |
| A large UK public body: a supplier-built system, more than 25 years old, which the trade press reported in 2025 may now run into the 2030s. | We make no comment on the body’s decisions, and our part is far narrower: where a system will run for years yet, we write down what it calculates. |
| India’s data protection rules of 13 November 2025: processing “for provision or issue of subsidy, benefit, service, certificate, licence or permit by State and its instrumentalities” is to follow standards that include “reasonable efforts to ensure the completeness, accuracy and consistency of personal data”, from about 13 May 2027. | We give no legal advice and do not say what the rules require of a body. Our specification shows what the system calculates; whether that meets any standard is for the body and its lawyers. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We put what your system calculates into words, so that the people who wrote the orders can set the two side by side.
Sources
In this issue
Wrong outputs trusted as correct
Research note 1
When a Figure Is Questioned, "the System Shows It" Is Often the Only Answer. Here Is What the Public Record Shows.
When a figure is questioned, 'the system shows it' is often the only answer. What the public record shows, four ways to respond and our benchmark.
Research note 3
Every Figure Your System Produces Should Trace to a Written Rule. Here Is the Benchmark We Would Set.
Changes to an old system are checked against memory because its rules were never written down. Four ways to check a change and the benchmark we set.
Issue study
As Per System
System figures relied on that nobody can check: a national system, a failed reconciliation, a new accuracy standard, the options and our benchmark.
More from Government and public sector
Replacement fails or overruns
A Deferred Replacement Is Still a Decision. Four Ways to Replace an Old System, Weighed.
Thin or missing documentation
A New Officer Takes Charge of Your System With Nothing to Read. Three Ways to Change That, Weighed.
Upkeep absorbs the budget