The Case of the Month

By the early 1990s, the US Department of Defense (DoD) had a problem that will sound familiar to anyone who has worked with a large organisation’s legacy systems: it had too many systems doing essentially the same thing.

The DoD had inherited a collection of systems developed independently by different parts of the organisation. As this was the early days of computing, groups based in different locations had created a multitude of good, homegrown IT systems that met local needs. These were built on a variety of technology stacks with many types of hardware and software with systems often “growing” organically.

Early in my data management career, I was part of a team brought in to understand these systems and help the DoD determine how they could be consolidated. By this point, 37 systems were involved in paying DoD personnel. They all worked, but we needed to decide what should happen to enable the organisation to manage them as a whole.

For example, a Pentagon manager might want to know how many employees worked at a particular location. This sounds like a straightforward question, but the answer depended on what each system meant by ‘employee’. A significant proportion of the DoD workforce had more than one job within the organisation. Different payroll systems handled these arrangements differently: one system might count people by counting paychecks, while another might treat the primary and secondary jobs differently. The resulting numbers could therefore be different without either system necessarily containing an obvious error, and the systems could be answering different questions while appearing to answer the same one.

This became particularly important when the DoD needed to decide which of its existing systems should provide the basis for a more consolidated approach. The 37 systems had similar purposes and, when their processes were compared, they looked remarkably similar. Process models showed the same basic pattern: personnel information went in, it was processed, and pay was produced.

Process analysis therefore did not provide a useful way of distinguishing between the systems. We needed to look somewhere else: at the data.

What Actually Happened?

Our team was asked to reverse-engineer selected legacy systems. Rather than starting with the documentation describing what a system was supposed to do, we examined the systems themselves to recover the business rules, requirements and data structures embedded within them. This revealed something that the process models had hidden: although the systems appeared to perform the same broad function, they did not necessarily represent the underlying business in the same way.

The distinction became particularly clear when we tested the systems against specific requirements. One memorable example involved a hypothetical but deliberately highly specific employee: a one-legged engineer working in waist-deep water, underneath rotating helicopter blades, on overtime. The point of this unusual example was not that the DoD had large numbers of employees fitting that description. It was that a requirement this specific could expose differences between systems. If a system’s data structures could represent the necessary combination of circumstances, that provided evidence that it could support the requirement. If they could not, the system could be ruled out.

This gave the DoD a way of making a decision based on evidence about the systems rather than on competing claims about which system was best. It also helped address the organisational politics surrounding the consolidation. Each system had people and resources associated with it, and there were understandable concerns about what would happen if a particular system was replaced. A transparent comparison based on agreed requirements provided a more objective basis for deciding which system could meet the organisation’s needs.

Disaster or Near-Miss?

The fact that the DoD could not always answer basic questions about its workforce consistently shows that the fragmented systems were already causing real problems. However, the greater risk arose when it needed to choose a system to take forward. Selecting one based on popularity, existing use, or apparently similar processes could have embedded its limitations into an enterprise-wide system.

By reverse-engineering the data models, we were able to identify differences that the process analysis had missed and test the systems against the DoD’s actual requirements. This meant the consolidation decision could be based on evidence rather than assumption and the underlying weaknesses were exposed before they were carried into the next generation of systems.

Why This Matters Now

Technology has advanced, but this problem hasn’t disappeared. In June 2026, the US Office of Personnel Management announced a $395 million contract with Oracle to modernise federal human-resources systems. The programme aims to consolidate more than 100 separate human-resources management systems across the US federal government into a single platform. The stated case for consolidation includes duplicated systems and functions, inconsistent application of policies and the cost of maintaining a fragmented HR environment.

The scale is very different from the DoD example of the early 1990s, but the underlying question remains relevant: what knowledge about the organisation is embedded in the systems being replaced?

Replacing many systems with one does not automatically create better data. A new system still needs to represent the concepts, rules and exceptions that matter to the organisation. If those things are poorly understood during the transition, consolidation can simply move existing problems into a new system. The DoD experience suggests that understanding legacy data should be part of the modernisation process, rather than something left until after a new system has been selected.

The Data Quality Pattern

This case illustrates a classic Governance Vacuum: systems were developed to meet local needs, but there was insufficient enterprise-level agreement about how the organisation’s data should be defined and represented.

The Practitioner Takeaways

We can take a lot from this case!

Define the question before counting the data. A seemingly simple question such as “How many employees do we have?” may have more than one valid interpretation. Agreeing what is being counted is a prerequisite for producing a useful number.

Don’t assume that systems doing the same job represent the same things. Similar processes do not necessarily mean compatible data. Look at the definitions, relationships and business rules embedded in the data.

Understand legacy systems before replacing them. Old systems may contain years of accumulated organisational knowledge, including requirements and exceptions that are not documented elsewhere. Reverse engineering can help uncover this knowledge before it is lost.

A single system is not automatically a single source of truth. Consolidation can reduce duplication, but data quality still depends on whether the new system represents the organisation consistently and appropriately.

Data models can be valuable evidence when organisations are making decisions about systems. Looking at the data structures helped reveal differences that were not apparent from looking at the processes alone.

The one-legged engineer is more than an entertaining anecdote. The example worked because it forced the team to ask a precise question about what the system needed to be able to represent. Sometimes an unusually specific requirement is exactly what reveals a hidden difference between systems.

The Case of the Month

The unique thing about clinical prediction models is that they aim to directly improve patient care by providing clinicians with personalised information. Yet they can also be treated as public health tools when applied through policy or guidelines. There is no question that these tools should be developed, validated and implemented with rigorous evidence and appropriate standards. However, a recent study identified 125 published articles for clinical prediction models that were developed with unreliable and potentially fabricated data (1). Articles using two datasets for stroke and diabetes were cited nearly 1,800 times, including in 86 review articles and a medical device patent. Three of the articles had evidence they were potentially used on patients.

We are seeing a boom in prediction model research due to interest in AI and the promise of personalised prediction, but AI also provides an easy way to generate data and papers. One place an individual may find data is on the website, self-proclaimed as the “world’s AI proving ground”, Kaggle, which hosts more than 700,000 datasets. Users can freely upload almost any data and receive community incentives such as followers, achievements, medals and rankings. These rewards may spur the uploading of synthetic or unreliable data.

Data provenance, the who, what, when, where, why and how of data is now more important than ever. Trust in the source and quality of data is imperative for developing predictions that aim to directly influence individual health and be applied to populations.

