You do not need a perfect MES to start AI projects in aerospace. You do need data that is trustworthy enough for a narrow, well-defined problem and traceable enough that engineering, quality, and operations can review how the output was produced.
In practice, the best starting point is not “all MES data.” It is the smallest data set that supports one operational question, such as predicting rework risk on a process step, identifying likely bottlenecks, or prioritizing quality review queues.
For most aerospace manufacturing use cases, the minimum useful MES data set includes:
Work order and routing history
Operation sequence, work center, planned versus actual step completion, hold events, rework loops, and dispatch status.
Part, serial, and lot traceability
Part number, revision, serial number or lot, parent-child relationships where applicable, and material or component consumption records.
Timestamps with consistent event meaning
Start, stop, queue, move, hold, release, inspection complete, and close timestamps. If timestamp semantics vary by area or by shift, AI outputs will be difficult to trust.
Quality outcomes
Inspection results, pass-fail dispositions, defect codes, NCR links, rework records, scrap events, and disposition timing.
Operator and resource context
Work center, machine or asset identifier, shift, certification or role if allowed by policy, and major tooling context. This matters when trying to separate product effects from resource effects.
Configuration and revision context
Routing revision, work instruction revision, process plan revision, and where possible the effective configuration at the time of execution.
Basic master data stability
Consistent part numbers, operation codes, defect codes, reason codes, and asset identifiers. If names and codes change without control, the model may learn noise instead of process behavior.
For aerospace, data quality and context usually matter more than raw volume. A smaller, cleaner execution history with stable identifiers and strong genealogy is more useful than a large MES extract full of missing timestamps, free-text workarounds, and uncontrolled code changes.
You should expect problems if any of the following are true:
The MES event model changed over time and no one mapped old and new meanings.
ERP, PLM, QMS, and MES disagree on part revision, operation naming, or status definitions.
Rework is recorded inconsistently or outside the MES in spreadsheets, email, or disconnected QMS workflows.
Inspection outcomes are captured, but not linked reliably to the exact operation, configuration, or serial number.
Important process changes were made without clean change control metadata, making before-and-after comparisons misleading.
The data needed depends on the use case.
Bottleneck and flow analysis
You mainly need event timestamps, routing states, queue and hold reasons, and work center context.
Yield, scrap, or rework prediction
You need genealogy, operation history, inspection outcomes, defect codes, rework loops, revision context, and enough historical examples of failures to train against.
Operator guidance or anomaly detection
You may also need machine, sensor, or test data outside MES, plus digital work instruction usage and exception history.
Scheduling or dispatch recommendations
You usually need MES plus ERP and planning context, because MES alone rarely contains all constraints, material status, outside processing dependencies, or program priorities.
So the honest answer is that MES data alone is often necessary but not sufficient.
A practical starting threshold is usually:
One clearly defined business question
Six to eighteen months of reasonably consistent execution history, if product and process conditions were stable enough during that period
Reliable identifiers linking work orders, operations, parts, serials or lots, and quality events
A known system of record for each critical field
Documented data gaps and business rules, rather than pretending the data is cleaner than it is
That said, the required history length depends on event frequency and process stability. High-mix, low-volume programs may not produce enough repeatable examples for some supervised models. In those environments, analytics, rules, and constrained anomaly detection may be more realistic than ambitious predictive AI.
In aerospace plants, MES data readiness is usually limited by coexistence issues, not just MES functionality. Many sites run mixed MES, ERP, PLM, QMS, and homegrown systems with different data models and years of integration debt. Important execution evidence may be split across digital travelers, test systems, inspection tools, and manual records.
That is why full replacement is rarely the right prerequisite for AI. Replacing MES or surrounding systems first often fails because of qualification burden, validation cost, downtime risk, integration complexity, and the long lifecycle of equipment and regulated processes. A narrower approach is usually safer: map the data needed for one use case, establish traceable extracts, validate logic with process owners, and expand only after the outputs are reviewable and useful.
Before using AI outputs operationally, you should have:
Clear data lineage from source systems to features and outputs
Change control for mappings, code sets, and model versions
Review procedures for questionable recommendations or anomalies
Defined handling for missing, late, or corrected records
Validation appropriate to the intended use and system impact
This does not guarantee acceptance or compliance outcomes, but without these controls, AI results are hard to defend in a regulated environment.
Start with MES data that can reliably answer one operational question: event history, routing context, genealogy, quality outcomes, revision context, and stable timestamps. If those links are weak, fix the data path before scaling AI. If those links are strong, you can begin with a bounded use case even in a brownfield aerospace environment.
Whether you're managing 1 site or 100, C-981 adapts to your environment and scales with your needs—without the complexity of traditional systems.
