Data quality is a decision property

A data record can be present, correctly formatted and consistently copied while remaining unsuitable for a decision. Quality should therefore be assessed against the use that depends on the record. An equipment identifier that is adequate for a broad planning summary may be inadequate for releasing a safety-sensitive intervention. A stock quantity that is useful for a retrospective report may be too old for a current promise. The relevant question is what error or omission would change the decision, not whether the dataset looks tidy.

In a fictional spare-parts service, the enterprise holds item descriptions, stock identities, location records and substitution relationships. A purchase request arrives with a familiar local description. The catalogue contains a recognised identifier, but its relationship to the requested use is unclear. Filling the identifier field would improve apparent completeness while potentially making the operating decision worse. The quality service should preserve the unresolved meaning and route it to a competent decision rather than reward a populated field regardless of its validity.

A quality requirement should state the decision consequence of a defect. If an incorrect location causes a planner to promise an unavailable part, the requirement concerns current availability for promise acceptance. If an inconsistent item identity prevents reconciliation, the requirement concerns cross-record meaning. If an obsolete substitution relationship could lead to an unacceptable material choice, the requirement concerns technical validity for the intended use. These requirements can share a dataset while demanding different checks and owners.

The enterprise should also distinguish a data defect from a legitimate unknown. A field may be empty because the relevant fact has not yet been established. Treating every unknown as poor entry behaviour can encourage plausible invention. The service should identify when a value may remain unknown, what work is required to resolve it and which decisions must wait. An honest unknown with a controlled route can be more useful than an apparently complete record whose certainty is unsupported.

Quality work should be funded as continuing operation. Definitions change, physical stock moves, new items enter the service and previously valid relationships become obsolete. An implementation exercise can improve the starting condition but cannot make the data permanently self-maintaining. The operating model should define how a defect is reported, who resolves it, which records are affected and how downstream users learn about the correction. A platform can support that service, but does not substitute for its decision powers and resources.

A quality dashboard is useful when it directs a response. Reporting unresolved records without identifying their decision consequence can produce a large clean-up programme with weak prioritisation. The fictional spare-parts service should ask which defect prevents a current request, threatens a material decision or undermines an important reconciliation. It can then distinguish urgent operating correction from longer-term catalogue improvement. This does not justify ignoring low-visibility defects; it gives the work a defensible relation to use.

A defect record should include the affected object, the contested field or relationship, the use in which the issue was found and the evidence needed for resolution. A statement that the item is wrong leaves the data steward unable to decide whether the problem is identity, description, location or permitted substitution. The service should also identify whether other records share the defect. Correcting a single request may restore continuity while leaving the underlying catalogue issue untouched. Both actions should be visible.

The resolution route should preserve an audit of meaning. If engineering approves a new substitution relationship, the change may affect open requests and existing planning assumptions. The data owner should decide how to represent the effective scope and how to notify affected users. A technical update applied to a current table is not necessarily a complete operating correction. A downstream service may hold a cached or exported version that remains consequential after the central record changes.

Quality controls should be placed where they can prevent or detect the relevant error with acceptable burden. A format check at entry can prevent malformed identifiers. It cannot prove that the selected identifier refers to the intended physical part. A human confirmation can establish context but may be impractical for every routine transaction. The design should combine proportionate checks and a usable exception route instead of making a broad claim that validation solves data quality.

Ownership must extend to the sources of data. If a supplier supplies availability information, the enterprise should state what it expects, how it tests or qualifies the information and what it does when it is absent or stale. An internal platform cannot guarantee an external fact it does not control. The investment proposition should distinguish improving the handling of supplier information from improving the supplier's actual performance. These effects may be related, but they require different evidence and authority.

A composite quality score can be convenient for reporting while obscuring a decisive defect. A dataset might perform well on routine fields and poorly on the one relationship that determines whether a substitute is acceptable. Averaging across fields could describe the dataset as mature despite the unresolved operating condition. A sponsor should retain visibility of critical defects and acceptance gates rather than allow favourable dimensions to compensate numerically for an unacceptable decision risk.

The Transformation map readiness input is a declared judgment multiplier. It does not inspect records, establish quality dimensions or enforce a data acceptance gate. An author can lower the readiness assigned to a data capability and examine the numerical effect. The result describes the supplied assumption. It cannot demonstrate that the underlying dataset is safe, usable or mature. Chapter ten and the frozen cases make this distinction explicit so a convenient numeric field does not acquire an authority its method does not possess.

For an actual programme, a quality assessment should identify its population and use. A review of selected difficult requests says something about those cases, not automatically the whole catalogue. A review of ordinary records can miss the exception relationships that matter most. The sampling or inspection plan should be chosen to answer a stated question and its limits should remain visible. This study does not invent an error rate or imply that a small illustrative record proves enterprise quality.

The assessment should also distinguish defect detection from defect resolution. A system can detect an ambiguous identifier reliably while leaving every affected case waiting. A high detection count might initially reflect improved visibility rather than deteriorating underlying data. Conversely, a falling defect count might reflect suppressed reporting rather than improvement. The service owner needs evidence about the mechanism and the reporting conditions before interpreting the trend. The intended operating outcome is useful resolution and prevention, not an attractive defect count in isolation.

A quality record should therefore retain the criterion, evidence, population, responsible role and decision consequence. It should state what remains unknown and what the next review will examine. A sponsor can then authorise a bounded improvement, adjust the use of data or retain a hold on a proposed capability. The record supports a decision even when it cannot provide a single enterprise-wide maturity score. Precision of meaning is more valuable than false precision in a summary number.

The fictional operator proposes automated parts promise acceptance. Discovery reveals that stock identifiers are generally recognised, but location updates do not consistently establish whether a part is available, reserved or physically inaccessible. The initial improvement therefore defines availability states and the events that legitimately change them. This is a semantic and operating task before it is a display task. The enterprise does not begin by promising that an interface will make every stock record current.

The completed acceptance record limits automated promise acceptance to recognised items with a current permitted availability state. Unresolved location or reservation meaning enters a controlled confirmation route. Stores owns the physical confirmation; the data owner owns the state definitions; the service owner owns the unresolved case and its communication to the requester. A technical owner implements the permitted state transitions. The division makes each obligation visible without pretending that software verification can establish physical stock existence.

The pilot tests both a straightforward available item and a reserved item whose planned release changes. It examines whether the current state and its meaning remain coherent through the change. It also tests a reporting user who should see a qualified quantity without being authorised to promise it. The same data can support several uses under different constraints. The design should avoid turning access to a value into authority to act on it.

The sponsor can approve the bounded service if these conditions are demonstrated, while retaining expansion to other item classes as a separate decision. No fictional proportion of the catalogue is declared ready. The record states the included population, its acceptance evidence and the unresolved scope. This creates an honest platform for later benefit measurement and avoids presenting a staged capability as a completed enterprise transformation.