In aerospace, engineering change is supposed to be the most controlled process in the company. Every engineering change notice (ECN) passes through reviews, signatures, and workflow steps inside PLM or equivalent systems. On paper, the digital thread looks clean.

But the real test of engineering change management is not whether an ECN was approved. It is whether the right hardware, at the right point in the build, at the right supplier, actually changed when and how it should.

For teams putting this topic into daily operation, execution systems for aerospace manufacturing, shop floor execution control, a connected execution platform help connect the concept to traceability, work-order reality, and audit-ready evidence.

This is where the gap appears between formal engineering change control and real execution. The headline metrics we track in aerospace programs rarely show how well changes are absorbed by production systems. The difference between a stable program and a fragile one often comes down to how repeatably you can push change through a live, regulated manufacturing environment without losing control of configuration.

The Nature of Engineering Change in Aerospace Programs

Aerospace hardware lives for decades. That longevity, combined with safety and regulatory expectations, makes engineering change both unavoidable and unusually high-stakes.

Drivers: safety, performance, cost, and obsolescence

Most significant aerospace engineering changes fall into one of a few categories:

• Safety and reliability: design corrections, fatigue findings, durability improvements, or corrective actions from incidents and test results.
• Performance and capability: weight reduction, fuel efficiency improvements, avionic upgrades, new mission variants, or customer-specific options.
• Cost and manufacturability: design for manufacturability and assembly (DFMA) updates, alternative processes, part consolidation, and yield-driven tweaks.
• Obsolescence and supply risk: discontinued components, changing export controls, or supplier exits that force redesign or alternate sourcing.

In all these cases, engineering change is not just a design activity. It is an operational event that must propagate through production systems, test, maintenance, and the supply chain while maintaining certification and traceability.

The volume and cadence of ECNs over long program lives

On a new or evolving platform, hundreds or thousands of ECNs can occur over the life of a program. Early years often see a heavy flow of changes as flight test findings, producibility feedback, and customer changes accumulate. Even mature programs see ongoing churn from obsolescence, regulatory updates, and incremental improvements.

This cadence matters because it reveals why one-off, manually coordinated change handling is fragile. If each ECN triggers ad-hoc email campaigns, spreadsheet impact logs, and one-time special instructions, the system will eventually miss something. The operational question is not can we execute this change? but can we execute change reliably, repeatedly, and predictably under load?

Implications for certified and flight-critical hardware

For flight-critical systems and safety-related components, the stakes are even higher. Configuration control is directly connected to airworthiness and regulatory approval. When a change affects:

• Primary structure,
• Flight controls, avionics, or propulsion interfaces, or
• Escape, fire protection, or other safety systems,

any misalignment between design intent and as-built configuration is not just a cost or schedule issue. It is a potential safety and certification issue.

This is why regulators and customers expect clean, auditable evidence that the right change was applied to the right hardware at the right time – not just a signed ECN in PLM.

Where Change Management Collides with Execution

Most aerospace organizations have mature engineering change workflows. The collision happens when those workflows meet real WIP, real schedules, and real suppliers.

ECNs approved in PLM but not reflected in work instructions

In many factories, engineering lives primarily in PLM and CAD, while execution lives in a combination of ERP, MES, work travelers, and local work instructions. When PLM issues an ECN, the translation into executable work is often partially manual:

• Manufacturing engineering updates routings and bills of material in ERP.
• Planners or industrial engineers update operation-level instructions in MES or document management systems.
• Supervisors communicate “use this new drawing” or “follow this deviation” on the floor.

Any latency or inconsistency in that translation creates a window where work can be started or completed using the wrong version of data. The PLM record says the change is effective; the actual instructions in front of the operator say something else.

WIP caught between old and new configurations

The hardest part of engineering change is rarely the future builds; it is the in-process work. Typical questions when a change lands:

• Which units can ship as-is under the previous configuration?
• Which assemblies must be reworked, and how invasive is that rework?
• Where is each serial number physically and process-wise in the build?
• Do we apply the change by effectivity date, shipset, or serial number range?

Without a system that can answer these questions in real time, teams often fall back to manual reconciliation of WIP travelers, spreadsheets, and tribal knowledge. That slows decisions and increases the probability that something slips through – a unit reworked unnecessarily, or worse, a unit that should have been reworked but was missed.

Suppliers building to outdated requirements

The same misalignment appears across the supply chain. Tiered aerospace supply chains frequently operate on:

• Released drawings and specs sent via portals or email,
• Purchase order references to configuration or revision, and
• Periodic pushes of updated documents, sometimes without clear effectivity rules.

If suppliers do not have a clear, system-backed view of which revision applies to which orders and serials – and if the OEM or integrator cannot see what configuration is actually being built – ECNs become a source of chronic confusion. It is common to discover parts in transit or in incoming inspection that are perfectly built to an old but no-longer-acceptable configuration.

Configuration Control Requirements in Regulated Environments

These operational collisions are not just internal headaches; they sit directly under aerospace quality and regulatory expectations.

AS9100 expectations for configuration management

AS9100 establishes clear expectations around configuration management, including identification and traceability, change control, and status accounting. In practice this means you must be able to show:

• How configurations are defined and baselined,
• How changes are reviewed, approved, and released, and
• How those changes are applied to specific hardware, with records to prove it.

Critically, configuration management in AS9100 is not only a design office concern. It extends into manufacturing, inspection, test, and supplier management. An ECN that cannot be traced cleanly into WIP, serial numbers, and supplier lots is a configuration risk, even if the PLM process is immaculate.

FAA/EASA implications when changes affect flight safety

When design changes touch aspects of the aircraft or system that are safety-significant, configuration evidence becomes part of the overall airworthiness case. Regulators expect that:

• The affected hardware is fully understood and controlled during transition.
• Test and conformity articles are clearly identified with their configuration state.
• Fielded equipment configuration can be traced back to approved design baselines.

Gaps between ECN intent and actual as-built configuration can ripple into service bulletins, retrofit campaigns, or in extreme cases, grounding and rework of in-service fleets. The cost and schedule impact of a configuration escape often dwarfs the cost of implementing the change correctly the first time.

Customer-specific configuration control practices

Defense and space customers often add another layer of configuration control expectations: contract-specific baselines, government-approved configuration items, and formal change boards with customer participation. For high-value flight hardware and classified programs, the ability to prove that a given serial number conforms exactly to the authorized configuration is non-negotiable.

This environment amplifies the need for an execution layer that can connect contract, configuration baseline, ECN, and as-built evidence without relying on manual reconstruction during audits or investigations.

The Role of the Execution Layer in Change Management

Bridging the gap between PLM-managed change and real production behavior requires a layer that understands where every unit is, what configuration it is supposed to be, and which instructions and materials are being applied at each step. That is the execution layer.

Identifying affected WIP, lots, and serial numbers in real time

When an ECN is approved, the first operational question is impact: which work, in which state, needs attention? An execution layer can answer this by holding:

• Serial-level or lot-level tracking of units and subassemblies,
• Their current operation or station, and
• The specific revision of instructions, BOMs, and specs applied at each step.

With that data, impact analysis shifts from a manual hunt to a query: “Show all hardware where operation X is complete under revision A, but ECN-123 requires revision B by shipset.” This is the difference between reacting slowly with spreadsheets and responding quickly with confidence.

Coordinating hold, rework, and scrap decisions

Once affected hardware is identified, teams must decide what to do with it. Some units can continue under old configuration, some must be held pending engineering disposition, others require specific rework, and in rare cases scrap is unavoidable.

An execution layer supports this by allowing coordinated actions against actual WIP:

• Placing holds at entity, lot, or operation level based on ECN impact.
• Attaching rework plans and deviations directly to affected serials.
• Capturing disposition decisions and their rationale for future traceability.

This is materially different from issuing a general “stop work” email and hoping local teams interpret it consistently.

Updating instructions and capturing evidence of correct configuration

Change only becomes real on the shop floor when the work instructions and checks in front of the operator reflect the new intent. An effective execution layer can:

• Link ECNs to specific operations, inspection steps, and data collections.
• Push revised instructions and control plans to the point of work with clear effectivity.
• Capture digital evidence (measurements, signoffs, test results) that the new configuration was built as intended.

The result is not just that change is executed; it is provably executed, with configuration evidence embedded in the production record, not reconstructed later.

Synchronizing PLM, ERP, and Shop Floor During Change

Most aerospace manufacturers rely on three primary system families: PLM for design and change, ERP for planning and commercial transactions, and various MES/quality systems for execution. During engineering change, these boundaries become pressure points.