What Actually Happened?

The two Kaggle datasets mentioned here were meant to represent data collected from diabetes and stroke patients. Unfortunately, Kaggle does not require data provenance to be supplied with any dataset, and no information was declared for where these data came from. After investigating the two datasets and assessing them against the international TRIPOD+AI reporting guidelines, no information was found to authenticate either dataset. An important piece of information — whether these supposed patients had haemorrhagic or ischemic strokes and type I or type II diabetes — was not disclosed.

Upon further inspection of the data, patterns appeared which were consistent with fabricated data. For example, the diabetes dataset had a perfect 100,000 patient observations and both HbA1c and blood glucose (important markers of diabetes) had 18 discrete values forming odd, organised patterns (Figure 1). The stroke datasets saw an unexpected and unexplained for shift in the blood glucose distribution at half the maximum patient ID. It also contained 5,110 unique patients, but 72,940 patient IDs were supplied in the dataset, indicating 67,830 patients (if real) were missing and unaccounted for (Figure 1).

Figure 1

Figure 1. Plot A is from the diabetes dataset showing the association between the HbA1c and blood glucose values for 100,000 individuals. Plot .B is from the stroke dataset showing an unexplained change in the distribution of blood glucose values at half the maximum patient ID for 5,110 individuals. Figure adapted from (1)

Issues with these data had been flagged on the Kaggle discussion pages but were dismissed by researchers who declared its use in research as evidence of authenticity:

“These datasets are frequently referenced in machine-learning literature and educational resources for developing and evaluating predictive models. They contain structured health-related attributes commonly used in disease prediction research.” (2)

Disaster or Near-Miss?

Three articles indicated they had used predictions on patients or were going to deploy the model in a local clinic, one article had even been referenced in a medical device patent. While it was not verified if patients were treated based on the predictions, it is nevertheless incredibly worrying. Further, 86 review articles cited one or more of these prediction model articles, indicating they are being passed off in the literature as legitimate. There is no place for medical treatments to be influenced by data that is not fit for purpose.

Only published articles were examined and identification of these articles relied on the authors referencing the Kaggle webpage. More than 600 outputs were identified using these datasets which included books, theses, preprints and conference proceedings. Thus, what was examined is a minimum representation to the extent of this problem, identified from only two datasets. It is very unlikely this is an isolated event, and more datasets and articles are likely being developed or used on patients.

Why This Matters Now

As we move into an era of prediction fuelled by AI, it is more important than ever that data is of sufficient quality. Patient and practitioner facing prediction tools are abundant and must produce predictions that can be trusted to be accurate and lead to improved outcomes. However, regulatory advancements are slow moving. Another recent study examining implementation of prediction models into guideline documents showed only 8 out of 84 guidelines mentioned guidance for prediction models and none of them were comprehensive (3). Not only is there a lack of guidance on implementation, but these tools may not perform as expected. An editorial prompting more oversight of these tools saw 81% performed worse on external data and 43% were recalled within the first 12 months (4). Additionally, from 1,357 FDA examined AI tools, only three examined patient outcomes (5).

The Practitioner Takeaways

The inundation of prediction models and unreliable data leaves us wondering what to trust. What will work? And which data is safe for use? Simply put, we can answer these questions by bringing this back to the fundamental underpinning of science and modern medicine: evidence.

Predictions need to provide evidence that they will improve outcomes. Like drugs, predictions will vary in their efficacy across patients and populations, and we need to follow these tools over the course of their use. Ideally, cluster randomized trials (like drug trials) will provide us with evidence of efficacy. However, retrospective validation studies can be sufficient for implementation into practice, but these paper-based performance metrics are not typically replicated in the real world. We need more evidence both that they do not cause harm and that they do improve outcomes. If it sounds too good to be true, it may just be.

The Data Quality Pattern: The Proxy Trap or The Governance Vacuum?

Two defined issues emerged from these findings. There exists a Proxy Trap where credibility and authenticity was given to datasets because they were used in previous research and are extremely popular. Decision making for the use of data was offloaded to other individuals and assumed to be correct. Yet, no processes for the verification of data and its provenance could be shown leading to a Governance Vacuum, further allowing unreliable data to be treated as authentic. Not only did the repository not require data provenance, but the journals did not either. No individual or institution took sole responsibility for the quality of data. The repository relied on individuals to report data, the individuals relied on journals as a sign of reliability, and journals relied on individuals to be correct, yet none of them were.

Six layers of humans in the research ecosystem failed. The repository, the uploading dataset users, the researchers, the peer-reviewers, the journal editors and review article authors did not require or check data provenance. Roughly 500 researchers, 250 peer-reviewers, 125 editorial decisions, not one of whom stopped to check the reliability or authenticity of the data. Such severe and potentially harmful outcomes could have just as easily been avoided by mandating simple reporting of who, what, when, where, why and how the data were collected. Trust in the source of data is more important than ever in an age where data creation is so easily met at our fingertips. Patients and practitioners deserve transparency to trust the systems they use.

References

1. https://doi.org/10.1186/s12916-026-04981-y

2. https://pubpeer.com/publications/64738FD54017B4FCDB292A6483FDD0

3. https://ebm.bmj.com/content/early/2026/05/28/bmjebm-2025-114164

4. 10.1056/AIe2600807

5. https://doi.org/10.1371/journal.pdig.0001597

What to expect

• Case studies that illustrate the opportunity
• Discussions of open research and practical topics and gaps in the current literature
• Workshops to help individuals & groups spot opportunities for themselves
• Networking opportunities to interact with others passionate about data quality

Keynote Speakers

The conference will feature keynote speakers Tom Redman, President of Data Quality Solutions, and Roger Hoerl, Professor of Statistics at Union College. Both are prominent authors on data quality, with work spanning the statistical and business literature, including Harvard Business Review and Sloan Management Review. They are also Real World Data Science columnists.

Call for abstracts.

Selected papers from the conference will be published in Real World Data Science, providing an opportunity to share practical insights and research with the RWDS community.

The Bayes Centre has a maximum capacity of 50 participants, so those interested in attending are encouraged to get in touch with the organisers as soon as possible.

To submit an abstract contact Rosemary Tate at rosemarytate@gmail.com.

To register as an attendee, click here.

Conference date: 22 October 2026

Location: Bayes Centre, Edinburgh

Abstract deadline: 22 September 2026

