← Writing

AI · MBA

Mainframe and the boundary of GenAI competence

Gartner forecasts that more than 70% of mainframe exit projects started in 2026 will fail to produce their intended benefits. The blame it assigns is an overestimation of what generative AI tooling can do. Read as a headline, that is one more failure statistic in a year full of them. Read as an experiment, it is more useful: a clean test of where a model's competence ends and someone else's work begins. Legacy code is close to the worst case you could design for this tool, and the reasons are specific enough to check against the pitch on your desk.

Language models can program. The limit is that the distribution they were trained on and the distribution they are asked to work on have almost nothing in common. And the expensive half of a migration was never the half a model touches.

What the forecast actually says

On 18 June 2026 Gartner published a press release with a sentence that travelled fast. More than 70% of mainframe exit projects initiated in 2026 will fail to produce the intended benefits, due to an overestimation of generative AI tooling capabilities. The named analyst is Alessandro Galimberti, VP Analyst. Gartner's newsroom returns a 403 to automated access, so I am working from three trade outlets that quote the release verbatim: IT-Online, DIGIT and TechEdgeAI. Treat the wording below as reported rather than read at source.

Three qualifiers sit inside that sentence. All three get dropped in retelling.

It is a forecast, not a measurement. There is no published sample, no method, no sampling frame. It is an analyst position built on client contact. That is a legitimate genre, and it is a different genre from a study.

The denominator is narrow. Projects initiated in 2026 — not migrations in general, not the installed base of past attempts, not a rate observed after the fact.

The threshold is soft. "Fail to produce the intended benefits" is not "collapse" and not "get cancelled". A project can land, run, and still miss its business case by a distance nobody wants to write down.

A second number from the same release gets welded onto the first, and should not be. By 2030, Gartner forecasts, 75% of vendors operating in the mainframe exit market will pivot their business models or cease operations. That is a prediction about a supply-side shakeout. Different denominator, different phenomenon. Adding it to the 70% produces a sentence with no referent.

Gartner's own recommendation is narrower and more interesting than "GenAI does not work on legacy". As reported, Galimberti describes a widening gap between the marketing promise of GenAI and its real-world ability to transform and migrate complex legacy code. The recommendation that follows is the half that gets cut: for many mainframe customers, GenAI can be used more effectively to enable modernisation in place than to accelerate migration off the platform. Same tool, different job. Reporting only the first half misquotes the source.

That is a claim about job selection, not about the strength of the instrument.

A circle drawn around a tool

Buffett's frame comes from the 1996 Berkshire Hathaway letter to shareholders: "You only have to be able to evaluate companies within your circle of competence. The size of that circle is not very important; knowing its boundaries, however, is vital." Munger developed it alongside him for decades. It was written about investing, and about the investor.

Move it one step. Apply it to the instrument, not the person.

The useful question about a language model is where its edge sits. That edge is set by the distribution of its training data measured against the distribution of the work. A model trained overwhelmingly on modern, open, well-tested code is inside its circle when it writes modern, open, well-tested code. A mainframe estate sits outside that circle on nearly every axis at once: language, runtime, idiom, era, and the absence of anything to check the answer against.

Three more frames name the specific parts of the problem. Each has an author.

Chesterton's fence. G.K. Chesterton, The Thing (1929), in the chapter "The Drift from Domesticity". The reformer who finds a fence across a road and cannot see why it is there has not earned the right to remove it. He must first go and find out. Every odd line in forty-year-old code is that fence: a workaround for a driver bug, a regulatory requirement from 1987, an ordering that a downstream batch job silently depends on. The fence is still standing. Nobody remembers the road.

Hyrum's Law. Observed by Hyrum Wright at Google around 2011, then named and published in Winters, Manshreck and Wright, Software Engineering at Google (O'Reilly, 2020). With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviours of your system will be depended on by somebody. The consequence for migration is severe and rarely priced. A rewrite that matches the written specification perfectly can still break users. The de facto contract is the observed behaviour: date format, record ordering, response latency, the exact text of an error message that some downstream script parses.

Legacy code is code without tests. Michael Feathers, Working Effectively with Legacy Code (Prentice Hall, 2004). The definition is deliberately blunt, and his method follows from it. Before you change anything, wrap it in characterisation tests that pin down actual behaviour rather than intended behaviour. That names the ground-truth problem exactly. With no tests, there is nothing to compare the model's output against.

