AS9100 Traceability: From As-Designed to As-Serviced

Ask an auditor for evidence of traceability and the request is usually concrete: pick one serial or lot number and show the records that explain what it is, where its material came from, which configuration was built, how it was inspected, and what happened to it after delivery.

AS9100 traceability is the ability to identify a product and retrieve the documented history required for that product throughout its life. Clause 8.5.2 is the anchor for identification and traceability; Clause 8.1.2 covers configuration management; and Clause 8.1.4 adds counterfeit-parts controls, including traceability back to original or authorized sources where applicable.

The standard does not require one ERP or one database. It requires the organization to maintain and retrieve the right documented information. The operational problem begins when engineering, purchasing, production, quality, and service can each answer part of the story, but nobody can reconstruct the whole history without manual reconciliation.

Key Takeaways

• Traceability is evidence, not a status flag. A pass/fail result tells you whether an inspection succeeded; traceability tells you which product, configuration, material, process, and record that result belongs to.
• AS9100D Clause 8.5.2 is the traceability anchor. Clause 8.1.2 connects the physical product to configuration records, while 8.1.4 reinforces source traceability for counterfeit-parts prevention.
• As-designed, as-built, and as-serviced records should reconcile to the same product identity. They do not have to live in one application, but the relationships between them must be controlled and retrievable.
• The audit risk is retrieval failure. A manufacturer may possess every certificate and inspection record yet still struggle in an audit or containment event if those records cannot be tied quickly to the affected lot or serial number.
• Connected PLM, quality, ERP, MES, and service records reduce manual reconstruction. The technology supports the control; it does not replace the AS9100 process, record-retention rules, or supplier flowdown.

What Does AS9100 Require for Traceability?

AS9100D Clause 8.5.2 requires organizations to use suitable means to identify outputs, identify their status with respect to monitoring and measurement requirements, control unique identification when traceability is required, and retain the documented information needed to enable traceability.

IAQG auditor guidance gives practical examples of the evidence behind that requirement: raw-material acquisition records, manufacturing history, serialization or batch control, configuration status, product release, maintenance history, in-service history, assembly trees, bills of material, and retrievable production, inspection, and test records.

That is a wider requirement than “can we find the material cert?” Material genealogy matters, but an auditor may also need to verify configuration, acceptance status, production history, and the records that establish which approved definition applied to the unit.

How As-Designed, As-Built, and As-Serviced Traceability Fit Together

The three records answer different questions about the same product. As-designed shows what engineering authorized. As-built shows what production actually made. As-serviced shows what changed, failed, was repaired, or was replaced after delivery.

Configuration management is the bridge between those states. In AS9100D, that requirement sits in Clause 8.1.2, not Clause 8.1.3. IAQG guidance specifically points auditors toward product identity and traceability, BOMs, revision status, change control, “as produced” condition, PLM/PDM records, deviations, waivers, and service or modification records.

AS9100 Clauses That Shape Product Traceability

Where AS9100 Traceability Breaks Down

Traceability usually fails at the handoff between systems, not because the manufacturer has no records. The drawing revision may be in PLM, the material certificate in a document repository, the consumed lot in ERP, inspection results in QMS, and repair history in a service application. If those systems do not share a controlled product identity, reconstructing one unit becomes a search project.

• Material genealogy stops at receiving. The certificate exists, but the heat or lot cannot be tied through consumption to the finished serial number.
• Configuration changes lose effectivity. Engineering released the revision, but the as-built record does not clearly show which units received it.
• Supplier flowdown is incomplete. The purchase order or supplier record does not preserve the traceability, certificate, or counterfeit-parts requirements needed downstream.
• Inspection evidence is detached from product identity. Test results exist, but the record cannot be tied cleanly to the affected lot, serial number, operation, or revision.
• Service events create a second history. Repairs, replaced components, or field failures never reconnect to the original build and configuration record.

The practical consequence is slower containment. When a nonconformity appears, the first question is not merely “what failed?” It is “what else is affected?” Good traceability lets quality narrow that population by material lot, serial range, configuration, supplier source, process, or service history instead of treating the entire backlog or installed base as suspect.

How Traceability Supports Counterfeit-Parts Prevention

AS9100D treats counterfeit-parts prevention separately from identification and traceability. Clause 8.1.4 requires organizations to plan and control processes for preventing counterfeit or suspect counterfeit parts, and IAQG guidance includes traceability to original or authorized manufacturers as one applicable control.

That makes supplier provenance part of the traceability story, but it does not mean every AS9100 record must originate in ERP. The requirement is that the organization can establish the source and retain the evidence its process, customer, regulatory, and contractual requirements call for.