Translating engineering changes into executable work

PLM is excellent at managing design data and formal change workflows, but ECNs must be translated into:

• Updated part numbers, revisions, and alternates in ERP,
• Changed routings and work centers, and
• New or modified work instructions and inspection plans.

If these translations are handled via disconnected uploads, PDFs, and manual data entry, it is almost guaranteed that change will hit the shop floor inconsistently. A connected execution layer can consume structured change data from PLM and drive updates into routings, instructions, and checks in a controlled, effectivity-aware way.

Managing effectivity dates and serial-level applicability

Effectivity is where theory and reality part ways. On paper, changes might reference:

• Calendar effectivity (after a certain date),
• Lot or batch numbers, or
• Serial number ranges and block points.

On the floor, this only works if the system executing work knows which unit is which, and which rule applies. An execution layer can act as the arbiter of effectivity, combining:

• PLM-declared effectivity logic,
• ERP order and delivery requirements, and
• Real-time WIP status and serial genealogy.

Without that, organizations fall back to blanket cutovers: “Everything started after this date uses the new design,” which often fails when long-travelers, rework, or out-of-sequence work are in play.

Ensuring suppliers receive and acknowledge updated requirements

Supplier synchronization is often the weakest link. Change packages might be pushed through portals, but acknowledgement and adoption are managed by email threads and status meetings. A more robust pattern is to treat suppliers as extensions of the execution layer:

• Expose current configuration requirements against specific orders and serials.
• Track which suppliers have accepted and implemented new revisions.
• Tie incoming inspection plans to expected configuration, with fast feedback when mismatches appear.

This does not require every supplier to run the same internal systems, but it does require a shared picture of configuration state that goes beyond static drawings.

Case-Style Scenarios of Better and Worse Change Handling

Abstract principles become clear when viewed through scenarios. The following examples are anonymized composites drawn from typical aerospace environments.

A change applied cleanly with full execution visibility

An integrator discovers a fatigue concern in a structural bracket. Engineering issues an ECN that changes material and adds an extra inspection step. The execution layer maps the ECN to affected assemblies and identifies:

• All WIP shipsets where the bracket has been installed under the old configuration.
• All upcoming work orders where the old bracket is planned but not yet installed.
• Supplier lots of the old bracket still in transit or stock.

Operations immediately places targeted holds on affected WIP, issues rework instructions to remove and replace brackets where necessary, and updates work instructions so future builds automatically route through the new inspection. Suppliers receive updated requirements tied to specific open orders. Within days, the organization can produce a clear list of serial numbers with old vs new configuration and the rework status of each.

A change misapplied due to missing WIP and supplier status data

In a different program, a similar bracket change is approved in PLM and cascaded via revised drawings. The ERP team updates part numbers, and a generic notice goes out to the shop and key suppliers. There is no shared system showing where brackets are installed or which supplier lots are in which assemblies.

Weeks later, incoming inspection identifies a mix of old and new brackets still arriving. A field issue triggers a deeper review, revealing that multiple aircraft left final assembly with the old bracket in positions that were supposed to be reworked. The team spends months reconstructing configuration from paper travelers, warehouse logs, and emails to determine which units must be inspected or modified in service.

The core failure is not engineering intent – it is the absence of an execution layer that could tie ECN, WIP, and supplier status together in real time.

Lessons learned for future change events

Across these scenarios, the same lessons emerge:

• Change velocity exposes execution maturity: processes that appear adequate under low change volume break down under real program pressure.
• WIP visibility is non-negotiable: you cannot control what you cannot see at the level of serials, lots, and operations.
• Suppliers are part of the configuration system: without integrated visibility into supplier adoption of change, your configuration story is incomplete.
• Evidence must be built-in: traceability that depends on reconstruction after the fact is fragile and expensive.

Designing a Repeatable Change-Execution Playbook

Closing the engineering change–execution gap is less about heroics and more about building a repeatable playbook, supported by the right execution infrastructure.

Standardizing impact analysis steps using execution data

A robust playbook starts with a consistent impact analysis pattern, driven by data rather than ad-hoc judgment. For each ECN, the organization should be able to answer quickly:

• Which part numbers, assemblies, and operations are affected?
• Which WIP units, by serial and location, intersect with those operations under the old configuration?
• Which inventory lots and supplier orders are tied to the old vs new design?

With an execution layer in place, these questions become queries and dashboards rather than war rooms and email chains.

Defining roles and responsibilities across engineering, quality, and operations

Process alone is not enough; roles must be clear. A typical pattern for aerospace change execution:

• Engineering owns design intent, ECN content, and effectivity rules.
• Manufacturing engineering/operations own translation into routings, instructions, and physical work changes.
• Quality owns risk assessment, additional controls, and verification that as-built configuration matches intent.
• Supply chain owns propagation and confirmation of change across external suppliers.

An execution layer gives each group a shared, live view of the same hardware and the same change event. That shared context is what turns roles into a coherent process rather than parallel activities.

How platforms like Connect 981 can support change orchestration

An aerospace-focused execution platform such as Connect 981 is designed to sit between planning systems and the real world of WIP, test, and suppliers. In the context of engineering change, that means:

• Ingesting structured ECN and configuration data from PLM.
• Maintaining serial-level and lot-level genealogy across operations and suppliers.
• Enforcing effectivity-aware work instructions and inspection plans at the point of work.
• Providing real-time visibility of impact, holds, and rework across the production system.

This does not replace PLM or ERP; it complements them by handling what they are not built to do: orchestrate change in a live, regulated execution environment. In the same way that headline program metrics hide the real execution system underneath, traditional engineering change metrics hide how hard it is to actually make change stick. The organizations that invest in a true execution layer are the ones that will be able to change fast without losing control of configuration.

Designing a Digital Manufacturing Architecture for Aerospace Execution

Aerospace manufacturers are under pressure to deliver more, faster, with tighter compliance and deeper traceability. Many already have PLM, ERP, MES, and quality systems in place, yet still struggle to answer basic questions in real time: What is actually happening on this program today? Where are we off-plan, and why? Which risks are accumulating in the supply chain right now? That gap between planning numbers and operational reality is the same visibility problem described in the execution-centric view argued in the scoreboard article—but now at the level of factory systems.

This article proposes a practical, technology-agnostic digital manufacturing architecture tailored to aerospace. It focuses on clear system roles, data boundaries, and integration flows, with a specific emphasis on introducing an execution layer that sits between planning systems and the real world of production. The goal is not a greenfield redesign, but a roadmap that works in brownfield, multi-site, and multi-supplier environments.

For teams putting this topic into daily operation, Connect 981’s aerospace execution solutions help connect the concept to traceability, work-order reality, and audit-ready evidence.

For teams putting this topic into daily operation, part genealogy and traceability, part traceability and as-built evidence help connect the concept to traceability, work-order reality, and audit-ready evidence.

The same operating model also depends on shop floor execution control, a connected execution platform, Connect 981’s aerospace operations guidance, practical aerospace operations FAQs, especially when decisions have to move across quality, production, suppliers, and program leadership without losing context.

The Current State of Digital Manufacturing in Aerospace

Typical system inventories at OEMs and larger suppliers

Most aerospace OEMs and tiered suppliers already operate a dense landscape of systems. A typical inventory includes:

• PLM and PDM for engineering data, configurations, changes, and controlled technical documentation.
• ERP for demand, MRP, capacity planning, purchasing, inventory, and financials.
• MES or shop-floor systems for work dispatching, data collection, and sometimes machine integration.
• Quality systems (QMS, eQMS, NCR/FRACAS tools) for inspections, non-conformances, concessions, corrective actions, and approvals.
• Point solutions for tooling, calibration, maintenance, document control, and test systems.

Each of these systems solves a real problem, often very well. The challenge is that they rarely form a coherent operational picture. Program leaders, industrialization engineers, and production managers end up assembling their own view through spreadsheets, status meetings, and ad hoc dashboards.

Pockets of automation alongside manual islands

A common pattern is deep automation in small pockets (for example, a highly automated machining cell or test facility) surrounded by manual coordination. Operators may log data digitally, but routing changes, rework decisions, and schedule recovery plans often move via email, shared drives, or side conversations.

This creates islands where data exists, but is not connected. A machine may be perfectly integrated to an MES, yet program management has no live visibility into whether today’s critical serial numbers are on track, blocked by quality, or waiting on supplier hardware.

Integration gaps that directly impact execution clarity

From an execution standpoint, the most damaging gaps are usually not missing systems, but missing contextual integration. Examples include:

• PLM sends BOMs and routings to ERP, but late engineering changes are not reliably propagated to the work instructions on the floor.
• MES collects operation completions, but ERP still shows the plan until someone manually reconciles exceptions.
• Quality holds and concessions live in a separate system, so planners cannot see which orders are blocked in real time.
• Supplier status is maintained in portals or emails, not as structured, machine-readable signals tied to specific assemblies and serial numbers.

The result is a fragmented view of reality. KPI dashboards may look healthy, while the true execution system is fighting fires. Closing this gap requires treating the execution layer as a first-class architectural component.

Core System Roles in Aerospace Manufacturing

PLM as design and configuration authority

In regulated aerospace, PLM is the design authority. It owns product definitions, configurations, CAD, controlled documents, and engineering change processes. PLM defines what is allowed to be built and under which configuration rules.

For a digital thread to function, PLM must clearly expose authoritative structures: engineering BOMs, manufacturing BOMs, routings, and approved work instructions. Downstream systems should not be re-creating these structures independently; they should consume them via controlled interfaces with explicit versioning, effectivity, and change control.

ERP as planning and financial backbone

ERP is the planning and financial backbone. It translates product definitions into demand, supply, capacity, and cost. It drives MRP, purchasing, lead times, and production orders. However, ERP fundamentally operates on planned states and summarized events.

In aerospace, this distinction is crucial. ERP knows what should have happened: which work orders should be in which status and when. It is not designed to track every micro-state, rework loop, or configuration-specific deviation at the level required for certification and root-cause analysis.

MES and plant systems for local control and data collection

MES and plant systems typically orchestrate work within a facility: dispatching operations, collecting inspection results, interfacing with equipment, and enforcing some aspects of process control. In many aerospace plants, legacy MES implementations are tightly coupled to specific lines or technologies, and their data models mirror local needs rather than program-wide visibility.

A well-implemented MES is vital, but it is still plant-centric. It usually lacks a program- and configuration-centric view that spans multiple sites and external suppliers. This is where an explicit execution layer becomes necessary.

Quality systems for inspections, NCs, and approvals

Quality systems are the backbone of compliance: they capture non-conformances, concessions, corrective actions, inspection plans, and audit evidence. In AS9100 and similar environments, they must remain authoritative for these records.

The architectural challenge is that quality events are often logged after the fact or in systems disconnected from live production status. That makes it hard to see, in real time, which serial numbers or assemblies are blocked, under concession, or carrying elevated risk. The execution layer has to surface quality status as part of the operational picture without compromising the QMS as the system of record.

Introducing the Execution Layer as a First-Class Component

Why existing systems struggle to represent live operational context

Most aerospace organizations discover that even with mature PLM, ERP, MES, and QMS, they still cannot reliably answer questions like:

• For this program, which serial numbers are currently in process, where are they physically, and who is working on them?
• Which operations are blocked by missing parts, tooling issues, or quality holds, and what is the downstream schedule impact?
• How many deviations from standard work have occurred this week, and how are they distributed across suppliers and sites?

The reason is architectural: each system holds a piece of the puzzle, but none is responsible for assembling current execution context across the entire value stream. That is the job of an explicit execution layer.

Execution layer responsibilities distinct from MES and ERP

A dedicated execution layer should not try to become another MES or another ERP. Its distinct responsibilities typically include:

• Live orchestration and status: maintaining a single, near-real-time model of every order, operation, and serial number across plants and key suppliers.
• Contextualizing data: joining work orders, configurations, quality events, and supplier signals into a coherent timeline per unit or lot.
• Exception management: making deviations from plan (delays, rework, holds, missing material) visible quickly and in the right context.
• Embedded traceability: capturing genealogy and process evidence as work happens, rather than reconstructing it later.

In other words, the execution layer is the operational nervous system that connects planning intent to what is actually happening, minute by minute.

Supporting multi-site and multi-supplier coordination

Aerospace programs are almost always multi-site and multi-supplier. An execution layer must therefore be designed for federated visibility from the outset. That means:

• Normalizing key identifiers (part numbers, serials, lots, orders) across organizations.
• Defining data contracts with suppliers that expose status, quality events, and certification documents in structured form.
• Handling different levels of system maturity—some suppliers may have MES, others may only have spreadsheets.

Platforms like Connect 981 operate in this space: not by replacing existing systems of record, but by serving as the execution fabric that links them into a coherent operational picture.

Key Data Flows in a Connected Aerospace Architecture

From PLM to execution: configurations, BOMs, and work instructions

The first critical flow is from PLM to the execution layer. Key elements include:

• Configuration structures (engineering and manufacturing BOMs) with clear versioning and effectivity.
• Process definitions: routings, operation sequences, key characteristics, and inspection plans.
• Controlled work instructions and reference documents that must be available at the point of work.

The execution layer does not re-author this data; it consumes it as authoritative, then maps it to specific orders, serial numbers, and sites. When engineering changes occur, the execution layer should be able to show exactly which in-process units are impacted and where rework or special instructions are required.

From execution to ERP: completions, variances, and schedule impact

The second major flow runs from the execution layer back to ERP. ERP needs summarized events: operation starts and completions, scrap, yield, and sometimes high-level reasons for variance. The execution layer should:

• Capture detailed execution events and statuses in its own model.
• Translate those events into the coarser transactions ERP expects.
• Push schedule-relevant status updates early enough that planners can adjust, rather than learning about delays after the fact.

This preserves ERP’s role as the planning backbone while ensuring its view of progress reflects what is actually happening on the floor and across suppliers.

From quality systems to execution: holds, concessions, and approvals

Quality systems remain the system of record for non-conformances, concessions, and approvals. However, the execution layer must be aware of their impact on work. Architecturally, this usually means:

• Quality events are created and managed in the QMS.
• The execution layer subscribes to these events via an integration, enriched with identifiers such as serial numbers, work orders, and affected operations.
• The execution layer enforces the operational consequences: holds, rework routing, special inspections, or additional approvals.

This separation preserves auditability while ensuring that quality decisions have an immediate and visible impact on execution.

From suppliers to OEMs: status, genealogy, and certification data

Supply chain visibility is often the weakest part of aerospace architectures. A mature execution layer should support:

• Status updates for critical parts and assemblies tied to specific orders and serials.
• Genealogy data at the level of lot, batch, and key serialized components.
• Certification artifacts (CoCs, test reports, inspection records) attached to the right units in a machine-readable way.

For suppliers with limited digital capabilities, this may start as structured data submissions via controlled templates or lightweight portals. Over time, deeper system-to-system integrations can be introduced, but the architecture should not assume all sites start at the same maturity level.

Governance, Ownership, and Change Control

Defining system-of-record responsibilities

One of the most important architectural decisions is clarifying system-of-record boundaries. A practical pattern for aerospace is:

• PLM is the system of record for product definition, configurations, and controlled engineering documents.
• ERP is the system of record for demand, orders, inventory, and financial transactions.
• QMS is the system of record for quality events, approvals, and audit trails.
• Execution layer is the system of record for current operational state: where each unit is, what has been done, and which exceptions are active.

Being explicit about these roles avoids duplication and helps resolve disputes when data disagree across systems.

Managing master data across organizational boundaries

Aerospace architectures often fail not because of interfaces, but because of inconsistent master data. Practical steps include:

• Adopting clear, shared identifiers for parts, configurations, serials, and orders.
• Defining who owns which reference data (e.g., part families, operation codes, defect codes) and how changes propagate.
• Ensuring that suppliers receive and return identifiers that can be reconciled across systems.

The execution layer can help here by acting as the place where inconsistent identifiers are mapped and reconciled, but it cannot fix master data without a governance process.

Handling upgrades and new capabilities without disrupting operations

Given the long life of aerospace programs, architectures must tolerate system upgrades and replacements. An interface-first, execution-centered design helps by:

• Decoupling core execution logic from any single MES or ERP implementation.
• Using stable APIs and data contracts at the execution layer boundary.
• Allowing local systems to evolve, as long as they continue to honor those contracts.

This approach reduces the risk that a plant-level MES replacement or ERP upgrade will destabilize program-level visibility.

Building the Architecture Incrementally

Starting with critical programs or product families

Attempting to re-architect the entire enterprise at once is rarely feasible. A more workable approach is to start with one critical program or product family where visibility gaps are already painful. For that scope, define:

• The minimum set of systems that must participate (PLM, ERP, QMS, key suppliers, key plants).
• The execution questions that must be answerable in real time (e.g., status by serial number, critical path operations, open concessions).
• The data flows required to answer those questions reliably.