The Case of the Month

In a press release dated March 10, 2022, Census Director Robert Santos stated: “Taking today’s findings as a whole, we believe the 2020 census data are fit for many uses in decision-making as well as for painting a vivid portrait of our nation’s people.” The “fit for many uses” clause leads to several questions: for what uses is the census fit? For what purposes is it not? And, perhaps most importantly, was it fit for apportionment of representatives for elections in the United States?

Apportionment is the critically important task of allocating congressional representatives to the fifty states. For apportionment, with its high political consequences, we expect the census to:

1. Ensure that each state is assigned the right number of representatives; and
2. Provide a measure of comfort that the results can be trusted.

These criteria constitute a high bar. But the stakes are high, fully justifying the expectations.

In 2022, we performed an independent review using data available on the Census Bureau website to address the question of fitness-for-apportionment. Our review raised serious concerns about the fitness of the 2020 census for apportionment. In particular, six states appeared to have been assigned the wrong numbers of representatives.

While the events examined here relate to the 2020 US Census, the underlying issue is much broader. This is fundamentally a quality assurance (QA) case, concerning how decision-makers can know that data are fit for their most important intended use. Whether the setting is government, healthcare, finance, research or business, the same challenge applies: data may be useful for many purposes yet still fall short where the stakes are highest.

What Actually Happened?

We collected relevant data from census.gov, including apportionment data—the population count used for apportionment—and estimated miscount rates based on a Census-conducted Post Enumeration Survey (PES).

While the apportionment state populations are counts, performed according to the US Constitution and Census regulations, the PES is a statistically based survey used to evaluate the accuracy of the apportionment count. One hopes that the resulting estimates of miscount rates are small.

There were statistically significant miscounts in fourteen states, and even one should give pause. Fourteen is of enormous concern, especially when compared to zero statistically significant miscounts in 2010.

Importantly, six states—Colorado, Minnesota, Rhode Island, Florida, Texas and Tennessee—receive different numbers of representatives when the estimated corrections are taken into account, i.e. when using the PES population instead of the apportionment population.

There were twenty-one states with large miscounts, with ten states having large undercounts and eleven large overcounts.

Conducting a census is difficult (try simply counting your socks!) and the pandemic added enormous challenges. One should expect problems. Further, as we’ve already noted, the census is used for many purposes. But none of this means that the central issue for representative democracy can be overlooked.

Had each state simply been over- or undercounted by a similar proportion, apportionment issues would likely have been minor. But the state-to-state variation is large, especially compared to the 2010 census. In 2010, estimated miscount rates were tightly clustered near zero, while for 2020 they were much more dispersed, which is especially clear looking at the below chart:

Ultimately, the high state-to-state variation and high miscount rates led to the different numbers of representatives officially apportioned and those projected using PES estimated state populations.

Disaster or Near-Miss?

Quality assurance (QA) asks a deceptively simple question: did the overall effort provide the required quality? Our two fitness-for-apportionment criteria represent a high bar, but in our view the pandemic does not justify relaxing them.

One cannot easily escape our main conclusion: the 2020 Census is not fit-for-apportionment. It appears to fail criterion one—assigning the correct number of representatives to each state—and it most certainly fails criterion two—providing confidence in the results.

The case therefore raises an important question. What safeguards might have prevented or contained the issue before apportionment occurred?

Why This Matters Now

Perhaps more than anyone, we appreciate the leadership, management and operational challenges associated with data quality. Interestingly, the UK also experienced serious problems conducting its 2021 census, and so, frankly, we’re surprised this topic hasn’t generated far more discussion.

The key issue raised by this case is embedded in the Census Director’s statement itself. Data may be “fit for many uses” and yet still not be fit for its most important purpose. That distinction matters in an era of growing reliance on analytics, AI and automated decision-making. The question is not whether data are generally useful. The question is whether they provide the required quality for the decision at hand.

The relevance of the discussion surrounding the Census extends far beyond population counting. National statistics, resource allocation, and research on all kinds of topics all rely on census data for high-consequence decisions, and people expect confidence that the data are fit for their intended use.

The Practitioner Takeaways

Of course, those running the Census should do all they can to “get it right the first time.” This means clarifying the most important uses, setting quality standards, carefully defining key terms, defining counting processes, managing and controlling them well, and making improvements in response to unexpected new circumstances.

The larger goal, however, is “getting it right” and that’s where QA comes in. A pertinent and timely analogy can be made to the introduction of video assistant referees (VAR). Over the last several years, football (or soccer, to Americans) has introduced VAR as a means to provide real-time QA for referees’ decisions. While purists may object that it disrupts the flow of the game, there is little question that it helps get more calls right! After all, even the best-trained and best-rated officiating crews make mistakes.

The implication is clear: If it really matters, you must build an overall quality system that embraces both doing all you can to get it right the first time and effective QA.

The Data Quality Pattern: The Leadership Vaccum

The Leadership Vacuum occurs when the quality system is not up to snuff (that is, efforts to get it right the first time and/or effective QA are missing). In this case the Post Enumeration Survey showed that the first element failed. And the PES itself did not lead to correct apportionment. As we’ve described, the result is a gap between actual and required levels of quality. Exacerbating this, when responsibility for resolving such a gap is unclear, confidence in outcomes is sure to suffer.

Despite the clear challenges that come with creating a census, especially in a pandemic, the bar for apportionment is necessarily a difficult one to clear. The stakes are high, fully justifying the expectations. The enduring lesson is that demanding requirements call for powerful, comprehensive quality programs.

Note: This article has been adapted, expanded and updated alongside the authors from: “Hoerl, R. and Redman, T.C. “Is the 2020 Census “Fit-for-apportionment”? Medium, 24 August 2022. All figures are taken from that article.

Watch the interview

The “Tag and Batch” Heuristic

Rather than reacting to every notification, Piers advocated for a “batch processing” approach to professional development.

• The System: Piers uses raindrop.io to store relevant bookmarks in a monthly repository for the newsletter. Each bookmark is added to a specific monthly collection, and also includes a tag for the newsletter topic it is relevant for. The bookmarks are then pulled together into a coherent narrative once, at the end of the month.

• Curation: Once a week, he performs quick scans of various trusted sources and newsletters he has built up over the years—such as TLDR (AI and Data) for technical updates and The Batch for curated commentary—saving interesting links without immediately diving deep. He advocates for a brief high level assessment at this stage to avoid going down rabbit holes- the risk is spending an unsustainable amount of time in this stage.

