Originally drafted 26 August 2026. First published 7 October 2026; revised for publication.

Consider a hypothetical district programme team preparing a monthly payment run for field workers. Its dashboard shows that hundreds of visits have been completed, but several supervisors know that some of those visits were recorded twice after a mobile form was submitted during a network interruption. The finance team sees a clean total. The data team sees duplicates only after an extract arrives. The people who can explain the exception are already working on the next day’s service.

The usual response is to ask analysts to clean the data before the report is sent. That can rescue a monthly figure, but it leaves the source process unchanged and makes the next report dependent on the same manual intervention. Data becomes trustworthy when an organisation treats its quality as a responsibility within the workflow that creates it, with a visible route to detect, correct and learn from defects. A warehouse, dashboard or AI model can surface a problem; none can permanently repair a record whose owner, meaning and correction path are unclear.

This matters in organisations where evidence travels through field applications, partner portals, spreadsheets, call centres and paper handovers. These arrangements are common in public services, enterprises and development programmes across Africa, often alongside shared devices, intermittent connectivity and teams working in several languages. They are not a reason to lower the standard. They are the reason to build data-quality controls into the operating reality rather than assume that a central team can cleanse uncertainty away.

A clean report can hide an unreliable process

A report can reconcile internally while still misrepresenting what happened. An analyst may remove duplicate rows, fill a missing category or align two codes so an executive view can be produced. Those steps are sometimes necessary, particularly during a transition. But if they are invisible, the organisation loses the signal that its service process, integration or training has failed.

ISO’s published ISO 8000-115:2024 — Master data: Exchange of quality identifiers: Syntactic, semantic and resolution requirements has a specific scope: requirements for quality identifiers used in master-data exchange, including their syntax, semantics and resolution principles. It is not a general methodology for managing, measuring and improving every dataset. An identifier standard also cannot establish that a record is accurate or fit for a particular decision; that judgement still depends on its source, meaning and use.

Fit for a decision is the relevant test. A billing workflow may need complete, current account identifiers. A disease-surveillance team may need timeliness and a clear way to distinguish a zero from a missing report. A lender may need a traceable basis for a credit decision. A board may accept a monthly aggregate, while a service supervisor needs a case-level record before acting today. The same field can be adequate for one purpose and unsafe for another.

Every priority field needs an owner and a consequence

Data ownership is often mistaken for a job title allocated to an IT or analytics unit. Technology teams can operate platforms and define controls, but they cannot decide alone what an incomplete licence record means, whether an address is current, or when a field observation is sufficiently verified for a programme decision. Those questions belong to the service and business functions that use the data.

For a small number of priority records, institutions should make four things explicit: what the field means; who is accountable for its accuracy at the point of capture; which system is authoritative for the relevant purpose; and what happens when the value is missing, late or contradictory. This is a data contract in its operational sense: an agreement that makes a record usable across people and systems.

The African Union’s Data Policy Framework places data governance within a wider agenda for a shared African data space, including rights, value creation and cross-border use. It does not instruct each institution to centralise all records in one database. For a hospital, utility, local authority or regional enterprise, the immediate work is accountable stewardship across the systems already supporting the service.

The consequence gives ownership meaning. If a missing registration number prevents a claim from progressing, the case worker needs a clear next action. If a delivery confirmation arrives late, the supply team needs to see the freshness problem rather than receive a false zero. If two partner systems disagree, a designated role needs the authority to resolve the discrepancy and record why. A field without a correction route is a request for future manual reconciliation.

The point of capture is part of the data architecture

Data quality is regularly discussed as if it begins after collection, in an integration pipeline or data lake. In practice, many consequential defects originate much earlier: a form that permits an ambiguous category, a workflow that requires the same information to be entered twice, an offline sync that does not explain its status, or a partner interface that accepts a record without identifying its source.

African operating conditions make this design work more important, not less. A health worker may submit a form after moving between connectivity zones. A small business may report through an agent rather than an app. A local government team may carry forward paper records during a system outage. A design that assumes uninterrupted connectivity, individual devices and uniform digital literacy will produce apparently individual errors that are actually predictable system behaviour.