Once the execution model for that program is stable, you can extend patterns and integrations to adjacent programs and suppliers.

Interface-first approaches to connecting legacy systems

Brownfield aerospace environments contain many legacy systems that cannot be easily replaced. An interface-first strategy acknowledges this reality:

• Identify where each system already emits useful data (reports, exports, log files, APIs) and how often.
• Wrap those outputs in adapters that normalize them to the execution layer’s data model.
• Prioritize bidirectional interfaces where immediate feedback is valuable (e.g., quality holds that must stop work).

This allows the execution layer to emerge without requiring big-bang system changes. Over time, some legacy components can be simplified or retired as their roles are subsumed into better-aligned platforms.

Patterns for introducing platforms like Connect 981

When introducing an execution platform such as Connect 981, the risk is often organizational rather than technical. Productive patterns include:

• Framing it as the execution fabric, not another system of record that competes with PLM or ERP.
• Aligning with compliance needs: using early pilots to prove that embedded traceability and live status reduce audit effort.
• Anchoring pilots in measurable problems: schedule adherence on a key program, reduced time-to-detect for escapes, or compressed response time to supplier disruptions.

The goal is to build confidence that the execution layer improves control without forcing disruptive rip-and-replace strategies.

Measuring Success of a Digital Manufacturing Architecture

Execution-oriented metrics: visibility, traceability, and response time

Success for this architecture should be measured in execution outcomes, not just IT milestones. Useful metrics include:

• Time required to determine the exact status of any unit or lot on a program.
• Coverage and completeness of digital traceability, including suppliers.
• Average time from issue detection (quality, material, process) to containment and plan adjustment.

These metrics directly reflect whether the execution layer is closing the gap between plan and reality.

Compliance and audit outcomes

In regulated aerospace environments, architecture should also be judged by compliance friction. Indicators include:

• Reduction in manual effort to assemble evidence for audits.
• Fewer late discoveries of missing records or incomplete traceability.
• Ability to answer auditor questions by navigating live data rather than reconstructing history.

When the execution layer is working, audit readiness becomes a byproduct of normal operations instead of a periodic crisis.

Supplier and site adoption indicators

Finally, a digital manufacturing architecture only delivers its full value when suppliers and sites adopt it. Leading indicators include:

• Percentage of critical suppliers providing structured status and genealogy data through defined interfaces.
• Sites using the execution layer as their primary view of work status, rather than private spreadsheets.
• Cross-functional teams (engineering, quality, supply chain) referencing a shared execution view in decision-making.

These behaviors show that the architecture has moved beyond an IT project and become an operational asset.

From Fragmented Systems to a Connected Execution Architecture

Aerospace performance is increasingly determined not by isolated system capabilities, but by how well those systems are connected into a coherent execution picture. PLM, ERP, MES, and QMS each have essential roles, yet none by itself can provide the operational clarity and embedded traceability that modern programs demand. That requires an explicit execution layer—an architecture that treats real-time context, exceptions, and genealogy as primary objects.

By advancing toward this architecture incrementally—program by program, supplier by supplier—organizations can move from the misleading comfort of high-level scoreboards to a grounded understanding of how their production systems actually behave. That shift, more than any single technology, is what will differentiate stable aerospace manufacturers from those constantly surprised by their own systems.

Implementing ISO 22400: Practical Steps to Standardize Manufacturing KPIs

ISO 22400 gives aerospace and defense manufacturers a common language for manufacturing KPIs, but the standard does not tell you how to roll it out across MES, ERP, historians, and supplier portals. Turning its concepts into repeatable practice requires a structured implementation approach that respects existing systems, AS9100 processes, and the realities of multi-site aerospace production. This guide focuses on practical, non-vendor-specific steps to adopt the ISO 22400 manufacturing KPI framework inside a regulated aerospace manufacturing environment.

The goal is not formal certification. Instead, the emphasis is on making KPI definitions consistent across plants, programs, and partners so that “availability,” “utilization,” and order-related indicators mean the same thing in every system and report. Done correctly, ISO 22400 becomes part of your digital thread, not a competing structure.

For teams putting this topic into daily operation, industrial security evidence, security and compliance requirements, a connected execution platform help connect the concept to traceability, work-order reality, and audit-ready evidence.

The same operating model also depends on Connect 981’s aerospace execution solutions, real aerospace execution examples, Connect 981’s aerospace operations guidance, practical aerospace operations FAQs, especially when decisions have to move across quality, production, suppliers, and program leadership without losing context.

Assessing Your Current KPI Landscape

Inventorying existing KPIs and definitions

The starting point for ISO 22400 implementation is a realistic picture of the KPIs you already use. In a typical aerospace or space hardware program, KPIs are scattered across:

• MES dashboards monitoring work centers, takt performance, and rework rates
• ERP and MRP reports on schedule adherence, order lead time, and WIP age
• QMS and nonconformance systems tracking defect rates, escapes, and MRB cycle times
• Maintenance systems tracking equipment downtime and mean time between failures
• Excel-based “shadow systems” created by program teams and industrial engineers

Create a structured KPI inventory that captures at least:

• KPI name as used today (for example, “machine uptime,” “line utilization,” “on-time to promise”)
• Formal or informal definition, including what is in or out of scope
• Calculation description or formula (even if only documented in a spreadsheet)
• Data sources and systems (MES, historian, ERP, QMS, manual entry)
• Organizational owner (operations, quality, program office, finance)
• Where it is visible (reports, dashboards, SLAs, customer scorecards)

For aerospace organizations running multiple sites or supporting multiple OEM programs, capture which sites or programs use each KPI. Many inconsistencies only appear when comparing KPI catalogs across factories or business units.

Identifying inconsistent terms across plants and systems

With the inventory assembled, the next step is to surface inconsistent terminology. In aerospace production, this often appears in three patterns:

• Same name, different meaning – for example, one plant labels a KPI “availability” but includes scheduled maintenance in the denominator, while another excludes it.
• Different name, same meaning – for example, “uptime” in one system and “run time” in another both correspond to the same operating state.
• Different aggregation logic – for example, OEE calculated at the equipment level in one plant and at the line level in another, but reported as a single corporate metric.

Document these conflicts explicitly. ISO 22400 implementation is largely the process of resolving them and aligning to the standard’s definitions for time categories, states, and indicator semantics. Pay particular attention to KPIs that appear in:

• Customer-facing reports or contract deliverables
• Regulatory or airworthiness-related metrics (for example, defect escape rates)
• Executive dashboards and board-level reporting

These are the KPIs where ambiguity is most costly and where alignment with ISO 22400 will have the greatest impact on clarity and comparability.

Mapping Existing KPIs to ISO 22400 Concepts

Renaming vs. re-defining KPIs

Once you understand your current KPI landscape, the next step is to map those KPIs onto ISO 22400 concepts. The standard provides structured definitions for performance indicators and KPIs based on equipment states, time categories, and quantity-based measures. For each existing KPI, ask:

• Does ISO 22400 define a directly comparable KPI (for example, an availability or utilization concept)?
• If so, is our current definition materially aligned, or are there meaningful differences in scope or time basis?
• If not, is our KPI a useful extension (for example, a specific aerospace traceability or certification metric)?

In practice, you will end up with three categories of KPIs:

1. Aligned KPIs – Current definition closely matches an ISO 22400 KPI. Here, you can retain the definition and, if needed, adopt ISO 22400’s naming and attribute conventions.
2. Adjustable KPIs – KPIs that can be brought into alignment with limited changes, such as slightly adjusting time categorizations or clarifying which equipment states are included.
3. Non-standard KPIs – Aerospace- or program-specific KPIs that serve important purposes but are outside ISO 22400’s scope (for example, certification batch release lead time, or first article inspection queue time).

For the first two categories, decide whether you will:

• Rename the KPI to match ISO 22400 terminology while keeping the underlying logic essentially the same, or
• Re-define the KPI to fully conform with the ISO 22400 concept, updating the calculation logic and documentation.

Renaming is less disruptive but can leave subtle inconsistencies if the underlying logic still diverges from the standard. Re-defining offers better interoperability but requires more careful change management and stakeholder communication.

Dealing with near-duplicates (availability vs. uptime)

Near-duplicate KPIs are common in aerospace factories that have grown through acquisitions or that support different OEM programs with separate reporting expectations. A classic example is “availability” versus “uptime,” both attempting to describe how much of the planned time equipment spends in productive states.

