What MES data do I need before starting AI projects in aerospace?

You do not need a perfect MES before starting AI projects in aerospace. You do need data that is usable, governed, and tied to a narrow business question. In practice, the required MES data depends on whether you are trying to predict delays, detect quality risk, reduce rework, improve labor planning, or identify process drift.

A good rule is this: start with one decision you want to improve, then confirm you have enough historical MES and adjacent system data to reconstruct what happened, when it happened, to which part or assembly, under which revision, at which operation, using which resources, and with what outcome.

Minimum MES data foundation

For most aerospace AI use cases, the minimum useful data set includes:

• Work order, traveler, or routing execution history by operation

• Part number, serial number, lot, and where applicable full genealogy links

• Timestamps for operation start, stop, queue, hold, completion, and rework events

• Resource context such as workcenter, machine, tool, line, or cell

• Operator or role information, if allowed by policy and handled appropriately

• Disposition outcomes such as pass, fail, scrap, rework, deviation, or concession status

• Nonconformance references and defect or symptom codes

• Recipe, process plan, routing revision, and work instruction revision in effect at execution time

• Material consumption and component issue records where product risk depends on material lineage

• Equipment or test results if process capability or condition affects quality or throughput

If you cannot connect execution records to outcomes, AI will usually produce weak correlations rather than operationally useful guidance.

What matters more than data volume

In regulated aerospace operations, data quality usually matters more than raw volume. A smaller, well-controlled history with reliable timestamps and revision context is often more useful than a large, messy export. Before starting, check for these basic conditions:

• Consistent identifiers across MES, ERP, QMS, and where relevant PLM

• Stable event timestamps and time zone handling

• Clear status transitions rather than free-text updates

• Reason codes that are actually used consistently on the floor

• Versioned master data for routings, resources, and instructions

• Enough history to cover normal variation, engineering changes, and atypical events

If your plant has frequent manual overrides, backfilled transactions, shared generic logins, or uncontrolled free text, say so early. Those are common realities, but they directly limit model reliability and explainability.

Use-case-specific data needs

Different AI projects need different MES depth.

• Delay and bottleneck prediction: queue times, operation durations, dispatch status, resource calendars, holds, shortage status, and rework loops.

• Quality risk prediction: defect history, inspection/test results, parameter readings, operator steps, material lots, genealogy, and revision history.

• Scrap and rework reduction: nonconformance codes, disposition paths, prior process conditions, tool or machine context, and process deviations.

• Knowledge capture and guidance: standard work adherence, step completion records, exceptions, and links to controlled instructions.

• Scheduling or labor recommendations: route variability, touch time versus elapsed time, skill constraints, and actual vs planned completion by operation.

If the project touches product quality, airworthiness records, or release-adjacent decisions, expectations for traceability, validation, and change control go up quickly. That does not make AI impossible, but it changes the burden of proof.

Data you probably need beyond MES

MES alone is often not enough. In brownfield aerospace environments, useful AI usually depends on stitching MES to nearby systems:

• ERP: order status, shortages, supplier delays, cost signals, and inventory state

• QMS: NCR, CAPA, dispositions, audit evidence, and recurring defect patterns

• PLM: revision effectivity, change history, and engineering context

• Test and equipment systems: measured values, calibration state, equipment events, and environmental conditions

• Document control systems: released work instructions and approval history

This is where many AI programs stall. The issue is usually not model selection. It is unresolved identifier mapping, conflicting timestamps, poor lineage, and missing business rules across systems.

What you do not need on day one

You do not need a full digital thread, complete automation, or years of perfectly labeled data to begin. You can often start with one bounded use case if you have:

• a stable process segment

• a measurable outcome

• several months of trustworthy event history

• basic traceability to revision and outcome

• a team willing to validate whether outputs are operationally credible

For many plants, the first sensible step is not a plant-wide AI deployment. It is a data-readiness assessment and a narrow pilot on one product family, line, cell, or recurring quality issue.

Common failure modes

• Starting with a generic AI platform before defining the operational decision

• Assuming MES transaction data reflects actual shop floor behavior without checking workarounds

• Ignoring engineering change timing and revision effectivity

• Treating free-text defect descriptions as a substitute for structured cause or disposition data

• Underestimating rework loops, split lots, and serialized genealogy complexity

• Trying to replace core MES, ERP, or QMS systems as part of the AI initiative

That last point matters. Full replacement strategies often fail in regulated, long lifecycle environments because qualification burden, validation cost, downtime risk, integration complexity, and traceability requirements are high. In most aerospace plants, AI has to coexist with existing MES, ERP, PLM, and QMS systems rather than forcing a reset.

A practical readiness threshold

You are probably ready to start if you can answer these questions with evidence:

• Can we reconstruct the execution history for a part, assembly, or work order?

• Can we link execution events to quality and schedule outcomes?

• Can we identify which revision, instruction, material lot, and resources were in effect?

• Can we explain major data gaps, overrides, and manual steps?

• Can we validate outputs without disrupting production or controlled processes?

If the answer is no to most of these, the right next step is usually data remediation and integration cleanup, not model development.

So the short answer is: you need enough MES and adjacent-system data to support traceable, revision-aware, outcome-linked analysis for one specific use case. Not more than that, but also not less.