Validation should help the work, not merely reject it. A useful capture control explains why a value is needed, prevents an impossible combination where appropriate, preserves an incomplete case for follow-up, and records when a staff member has made an informed override. It should not force a user to invent a number to move forward. Where verification cannot happen immediately, the system should mark the record’s status so later users understand its limits.

This distinction protects people as well as data. Excessive mandatory fields can exclude users whose documentation is incomplete or whose circumstances do not fit a standard form. Removing all controls transfers ambiguity downstream. The better design separates what must be known before a decision, what can be collected later, and what needs a human exception path.

Correction must travel back to the source

A recurring defect should create a feedback loop, not a private spreadsheet fix. If a supervisor identifies a duplicate visit, that finding should be available to the team responsible for the field workflow. If a finance analyst corrects an account identifier, the authoritative record should be updated through a controlled process, with an audit trail rather than an undocumented overwrite.

A correction has evidence. It should show what was changed, who made the change, why it was justified and which decision or report may be affected. That does not require a complex ledger for every record. Governed operational systems and audit logs are usually the right place for personal and service data. Where independent parties genuinely need shared provenance or settlement, a jointly governed registry can provide a narrower trust layer. Neither arrangement makes an inaccurate original claim true; verification remains an organisational responsibility.

The correction loop should reveal patterns: an unclear category, inadequate training, a failing integration or a field that staff cannot reasonably capture. Root causes are more valuable than an expanding team that repairs extracts.

AI magnifies weak data discipline

AI can classify documents, identify anomalies, retrieve information and propose actions. It can also turn an uncertain record into a fluent explanation that sounds more certain than the evidence warrants. The quality question therefore becomes sharper when an institution uses AI: can a reviewer see which source informed a recommendation, how current it was and whether it carried unresolved exceptions?

NIST’s Generative AI Profile, published in July 2024 as a voluntary companion resource to the AI Risk Management Framework, identifies risks including confabulation, data privacy and information integrity. It is not a sector-specific implementation manual. It does reinforce the need to connect AI evaluation and oversight to the data, context and consequences of the actual deployment.

An AI tool that identifies a potentially overdue payment can be useful if it makes the relevant transaction, date and uncertainty visible to the responsible officer. A tool that silently combines stale records from several systems and produces a confident recommendation is harder to govern. Data lineage is not a technical ornament in this setting; it is the evidence a person needs to accept, reject or escalate an automated proposal.

Start with one defect that changes a real decision

A large data-transformation programme is not required before an organisation improves quality. The strongest starting point is a recurring defect that causes a visible operational cost: delayed supplier reconciliation, duplicate beneficiary records, incomplete customer onboarding, unreliable stock counts or a case queue that cannot be trusted.

Discover the decision and its evidence. Follow the record from first capture to the moment someone acts. Identify every handoff, system, informal workaround and partner involved. Specify what the accountable person needs to know, and what uncertainty makes that decision unsafe.

Design the control and correction path. Set the minimum validation, ownership, freshness rule and exception status required for that decision. Make it easy for the person closest to an error to add context, while protecting sensitive records and preserving a review trail.

Build the learning loop. Measure defects by their operational consequence: delayed resolution, rework, failed verification, incorrect payment, repeated customer contact or an avoidable escalation. Review the causes with the teams who perform the work, then update the form, integration, policy or training that produced the error.

Xelius supports organisations through workflow research, data architecture, analytics and platform implementation. A practical engagement begins with the decision that is repeatedly delayed or disputed because nobody can establish which record is reliable, then builds the smallest durable correction loop around it.

Better data is a service capability

A reliable dataset is not an asset produced once and handed to leadership. It is the trace left by a service that can identify what happened, correct what is wrong and show why a decision was made.

That is the leadership standard worth pursuing. When a number changes, the organisation should be able to trace the source, understand the consequence and improve the work that created it. A dashboard can then become useful evidence. An AI system can then be constrained by facts. Without that discipline, more reporting will only make a fragile operating model look tidier.