ISO 22400 helps by providing precise definitions for equipment states (e.g., RUN, STOP, IDLE, SLOW) and the time categories derived from them. To reconcile near-duplicates:

1. Express each existing KPI in terms of ISO 22400 states and times (for example, “uptime” = RUN time only; “availability” = RUN + IDLE over planned time).
2. Identify which KPI best aligns with the ISO 22400 availability or utilization concept.
3. Standardize on that definition and make the alternative an alias or a retired KPI.

In aerospace, be especially rigorous with KPIs used in customer contracts or offset agreements. If an OEM contract references “equipment availability” for a nacelle line or composite layup cell, you should ensure the governing definition is explicitly mapped to the ISO 22400 concept and unambiguous across all reporting tools.

Adapting Data Models and Interfaces

Aligning equipment states and time categories

Conceptual alignment is only effective if your data models support it. ISO 22400 relies heavily on equipment states and their associated times. In practice, this means standardizing how signals from machines, test stands, and assembly cells are translated into high-level states across all plants.

For an aerospace environment with diverse equipment (CNC machining centers, autoclaves, bonding ovens, engine test cells, structural assembly lines), the implementation steps typically include:

• Defining a canonical set of equipment states aligned with ISO 22400 (for example, RUN, STOP-planned, STOP-unplanned, IDLE, SETUP, SLOW).
• Mapping PLC or control system signals into those states in a consistent way, even if different OEMs use different tags.
• Ensuring that historians and MES capture time in each state at an appropriate granularity.
• Deriving standardized time categories (planned time, busy time, operating time, downtime) from those states.

Because aerospace production frequently includes long-cycle, high-mix operations, state definitions must also consider:

• Setup and changeover for configuration changes and engineering effectivity
• Waiting states due to missing certifications, FAI completion, or quality hold
• Planned pauses due to coordination with external test facilities or customer inspections

Your implementation should make these distinctions explicit so that KPIs derived from state times remain interpretable by both operations and compliance teams.

Updating MES, ERP, and historian data schemas

After aligning states, you need to ensure that the underlying data models can express ISO 22400 KPIs cleanly. This does not require replacing existing systems, but it does typically involve schema extensions and interface adjustments. Common changes include:

• Adding standardized KPI identifiers and attributes to MES and reporting databases.
• Introducing explicit fields for ISO 22400 time categories instead of inferring them in every report.
• Tagging KPIs as ISO 22400-aligned versus organization-specific extensions.
• Harmonizing units of measure and timestamp conventions across systems (especially important in multi-site, multi-time-zone aerospace networks).

For ERP systems that manage orders and work breakdown structures, you may need to:

• Align production order and operation identifiers with the objects of measurement defined in ISO 22400.
• Ensure that order-level and equipment-level KPIs can be linked, enabling analysis of how equipment performance affects program schedule adherence.

A digital manufacturing platform such as Connect 981 can sit above existing MES, QMS, and ERP systems, mapping their native data structures into an ISO 22400-aligned KPI model. This approach allows you to standardize KPI semantics without forcing a single vendor stack across the entire enterprise or supply chain.

Governance: Owning and Maintaining KPI Definitions

Creating a KPI data dictionary and ownership model

ISO 22400 implementation fails quickly if KPI definitions drift over time. To prevent this, establish a formal KPI data dictionary and governance model that treat KPI definitions as controlled data assets, similar to engineering configurations or process specs.

Your KPI data dictionary should include, at minimum:

• The KPI name and unique identifier
• A clear, ISO 22400-based conceptual definition
• Mathematical expression or calculation logic
• Object of measurement (equipment, line, work center, area, site, order)
• Applicable time behavior, units of measure, and expected range
• Data sources and system-of-record
• Primary user groups (operators, manufacturing engineering, program management, executives)

Treat the dictionary as a controlled document or database under configuration control. Assign explicit ownership, typically through a cross-functional KPI governance board that includes operations, quality, IT/OT, and program representation. In AS9100 environments, the KPI dictionary often integrates with existing document control and change management processes.

Change management for KPI definitions and dashboards

Because KPIs influence decisions, incentives, and sometimes customer penalties, changing a KPI definition is a significant event. Your governance model should define:

• How KPI changes are proposed, reviewed, and approved
• How version history is maintained, including effective dates for each definition
• How changes propagate into reports, dashboards, and interfaces
• How historical data is handled (recalculated, re-labeled, or left unchanged with clear cutover markers)

In practice, this often means adopting a release cadence for KPI changes (for example, quarterly) and treating KPI updates like software or process changes. For aerospace programs with strict contractual reporting, align KPI definition changes with contract cycles or explicit customer agreement to avoid disputes over performance metrics mid-program.

Training Stakeholders on ISO 22400 Concepts

Educating operators, engineers, and managers

Standardized KPIs only deliver value if stakeholders understand what they mean and trust them. ISO 22400 concepts must therefore be embedded into everyday language on the shop floor and in program reviews.

Training should be tailored by role:

• Operators and cell leads need to understand equipment states, why accurate state entry matters, and how their actions affect KPIs such as availability and utilization.
• Manufacturing and industrial engineers need deeper knowledge of time categories, data models, and how their process changes might impact KPI definitions.
• Program managers and executives need clarity on how site-level and equipment-level ISO 22400 KPIs roll up to program performance views and what is and is not comparable across plants.

Use real examples from your own aerospace lines—such as a composite layup cell, an engine test bay, or a structures assembly station—to illustrate how states, times, and KPIs interact. This grounding avoids the perception that ISO 22400 is an academic overlay disconnected from day-to-day operations.

Communicating changes to suppliers and customers

Aerospace and defense production depends on a complex, regulated supply chain. When you change KPI definitions, your suppliers and customers can be affected, especially if KPIs appear in contracts, supplier scorecards, or performance-based logistics agreements.

For key partners, consider providing:

• A summarized ISO 22400-aligned KPI catalog you intend to use
• Clear mapping from any previously used KPIs to the new definitions
• Transition timelines and how historical performance will be treated

Some organizations use a digital manufacturing platform as a shared lens where both internal teams and suppliers can see KPI definitions and values aligned to the same ISO 22400 semantics. This approach minimizes misunderstandings when comparing performance across different factories or supplier tiers.

Example Implementation Timeline and Pitfalls to Avoid

Phased rollout across sites and systems

ISO 22400 implementation is best approached as a phased program rather than a single “big bang,” especially in multi-site aerospace networks with legacy systems. A typical pattern might look like:

1. Pilot scope definition – Select one value stream or product family (for example, a specific engine model, satellite program, or structural assembly line) and a constrained set of KPIs (for example, availability, utilization, order execution reliability).
2. Discovery and mapping – Complete the KPI inventory, mapping, and data model alignment for the pilot scope, including necessary MES/historian tweaks.
3. Governance and training – Stand up the KPI data dictionary, governance structure, and targeted training for the pilot stakeholders.
4. Pilot operation – Run with ISO 22400-aligned KPIs in parallel with existing reporting for a defined period to build trust and validate behavior.
5. Scale-out – Extend to additional lines, plants, or supplier tiers, reusing the data models and governance patterns built in the pilot.

Timelines will vary by organization size, system complexity, and regulatory constraints. The key is to preserve consistency of definitions while allowing local implementations to adapt to specific equipment, processes, and certification requirements.

Common mistakes in ISO 22400 adoption

Several common pitfalls tend to derail ISO 22400 initiatives in aerospace and defense manufacturing:

• Treating ISO 22400 as a reporting project only – Focusing solely on dashboards and ignoring the underlying state models and data quality leads to attractive visuals with inconsistent semantics.
• Over-customizing the standard – Adding many local variants of KPIs with subtle definition differences defeats the purpose of standardization and complicates multi-site comparisons.
• Underestimating change impact – Changing KPI definitions without careful communication can undermine trust from program teams and external partners who rely on year-over-year comparability.
• Ignoring non-standard but critical KPIs – For aerospace-specific indicators (for example, part genealogy completeness metrics or airworthiness sign-off cycle time), the goal is coexistence with ISO 22400, not forced alignment where it does not fit.

A disciplined approach that distinguishes between ISO 22400-aligned KPIs and intentional, well-documented extensions gives you the benefits of standardization without constraining necessary aerospace-specific measures.

Bringing ISO 22400 into the Aerospace Digital Thread

ISO 22400 does not replace your AS9100 processes, digital thread initiatives, or engineering change control. Instead, it supplies a shared vocabulary for performance measurement that can be woven through existing systems and workflows. When equipment states, time categories, and KPI definitions are standardized, it becomes easier to connect events in design, planning, execution, and quality into a coherent performance narrative.

