What data should be captured at each operation to support traceability and genealogy?

At each operation, you need enough data to reconstruct a defensible, time-ordered “as-built” or “as-maintained” record: who did what, to which unit or batch, using which resources, against which specification, and with what outcome. The exact fields depend on your processes, systems, and regulatory scope, but the core categories are consistent.

1. Identification of the unit being processed

You must be able to unambiguously tie every data point to a specific part, lot, or assembly.

• Top-level identifier being worked (e.g. serial number, tail number, equipment ID, or lot/batch ID).
• Work order / shop order / operation number (and any sub-ops).
• Parent / child relationship at this step (e.g. which subassemblies or components are being joined to which parent serial).
• Quantity processed, accepted, rejected, and scrapped at the operation.

2. Process and configuration context

Traceability is weak if you cannot show which version of process or design was followed.

• Routing step / operation code or name (e.g. OP20 Drilling, OP40 Heat Treat).
• Applicable specification and drawing references (drawing number, model reference, spec IDs).
• Revision identifiers for:
  • Engineering drawing / model.
  • Work instructions or standard operating procedure.
  • NC program, test script, PLC recipe, or other automated program (including revision or checksum).
• Configuration or option codes applied to this unit (e.g. variant, customer-specific configuration).
• Any active deviations, waivers, or concessions that apply to this operation (with IDs that link to QMS records).

3. Material and component genealogy

To reconstruct genealogy, you must be able to follow material and components from receipt through every assembly and rework step.

• Component or subassembly IDs consumed at the operation:
  • Serialized components: individual serial numbers.
  • Non-serialized components: lot/batch numbers and quantity consumed.
• Raw material lot, heat, cast, or batch numbers where applicable (e.g. forgings, plate, resin, chemicals).
• Source information where needed by regulation or customer:
  • Supplier ID or site code.
  • Certificate of Conformance (CoC) or test report reference numbers.
• For rework or repair: explicit linkage to the prior configuration or prior NCR that triggered the work.

4. Tools, equipment, and calibration references

For many regulated processes, you must show that qualified and calibrated resources were used.

• Primary equipment / asset ID used at the operation (machine tool, oven, test stand, torque tool, etc.).
• Key tools or fixtures that impact quality or conformity (e.g. torque tools, crimp tools, calibrated fixtures, test instruments) with their IDs.
• Where required: calibration record IDs or due dates (typically linked from a separate calibration system, not duplicated).
• Any special process qualifications (e.g. NADCAP process codes) applicable to the operation, referenced by ID.

5. Process parameters and conditions

What you record here depends heavily on risk and process capability. For some steps, a simple pass/fail is enough; for others, detailed parameters are essential.

• Critical process parameters actually used, where they impact fit, function, or safety, such as:
  • Temperature/time profiles (e.g. cure, heat treat, bake cycles).
  • Pressure, torque, force, or flow values.
  • Speeds/feeds, key program offsets, or tool number for machining when required by your control plan.
  • Mold cavity, press number, or chamber ID for batch processes.
• Environmental conditions where they are part of the specification (e.g. humidity, temperature ranges for bonding or test).
• If parameters are captured automatically by machine or test systems, capture:
  • Linkage ID between MES/ERP record and the source data file or historian record.
  • Date/time and equipment ID from the source system.

6. People, timing, and accountability

Regulated environments usually need a clear chain of responsibility and timing.

• Operator / technician ID(s) performing the work (often with electronic signoff per step).
• Inspector or independent verifier ID where required (e.g. buyoff, key characteristics, pressure tests).
• Supervisor or approver ID where additional authorization is needed (e.g. deviation use, rework authorization).
• Date and time stamps for:
  • Operation start and completion, or at least completion time.
  • Each formal signoff or approval event.

7. Inspection, measurement, and test results

Traceability and genealogy are often scrutinized around inspection and conformance evidence.

• Inspection or test status at the operation:
  • Accepted / rejected / reworked / use-as-is.
  • For partial acceptance, quantities in each category.
• Measurement results where required by control plans or standards:
  • Key or critical characteristics values.
  • Test results (e.g. pressures, leak rates, electrical values, cycle times, functional test outcomes).
  • For automated tests, the record or file ID that stores the full dataset.
• Sampling plan references (e.g. AQL level, inspection plan ID) when relevant.
• Linkage to formal inspection reports (e.g. AS9102 FAI reports) when the operation is part of a first article or qualification build.

8. Nonconformances, rework, and concessions

Genealogy is incomplete if it does not follow nonconforming material and subsequent actions.

• Nonconformance identification when a part fails at this operation:
  • NCR number or defect record ID.
  • Defect codes, categories, and affected quantities.
• Rework or repair actions performed at this step, with references to:
  • Approved rework instructions or dispositions (e.g. MRB decisions).
  • Any associated risk assessment or engineering authorization IDs.
• Concessions, deviations, or use-as-is dispositions tied to this operation, with QMS record references.

9. Scheduling and flow-related data

Although sometimes seen as planning data, timestamps and WIP moves are critical for traceability, bottleneck analysis, and some regulatory questions.

• Planned vs actual start and completion dates (or at least actuals) for the operation.
• Work center or cell where the operation was executed (especially if multiple identical resources exist).
• Queue time or wait time when time limits between operations are specified (e.g. time-from-clean to bond).
• Transfers between sites, buildings, or external processors, with shipment/receipt references.

10. Practical considerations and tradeoffs

In brownfield, regulated environments, capturing all of the above perfectly at every operation is rarely realistic on day one. You will need to prioritize and account for system coexistence.

• Prioritize by risk and regulatory impact. Start with operations that affect safety, airworthiness, or critical characteristics, plus known chronic problem areas. Not every drill or deburr step justifies full parameter logging.
• Leverage existing systems instead of replacing them. Often, ERP holds order and material data, MES or travelers hold operation data, machine controls or test stands hold parameter data, and QMS holds NCR and deviation records. Traceability usually comes from stitching these together via IDs and timestamps, not from a single new system replacing all of them.
• Define a minimum data set per operation type. For example:
  • Simple assembly: unit ID, components/lots consumed, operator, start/finish time, pass/fail, NCR links.
  • Special process (heat treat, bond, plating): full batch ID, load map or contents, recipe/program ID, qualified equipment, key temperature/time/pressure data, operator, inspection/test results.
  • Test operations: unit ID, test stand ID, test script version, summary result, link to detailed data file, operator, time.
• Avoid capturing data you cannot maintain or validate. Excessive manual fields drive errors and operator workarounds. Automatic collection (e.g. from machines) is preferable but requires integration effort and validation.
• Plan for long lifecycle and change control. Once you define the traceability dataset for a program, changing it later is costly: validation effort, traveler or MES changes, retraining, data migration, and potential audit questions about gaps. Invest in a deliberate design phase.

11. Why full replacement strategies often fail here

Trying to replace all existing ERP, MES, QMS, and machine data collection at once to “fix” traceability frequently fails in aerospace-grade and similar environments because of:

• Qualification and validation burden. New systems that hold production records typically require formal validation and sometimes customer or regulatory review.
• Integration complexity and history. Legacy machines, homegrown databases, and supplier portals often carry critical genealogy data that is hard to replicate. Clean cutovers are rare.
• Downtime risk. Migrating every route and traveler into a new system risks production disruption and extended parallel runs.
• Traceability gaps. If history is not migrated or reliably linked, you can lose genealogy across the cutover boundary, which is often unacceptable for long-lived assets.

Most plants make better progress by defining a standard traceability schema, integrating or overlaying systems to meet it, then tightening data capture over time, operation by operation.