• Assimilation: Then, once a month, he calls up the saved bookmarks and compiles them into a coherent story. This can be time consuming but is very worthwhile in terms of understanding. He starts with the first topic, opening up all the relevant links, and thinks through how they are related, how important they are and how best to position them from a narrative perspective. Once the first topic is done, he continues through the rest of the topics, finally pulling out the “top 5 must reads” for the headline links at the top of the newsletter.

• The Benefit: By tagging articles by section (e.g., Ethics, Engineering, Big Picture) at the point of discovery, the final synthesis becomes a task of finding themes rather than hunting for links. And the deeper dive learning happens in a consolidated period once a month rather than spread in an expanding amount of time throughout the month.

Evals and Breadth

The evening concluded with a spirited Q&A that touched on the future of the role of a data scientist. When asked how early-career data scientists should prepare for a world where AI automates code, Piers’ advice was twofold: evals and breadth.

With AI making output generation increasingly easy (whether it is applications or analytical output), the critical question becomes whether or not the output is any good. A crucial capability all data scientists need is the ability to evaluate the output. How do we measure how good it is? How do we build processes that allow us to keep track of this quality measurement? How do we understand whether or not changes we make, cause the system to actually improve?

Separately, AI allows individual engineers, data scientists (and product managers and designers) to do more things. So exploring and expanding your capabilities across different areas - giving yourself more breadth - allows you to stand out if there is increasing downward pressure on team sizes and hiring.

Source Toolkit

Workflow Tool: Raindrop.io for bookmarking and tagging.

The Evolution: Compare our Feb 2020 debut with our April 2026 edition.

Reading List:

• TLDR (AI and Data newsletters);

• The Batch from Andrew Ng;

• Data Science Weekly;

• Import AI from Jack Clark;

• One Useful Thing from Ethan Mollick;

• Benedict Evans newsletter

• Exponential View from Azeem Azhar.

If you have found this helpful, make sure to check out the newsletter here.

The Case of the Month

According to the US Centers for Disease Control (CDC), roughly half of adults in the US have hypertension (high blood pressure). Roughly 60% of these take medication to keep their blood pressure under control.

However, measuring blood pressure turns out to be much more complicated than is widely acknowledged. This leads to the question of how many “false positives” there might be; that is, how many people diagnosed with high blood pressure don’t actually have it.

Blood pressure medication, like all medication, has side effects, and people who don’t actually have high blood pressure shouldn’t be taking these medications. There may also be false negatives – people who are told they have normal blood pressure but are actually hypertensive, which can have extreme and well documented implications. This is why obtaining high-quality data prior to diagnosis and treatment is so critical in addressing this common medical problem.

What Actually Happened?

As noted by Myers and Kaczorowski, different ways of measuring blood pressure produce different results. In particular, the automated devices commonly used in clinical settings, as well as those bought for at-home measurement, are known to be highly variable. For example, one of the current authors experienced an automated reading in a clinic of 138/92, but when measured manually five minutes later, the reading was 123/82.

Manual readings are also subject to tester-to-tester variation. Again, one of the authors experienced a 152/96 manual reading from a nurse, followed by a 122/78 reading by a doctor a few minutes later.

These are not the only issues. In addition to ensuring that the patient is at rest, the American Medical Association recommends seven tips to ensure accurate and consistent blood pressure measurement:

1. The patient’s arm should be held at the same height as the heart.
2. The cuff should be placed on the bare arm, with no clothing between the cuff and arm.
3. The correct size cuff should be used, based on the diameter of the patient’s arm.
4. The patient should not speak, or be spoken to, during measurement.
5. The patient should have an empty bladder.
6. The back and feet of the patient should be supported (e.g., feet not “dangling” from the examination table).
7. The patient’s legs should not be crossed.

Research has been carried out that shows how important cuff sizing is in accurately diagnosing hypertension, especially in overweight adults. The research showed that too-small cuff size resulted in a mistaken diagnosis of high blood pressure in 39% of patients, while 22% of those with hypertension were given false negatives by the automated monitors.

And this is only 1 of the 7 guidelines. In our collective experience, medical personnel frequently do not follow a number of the steps necessary for accurate readings. In fact, in a statistical analysis of stock images in which the subject is measuring blood pressure, including images disseminated by prestigious medical and educational institutions like Harvard Publishing and Oxford University, only 1 in 7 images aligned with all the recommended clinical guidelines. So it is hardly surprising that inaccurate and highly variable measurements are common.

Disaster or Near-Miss?

Taking medication unnecessarily, or not taking medication when it is needed, can have serious consequences, including stroke and heart attack. Modelling data from Canada, Leung et al. found that, “If both systolic and diastolic BP were overestimated by 10 mm Hg, the prevalence of hypertension would falsely increase by 50% to 63%, potentially leading to overtreatment of approximately 3.5 million Canadians.” We suspect that the implications, both for misdiagnosis as well as under-diagnosis, are very serious, and this is at least a potential disaster.

But there is also another angle to consider. The impact this may have on trust in medical results, as well as the implications for population statistics and national and international health interventions, are unknown. As good data are essential for improving health outcomes, especially in more deprived areas (see for example, the Public Health England report ’Tackling high blood pressure From evidence into action’), this prevalence of poor data is especially concerning.

Why This Matters Now

The differences noted previously are of clinical significance. In addition to deciding whether someone should or should not be on medication, there are decisions as to which medications to prescribe, and at what dosages, with one of the authors’relatives having been on three different blood pressure medications at the same time, with serious side effects. Regardless of the expertise of physicians and nurses, inaccurate data will prevent them from making the proper decisions for their patients.

This is also relevant for research – and decisions made based on that research – that aggregates data to inform population-level health programming and initiatives that target hypertension across the globe, like the WHO’s Global report on hypertension 2025: high stakes: turning evidence into action.

The Practitioner Takeaways

For patients, the advice is simple enough: when having your blood pressure taken, insist on medical staff following the recommended protocols. Don’t rely solely on the automated measurement.

But there is also the question of how inaccurate readings impact population data, resource allocation and health outcome measurement on a national and international level. For the data scientist, the key lesson is to make sure data are never taken at “face value,” and to always delve into the “data pedigree,” the details of how, when, where, etc. the data were collected.