Underneath all of it sits a hard ceiling. Rice's theorem (H.G. Rice, Transactions of the AMS 74(2), 1953) says that every non-trivial semantic property of a Turing-recognisable language is undecidable. Functional equivalence of two programs is such a property. In plain terms: "prove that the new system does the same thing as the old one" is not, in the general case, a task you can close with a proof. What remains is differential testing on real traffic: a parallel run. That is calendar time and operating cost, not a model licence.

Put the four together and the shape of the problem appears. The specification is the code. The contract is the observed behaviour. The oracle does not exist. And equivalence cannot be settled by argument.

Why the syntax is the small part

A migration looks like a translation problem. COBOL in, Java out. That framing is precisely what makes GenAI look like the obvious accelerator, because translation is the thing these models visibly do well.

Decompose the work instead. A running mainframe application is at least four things stacked on each other.

  1. Text. Syntax and control flow. Written down, machine-readable, complete.
  2. Behaviour nobody wrote down. Timing windows, batch ordering, retry semantics, the error path that evolved incident by incident, the reason a field is padded a particular way.
  3. Environmental coupling. CICS, JCL, VSAM, DB2, the scheduler, the operator runbook, the job that must finish before the other one starts.
  4. A behavioural contract with everything downstream, in Hyrum's sense, including consumers nobody has a list of.

Only layer one is in the repository. Layers two, three and four exist as consequences, not as artefacts. A model reads layer one flawlessly and can do nothing but infer the rest.

After forty years of amendments, the specification is the code. That is not a metaphor. Whatever document once described intent has drifted from what runs, because every production incident added a branch and every regulator added a rule. The system's real behaviour is the accumulated residue of those changes, and it lives in exactly one place.

Two structural reasons make this the hard case for a model, and both are checkable.

The first is distribution. COBOL is, in machine-learning terms, a low-resource language with distinct logic patterns. That is not my framing; it is stated directly in the 2026 SEDCoT paper, which names the property as the reason general-purpose models show suboptimal correctness on COBOL translation. Competence degrades systematically off-distribution. Here the work is off-distribution in every direction simultaneously.

The second is asymmetry. Generating code that looks right is cheap. Proving that it behaves identically is expensive, and Rice's theorem says the general case has no shortcut. So the part of the work that AI compresses is not the part that costs. You can buy a translation in an afternoon. You cannot buy an oracle.

This is the same shape as the argument in ROI doesn't live in the model. The model is one station on a chain, and the chain here runs: establish ground truth, extract rules, generate code, build tests, run in parallel, cut over, support afterwards. GenAI can eat one station entirely and leave the total cost roughly where it was, because the constraint sits at the stations that never appear in a demo.

What the benchmarks measure, and what they don't

The evidence on this boundary is unusually good for a question this young, and it points in a consistent direction. It also gets quoted badly, so the unit of analysis matters as much as the number.

Start with the easy case. Pan and colleagues published "Lost in Translation: A Study of Bugs Introduced by Large Language Models while Translating Code" at ICSE 2024, out of IBM Research and UIUC. They tested 1,700 code samples across five high-resource languages, using three benchmarks, two real projects and over 10,000 tests. The share of correct translations ranged from 2.1% to 47.3% depending on the model. The team hand-labelled 1,748 bugs into 15 categories of translation error. This is C and Java and Python, with abundant training data and code that already has tests. It is the friendliest possible version of the task.

Now the unfriendly one. COBOL-Coder (Dau and colleagues, arXiv:2604.03986, 5 April 2026) evaluated models on COBOLEval, a COBOL adaptation of HumanEval. GPT-4o reached 41.8% compilability and 16.4 pass@1. Open-source baselines (CodeGemma, CodeLlama, StarCoder2) mostly failed to produce a program that compiled at all. A domain-adapted model reached 73.95% compilability and 49.33 pass@1, and 34.93 pass@1 on Java-to-COBOL where general models scored near zero. The methodological caveat is the important part. These are standalone HumanEval-style functions, not production modules wired into CICS, JCL, VSAM and DB2. If the number is 16.4% on toy functions, it is a lower bound on difficulty for a real estate, not an upper one.