Platforms like Connect 981 can implement ISO 22400-aligned KPI structures as part of a broader aerospace digital operations layer, tying together MES, ERP, QMS, and supplier data without forcing a single monolithic solution. The standard defines what KPIs mean; your organization decides which ones matter, how aggressively to target them, and how they support safe, compliant, and efficient aerospace production.

Most FAI debates do not start with bad intent. They start with a drawing revision, a supplier move, a long production gap, or a customer note buried in a purchase order. This guide answers when is full fai required, when a partial fai is enough, and how aerospace teams can make that decision without turning every change into a program delay.

Fast Answer: When Is a Full First Article Inspection Mandatory?

A full first article inspection is required when the prior baseline no longer proves that the article meets all engineering, manufacturing, and customer requirements. AS9102C, released on 2023-06-28, is the current aerospace reference, and customer flowdowns can be stricter than the standard.

A full FAI is required during new product introduction, production gaps, significant changes, major process overhauls, or customer demand for a re-baseline of quality data. If minor modifications are made, a partial or Delta FAI, focusing only on affected characteristics, is used instead of repeating the full FAI process.

Core triggers include:

• New part number, new first article, or first build to a customer design.
• Design change affecting fit, form, function, safety, or performance.
• Production lapse of 24 months or more, unless customer requirements define another interval.
• New site, new primary equipment, or new production process route.
• Change of material, source, or key special process, such as heat treat, plating, bonding, or welding.
• Customer-directed full FAI on the contract, purchase order, corrective actions plan, or approval process.

A full FAI covers the entire drawing and full characteristic accountability. A partial FAI covers only affected characteristics and links back to the baseline first article inspection report.

Full vs Partial FAI: Clear Definitions and Boundaries

A First Article Inspection (FAI) is a comprehensive review of the engineering documentation and the manufacturing process from raw materials through conversion and functional testing for one part. The AS9102 standard, developed by the International Aerospace Quality Group (IAQG), outlines the requirements for First Article Inspection in the aerospace industry, ensuring that all aspects of design, manufacturing, and inspection are verified and documented.

A complete fai includes:

• Ballooned engineering drawings or 3D models with every design characteristic, material note, surface finish, and specification requirement identified.
• A complete article inspection report FAIR using the three forms: Form 1, part number accountability form; Form 2, product accountability; Form 3, characteristic accountability with measured values.
• Compatibility evaluation against the latest design records, specification requirements, documentation requirements, and purchase order.

A partial FAI includes:

• Only new or revised dimensions, notes, materials, inspection methods, or production process changes.
• A FAIR that references the original baseline article inspection report by number and date.
• Evidence that unchanged tooling, calibrated tools, coordinate measuring machines, and inspection plan remain controlled.

Boundary example: a design note clarification with no functional effect usually supports partial FAI. A new machining center and fixture for the same part may require full FAI because the manufacturing environment changed.

Trigger Matrix: When a Full FAI Is Required vs When Partial Is Enough

Use a trigger matrix during supplier review, quality control, and formal approval. It gives responsible parties a consistent way to decide the required article inspection level.

Event

Impact

Typical decision

Notes

New Airbus A320neo bracket

No baseline

Full FAI

New first article inspection requirement

Hole location or tolerance change

Fit or function

Full FAI

Assembly risk

Drawing typo correction

Documentation only

Partial FAI

No change to specified requirements

New forging supplier for landing gear

Material and safety

Full FAI

Supply chain risk

Deburr clarification or cosmetic surface finish

Cosmetic only

Partial FAI

Unless CTQ

Flight control link restarted after 30 months

Lapse

Full FAI

Revalidate process and fai report

Standard inspection only

No change

No FAI

Normal inspection results still recorded

Default to full FAI if risk is unclear. That rule reduces non conformances, audit debate, and late customer rejection.

First Article Inspection is crucial in industries such as aerospace, defense, and automotive, where precision and quality are paramount, helping to prevent defects and ensure products meet design and performance criteria from the outset of production. The same risk logic appears in other regulated industries, including a medical device production run where a component fails and the team must prove the production process remains valid.

Design Change Triggers: Do All Design Changes Require a Full FAI?

No. AS9102C and most OEM specifications distinguish between changes that affect fit, form, function, safety, or performance and changes that are editorial.

Full FAI is normally required when a design revision:

• Adds or relocates mating interfaces, mounting holes, or datum schemes.
• Changes CTQ tolerances, GD&T, or key components.
• Adds functional requirements for pressure, load, vibration, leakage, electrical paths, or functional testing.

Partial FAI is commonly used when the change is limited to:

• Clarified inspection methods without changing the requirement.
• Spelling, unit symbols, or reference document numbers.
• Removal of unused reference dimensions while retaining the functional scheme.

Before deciding, confirm all routings, digital work instructions, CNC programs, CMM programs, and engineering documentation match the new revision. Some OEMs, including Boeing through D6-51991 practices and primes using advanced product quality planning or AS9145, may require full FAI for any revision on high criticality parts.

Process, Tooling, and Location Changes: When Production Lapses and Restarts Matter

AS9102C treats significant process and context changes as renewed article inspection triggers even when the drawing did not change. The question is whether the prior first article inspection fai still represents the actual production process.

Full FAI is typical for:

• Moving production to a different facility.
• Switching manual machining to five axis CNC, a new molding press, or a new welding cell.
• Replacing key fixtures that locate CTQ features.
• Introducing automation that changes process capability.

A common aerospace rule is that if manufactured parts have not been produced for 24 months or more, full FAI is usually required unless the customer specifies a shorter or longer interval. An actuator housing last built in 2021 and reordered in 2024 should receive full FAI to revalidate the article inspection process and article inspection report fair.

Partial FAI may be reasonable for documented minor tool wear replacement or non-critical cleaning changes. Connect981 can track last-production dates, routing changes, tooling IDs, and production process changes so teams can quickly see whether a full or partial FAI is required.

Material, Special Process, and Supplier Changes: Article Inspection Requirement Impacts

Material and special process changes are frequent sources of escapes. Full FAI is usually required for:

• Alloy or material specification changes, such as 7075-T6 to 7050-T7451.
• Material form changes, such as bar to forging or casting.
• New material supplier for structural or safety-critical parts.

Special process changes also matter. Heat treat, NDT, anodizing, plating, bonding, welding, curing cycle, temperature, or atmosphere changes should trigger re-validation and updated article inspections. If the change may affect performance, fatigue, corrosion, sealing, or safety, default to full FAI. If only a localized coating changes with no CTQ impact, partial FAI may be acceptable with customer approval.

Form 2 must be updated with new certifications, source approvals, test results, and product accountability evidence.

Customer, Regulatory, and Corrective-Action Driven Triggers

First Article Inspection (FAI) is mandated by various industry standards, including AS9100 for aerospace, which requires compliance with specific quality management practices to ensure that products meet design specifications before full production. FAI enhances regulatory compliance, as it is a mandatory requirement for many manufacturing sectors, including aerospace and automotive, ensuring that manufacturers meet critical regulations and standards.

Customer-driven triggers include:

• PO or quality clause requiring “AS9102 full FAI with Forms 1–3.”
• OEM-specific checks, such as BFAI, Boeing First Article Inspection.
• APQP, PPAP, or production part approval process gates.

Corrective-action triggers include:

• Escape or major nonconformance showing the original FAI is no longer valid.
• Repeat defects on CTQ features requiring containment, root cause, and full revalidation.

Audits, DER or UMAR approvals, NADCAP findings, AS9100 gaps, and safety-of-flight issues may also force retroactive full FAIs. Transparent article inspection reports help preserve customer confidence.

Supplier Decision Logic: How to Choose Full vs Partial FAI in Practice

Suppliers need repeatable fai procedures, not ad hoc judgment. A practical path is:

1. Check AS9102C, contract, customer requirements, quality requirements, and purchase order.
2. Classify the trigger: new part, design revision, process change, material change, location change, lapse, or corrective action.
3. Assess fit, form, function, safety, regulatory impact, and whether the article meets all specified requirements.
4. Use an internal matrix to choose full FAI, partial FAI, or no FAI, then document the rationale.
5. Get customer concurrence when selecting partial FAI for borderline cases.

High criticality parts such as flight controls, landing gear, pressure vessels, and structural sub component assemblies should lean toward full FAI. Low-risk covers or brackets may justify partial FAI for minor changes. The decision record should ensure traceability and support future audits.

