Information can look authoritative because it is formatted well, appears in a familiar system or carries a senior person’s name. None of these features establishes whether it is correct and applicable.
Information quality concerns fitness for a defined use. Provenance helps explain where the information came from and what happened to it before it reached the user.
Define quality in relation to the task
The same information can be adequate for one purpose and unsuitable for another. An approximate equipment location may support regional planning while remaining inadequate for dispatch or safety work.
Specify the intended decision, required precision, acceptable delay and consequence of error. Then define checks that address those requirements.
The UK Government Data Quality Framework provides a practical reference through dimensions including completeness, uniqueness, consistency, timeliness, validity and accuracy. A complete record can still contain incorrect values; a valid format does not prove correspondence with reality.
For documents and guidance, also examine relevance, comprehensibility and applicability to the user’s situation.
Trace information through its transformations
A value may be entered manually, copied between systems, converted into another unit and aggregated into a report. Each step can change its meaning or introduce error.
Record the authoritative source, relevant transformations, responsible parties and effective dates. W3C’s PROV approach provides a reference model for describing entities, activities and agents involved in producing information.
Provenance supports investigation and informed trust. It does not certify that the original observation was accurate.
Control quality where it enters the process
Place checks near creation or change, where correction is usually easier and the context is available.
A hypothetical product-data process might validate units, require an applicable revision and prevent reuse of an identifier for a different item. Human review may still be needed to establish whether the technical value is right.
Avoid treating every quality issue as a cleanup exercise at the reporting end. Repeated correction indicates a process, definition or ownership problem upstream.
Distinguish prevention, detection and correction. Each has a role, with effort proportionate to the consequences of failure.
Make uncertainty visible
Users should know whether content is approved, provisional, estimated or outdated. Include relevant limitations and review conditions.
A report can remain useful when some inputs are incomplete if the uncertainty is clearly explained and acceptable for the decision. Concealing the gaps creates a different risk.
Do not equate recent publication with current applicability. A newly uploaded document may describe an old configuration, while an older controlled instruction may remain valid.
Give issues an owner and a route to resolution
Users need a simple way to report conflicting or questionable information. Route the issue to an accountable owner who can assess impact and correct the source.
Where the error has propagated, identify affected outputs and users. Correcting one visible copy may leave the underlying problem active.
Set priorities according to operating consequence rather than the number of records involved. A small set of critical configuration errors can matter more than thousands of missing optional fields.
Monitor quality as an operating capability
Track critical defects, recurrence, resolution time and the decisions affected. Review whether controls detect the failures that matter.
Sample actual use to understand how users interpret the information. A technically correct field can still cause mistakes if its label or context is misleading.
Trustworthy information emerges from maintained definitions, traceable transformations and responsive ownership. The executive objective is a dependable basis for action, with uncertainty visible where it cannot be eliminated.