AS9102 Rev C keeps the same basic structure and intent as Rev B: it defines requirements for First Article Inspection in aerospace. There is no wholesale process redesign, but there are meaningful clarifications and terminology changes that can affect forms, procedures, and software tools.
High-level comparison
In practical plant terms, the main differences between Rev B and Rev C are:
- Clarified intent and scope: Rev C refines language around when FAI is required, partial vs full FAI, and when FAI must be repeated. This reduces some interpretation wiggle room that existed in Rev B, but edge cases still need customer agreement.
- Terminology and definitions: Several definitions are tightened or updated (for example, around design characteristics, key characteristics, traceability expectations, and when planning changes require FAI). This mainly impacts how you write and train to your internal procedures.
- Form instructions and examples: The familiar Form 1 / Form 2 / Form 3 model remains, but the guidance around how to fill them out is clearer and more prescriptive in some areas. Digital FAI tools and templates may need configuration updates to match.
- Better alignment with current aerospace quality practices: Rev C is tuned to fit more cleanly with current AS9100 expectations and common customer requirements, reducing some of the gray areas around configuration control and changes.
What did not change in Rev C
For most established aerospace manufacturers, the following fundamentals remain the same between Rev B and Rev C:
- The purpose of FAI: to verify that production processes can consistently produce parts that meet design requirements.
- The three-form structure (Form 1: Part Number Accountability, Form 2: Product Accountability, Form 3: Characteristic Accountability/Inspection Results).
- The expectation that FAI is part of your controlled production process, with records maintained under your QMS and configuration management practices.
- The need for clear linkage between drawings, ballooned characteristics, inspection results, and objective evidence.
Areas where Rev C usually impacts operations
The operational impact of Rev C versus Rev B depends heavily on how strictly you implemented Rev B and how your customers interpret the standard. Common change areas include:
- Trigger logic for when to perform or repeat FAI: Rev C refines language around engineering changes, process changes, tooling changes, and supplier changes. Many organizations need to update their internal FAI trigger matrices and change-control checklists.
- Flowdown and supply-chain expectations: The clarified definitions and expectations often require tighter coordination with suppliers on when they must perform FAI and what evidence they must provide.
- Digital and paper forms: Any hard-coded Rev B forms (in Excel, PLM, QMS, MES, or specialized AS9102 software) may need adjustment to field names, instructions, and default text so that they align to Rev C wording and expectations.
- Training and tribal knowledge: Inspectors and engineers who “knew” the gray areas under Rev B may need retraining to avoid carrying forward outdated interpretations that conflict with Rev C text.
Brownfield and system coexistence considerations
In most aerospace plants, FAI is woven into a brownfield stack that includes legacy ERP, MES, PLM, QMS, and various standalone tools. Moving from Rev B to Rev C is rarely a clean-slate exercise:
- Mixed standards in one plant: You may have legacy FAIs done to Rev B that remain valid while new FAIs are done to Rev C. Your QMS should explicitly describe how you handle these mixed baselines and how you show traceability to the applicable revision per contract.
- Tool and template updates, not full replacement: In regulated, long-lifecycle aerospace environments, fully replacing FAI tools or workflows solely for a revision change is usually not realistic due to validation, qualification, and downtime constraints. Most organizations incrementally update templates, macros, and electronic forms.
- Validation and change control: Any changes to digital FAI workflows, integrations, or automated data capture (for example, pulling characteristics from PLM into an AS9102 form) should go through your formal change-control and validation processes. This is especially important if customers or auditors rely on those records as objective evidence.
- Data mapping and interoperability: If you exchange AS9102 packages through portals (such as Net-Inspect or OEM-specific systems), verify that field mappings and XML/CSV exports still match the portal’s expectations under Rev C.
Compliance and contractual realities
Whether you must adopt AS9102 Rev C, and on what timeline, is primarily driven by:
- Customer contracts and PO terms: Many primes and Tier 1s specify the required revision of AS9102. You may need to run both Rev B and Rev C in parallel for different customers for a period.
- Internal QMS and AS9100 alignment: Updating your procedures, forms, and training to Rev C usually aligns with AS9100 expectations for document control and configuration management, but it does not guarantee any particular audit outcome.
- Legacy FAI packages: In long-life programs, FAIs created under Rev B typically remain part of the product record. Re-performing FAIs solely due to the standard revision is uncommon unless a customer explicitly requires it.
In practice, the shift from Rev B to Rev C is an evolution, not a reinvention. The main work is in tightening definitions, updating triggers and templates, and ensuring that your digital and paper workflows reflect the clarified expectations while coexisting with legacy records and systems.
