FAI rules and responsibilities should be defined in controlled quality management system documents, with one primary FAI procedure as the authority. AS9102 and customer requirements may set expectations, but they do not by themselves define who does what inside a specific company. Internal ownership, triggers, approvals, records, and escalation paths need to be documented, approved, version-controlled, and aligned with the systems used to execute the work.
Core documents that should define FAI governance
The exact document names vary by site, but the following controlled documents commonly need to work together:
- Quality manual or QMS process map: Defines where FAI fits in the broader quality system and which process owns it.
- FAI procedure: Defines when full or partial FAI is required, applicable forms, required evidence, review steps, approval authority, customer submission rules, and closure criteria.
- Responsibility matrix or delegation of authority: Identifies who prepares, reviews, approves, submits, accepts, or rejects FAI packages. This should include quality, manufacturing engineering, inspection, program management, supply chain, and supplier quality where applicable.
- Contract review and customer requirements procedure: Captures customer-specific FAI requirements, flowdowns, portal requirements, exceptions, and required approvals before work is released.
- Configuration management and engineering change procedure: Defines which design, process, tooling, source, or manufacturing location changes trigger a new or partial FAI.
- Inspection planning, control plan, or manufacturing planning procedure: Defines how characteristics are ballooned, inspected, sampled if allowed, measured, and tied to routers, travelers, or inspection records.
- Supplier quality manual or purchasing quality clauses: Defines supplier FAI obligations, sub-tier flowdown, submission timing, review responsibility, and rejection handling.
- Nonconformance, MRB, and CAPA procedures: Defines how FAI discrepancies, escapes, waivers, deviations, and corrective actions are handled before acceptance or shipment.
- Document control and record retention procedure: Defines approval, revision control, access control, retention period, traceability, and archival requirements for FAI records.
Where software should fit
MES, ERP, PLM, QMS, inspection software, and supplier portals can enforce or record parts of the FAI process, but they should not be the only place where the rules exist. System configuration should reflect the controlled procedure, not replace it.
In brownfield environments, FAI data often crosses legacy PLM revisions, ERP part masters, MES travelers, QMS nonconformance workflows, and customer or supplier portals. That creates real failure modes: mismatched revisions, missing characteristic traceability, unclear approval status, duplicate records, or manual re-entry errors. Full system replacement is usually unrealistic in regulated aerospace-grade environments because of qualification burden, validation cost, downtime risk, integration complexity, and long asset lifecycles. Controlled procedures and validated integrations are usually more practical than assuming one platform will solve the governance problem.
Common failure modes to avoid
- FAI triggers are known by experienced employees but not written in a controlled procedure.
- The FAI procedure conflicts with contract review, engineering change, or supplier quality procedures.
- Software workflows allow release or shipment before required FAI approvals are complete.
- Customer-specific FAI requirements are stored in email or portal notes instead of controlled contract review records.
- Partial FAI rules are vague, especially after design revision, tooling, process, source, or site changes.
- Supplier FAI responsibilities are defined in purchasing terms but not tied to receiving inspection or supplier quality review.
The practical test is simple: an auditor, customer representative, or new responsible employee should be able to determine from controlled internal documents when FAI is required, who owns each step, what evidence is required, which system of record applies, and what happens when the FAI is incomplete or nonconforming. That does not guarantee acceptance or audit results, but it reduces ambiguity and supports traceable execution.