In the meantime, medical professionals taking care to follow the guidelines, recognise the issues with BP readings and communicate them clearly to patients, and not giving too much credence to any one measurement, could go a long way to combatting over-treatment and undertreatment, as well as mistrust in results.

The Data Quality Pattern

The fundamental issue here is that clinical decisions are being made based on poor and inaccurate data. But the cascading consequences of poor measurement, both for patient trust and population level outcomes, could be leading to what we at Data Quality Under the Lens call the Metric Mirage: a measure that appears to show success, failure, or progress, but is misleading because it is poorly defined, incomplete, or taken out of context.

With an underlying instability involving questionable measurement accuracy and precision, the pivotal questions around health outcomes and the reliability of the data that backs decisions become paramount. Are the data being used to make and measure medical interventions fit for purpose, or are choices being made based on only the mirage of evidenced understanding?

Data that come from an automated device, or from a trained and experienced healthcare provider, are often assumed to be accurate. In the case of blood pressure measurement, they frequently are not.

The Case of the Month

On 15th April the UK government published the Independent Review into Releases in Error, authored by Dame Lynne Owens (the former head of the National Crime Agency). Between April 2025 and March 2026 179 prisoners were freed “in error” in England and Wales, according to the Ministry of Justice. Some of these releases resulted from misplaced warrants for imprisonment or remand, sentence miscalculations, or the result of mistakes by courts or other authorities, but most were due, essentially, to poor data quality.

The consequences – individuals released into the community earlier than intended – highlight the potential public safety implications of data quality.

What Actually Happened?

In the last few years there has been a sharp increase in the number of prisoners released in error.

These include:

• A convicted sex offender, whose release, caused by paper notes being misinterpreted by poorly trained staff, led to the government’s independent report.
• A high-profile fraudster released due to the court incorrectly recording his 45-month jail term as a suspended sentence.
• A man who had committed serious violent offences and robbery, released due to a clerk failing to properly aggregate multiple sentences.

Although it appears that there has been a downturn in error since the peak of 2024, the report acknowledges that “some releases in error incidents are only identified when a prisoner returns to custody at a later date. Consequently, figures for more recent years may increase over time.” In her report, Dame Lynn states “The fact that the Department’s understanding of the true extent of releases in error is the minimum of what is likely to be the case was not my only point of alarm. The immediate concern I had was that the Ministry of Justice and HMPPS seemed to explicitly accept that the data is not representative of the ‘true’ picture of releases in error and yet had no means by which they were regularly quantifying the level of inaccuracy and therefore the level of extant risk of harm to the public. Without an established level of ‘accepted’ inaccuracy and risk, nor a regular means by which to check this, my concern thus became that the Government has historically and ongoingly accepted an outstanding and unquantifiable risk to the public.” In short, the crisis was two-fold: not only were dangerous prisoners being released in error, but the data intended to track these failures was so fundamentally flawed that the true risk to public safety remained hidden and unquantifiable

Disaster or Near-Miss?

Some of the prisoners who were released in error handed themselves back in. But, in some cases, the error of their release was only identified as a result of their committing a new offence. There are likely more unlawfully released prisoners that we don’t yet know about.

Why This Matters Now

This case reveals failures at two levels. At the operational level,low staffing, inadequate training and poor morale, within what has been described as a “highly challenging operational environment,” are leading to errors in how information is recorded or interpreted. At the systemic level, there is insufficient visibility into how and when these failures occur. Together, these issues show that a digital-first strategy cannot succeed on a foundation of “fragmented information”. Without skilled human oversight to verify facts, there is a risk that systemic problems will be automated rather than resolved.

The Practitioner Takeaways

The report highlights understaffing and low morale as key contributors to failure, yet the government’s response – only £8m in funds allocated for additional staff, but £82m allocated for a digital overhaul – prioritises digital investment over workforce capacity. That imbalance matters: if previous moves toward computerisation have coincided with declining system integrity, it suggests the issue is not simply tooling, but the capacity of people to manage and validate the data those tools depend on.

For practitioners, there are some clear takeaways to avert similar disasters:

• Don’t just track outputs; measure uncertainty—missing data, overrides, corrections, and inconsistencies. If you can’t see where errors arise, you can’t manage them.
• Design for verification, not just speed. Build checkpoints that prevent unvalidated data from flowing downstream.
• Ensure staff have the time and training to exercise judgement, not just act as a procedural step.
• Regularly trace records back to their origin, especially where legacy or paper systems are involved.
• Make data quality visible. Surface error rates and data gaps alongside performance metrics so trade-offs are explicit.

The Data Quality Pattern

This case is an example of what we at Real World Data Science refer to as a Metric Mirage. Leadership accept and rely on data they know is unrepresentative because they have no means of quantifying the true scale of failure. This happens when fragmented, often paper-based, records are treated as reliable digital data without being properly verified. As systems become more complex, human judgement and professional curiosity are increasingly displaced by the pursuit of speed and automation. This doesn’t fix the underlying errors; it simply hides them, allowing a Silent Drift in accuracy to continue unchecked until a high-profile tragedy forces a review.

Our prisons remain in crisis, and there is no quick fix.

It is therefore right that the government has accepted Dame Lynne’s findings and is moving swiftly to strengthen training, support and oversight for frontline staff. But lasting progress will depend on whether prisons are given sufficient, experienced staff with the time, tools and confidence to calculate sentences accurately. New systems and simpler rules will help but, when there is underinvestment in the people responsible for data quality, no amount of digital transformation will fix the problem— failures will simply be scaled more efficiently.

Digital Sovereignty, The Five Paradoxes of AI Adoption and the Pilot Trap

Brown begins by setting out the conditions that underpin what he terms ‘digital sovereignty’. Rather than framing sovereignty in narrow political terms, he defines it practically, arguing that any nation seeking to benefit from AI must secure three core levers: sufficient compute capacity, access to appropriate data, and effective systems of oversight. This framing is helpful both for its clarity and for grounding often abstract debates about AI leadership in tangible capabilities. In the same early chapters, Brown provides accessible definitions of the main categories of AI, striking a careful balance between technical accuracy and readability for those without deep specialist knowledge.

One of the most compelling contributions of the book emerges early on, when Brown introduces the five paradoxes confronting UK leaders attempting to adopt AI at scale. Among these, the tension between centralisation and local adoption stands out. The balance between national consistency and local accountability - often caricatured as the choice between coherence and the ‘postcode lottery’ - is a familiar problem in public policy, and Brown articulates it with clarity. These paradoxes recur throughout the book, acting as a lens rather than a checklist, and they help explain why well‑intentioned initiatives so often struggle to move beyond initial success.