The sharpest result is AgentModernize (Ahmed and Galib, arXiv:2605.17535, 17 May 2026). Naive baselines (single-prompt translation and chain-of-thought) preserved system behaviour in 0.0% of cases, on every scenario and every base model tested. A multi-agent framework built around an explicit intermediate artefact, a Behavioral Specification Graph, extracted 91.2% of gold-standard rules with a best behavioural error of 8.1%. The authors' own conclusion is the one worth carrying: the bottleneck is code generation, not knowledge extraction. Reading is cheap. Proving equivalence is not.

And the direction of improvement is specific. SEDCoT (Entin and colleagues, arXiv:2607.04092, 5 July 2026) reports at least a 12% gain over the prior state of the art. It came from symbolic execution, generated test suites and delta debugging to minimise counterexamples. The thing that moved the boundary was machinery for proving, not machinery for writing.

Meanwhile, the tasks that consist of reading rather than rewriting come out well. Diggs and colleagues (LLM4Code 2025 at ICSE, arXiv:2411.14971) found LLM-generated documentation for MUMPS and IBM Assembly Language Code to be generally hallucination-free, complete, readable and useful against ground truth. Assembly was the harder of the two. Their own caveat deserves equal billing: no automatic metric correlated strongly with comment quality, so there is no cheap way to measure whether the documentation is good other than a human reading it. COBRAIN (EASE 2025) extracted business rules from COBOL at precision 1.0 and recall 0.746 against the rule-based COBREX tool, with F1 0.73 against ground truth versus 0.59. In a comprehension study with 28 participants, over 80% preferred the LLM output.

One more result belongs here, from a different setting. METR ran a randomised controlled trial with 16 experienced open-source developers across 246 tasks on their own mature repositories (arXiv:2507.09089, July 2025). With early-2025 AI tools they were 19% slower, while estimating afterwards that the tools had made them 20% faster. This is not a law about AI and productivity, and METR does not present it as one. It is a snapshot of one context, with a small sample and tools that have since changed. It is the closest available analogue to deep context that lives outside the code, and it carries one transferable lesson. Self-reported acceleration is not evidence.

StudyUnit of analysisResultWhat it does not show
Pan et al., ICSE 2024Code sample, high-resource languages2.1–47.3% correct translations; 1,748 bugs in 15 categoriesAnything about COBOL, or about code without tests
COBOL-Coder, 2026Standalone HumanEval-style COBOL functionGPT-4o 41.8% compilable, 16.4 pass@1; domain-adapted 73.95% / 49.33Production modules with CICS, JCL, VSAM, DB2
AgentModernize, 2026Behaviour preservation across scenariosNaive baselines 0.0%; multi-agent 91.2% of gold rules, 8.1% best behavioural errorThat the extracted rules survive contact with a real cutover
SEDCoT, 2026COBOL translation correctness≥12% over prior state of the art, from symbolic execution and delta debuggingThat scale alone produces the same gain
Diggs et al., 2025Generated documentation for MUMPS / assemblyGenerally hallucination-free, complete, usefulA cheap automatic quality metric — none correlated
COBRAIN, EASE 2025Business rules extracted from COBOLPrecision 1.0, recall 0.746; F1 0.73 vs 0.59; 28 participants, >80% preferredThat extraction equals migration
METR, 2025Task completion time, 16 devs, 246 tasks19% slower with AI; self-estimated 20% fasterA general law; sample is small and tools have moved

The table splits in two. Where the task is to read, describe or extract, the results are good. Where the task is to rewrite and be trusted, the results are poor. They improve when someone bolts on a verification apparatus.

The estate you are holding

Before evaluating a pitch, it helps to know what is being pitched against. The volume figures everyone quotes are weak, and the weakness has to be stated every time they are used.

Two numbers circulate. Reuters, in 2017, reported roughly 220 billion lines of COBOL in use, 43% of banking systems built on it, and 95% of ATM card swipes touching it. That is a journalistic compilation of industry figures with no published counting method. The other is "over 800 billion lines in daily use", which comes from a 2022 Micro Focus survey of 1,104 respondents across 49 countries. That is a vendor measuring perception, not an audit of repositories. Both figures are orders of magnitude, not measurements, and should be labelled as such whenever they appear on a slide.

The audited numbers are better and worse. The US Government Accountability Office reported in July 2025 (GAO-25-107795) that CFO Act agencies identified 69 legacy systems. GAO singled out the 11 most critical: between 23 and 60 years old, costing around $754 million a year to maintain. Eight of the eleven run on outdated languages; Treasury's runs on COBOL and assembler. Seven operate with known security vulnerabilities. Four run on unsupported hardware or software. Only three of the eleven had a complete modernisation plan, and two had none at all.