What a Full FAI Actually Includes: Article Inspection Process and FAIR Content

Once triggered, the first article inspection process must follow a structured inspection process. Utilizing a full FAI can help detect errors, tooling misalignments, or misunderstood specifications before mass production begins, mitigating expensive scrap, rework, and recalls.

The article inspection process includes:

• Validate latest drawings, models, specifications, design specifications, and purchase order requirements.
• Balloon every dimension, material requirement, note, and surface finish.
• Execute dimensional, visual, material, and functional tests using calibrated tools, gages, NDT, and coordinate measuring machines.
• Record measured values, inspection results, pass or fail status, and approval signatures.

The First Article Inspection Report (FAIR) serves as a formal record of the inspection and provides crucial information to both the manufacturing entity and the customer, including inspection details, results, and approval signatures. The First Article Inspection Report (FAIR) is a critical document that summarizes the findings of the FAI process, including inspection results, non-conformance issues, and approval signatures, and is essential for compliance with industry standards.

Good FAIRs improve the approval process, ensure accuracy, support compatibility evaluation, and help both the manufacturer and the customer avoid disputes.

Avoiding Over-Inspection and Under-Inspection: Practical Risk Balancing

Full FAIs consume time. Under-inspection creates escapes. First Article Inspection (FAI) is crucial in various industrial quality management systems and standards, such as ISO 9001 and AS9100, as it acts as a form of risk mitigation by helping to catch potential issues before production begins.

Do not repeat full FAI for pure editorial corrections when no requirement changed. Use partial FAI for tightly scoped changes backed by stable capability data.

Do not rely on partial FAI when the manufacturing method, site, key material, or long lapse has changed. Implementing a structured FAI process can prevent costly defects, which dramatically reduces costs associated with scrap, rework, and product recalls, thereby enhancing overall manufacturing efficiency.

A robust Quality Management System (QMS) provides a structured framework and systematic approach to quality control, which is instrumental in ensuring the accuracy, reliability, and compliance of First Article Inspection processes in the manufacturing industry. Quality Management Systems are essential for ensuring compliance with industry standards such as AS9100, which governs quality assurance in aerospace manufacturing. The implementation of a Quality Management System helps organizations monitor and control all aspects of part production, ensuring that inspection plans are based on the technical data package tied to customer contracts.

One note on terminology: outside manufacturing, a full Fair Admission Index is needed when broad demographic changes invalidate prior admissions results or when transitioning between admissions criteria. In educational contexts, a full Fair Admission Index (FAI) is required when transitioning to a lottery-based system to ensure equitable access for all students. That is not the aerospace first article inspection fai discussed here.

Digitizing FAI and Trigger Logic with Connect981

Connect981 is built for aerospace manufacturing and MRO teams that need reliable digital article inspection fai workflows, not more spreadsheet control points. It connects ERP, MES, QMS, supplier data, documentation, and shopfloor execution in one operations layer.

The Connect981 platform helps teams:

• Centralize engineering documentation, revision history, routings, inspection plan data, and quality management records.
• Embed a configurable FAI trigger matrix into workflows so article inspection requirement decisions are consistent.
• Generate and manage article inspection reports, including characteristic accountability tables from ballooned drawings or models.
• Track production lapses from ERP and MES data and flag when AS9102C logic suggests a new full FAI.
• Link non conformances and corrective actions directly to FAI records.
• Give cross-factory and supplier visibility into current full and partial FAI status.

This ensures consistency, supports continuous improvement, and helps teams exceed customer expectations without adding manual reporting burden.

Request a demo to see a working FAI trigger matrix, digital first article inspection process, and automated FAIR workflow inside Connect981.

In aerospace and defense manufacturing, equipment-related KPIs sit at the core of production visibility, certification readiness, and multi-site reporting. ISO 22400 gives a shared vocabulary for these KPIs, including overall equipment effectiveness (OEE), availability, and utilization, without forcing plants into a single calculation method. For aerospace organizations building a digital thread across MES, ERP, PLM, and quality systems, aligning with the ISO 22400 manufacturing KPI standard helps ensure that equipment performance numbers mean the same thing at every site and supplier.

This article explains how ISO 22400 treats equipment-focused KPIs conceptually, how its OEE-related models (OEEA, OEEB) differ from traditional TPM-style OEE, and how aerospace manufacturers can adopt the terminology without rewriting every KPI formula. The focus is on definitions and structure, not on prescribing a specific way to improve performance.

For teams putting this topic into daily operation, ISO 22400 KPI governance, shop floor execution control, a connected execution platform help connect the concept to traceability, work-order reality, and audit-ready evidence.

The same operating model also depends on Connect 981’s aerospace execution solutions, real aerospace execution examples, Connect 981’s aerospace operations guidance, practical aerospace operations FAQs, especially when decisions have to move across quality, production, suppliers, and program leadership without losing context.

Why Equipment KPIs Are Central in ISO 22400

The role of equipment behavior in manufacturing performance

ISO 22400 pays particular attention to equipment because, in most aerospace production environments, complex assets drive both throughput and certification risk. A five-axis machining center, composite layup cell, or engine test stand may be the bottleneck for an entire aircraft program or propulsion line. If those assets are not running when planned—or if they run but produce nonconforming hardware—schedule and cost performance quickly degrade.

The standard therefore structures many KPIs around how equipment spends time and what it produces in that time. Time spent in specific states (RUN, STOP, IDLE, SLOW) is aggregated into concepts such as operating time, busy time, and downtime. Quantities produced in those time windows are tracked as good parts, rejections, and rework quantities. From these foundational elements, ISO 22400 defines equipment-oriented KPIs that can be compared across different plants, systems, and products.

For aerospace, this provides a disciplined way to separate questions like “Was the machining center available?” from “When it was busy, did it produce conforming hardware?” That distinction is important when determining whether issues belong to maintenance, production planning, or quality engineering.

Linking equipment KPIs to MOM and enterprise decisions

ISO 22400 places equipment KPIs within the broader context of manufacturing operations management (MOM). KPIs such as availability, utilization, and conceptual OEE are positioned at the level where work orders, routings, and resource assignments are executed—typically managed by MES or similar systems. These indicators feed upstream decisions in enterprise systems without forcing those systems to adopt a particular database or UI technology.

In an aerospace plant, this linkage might look like:

• MES level: Tracks equipment state changes, order execution, and scrap events; calculates ISO 22400-aligned indicators.
• ERP level: Consumes summarized equipment KPIs to refine capacity planning, program cost forecasts, and promise dates.
• PLM / configuration management: Uses production execution and quality-related KPIs to assess manufacturability of new designs and the impact of engineering changes.

By using a common ISO 22400 vocabulary across these systems, aerospace organizations can reason about equipment constraints, schedule risk, and capacity investments without debating what “availability” or “utilization” actually mean.

Conceptual View of OEE in ISO 22400

OEE as a composition of time and quantity indicators

ISO 22400 treats overall equipment effectiveness as a conceptual construct rather than as a single mandated formula. In the standard, OEE is assembled from well-defined time-based and quantity-based indicators. Time indicators describe how much of the calendar period is actually used for productive operation, while quantity indicators describe how much of the resulting output meets quality criteria.

This leads to a layered structure:

• Time-based elements: planned time, operating time, busy time, downtime categories, and related state-derived durations.
• Quantity-based elements: produced quantity, accepted quantity, rejected quantity, and reworked quantity.
• Derived indicators: equipment availability, utilization, and conceptual effectiveness ratios built from combinations of the above.

For aerospace plants, this abstraction allows different product families (e.g., composite structures vs. precision machined parts) to maintain their own cycle-time assumptions and yield profiles, while still reporting high-level OEE-related KPIs in a comparable way across programs.

How OEEA and OEEB models are structured conceptually

Within this conceptual framework, ISO 22400 introduces multiple OEE-related models, often referenced in literature as OEEA and OEEB. Each model describes a different way to compose time and quantity elements into an effectiveness measure while staying within the same terminology set.

Conceptually, OEEA tends to emphasize the relationship between busy time and produced volume, while OEEB more explicitly separates availability-related time losses from speed and quality-related losses. Both models rely on the same building blocks:

• Time structure: definitions of when equipment is considered operating, busy, or down.
• State mapping: rules for assigning RUN, STOP, IDLE, and other states into those time buckets.
• Output structure: distinctions between good pieces, scrap, rework, and test output.

ISO 22400 does not require any aerospace manufacturer to select one model over the other. Instead, it provides a common language so that, for example, a machining center in a European airframe plant and a test stand in a North American propulsion facility can both declare which conceptual OEE model they use and how it maps to their local KPI definitions.

