2. Data quality dimensions for engineering datasets

Engineering datasets are not generic business tables. A vibration record from a rotating machine, a bill of materials for a pressure vessel, or a time-series export from a SCADA historian carries physical meaning: units, sampling rates, sensor calibration, revision states, and operating context. When we assess the quality of such data, we are not asking an abstract question — we are asking whether the data can be trusted to support a specific engineering decision, such as a fatigue calculation, a tolerance stack-up, a fault diagnosis, or a regulatory submission. Six dimensions form the practical backbone of this assessment: accuracy, completeness, consistency, timeliness, validity, and uniqueness. Each dimension answers a different question, and each fails in characteristic ways.

What Each Dimension Actually Measures

Accuracy is the degree to which a recorded value agrees with the true physical quantity. In engineering data this is rarely a simple "correct or incorrect" judgment, because accuracy is bounded by measurement uncertainty. A bearing temperature of 78.3 °C from a Type-K thermocouple with ±1.5 °C tolerance is accurate within its stated uncertainty; the same value from an uncalibrated sensor is not. Accuracy assessment therefore requires a reference — a calibrated instrument, a certified standard, or a redundant measurement channel.

Completeness measures whether all required values are present. For a time-series dataset, completeness has two layers: record-level completeness (are all expected timestamps present?) and attribute-level completeness (are all required fields populated?). A 24-hour vibration log sampled at 1 Hz should contain 86,400 samples; if only 82,100 are present, completeness is 95.0%, and the missing 4,300 samples may correspond to a machine shutdown or a data acquisition dropout — two very different root causes.

Consistency checks whether values agree across related records, systems, or representations. A pump rated at 45 kW in the equipment register but 37 kW in the maintenance database is a consistency violation. Unit mismatches (psi vs. bar), sign conventions, and coordinate reference frames are common consistency traps in engineering data.

Timeliness asks whether the data is available when it is needed and whether it reflects the current state of the asset. A design change order issued three weeks ago but not yet reflected in the as-built dataset is timely as a record but stale as an engineering input.

Validity concerns conformance to a defined domain, format, or rule set. A pressure value of −5 bar absolute is invalid because absolute pressure cannot be negative. A material grade code "S355JR" is valid against EN 10025; "S355XX" is not. Validity is rule-based and can be checked automatically.

Uniqueness ensures that each real-world entity appears exactly once. Duplicate sensor tags, repeated work orders, or double-counted inspection records inflate statistics and corrupt aggregation. In engineering datasets, uniqueness violations often arise from merge operations between legacy and current systems.

Key distinction: Validity is about rules; accuracy is about truth. A value can be perfectly valid (correct format, within range) yet inaccurate (sensor drift). Conversely, an accurate reading can be invalid if it falls outside a poorly chosen rule boundary. These dimensions are independent and must be assessed separately.

How the Dimensions Interact

The six dimensions are not isolated checkboxes. They form a dependency structure that determines which assessments are meaningful and in what order. Validity and completeness are typically prerequisites: if a value is missing or malformed, accuracy cannot be evaluated. Consistency and uniqueness operate on relationships between records, so they require a defined entity model. Timeliness depends on the use case — the same dataset may be timely for a monthly report but stale for real-time control.

Data Quality Dimensions — Assessment Dependency and Failure Modes Completeness Missing timestamps, null fields → blocks accuracy assessment Validity Range, format, domain rules → blocks accuracy assessment Uniqueness Duplicate entities, double counts → blocks aggregation Accuracy Sensor calibration, reference comparison, uncertainty bounds Consistency Cross-system agreement, units, sign conventions, revisions Timeliness Latency vs. use case, staleness of as-built vs. as-designed Fitness for Engineering Purpose Can this dataset support the intended calculation, diagnosis, or decision? Typical failure cascade: Missing records (completeness) → invalid range check (validity) → duplicate tags (uniqueness) → wrong cross-reference (consistency) → stale revision (timeliness) → undetected sensor drift (accuracy) Each dimension failure can mask or amplify others; assess in dependency order.