Brown’s exploration of the UK’s digital past reinforces this point. Drawing on a range of examples, he highlights the persistence of what he calls the ‘pilot trap’: the tendency to celebrate high‑profile demonstrators while failing to deliver equivalent capability at scale. The lesson is not that pilots are misguided, but that scaling is a fundamentally different challenge, requiring institutional commitment, procurement maturity, and sustained leadership. This section is particularly effective in drawing practical lessons rather than offering retrospective criticism.

Making AI Work: Institutions, Skills and Governance

Turning to the present, Brown shifts his focus to what must change if AI is to deliver real value now. He groups the core challenges into three interconnected themes: institutional change, workforce upskilling, and governance. Importantly, ‘institutional’ here extends beyond government. Brown treats business, industry, and civil society as active participants in the national AI ecosystem, each needing to adapt if progress is to be collective rather than fragmented.

The discussion of workforce upskilling is especially strong. Using concrete examples from the NHS, financial services, the creative industries and government, Brown shows how AI skills requirements differ by sector while sharing common obstacles. These case studies exemplify one of the book’s key strengths: its grounding in real‑world experience rather than abstract aspiration. Brown does not shy away from the barriers to upskilling, including structural inequalities related to gender, ethnicity and geography, and he situates skills development firmly within a broader transformation strategy rather than treating it as a standalone intervention.

Governance and ethics are addressed with similar pragmatism. Rather than rehearsing familiar warnings, Brown draws on practical experience to suggest specific actions that align oversight with innovation. The result is an approach that recognises risk without allowing it to become an excuse for inertia.

A Strategy for What Comes Next

The final section, ‘What comes next’, is framed not as speculation but a proposal, even an exhortation. Brown compares the UK’s position with that of other countries - supported by a useful appendix - but repeatedly stresses that imitation is not a strategy. The UK, he argues, must develop an approach that reflects its own institutional strengths and constraints. He then sets out a phased programme covering governance, procurement, infrastructure, skills, and international positioning, before returning to the human dimension by examining what leaders themselves must do differently.

Who Should Read This Book?

I found the book both accessible and grounded in hard‑won experience. It would serve well as a primer for leaders, advisers and informed members of the public who want to move beyond slogans and understand how AI transformation happens. In bringing together clear analysis, original insights and practical recommendations, Brown offers a persuasive and constructive roadmap for making AI work for Britain, and I commend it to anyone concerned with how the nation will navigate its AI future.

Watch the discussion

Takeaways at a glance

• Reusability – rather than just reproducibility – of code and methods is the next frontier.
• Digital twins have huge potential but are still in an early, exploratory phase.
• New tools (especially coding tools) are lowering barriers to entry and improving communication of complex ideas.
• The rise of “vibe coding” and similar approaches is dramatically increasing development speed.

Key themes and analysis

From reproducible to reusable data science

Rhian highlights an important shift: reproducibility (being able to rerun someone else’s work) is becoming baseline, while reusability (adapting and building on it) is where the real value lies.

This reflects a maturation of the field when you consider that reproducibility supports verification and confidence (“can we trust this result?), where reusability supports acceleration and scale (can we take this and build on it?) The implication is that tooling, standards, and culture should increasingly prioritize modular, well-documented, interoperable outputs. “Clever but opaque” solutions become less valuable; simplicity and interface design become more important and standardisation becomes a force multiplier.

Acceleration through tooling, but not automation without expertise

Janet is excited about the speed gains from modern tools, including AI-assisted coding (“vibe coding”), but is careful to frame this as augmentation of experts rather than unregulated democratisation. In the hands of experts, new tools can lead to exponential productivity. In the hands of non-experts, they create a real risk of misuse.

This reinforces a key tension in modern data science, where an influx of new tools are making it easier to build solutions, but not necessarily easier to build correct solutions.

Lowering barriers to communication

Beyond technical productivity, tools are also improving how data science is communicated, making complex ideas more accessible, supporting scientific communication and bridging the gap to general audiences

Digital twins as an emerging frontier

Edith mentions digital twins — a high-potential but not yet fully realized concept that would allow for replicating real-world systems digitally, and enabling simulation, testing, and prediction at scale.

A digital twin is a continuously updated simulation of something real — a machine, a city, a supply chain, or even a human system — fed by real-world data. Moving far beyond a typical static model, a digital twin provides a live, evolving digital model of a real system that you can test against, experiment on, and optimise without touching the real thing. This means that instead of asking “what is likely to happen?” you can ask “what happens if I change this in the real system?”, shifting from prediction to experimentation.

Applications of the digital twin concept are already emerging in manufacturing and industrial systems (simulating production changes before implementing them) and urban planning (simulating effects of new housing developments or managing congestion manually). At a more advanced frontier, digital twins could be used in a healthcare context to simulate how a patient responds to treatment, test the effects of drugs before prescribing them, or even to plan surgeries using personalised anatomical models.

For now, the concept is promising but the practical frameworks, standards, and widespread adoption are still evolving.

Real-time responsiveness as a new capability

A key implication of faster data science workflows is the move toward real-time or near real-time responsiveness. Where analysis once took days or weeks, improved tooling and reusable components now allow teams to identify and respond to new patterns much more quickly. For example, emerging fraud patterns can be detected and addressed without building solutions from scratch.

As a result, latency — the delay between observing and acting — becomes increasingly important, and iteration cycles become more continuous. Rather than producing insights at fixed intervals, data science is more closely embedded in ongoing decision-making.

Overall, this reflects a shift from batch-style analysis to more responsive systems, where value depends on how quickly insights can be turned into action.

An inflection point

Hearing what our panel is most excited about at the moment makes clear that data science is at an inflection point. Technically, the field is accelerating rapidly, driven by advances in tooling and AI. In practical terms, there is a clear shift toward reusability, greater speed, and more real-time application of methods and models. At the same time, there are increasingly urgent social considerations, particularly around ethics, communication, and governance.

Taken together, these trends point to a broader change in where value lies. The most significant gains are unlikely to come solely from developing better algorithms, but from how effectively those algorithms and methods are reused, communicated, and deployed in a responsible way.

We want to hear what you’re most excited about, so get in touch.

Watch the discussion