The IRS Individual Master File is the canonical case. Over 60 years old, written in assembler and COBOL, designed for the IBM System/360. Its replacement programme, CADE, was abandoned in 2009. CADE-2 has still not replaced it and is not expected to before 2030. In March 2025 the IRS told GAO it had paused modernisation programmes while priorities were being revised. That is roughly twenty years of attempts, all of them before GenAI existed.

One commercial reference point for doing it properly. Commonwealth Bank of Australia replaced its core banking platform over five years, at a cost above one billion Australian dollars (around 750 million US dollars at 2017 exchange rates). Hold that number next to any proposal promising a migration in two quarters because the tooling has improved.

One narrative needs correcting, because it is the one most often used to create urgency. "All the COBOL programmers are retiring" is weaker evidence than its confidence suggests, and the best available data points the other way. The BMC Mainframe Survey 2025 is the twentieth edition, with over 1,100 respondents. It found the 18–49 age group rising from 53% in 2018 to roughly 80% in 2025, and Gen Z from 1% to 15%. In the same survey 97% held a positive view of the platform, 93% planned further investment, and only 3% were considering alternatives, down from 10%. Around 75% treated GenAI as a strategic initiative, but only about 30% would allow AI to execute tasks autonomously. That survey polls a mainframe vendor's own customers, so it has an obvious interest in the conclusion "the mainframe is alive". Keep both biases in frame.

The accurate sentence is narrower and harder. What thins out is the number of people who remember why a particular line is there. That is a different problem from a shortage of COBOL programmers, and you cannot hire your way out of it.

There is a figure I would like to put here and cannot. No independent public number exists for the share of mainframe estates carrying meaningful regression test coverage. That is the single most decision-relevant statistic in the whole argument, and nobody has counted it.

Reading a modernisation pitch

The frames above collapse into a short interrogation. None of these questions requires technical depth to ask, and the quality of the answers separates a plan from a brochure.

  1. Where will the ground truth come from? A parallel run on production traffic? Recorded inputs and outputs? Or a specification nobody has seen?
  2. What is the coverage of the tests that already exist — not the ones you intend to generate? If it is zero, who signs the statement that outputs are equivalent?
  3. How will you detect differences that are not functional bugs? Timing, batch ordering, throughput, message formats. This is the Hyrum's Law question, and it is the one that gets answered worst.
  4. Who on our side knows this system? How many people, how many years, and when do they leave?
  5. What is the unit in your benchmarks? A HumanEval-style function, or a production module with CICS, JCL and VSAM? The gap between those two is where most of the marketing lives.
  6. What is the measure of success in the contract? Lines translated, or transactions passing a parallel run without divergence? Only one of those is a business outcome.
  7. Big bang or incremental? With a running original and a path back, or a single cutover weekend?
  8. Which step of the chain does AI actually shorten, and what share of today's budget does that step represent?

Question one carries most of the weight, and there is a cautionary case for what happens when it goes unanswered. Michigan's MiDAS system auto-adjudicated 22,427 unemployment fraud cases between October 2013 and August 2015. The Michigan Office of the Auditor General reported in February 2016 a 93% error rate for appeals filed between October 2013 and June 2015, and 20,965 decisions were subsequently reversed. Tens of thousands of people were assessed quadruple penalties, with wages and tax refunds garnished. MiDAS was rule-based, not machine learning, and calling it an AI failure would be wrong. The pattern is what transfers: automation deployed at scale where the ground truth had never been verified.

The other half of the answer is where GenAI genuinely earns its place in a legacy programme. Gartner's own recommendation, modernisation in place rather than migration acceleration, points at the same set of tasks the research supports.

TaskIs there an oracle?Cost of a wrong answerVerdict
Documenting undocumented modulesHuman review only; no automatic metric correlatesLow — a bad comment gets discardedUse it
Extracting business rules into a reviewable artefactComparable against rule-based toolsLow, if the artefact is reviewed before useUse it, then review it
Generating characterisation tests against the running systemThe running system is the oracleLow — a wrong test fails visiblyUse it; highest value per hour
Impact analysis and dependency mappingPartially checkable against the codeMediumUse it, verify the edges
Wholesale translation of production modulesNone, unless a parallel run existsHigh — silent behavioural driftDo not buy this as the plan
Migrating batch orchestration and timingNothing in the code to check againstHigh, and discovered latePeople, plus a parallel run

