Glossary

birth-to-grave records

Birth-to-grave records are lifecycle records that trace an item from creation or receipt through final disposition.

Data Integrity, Version Control and Audit Trails

Birth-to-grave records are the collected lifecycle records that document an item, batch, asset, or work order from its origin through its final disposition. In manufacturing, the term commonly refers to traceable evidence covering creation, receipt, processing, inspection, movement, use, maintenance, rework, shipment, scrap, or retirement, depending on the object being tracked.

These records may be maintained across MES, ERP, QMS, PLM, EAM, or document control systems. They can include material certifications, lot or serial history, routing steps, operator signoffs, inspection results, nonconformance records, rework activity, maintenance history, and disposition decisions.

Birth-to-grave records do not usually mean a single document. They are more often a connected record set or evidence trail. The term is also broader than an audit trail: an audit trail records changes and actions in a system, while birth-to-grave records describe the full operational history of the item or process being controlled.

Under AS9100, work instruction revisions are controlled through documented document-control and change-control processes, not by ad hoc edits on the shop floor. In practice, that means formal review and approval, revision identification, controlled release, removal of obsolete versions, traceable training impact assessment, and objective evidence that only the correct revision was available at point of use.

Should we store manufacturing timestamps in local time or UTC?

Use UTC as the system record for manufacturing timestamps in databases, integrations, and audit trails. Local plant time is still useful for operator screens, shift review, and reports, but storing only local time creates ambiguity during daylight saving changes, cross-site analysis, and system integration. The right approach depends on source systems, time sync, and validation discipline.

What data quality rules should I enforce before calculating KPIs?

Before calculating KPIs, enforce rules for definition control, timestamp integrity, unit consistency, master data alignment, completeness, duplicate handling, and exception treatment. If these controls are weak, the KPI may still calculate, but it will not be trustworthy enough for operational decisions, trend analysis, or regulated evidence use.

What data quality checks should we run before publishing KPIs?

Before publishing KPIs, verify definition control, source lineage, timestamp consistency, completeness, duplicate handling, unit normalization, status logic, and reconciliation to systems of record. In brownfield environments, most KPI errors come from integration gaps, master data drift, and ungoverned calculations, not dashboard design.

Related Glossary

privacy baseline

A documented set of privacy requirements that defines what data is collected, how it is used, and how systems must handle personal or sensitive data.