Takeaways at a glance

• AI is built on statistical thinking – even when it’s not labelled that way.
• Job titles change; core skills don’t.
• Statistics sometimes undersells itself by focusing on mechanics over impact.
• Communication and visualisation are central, not peripheral, to modern statistical work.
• Kindness, collaboration, and trust are professional assets.
• The future belongs to skill-based identities, not title-based ones.

Key themes and analysis

The “rebranding” meme

The panel opens with a familiar joke: take statistics, put a new frame around it, call it machine learning or AI, and suddenly everyone pays attention. It’s humorous—but revealing.

Many roles advertised today as “AI” or “data science” positions are deeply statistical at heart. They involve modelling uncertainty, validating assumptions, managing bias, evaluating performance, and interpreting results. In other words: core statistical competencies.

Rather than resisting this relabelling, the panel suggests recognising it as part of the natural evolution of fields. The key question becomes not “What should we call ourselves?” but “What value are we delivering?”

Identity versus skills

One of the strongest messages from the discussion is this: don’t over-identify with a job title.

“Statistician,” “data scientist,” “AI specialist” are all potentially transient labels, whereas the skills underpinning them remain the same:

• Framing problems carefully
• Questioning assumptions (“Are you sure? Are you sure-sure-sure?”)
• Quantifying uncertainty
• Designing analyses that are robust and defensible

The panel suggests that the healthiest professional stance is to focus less on identity and more on what you can do and what you care about.

The communication gap: loving the sausage-making

Statisticians, the panel observes, sometimes make things harder than they need to be—at least in how they explain their work.

“We’re too interested in the mechanics,” one panellist notes. “Nobody cares how you made the sausage.”

This doesn’t mean rigour is unimportant. It means that impact must lead the narrative. Instead of focusing first on models, methods, and diagnostics, statisticians might begin with:

• What problem was solved?
• How did this make life easier, safer, or better?
• What decision did this enable?

AI has been marketed effectively because it is framed in terms of transformation and possibility. Statistics can claim that space too, without sacrificing integrity.

Visualisation and bringing data to life

Visualisation is a key bridge between statistical thinking and real-world impact. Good visualisation:

• Makes uncertainty legible
• Builds trust
• Enables decision-making
• Tells stories grounded in evidence

In a world flooded with dashboards and generative outputs, the ability to present data clearly and responsibly is not a soft skill. It is core infrastructure.

Trust, collaboration, and professional culture

People want to work with statisticians they trust, which flows not only from technical competence but from clarity, openness, and collaboration.

As AI systems become more powerful—and more controversial—the professionals who can explain, contextualise, and responsibly deploy them will be in

From background discipline to visible foundation

If AI continues to evolve—as it surely will—so too will the labels attached to those who work in it. But uncertainty, inference, modelling, and critical thinking aren’t going anywhere.

We would love to receive contributions to the site that tackle this issue.

Is statistics undervalued in the AI conversation, or quietly thriving?

Where, in your experience, does statistical thinking most visibly shape AI work?

And where is it least acknowledged?

Have you seen statistical work rebranded as AI in your organisation?

We are actively seeking submissions on these topics so, if you would like to be part of the conversation, get in touch.

Watch the discussion

Takeaways at a glance

• Innovation and regulation are not opposites – both are essential, but difficult to balance.
• Responsible progress requires proportionality – not all AI applications carry the same level of risk.
• Transparency enables better governance – open dialogue between developers and regulators is key.
• Risk-based frameworks provide structure – distinguishing low-, high-, and unacceptable-risk uses helps focus oversight.
• Global disparities complicate regulation – some regions are regulating advanced AI systems, while others are still building foundational capacity.
• Innovation needs protected space – experimentation, iteration, and even failure are critical before formal standardisation.

Key themes and analysis

Proportional regulation through risk

Not all AI systems pose the same level of harm. A risk-based approach — distinguishing low-, high-, and unacceptable-risk uses — offers a practical middle ground. It avoids blanket restrictions while ensuring stronger oversight where impact is greatest. The debate becomes less about whether to regulate, and more about how proportionate that regulation should be.

Transparency as common ground

Openness can bridge the gap between technologists and regulators. Clear communication about capabilities, limitations and risks enables more informed policy decisions. When innovation happens transparently and in dialogue with regulators, governance can evolve alongside technology rather than lagging behind it.

The global unevenness of AI governance

AI regulation is developing unevenly across regions. While parts of the West are formalising frameworks, many countries are still building foundational AI capacity. This raises difficult questions about sequencing: should regulation lead innovation, or follow it? A one-size-fits-all model may not reflect global realities.

Protecting space to experiment

Innovation requires room to test, iterate and occasionally fail. Early experimentation should not be overburdened with rigid controls — but successful, scalable systems must eventually transition into more standardised and regulated environments. The challenge is designing pathways that support both creativity and accountability.

Looking ahead

As AI continues to evolve, the balance between innovation and regulation will remain dynamic — and contested. This conversation opens up important questions, and we would love to hear our readers’ thoughts about how we move some of the principles mentioned in the video into practice.

• How do we facilitate transparent channels of communication between those developing AI and those designing the regulatory frameworks that will govern it?
• What should determine whether an AI system is low, high, or unacceptable risk?
• How do we define a “safe speed” for AI development — and who gets to decide?

We are actively seeking submissions on these topics so, if you would like to be part of the conversation, get in touch.

From Governance Principles to Technical Work

Colorado’s law followed a pattern increasingly visible in global AI governance, particularly the European Union’s AI Act. These frameworks share a risk-based logic in that systems that influence consequential decisions face higher expectations for transparency, oversight, and accountability.

At a high level, these expectations (fairness, consumer protection, responsible use) sound abstract. In practice, they translate directly into technical work:

• Clear documentation of model purpose, training data, and limitations
• Records showing where data comes from and how it changes over time
• Reproducible experiments and versioned artifacts
• Ongoing monitoring for performance drift and unintended impacts
• Defined processes for human review and intervention

None of this lives in legislation. It lives in scripts, workflows, dashboards, deployment systems, and operational infrastructure.

Colorado’s stalled implementation of AI policy surfaced a familiar pattern, as many organizations are well equipped to optimize model performance, but far less prepared to operationalize accountability at scale. The friction emerged not because governance goals were controversial, but because the supporting technical infrastructure was uneven.

Why Uncertainty Becomes a Design Risk