The pattern in the right-hand column is the same one Feathers described in 2004. The tool is strong wherever the running system can act as its own judge, and weak wherever a human has to certify equivalence from nothing.

Limits, and the counterargument that matters

Three objections have real force, and a reader with a mainframe estate should hold all three.

One: the boundary moves, and it is moving now. Between April and July 2026 at least three published papers pushed it: COBOL-Coder, AgentModernize, SEDCoT. The Gartner forecast is about projects initiated in 2026, not about a permanent property of the technology. Reading it as a verdict on GenAI is the misreading worth avoiding. There is a more useful version of the claim, and it is falsifiable. The boundary appears to be moving through verification machinery (symbolic execution, generated test suites, delta debugging, explicit intermediate artefacts), not through model scale. If the next large gain on COBOL translation comes from a bigger general-purpose model with no verification apparatus attached, the mechanism argued here is wrong.

Two: most of these failures will have ordinary causes. Flyvbjerg and Budzier, writing in Harvard Business Review in September 2011, studied 1,471 IT projects. The average cost overrun was 27%. But one in six was a black swan, with an average cost overrun of 200% and a schedule overrun near 70%. The distribution is fat-tailed, so the mean tells you nothing about the risk. The TSB migration of April 2018 makes the point concrete. Around five million customers were moved off Lloyds systems in a single weekend. Branch, telephone, online and mobile banking became unavailable for much of a 5.2 million customer base, and fraud attacks ran at 70 times normal levels at the peak. The regulatory fines came to £48.65m (FCA £29.75m plus PRA £18.9m, after a 30% settlement discount; £69.5m without it), alongside £32.7m in redress and a total reported cost of roughly £366m. The independent review by Slaughter and May, published in November 2019, pointed at the scale and pace of the migration and at the failure to assess the main IT supplier's capability. Scope, pace, supplier governance, and a big-bang cutover. No AI involved anywhere. A meaningful share of the projects Gartner is forecasting about would miss their benefits with or without a model in the room. Attributing everything to GenAI hides the causes that were already there.

Three: a competence boundary makes an excellent alibi. "AI cannot do this" does not imply "so we leave it alone", and the slide from the first to the second is the most expensive move available. GAO's eleven systems cost around $754 million a year to run, seven of them with known vulnerabilities and four on unsupported hardware or software. The IRS has been trying since before 2009 and paused again in March 2025. The cost of not moving is measurable, compounding, and larger than the cost of moving carefully. Modernisation in place is a real option. Incremental replacement with a parallel run and a path back is a real option. Another decade of paused programmes, justified by a correct observation about model limits, is not.

There is a fourth limit, and it applies to the anchor itself. The Gartner forecast has no published sample, no method and no sampling frame, and I read it through three secondary outlets because the source returns a 403. It converges with the research above, which is worth something. It is not a measurement, and it should not be quoted as one — including by essays that agree with it.

Closing

Put two questions to a modernisation pitch. Which step of the work does the tool remove? And who signs the statement that the new system does the same thing as the old one? If nobody in the room can name that person, you are not buying a migration. You are buying a translation, and hoping.