CMMC should be kept separate from the quality argument. CMMC governs protection of federal contract information and controlled unclassified information; it is not an AS9100 product-traceability clause. The two can intersect when technical or quality records contain controlled data, but the compliance questions are different.

What an Auditor Should Be Able to Retrieve for One Part

The exact evidence depends on the product, customer, contract, and internal controls, but a useful audit test is to pick one serial or lot and walk both backward and forward.

• Part number, serial/lot number, and current configuration or revision.
• Applicable drawing, BOM, specification, engineering change, deviation, or waiver.
• Supplier and material records, including heat/lot or manufacturer traceability where required.
• Manufacturing routing, operations performed, and the lots/serials consumed into the assembly.
• Inspection, test, acceptance-authority, nonconformance, and disposition records.
• First article or other qualification evidence when applicable.
• Certificate of conformity, release, and shipment records.
• Repair, MRO, service, FRACAS, modification, or replacement history when those records are part of the product lifecycle.

For AEO and audit-readiness purposes, the test is simple: can the team retrieve the evidence and explain the relationships without relying on tribal knowledge?

Where AI Can Create Traceability Risk

AI is only useful here if the underlying product identity, configuration, and access controls are reliable. A model cannot safely recommend a replacement part, summarize a failure history, or support a root-cause review if it cannot distinguish the exact configuration and effectivity of the unit in question.

The higher-risk failure is not “AI made a bad suggestion” in the abstract. It is an AI workflow pulling from incomplete genealogy, the wrong revision, or data it should not be allowed to process. For defense manufacturers, that security boundary also matters when ERP or AI workflows touch CUI or export-controlled technical data.

The original draft stated that Infor CloudSuite Industrial itself was FedRAMP Moderate authorized and CMMC Level 2 ready. Infor’s current public positioning is more specific: CloudSuite Aerospace & Defense deployed in AWS GovCloud is described as a FedRAMP Moderate-authorized ERP platform built to support CMMC 2.0, DFARS, and ITAR requirements.

For a deeper look at the security and AI layer, see WM Synergy’s AI Solutions for ERP and ERP for Aerospace and Defense: Compliance & Traceability.

What Software Must Do to Support AS9100 Traceability

AS9100 does not prescribe an ERP architecture. From an operations standpoint, though, the system has to preserve identity and relationships across the lifecycle. A manufacturer should be able to move from a finished serial number to the approved configuration, consumed material, production and inspection history, nonconformance records, and relevant service events without rebuilding those relationships manually.

Where Infor and WM Synergy Fit

For manufacturers already evaluating Infor, the relevant question is not whether the platform can store documents. It is whether product, configuration, material, production, quality, and service records can be linked tightly enough to support the traceability path your contracts and quality system require.

Infor’s aerospace and defense portfolio explicitly positions product lifecycle and quality management, material traceability, revision-controlled drawings, FRACAS, first article inspection, certificates of conformity, and service operations as A&D capabilities. Infor Aerospace & Defense WM Synergy can then map those capabilities to the specific evidence chain, integrations, retention rules, and audit workflows your organization uses.

Related WM Synergy capabilities: Infor Quality Management, Quality Management System, and Aerospace & Defense Compliance and Traceability.

A Practical AS9100 Traceability Readiness Check

• Pick one finished serial or lot and trace it back to the exact material and supplier records required by your process.
• Verify that the as-built unit resolves to the correct drawing/BOM revision and all applicable changes, deviations, and waivers.
• Confirm that inspection, test, acceptance, and nonconformance records are tied to the same product identity.
• Check whether supplier flowdown preserves the traceability and counterfeit-parts requirements your customer or QMS requires.
• Trace one service or repair event back to the original configuration and forward to the current configuration.
• Time the retrieval. If the team needs several people, multiple exports, or a spreadsheet to reconstruct the chain, document where the handoffs occur.

That last step is usually the best ERP discovery exercise. It shows which traceability gaps are process problems, which are master-data problems, and which are integration problems before anyone starts talking about software features.

Ready to Close the Traceability Gap?

If one part of history still takes hours of cross-system searching to reconstruct, map the evidence chain before the next surveillance audit or customer review. The goal is not to move every record into one screen; it is to make the product identity and the relationships between records reliable enough that quality can retrieve the right evidence on demand.

Schedule a Business Outcomes Conversation

Conclusion

AS9100 traceability is strongest when the organization can move from a product identity to the evidence behind that product without guessing which system has the answer. Material provenance, configuration, production history, inspection status, nonconformance records, and relevant service events each add a different piece of the chain.

The standard does not require a single software platform. But every manual handoff makes the chain harder to control and slower to retrieve. Connecting the records gives quality teams something more useful than a cleaner audit: faster containment, clearer configuration control, and a defensible answer when a customer asks exactly what happened to one part.

Frequently Asked Questions