As Per System
A study of system figures that are relied on without anyone being able to check them, from the public record: a national body's system, a council's failed reconciliation, a new Indian accuracy standard, the options a public body has, what we would advise against, and the benchmark we would set.
1. At a Glance
Issue study · From the public record. None of the bodies named here was an IOanyT client, and IOanyT had no part in the events described. All are far larger than the departments, municipal bodies, utilities and boards we write for. We found no public record of an Indian public body, or of a body of our readers’ size, on this issue. Each case is reported in the public record’s own words, without judgement on any body, official, supplier or court.
| Organisation type | A national body’s system, as the trade press reported it, set beside the position of a mid-size public body whose application works out what people owe, are paid or qualify for |
| Size band | The cases: a national body, a large council and the US federal government. Our reader: a state department or directorate, a municipal corporation or council, a public utility, a board or authority, or a public-sector undertaking |
| Region | The cases: UK and US, with one Indian rule. The reader: anywhere |
| The decision at stake | How a body answers for the figures its system produces: trust the system, audit a sample of its outputs, or write down the rules it applies so that its own officers can judge them |
| The public outcome | A large UK public body ran a supplier-built system, more than 25 years old, which the trade press reported in 2025 performed poorly while its figures were relied on; the same reporting said it may now run into the 2030s |
| Why it matters to a mid-size public body | A body whose system works out arrears, fees, pensions or eligibility relies on rules that were written into code over years. If nobody can show the rule behind a figure, a disputed figure can only be answered by repeating it |
2. The Business Problem, in the Buyer’s Words
“When a figure is questioned, my officers tell me the amount is as per system, and I have no way to look behind that. Our IT cell can trace one figure if I give it a few days, and then only one person knows the answer. An audit observation last year told us the system was charging a rate we had withdrawn. I do not know what else it applies that we did not intend, and I would rather find out from my own officers than from an auditor.”
These words are imagined. They describe the decision as the research shows it, not a real conversation.
The body is caught between figures it must stand behind and rules it cannot read, because nobody has written down what its system actually calculates.
3. What We Found
Method. We went through the public record on systems whose figures were relied on: reporting in 2025 on a large UK public body’s system, reporting in 2026 on a large UK council’s finance system, the US national auditor’s July 2025 report on the most critical federal legacy systems, and India’s Digital Personal Data Protection Rules, published in the gazette on 13 November 2025. The sector research behind this study holds no Indian public body and no body of our readers’ size on this issue, and no figure for how often a system’s calculation is wrong.
A system relied on over people. A large UK public body ran a supplier-built system, more than 25 years old, which, as the trade press reported in 2025, performed poorly while its figures were relied on. We report the case as the press gave it and add nothing to it. We do not name the body or its supplier, we do not say what the fault was, and we pass no judgement on the body, its officials, its supplier or any court. It is a national body’s system, far outside IOanyT’s kind of work.
A system expected to retire. The same reporting said the system may now run into the 2030s, later than its planned replacement. That is a possibility, not a fixed date.
A function that failed. A large UK council replaced its finance system with a packaged product. Custom changes included a reconciliation function that failed, and the council could not produce auditable accounts. A packaged finance product is not IOanyT’s kind of work, and its makers are not named here.
Decades of amendment. The US national auditor reported in July 2025 that the 11 most critical federal legacy systems are “about 23 to 60 years old”. Some are written in languages and run on machines that are not IOanyT’s kind of work.
A standard on the way in India. 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). It is to be “done following the standards specified in Second Schedule”, which include “reasonable efforts to ensure the completeness, accuracy and consistency of personal data”. Rule 5 “shall come into force eighteen months after the date of publication”: about 13 May 2027. 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. The rules speak of personal data, not of calculations, and say nothing about old systems.
Our reading of why figures are trusted without being checked. These four are our reasoning from the record above. None is a finding of any source, and none is a statement about the national public body.
- Nobody can show the rule behind a figure. The rules are in the code. When a figure is questioned, the only check available is to look at the system again.
- The system has drifted from the orders it applies. Rules are amended one at a time, in one place at a time, and nobody compares the whole with the orders.
- A change can alter a calculation nobody meant to touch, and there is no written rule to check the result against.
- Doubt has no procedure. A printed figure outweighs a person’s word, and each dispute is handled alone.
What this record does not show. The record we used on the national public body is one sentence: it does not say what the fault was, how it arose, how it came to light or how many people were affected, and we say none of these. The council case concerns a packaged product, and we did not examine why the function failed beyond what the source gives. The US figure describes federal systems far larger than any body we write for. The data protection rules come into force about 13 May 2027, bind the State and its instrumentalities with the exemptions stated, and do not mention calculations or old systems; whether a calculated figure is personal data within the accuracy standard is a legal question we do not answer, and that a body which cannot say what its system calculates will find accuracy harder to show is our reading. We found nothing from India on the problem itself, nothing from the Middle East, and no figure for how often a system’s figures are wrong; we do not suggest it is common. This study does not claim that any mid-size public body has suffered what is described above.
4. The Options a Body in This Position Had
| Option | When it fits | What it risks | Our view |
|---|---|---|---|
| Trust the system, and answer a disputed figure by checking the system again | The system applies few rules, rarely amended, and its figures are rarely questioned | The system agrees with itself; a wrong rule is confirmed as often as a right one, until an auditor finds it | Right only for a simple system with known rules |
| Ask the IT cell or supplier to trace each disputed figure as it comes | Disputes are few, and someone who knows the code is still there | Days per question; the answer stays with one person; a fault behind many disputes is seen one at a time | A stopgap, not an answer |
| 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 | Right for one doubt, not for a system |
| Write down what the system actually calculates, each rule traced to the code, for the body’s own officers to judge against what was intended | The system’s figures decide what people owe, are paid or qualify for, and its rules have been amended over years | 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 |
What we would have advised against: for a body in this position, treating a second look at the same screen as a check; settling a disputed figure on the system’s word alone when nobody can say which rule produced it; asking the supplier to vouch for its own work as the only evidence of what the system does; and replacing the system before its rules are written down, which carries the old rules into the new system unread.
5. Our Recommendation, and the Decision It Asks of the Board
For the applications a body built or had built that work out what people owe, are paid or qualify for (property tax and utility billing, pension and payroll applications, licence and permit registers, grievance and case-management systems): write down the rules the system applies, starting with the calculations that decide what people are charged, paid or allowed. Each rule goes into plain language and is traced to the place in the code where it is applied. The body’s own officers, in the section that owns each rule, then decide whether it is what was intended, and what to do about any rule that is not. IOanyT records nothing about whether a rule is right. Once the rules are written, the body’s own team can check each later change against them, by hand or with tests it adds. What a body does about past cases touched by a wrong rule is for the body and its legal advisers.
The decision it asks of the board: approve a fixed-price assessment of the application whose figures the body most relies on, and name an officer in each section who will read its rules. The body stops answering disputes with “the system shows it”, and starts answering them with the rule.
6. Benchmark: Where You Are Now, and Where You Should Be
These are targets, not results. In an engagement the starting points are replaced by the body’s own figures, taken in the first review.
| Measure | Typical starting point | Where it should be | How it is checked |
|---|---|---|---|
| The rule behind each figure | In the code only | Written in plain language for each calculation the system makes, traced to the code | The specification |
| Who owns each rule | Nobody named | The section whose order it carries out, as the body names it | The specification, with the owners the body names |
| 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 |
| How a disputed figure is answered | ”The system shows it” | With the written rule behind it | The body’s own record of disputes |
| How a change is checked | Tried by hand on the cases it was meant for | Checked against the written rules it touches, by the body’s own team | The body’s own release record, set against the specification |
| Rules nobody can explain | Not known | Listed, each put before the owning section | The risk register |
7. How IOanyT Would Work
- We listen: a free Reliability Review. A first conversation about the figures the body’s system produces, the ones that are questioned and the orders behind them. 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 study is an example of that work.
- We read the system and propose: the Legacy System Specification Assessment. Here the system is the application that works 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: each rule the system applies, in plain language. 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.
- If you approve, we build. For this issue our offer is narrower than a rebuild: it ends with the written rules and the body’s 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.
8. What the Client Would Own
- The map and the specification: each rule the system applies, in plain language, traced to the code. The body owns it and can show it to any supplier, subject to its own contract with its present supplier.
- The risk register: among its entries, the rules nobody could explain, each listed for the section that owns it.
- The cost comparison and the staged plan: produced by the assessment, for a body that later decides to replace a part. Taking them further is the body’s separate decision.
- The filled-in benchmark: each measure, where it started and where it stands.
Where the body separately decides to replace a part: the traceability matrix for each rebuilt module, and the rebuilt code, which is the body’s. The officers’ judgements on each rule, and any decision about past cases, are the body’s own record.
9. What This Approach Does Not Cover
- IOanyT does not investigate past errors or past cases, and does not decide who is right in a dispute between a body and a person.
- IOanyT is not an expert witness and gives no legal advice, including on the data protection rules: what they require of a body is for its lawyers.
- IOanyT does not interpret an order, a rule or a law, and does not decide which version of a rule is right.
- IOanyT does not say that a system or a result is correct. It writes down what the system does; the body’s own officers judge it. A written rule makes a system checkable, not right.
- IOanyT does not add tests, maintain the system, keep its written rules current or run its releases in this offer; the body’s own team does.
- IOanyT’s published terms on handling cover code and system access during the assessment, not citizens’ records.
- IOanyT does not implement packaged finance products, and does not work in COBOL or assembly language or on mainframes.
- IOanyT does not say it is empanelled, registered or approved as a supplier to any government, or that it meets the conditions of any tender. It gives no advice on procurement rules.
- This study does not say IOanyT would have prevented or uncovered the events described. IOanyT has no published case of this work for a public body.
About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.
10. Sources
| Source | Used for |
|---|---|
| Trade press, 2025 | The UK national public body’s system: the one sentence reported, and its age |
| Trade press, 2026 | The large UK council: the reconciliation function and auditable accounts |
| US Government Accountability Office, GAO-25-107795, 17 July 2025 | The age of the 11 most critical federal legacy systems |
| India, Digital Personal Data Protection Rules, 2025, gazette of 13 November 2025 | Rule 5, the Second Schedule’s accuracy standard, and the date of coming into force |
| India, Digital Personal Data Protection Act, 2023 | The exemptions in section 17(2)(a) and 17(4) only |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We write down what your system calculates, so that your own officers can answer for every figure with the rule behind it.
Read the research notes on 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 2
Nobody Has Set Your System Beside the Rules It Was Built to Apply. Three Ways to Check, Weighed.
Public systems drift from the orders they apply and nobody compares the two. Three ways to check what a system calculates, and a new accuracy standard.
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.