Applying the Dimensions: A Worked Example

Consider a dataset of 1,200 centrifugal pump inspection records exported from a maintenance management system for reliability analysis. The engineering goal is to estimate mean time between failures (MTBF) by pump model. We assess each dimension against this specific purpose.

Completeness: The export contains 1,200 rows, but the failure_date field is null in 84 rows (7.0%). The pump_model field is null in 12 rows (1.0%). For MTBF calculation, rows with null failure dates cannot contribute and must be excluded or investigated. The 12 rows with missing model codes cannot be grouped and are excluded from per-model analysis.

Validity: A rule set is applied: failure_date must be a valid date between 2015-01-01 and the current date; operating_hours must be a positive number; failure_mode must belong to the controlled vocabulary {seal_leak, bearing_failure, impeller_damage, coupling_failure, motor_fault, other}. Three records have operating_hours = 0, which is physically implausible for a failure event and fails the validity rule. Two records use "bearing wear" instead of the controlled term "bearing_failure" — a validity failure that also creates a consistency problem.

Uniqueness: Checking work_order_id reveals 18 duplicate pairs. Investigation shows these are not true duplicates but split work orders — the same failure event recorded under two work order numbers because the repair was performed by two different crews. For MTBF, these must be merged into single failure events, reducing the effective count from 1,200 to 1,182.

Consistency: Cross-referencing pump_model against the equipment register shows that 7 records use an obsolete model designation ("P-200A") that was superseded by "P-200B" in 2019. Without harmonization, these records would form a spurious separate model group with an artificially low MTBF.

Timeliness: The export was generated on 2024-06-15, but the most recent failure record is dated 2024-03-20. The three-month gap suggests either a data entry lag or a genuine absence of failures. Checking the maintenance system directly confirms that 14 failure records from April and May 2024 exist but were not included in the export — a timeliness failure caused by an incorrect export filter.

Accuracy: No independent reference exists for failure dates in this dataset. However, operating_hours can be cross-checked against the SCADA historian's runtime counter for a sample of 30 pumps. The comparison shows a mean absolute difference of 47 hours (2.3% of average operating hours), which is within the expected recording lag between the two systems. Accuracy is acceptable for MTBF estimation at the model level but not for individual pump reliability curves.

Dimension Assessment Summary

Dimension Question Answered Example Check Result in Worked Example
Completeness Are all required values present? Null count per required field 7.0% null failure dates; 1.0% null model codes
Validity Do values conform to defined rules? Range, format, controlled vocabulary 3 zero operating hours; 2 non-standard failure modes
Uniqueness Does each entity appear once? Duplicate key detection 18 duplicate work order pairs (split events)
Consistency Do related values agree? Cross-system key matching 7 obsolete model codes
Timeliness Is data current for the use case? Max date vs. export date 3-month gap; 14 records missing from export
Accuracy Do values match physical truth? Reference comparison, uncertainty 2.3% mean difference vs. SCADA runtime
Practical guidance: Assess dimensions in dependency order — completeness and validity first, then uniqueness and consistency, then timeliness, and finally accuracy. This order prevents wasted effort on accuracy checks for records that are missing, malformed, or duplicated. Document the assessment purpose explicitly, because the same dataset may pass for one engineering use case and fail for another.
Common pitfall: Treating a dimension score as a single number. "95% complete" is meaningless without specifying which field, which time window, and which use case. Always report dimension assessments with the field name, the rule applied, the affected record count, and the impact on the intended engineering decision.

The six dimensions provide a structured vocabulary for a conversation that engineers already have informally: "Can I trust this data?" By separating the question into completeness, validity, uniqueness, consistency, timeliness, and accuracy, the assessment becomes repeatable, auditable, and actionable. Each dimension points to a different remediation path — data acquisition fixes for completeness, rule definition for validity, entity resolution for uniqueness, system integration for consistency, pipeline scheduling for timeliness, and calibration or reference measurement for accuracy.

← Previous 📖 Contents Next →