What data should an aerospace MES send to a QMS to support traceability?

An aerospace MES should send the QMS the quality-relevant execution evidence needed to reconstruct what was built, how it was built, under which revisions, by whom, with which materials, tools, equipment, inspections, exceptions, and approvals. It should not simply dump every shop-floor transaction into the QMS. The useful boundary is traceability: stable identifiers, controlled revisions, genealogy, inspection and test evidence, nonconformance links, electronic signatures where used, and audit-trail metadata.

The exact dataset depends on which system is the system of record for each process. In many brownfield plants, MES, ERP, PLM, QMS, maintenance, calibration, and document control systems all hold part of the evidence. The interface has to respect those ownership boundaries or it will create duplicate records that disagree during an audit, customer review, or escape investigation.

Core identifiers and configuration context

The QMS usually needs enough context to tie a quality record to the correct product configuration and execution state. Typical MES-to-QMS data includes:

• Part number, part revision, serial number, lot number, batch number, or unit identifier.
• Work order, shop order, traveler, routing, and operation identifiers.
• Program, customer, contract, or purchase order references where they are required for traceability.
• BOM, routing, drawing, specification, and work instruction revisions used at the time of execution.
• Build configuration, effectivity, engineering change, deviation, or waiver references when applicable.

This depends heavily on master data discipline. If part revisions, routing versions, and document identifiers are inconsistent across MES, ERP, PLM, and QMS, the interface will move bad context faster rather than improve traceability.

As-built genealogy

For serialized or lot-controlled aerospace work, the MES should provide the QMS with as-built genealogy where the QMS needs it for containment, investigation, or customer evidence. This commonly includes:

• Components consumed into each parent serial number or lot.
• Material lot, heat, batch, shelf-life, cure date, or expiration references where relevant.
• Supplier lot and certificate references, if the MES captures consumption against those records.
• Substitutions, alternates, split lots, partial consumption, and rework consumption history.
• Kit, staging, and issue references when material traceability depends on them.

The QMS may not need to store every certificate attachment if another controlled repository owns those records. In many architectures, the QMS stores the traceability link and retrieves the certificate or document from ERP, PLM, a supplier quality system, or document control when needed.

Process execution evidence

The MES should send execution records that affect product conformity or investigation quality. Typical examples include:

• Operation start, completion, hold, restart, and signoff events.
• Operator, inspector, or approver identifiers, including qualification status references where the system supports them.
• Equipment, machine, fixture, tool, mold, program, or gage identifiers used during the operation.
• Calibration status references for measurement equipment at the time of use.
• Critical process parameters, machine data summaries, or environmental readings where they are defined as quality-relevant.
• Rework, repair, teardown, retest, or repeat-operation history.

Raw machine data is not always appropriate to copy into the QMS. For high-volume signals, the better pattern is often to store controlled summaries, pass/fail outcomes, parameter limits, and links to the validated source system. That decision should be based on retention requirements, investigation needs, data volume, and validation scope.

Inspection and test results

Inspection data is often central to MES-QMS traceability. The MES should send results in a way that preserves the link between the measured value and the requirement being verified. Common fields include:

• Characteristic identifier, balloon number, or inspection plan step.
• Acceptance criteria, tolerance, specification, and revision in effect.
• Measured value, units of measure, pass/fail status, and result timestamp.
• Sampling plan, sample size, and sample disposition where sampling is used.
• Inspector identity, inspection equipment, and calibration reference.
• Test station, test program, software revision, or automated test file reference where applicable.

For AS9102 first article inspection, customer-specific reporting, or special-process evidence, the required data may be more detailed. That requirement is program- and customer-driven, not universal.

Nonconformance, deviation, and disposition links

The MES and QMS must agree on how quality exceptions move between systems. The MES should usually send the event and affected scope; the QMS often owns formal nonconformance, MRB, disposition, corrective action, and approval workflows. Useful integration data includes:

• NCR, defect, discrepancy, or issue identifiers.
• Affected serial numbers, lots, operations, characteristics, and material genealogy.
• Defect codes, location, quantity affected, containment status, and discovered-at operation.
• Links to photos, measurement files, operator notes, and relevant attachments.
• Disposition outcome, rework or repair routing reference, use-as-is approval, scrap status, or return-to-supplier reference.
• MRB, concession, waiver, deviation, CAPA, or escape investigation links where applicable.

The integration should avoid two independent disposition records for the same event. If operators can close an issue in MES while quality closes a related NCR in QMS, status conflicts are likely unless ownership and synchronization rules are explicit.

Electronic signatures, timestamps, and audit-trail metadata

Where electronic records and signatures are used, the QMS needs more than a final status. It may need the identity, role, timestamp, reason code, meaning of signature, and record version. The MES should also preserve audit-trail metadata for changes to quality-relevant records, including who changed what, when, from what value, to what value, and under what reason or approval path.

This does not mean every audit trail must be duplicated into the QMS. In validated environments, it is common to keep the authoritative audit trail in the source system and provide controlled access, reports, or references. The key is that the record can be reconstructed and defended without manual guesswork.

What the QMS may send back

Traceability is not only MES-to-QMS. The QMS often sends status or control signals back to MES, such as quality holds, release decisions, rework instructions, inspection requirements, containment actions, approved deviations, CAPA tasks, or supplier quality restrictions. These return flows need the same change control and validation discipline as the outbound traceability feed.

Common failure modes

• Sending records without stable serial, lot, operation, or revision identifiers.
• Using free-text fields where controlled defect codes, characteristic IDs, or disposition codes are needed.
• Copying documents without preserving document revision, approval state, or source repository.
• Letting MES, QMS, and ERP each become partial systems of record for the same status.
• Ignoring time synchronization, user identity mapping, and role changes.
• Building an interface before master data, routings, inspection plans, and document control are clean enough to support it.
• Changing the interface without validation, regression testing, and change control.

In aerospace brownfield environments, full system replacement is often unrealistic because of qualification burden, validation cost, downtime risk, integration complexity, traceability obligations, and long asset lifecycles. A controlled MES-QMS interface is usually more practical than trying to force one platform to own every record. The interface still has to be specified, validated, monitored, and governed as part of the regulated production system.