Sources

  1. primaryGartner, "Gartner Predicts More Than 70% of Mainframe Exit Projects Will Fail Due to Overestimation of Generative AI's Capabilities" (press release, 18 June 2026) — the 70% forecast, the 75% vendor-shakeout forecast, and the "modernisation in place" recommendation; analyst Alessandro Galimberti. (Newsroom returned 403 to automated access; wording verified through the secondary outlets listed below.)
  2. primaryWarren Buffett, letter to Berkshire Hathaway shareholders (1996) — circle of competence; "knowing its boundaries, however, is vital".
  3. primaryG.K. Chesterton, The Thing (1929), chapter "The Drift from Domesticity" — the fence across the road.
  4. primaryTitus Winters, Tom Manshreck & Hyrum Wright, Software Engineering at Google (O'Reilly, 2020) — Hyrum's Law, observed by Hyrum Wright: all observable behaviours of a system will be depended on by somebody.
  5. primaryMichael Feathers, Working Effectively with Legacy Code (Prentice Hall, 2004) — legacy code as code without tests; characterisation tests pin actual, not intended, behaviour.
  6. primaryH.G. Rice, "Classes of Recursively Enumerable Sets and Their Decision Problems," Transactions of the American Mathematical Society 74(2) (1953) — non-trivial semantic properties, including program equivalence, are undecidable.
  7. primaryRangeet Pan et al., "Lost in Translation: A Study of Bugs Introduced by Large Language Models while Translating Code," ICSE 2024 — 1,700 samples, five languages, 2.1–47.3% correct translations, 1,748 labelled bugs. (arXiv:2308.03109 · DOI 10.1145/3597503.3639226)
  8. primaryA.T.V. Dau et al., "COBOL-Coder: Domain-Adapted Large Language Models for COBOL Code Generation and Translation" (arXiv:2604.03986, 5 April 2026), and P. Entin et al., "SEDCoT: Enhancing LLM-Based COBOL Code Translation via Symbolic Execution and Delta Debugging" (arXiv:2607.04092, 5 July 2026) — COBOLEval results, COBOL as a low-resource language, and gains from verification machinery.
  9. primaryS.N. Ahmed & M. Galib, "AgentModernize: Preserving Business Logic in Legacy Modernization with Multi-Agent LLMs and Behavioral Specification Graphs" (arXiv:2605.17535, 17 May 2026) — 0.0% behaviour preservation for naive baselines; the bottleneck is code generation, not knowledge extraction.
  10. primaryC. Diggs et al., "Leveraging LLMs for Legacy Code Modernization: Challenges and Opportunities for LLM-Generated Documentation," LLM4Code 2025 at ICSE (arXiv:2411.14971), and "LLM vs Rule-Based — The COBRAIN Tool and An Empirical Study on Extracting Business Rules from COBOL," EASE 2025 (DOI 10.1145/3756681.3756982) — documentation and rule extraction results, with the authors' caveat that no automatic metric correlates with quality.
  11. primaryMETR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" (10 July 2025) — RCT, 16 developers, 246 tasks, 19% slower against a self-estimate of 20% faster. (arXiv:2507.09089)
  12. primaryU.S. GAO, "Information Technology: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems," GAO-25-107795 (17 July 2025), and "Information Technology: IRS Is Developing a New Modernization Framework," GAO-25-107611 — the 11 critical systems, $754m annual maintenance, and the IRS Individual Master File timeline.
  13. primaryTSB Bank / Slaughter and May, "Independent Review of TSB's 2018 migration to a new IT platform" (19 November 2019), and FCA, "TSB fined £48.65m for operational resilience failings" (20 December 2022) — scale, pace, supplier assessment, fines and redress.
  14. primaryBent Flyvbjerg & Alexander Budzier, "Why Your IT Project May Be Riskier Than You Think," Harvard Business Review (September 2011) — 1,471 projects, 27% average cost overrun, one in six with a 200% overrun.
  15. secondaryIT-Online, "Overestimating GenAI will see mainframe exit projects fail" (23 June 2026); DIGIT, "Orgs are overestimating GenAI when it comes to mainframe exits" (22 June 2026); TechEdgeAI, "Mainframe Exit Projects Face GenAI Reality Check" (18 June 2026) — three outlets quoting the Gartner release verbatim; the basis for every Gartner quotation above.
  16. secondaryEstate-scale figures, all of them weak, and used above only as orders of magnitude: Reuters via CNBC, "Banks scramble to fix old systems as IT 'cowboys' ride into sunset" (11 April 2017) — the 220bn-lines / 43% / 95% figures and the Commonwealth Bank of Australia cost, a journalistic compilation with no published counting method; The Stack, "There's over 800 billion lines of COBOL in daily use" — the Micro Focus 2022 survey of 1,104 respondents across 49 countries, a vendor measuring perception; TechChannel, "Mainframers Are Getting Younger: BMC Survey" — BMC Mainframe Survey 2025, over 1,100 respondents, vendor-sponsored with a self-selecting sample of that vendor's own customers.
  17. secondaryGovTech, "Michigan Integrated Data Automated System Experiences 93 Percent Error Rate" (on the Michigan Office of the Auditor General report, February 2016), and Ford School STPP, "Cahoo v. SAS — MiDAS explainer" (2024) — 22,427 auto-adjudicated cases, 20,965 reversals; a rule-based system, not machine learning.