One challenge Colorado encountered was definitional ambiguity. For example, what qualifies as “high risk”, what safeguards are sufficient, and how should harms should be assessed? These questions are not merely legal - they are technical and context dependent.

Different data sources, deployment approaches, and users lead to different answers. For teams building data systems today, that uncertainty creates risk. When teams cannot easily see how data moves through a system, how models change over time, or how decisions are produced, adapting later becomes costly and disruptive.

Recent federal signals add another layer of complexity. President Trump’s executive order discouraging state-level AI regulation aims to reduce fragmented policy on AI, but it does not replace state experimentation with a concrete national policy. Teams now operate in a moving landscape shaped by state initiatives, evolving federal priorities, and international regimes like the EU AI Act. In this environment, aiming for minimal compliance is risky. Teams are better served by designing systems that are flexible and easy to observe from the start.

Responsibility Does Not End at Deployment

A lesson emerging from both policy debates and practice is that accountability does not stop when a model goes live. Responsibility shifts across teams over time, from data scientists to engineers, product owners, operators, and decision-makers.

This challenge is the focus of the Responsible Handover of AI framework developed by Sense about Science, which emphasizes the need for clear transitions of responsibility as AI systems move from development into real-world use. Rather than treating deployment as a handoff to “the business”, the framework highlights the risks that arise when assumptions, limitations, and responsibilities are not carried forward with the system.

For practitioners, this framing maps governance concerns onto familiar operational questions, such as who monitors systems after deployment, which development assumptions still matter in production, how limitations are communicated to users, and what happens when systems are updated or handed over to new teams.

Without explicit handover practices, accountability gaps emerge because responsibility becomes diffuse as systems evolve. From this perspective, many regulatory requirements are not adding entirely new work, rather they formalize practices teams already rely on. This includes documentation that travels with systems, monitoring in production, and clear escalation paths when something goes wrong.

Practical Steps Teams Can Take Now

Regardless of how U.S. and international regulation ultimately settles, many investments pay off immediately while reducing future risk, including:

• Standardizing documentation. Ensure model summaries and data descriptions travel with systems as they move between teams
• Build end-to-end visibility. Version datasets, features, models, and configurations so results can be reproduced
• Instrument monitoring early. Track input drift, unstable predictions, performance decay, and downstream impacts once systems are in production
• Clarify governance workflows. Define who approves releases, who monitors systems, and how responsibility shifts over time
• Translate risk for leadership. Gaps in documentation and visibility tend to come back later as messy, expensive fixes; addressing them early saves time and pain

These practices are not limited to machine learning. Any system that informs decisions can create similar accountability challenges.

Governance Lives in the Data Stack

There’s still no settled agreement on how AI should be governed. But for people building real-world data systems, its implications are already concrete. Accountability increasingly lives in the data stack in how workflows are instrumented, how models are monitored, and how decisions can be examined after the fact.

This is not simply about regulatory compliance. It is about building systems that are transparent, resilient, and trustworthy at scale. Organizations that treat governance as a core technical problem (rather than an external policy constraint imposed later) will be best positioned to navigate whatever regulatory balance ultimately emerges.

Video: What Are the Key Challenges Facing Data Scientists Today?

The Patterns Behind the Problems

Although the challenges raised span technical, organisational, and personal domains, they are connected by a small number of deeper themes that shape modern data science.

Looking Ahead

Taken together, these themes suggest that the biggest challenges in data science are not isolated problems to be solved individually. They are interconnected tensions between speed and rigour, access and expertise, innovation and organisational inertia.

Addressing them requires interdisciplinary, systems-level thinking.

Which of these challenges resonates most with your own experience in data science? How can practitioners use these tensions as inflection points to actively shape the field, rather than simply react to it?

Our Audience:

People working in data science looking for practical insights, methodological rigour and thought-leadership that informs their work and decision-making.

Our Voice:

Authoritative, Trustworthy, Cutting Edge

Our Editorial Sections:

Real World Data Science has four editorial sections. Please read through and consider where your piece would fit best. Each piece we publish needs to be tailored towards the focus of one of these sections.

THE PULSE

News, updates and real time commentary.

Purpose: To respond to current events, trends and debates in the data science world with rigour, insight and relevance.

Content Types: Articles that speak directly to current events/trends/launches

Example Call To Action: Invite readers to share your commentary with their networks as a trusted voice in the space. Invite engagement, discussion and debate over the topics.

APPLIED INSIGHTS
How data science is used to solve real-world problems in business, public policy and beyond.

Purpose: To showcase real-world applications of data science, including hands-on tutorials, project walk-throughs, and case studies from industry, academia, or public service.

Content Types:

• High-quality step-by-step tutorials with code
  
• Case studies detailing a problem, approach, and outcome
  
• Lessons learned from real-world deployments

Example Call To Action: Readers should walk away with something to try.

FOUNDATIONS & FRONTIERS
The ideas behind the impact: the concepts, tools and methods that make data science possible.

Purpose: To deepen understanding of the theoretical and ethical foundations of data science, and to spotlight thought leadership and emerging ideas.

Content Types:

• Think-piece style articles with an engaging angle on methodology, ethics and standards
  
• Interviews with thought-leaders
  
• Data Science Bites - our handy summaries/explainers of academic papers

Example Call To Action: Invite discussion and engagement – pose questions and challenges to the reader.

PEOPLE & PATHS
Strategic reflections on careers, leadership and professional evolution in data science.

Purpose: To explore the evolving nature of data science careers through the lens of experience, leadership, and long-term impact. This section highlights how professionals shape and are shaped by the field—through roles, decisions, and philosophies.

Content Types:

• Profiles of/interviews with senior professionals reflecting on career philosophy and leadership
  
• Roundtables with experts on hiring, mentoring, or organisational design
• Commentary on career-defining trends, such as the rise of AI governance or the shift toward interdisciplinary teams

Example Call To Action: Encourage readers to share our strategic insights with their community.

Use of AI in Submissions

We recognise that LLMs and other generative AI tools are increasingly part of the data science workflow, from code generation and data cleaning to drafting documentation and shaping analysis. We welcome a transparent approach in submissions that have made use of these tools, and ask that authors include a declaration outlining where and how AI was used in the development of their submission. This helps us maintain transparency, uphold standards of reproducibility, and better understand the evolving role of AI in real-world data science practice.

To make your submission, please review our contributor guidelines and email us at rwds@rss.org.uk