Availability, Performance, and Quality Concepts

Time categories used to express availability

Availability in ISO 22400 is based on carefully defined time categories, rather than on informal labels such as “uptime.” Typical categories include:

• Planned time: the portion of the calendar where equipment is scheduled to be available for production or test.
• Operating time: the subset of planned time when the equipment is in a state that can produce, even if it is not actually busy.
• Busy time: the subset of operating time during which equipment is actively executing work (for example, producing a part or running a test sequence).
• Downtime: periods within planned time where the equipment is not available for production due to failures, setups, or other reasons.

For aerospace, this distinction between operating and busy time is important. A radar test bench that is powered on and ready (operating) but waiting for engineering sign-off or configuration data is not busy, yet it still consumes facility resources and may block other work. ISO 22400’s definitions support KPIs that highlight this difference.

Quantity concepts behind performance and quality factors

ISO 22400 also standardizes how quantities are treated within KPIs. Rather than mixing concepts like throughput and yield, it separates them into well-defined indicators:

• Produced quantity: total units processed by the equipment in a period, regardless of quality.
• Accepted quantity: units that meet defined quality criteria and are released for downstream use (assembly, test, shipment).
• Rejected quantity: units that are scrapped or quarantined as nonconforming.
• Reworked quantity: units that initially failed criteria but are successfully recovered through rework.

From these quantities, performance and quality-related factors are derived. In aerospace and space hardware production, where part genealogy and serial-level traceability are mandatory, tying these quantity concepts back to specific work orders, serial numbers, and configurations is essential. ISO 22400 does not define the traceability system itself, but it ensures that KPIs built on top of that system have consistent meaning.

Equipment States and Time Categories

RUN, STOP, IDLE, SLOW and their meaning

Equipment state models in ISO 22400 act as the bridge from control-system signals to conceptual KPIs. Common states include:

• RUN: equipment is executing productive work, such as machining, drilling, or test execution.
• STOP: equipment is not running, often due to a fault, changeover, or scheduled maintenance.
• IDLE: equipment is ready and capable of running but is waiting for material, instructions, or authorization.
• SLOW: equipment is running below its nominal performance, for example due to conservative feed rates on a new material or risk mitigation on a first article.

In an aerospace environment, these states can be further enriched with domain-specific reasons—such as waiting for nonconformance disposition, engineering change approval, or special process certification. ISO 22400 does not prescribe reason codes, but it ensures that however they are defined, they roll up consistently into state-based KPIs.

Mapping states to operating, busy, and downtime categories

Once state definitions are clear, ISO 22400 describes how to group them into time categories that underlie availability and utilization indicators. A typical mapping might be:

• Operating time: RUN, IDLE, SLOW, and possibly certain test or warm-up states.
• Busy time: RUN and SLOW, where equipment is actively processing a work order or test program.
• Downtime: STOP states that occur within planned time, subdivided into planned and unplanned downtime.

For aerospace manufacturers with highly engineered products, this mapping clarifies discussions where engineering or quality events appear as “downtime” from a scheduling perspective. If a composite cure oven is STOP because of an engineering hold on a material batch, the corresponding downtime can be categorized consistently across sites. That, in turn, supports comparisons across programs and facilities when analyzing bottlenecks in a regulated production network.

Comparing ISO 22400 OEE with Traditional TPM OEE

Where definitions align and where they differ

Traditional TPM-style OEE is often implemented as a product of three factors—availability, performance, and quality—each computed according to locally agreed formulas. ISO 22400 aligns with this general structure but is more explicit about the time and quantity elements that underlie each factor. Instead of declaring a single canonical OEE equation, it formalizes the building blocks and offers alternative composition models.

Alignment occurs at the conceptual level: unplanned downtime reduces availability; reduced speed and micro-stops affect performance; nonconforming output reduces quality. Differences arise in the degree of standardization. TPM implementations sometimes blur distinctions between operating vs busy time or between scrap vs rework, whereas ISO 22400 requires these concepts to be clearly separated and named. For aerospace programs seeking audit-ready KPI definitions, this additional clarity is an advantage.

Avoiding confusion in multi-site OEE reporting

One of the main risks in global aerospace production is believing that OEE numbers are comparable when they are not. Two plants might both report “OEE = 78%,” yet one includes test re-runs in performance losses while another does not. ISO 22400 helps avoid this by encouraging organizations to document which conceptual model they use (e.g., OEEA or OEEB), how states are mapped to time categories, and which quantity indicators are included in each factor.

For a multi-site aerospace or space hardware manufacturer, this documentation should be part of the digital manufacturing infrastructure: MES configuration, KPI catalogs, and integration contracts between systems. When a central team aggregates OEE data from different facilities, they can verify that the underlying ISO 22400 concepts match before drawing conclusions about best-performing plants or suppliers.

Using ISO 22400 Equipment KPIs Without Over-Prescription

Selecting which equipment KPIs to track

ISO 22400 defines a structured catalog of KPIs, but it does not tell an aerospace organization which ones it must use. In practice, plants choose a subset aligned with their operational priorities and regulatory context. A few examples:

• Engine test facilities may emphasize utilization and test-cycle adherence KPIs, since test cell access is a scarce resource.
• Precision machining centers may focus on availability and first-pass yield to manage capacity against long-cycle aerospace parts.
• Composite curing operations may track oven utilization and batch conformance indicators, as cure cycles often drive schedule risk.

All of these KPIs can be named and structured according to ISO 22400, even if not every KPI from the standard is implemented. That approach gives aerospace manufacturers a consistent conceptual basis while retaining flexibility.

Communicating definitions across plants and suppliers

The greatest value of ISO 22400 in aerospace manufacturing often appears at the boundaries between organizations: between a prime contractor and its tiered suppliers, or between an OEM and its MRO network. When contracts or performance reviews reference KPIs like equipment availability or utilization, tying those terms to ISO 22400 definitions reduces ambiguity.

Practically, this may involve maintaining an ISO 22400-aligned KPI dictionary within a digital manufacturing platform. Each KPI entry describes which states, time categories, and quantity indicators are used; which OEE-related model (if any) is assumed; and how the KPI is reported. When onboarding a new supplier or bringing a new plant into the network, that dictionary becomes the reference for configuring local MES and reporting systems, and it complements broader discussions of standardized KPIs as described in the ISO 22400 manufacturing KPI standard hub content.

Practical Considerations for Aerospace and Space Hardware Production

Integrating ISO 22400 concepts into MES and digital thread

To make ISO 22400 actionable, aerospace organizations embed its concepts in their MES and digital thread architecture. At the MES layer, equipment states, order events, and quality decisions are captured with sufficient granularity to derive ISO 22400-aligned time and quantity indicators. At higher layers, these indicators are associated with specific configurations, serial numbers, and engineering baselines, tying equipment performance back to the product definition.

In practice, this could mean:

• Standardizing state models and time-category mappings across all test stands or machine types in a program.
• Ensuring that part genealogy records link nonconforming quantities to the exact equipment and time window where they were produced.
• Configuring dashboards so that availability and utilization KPIs are derived from the same ISO 22400 building blocks across different plants.

This creates a consistent KPI layer in the digital thread, improving both operational decision-making and audit readiness.

Working within AS9100 and regulated environments

AS9100 and related aerospace quality requirements emphasize documented processes, traceability, and evidence-based decision-making. ISO 22400 contributes by providing standardized, auditable definitions of what key equipment-related KPIs mean. While AS9100 does not mandate specific OEE values or formulas, it does expect organizations to monitor and control processes that affect product quality and delivery.

By adopting ISO 22400 terminology, an aerospace manufacturer can demonstrate that KPIs used in management review and continuous improvement activities are consistently defined across programs and facilities. This reduces the risk that different sites interpret the same KPI differently during customer or regulatory audits and supports clear linkage between process performance and quality outcomes.

Balancing standardization with local optimization

Finally, ISO 22400 is explicit about its own limits: it standardizes definitions, not business strategy or improvement methods. Aerospace plants remain free to set their own OEE targets, to prioritize certain KPIs over others, and to implement local optimization practices aligned with their mix of programs and technologies.

The practical balance is to keep KPI definitions standardized (names, time and quantity concepts, state mappings) while allowing each plant to decide how aggressively to improve them. A propulsion test center and a structures assembly plant may share the same availability definition but choose different thresholds for what counts as acceptable performance. ISO 22400 supports that diversity by providing a common measurement language rather than enforcing a uniform scorecard.