How should suppliers document the rationale for not performing an FAI after a change?

Suppliers should document it as a controlled, traceable decision record, not as an informal note. If a change occurs and the supplier determines that a full or partial FAI is not required, the file should clearly show what changed, how the FAI impact was evaluated, what objective evidence supports the conclusion, and who approved the decision under the supplier’s quality system and any applicable customer requirements.

In practice, the rationale should usually include:

• identification of the part number, revision, job, lot, or affected configuration

• a clear description of the change, including date, source, and whether it was design, process, tooling, software, inspection method, material, source, sequence, or documentation related

• an assessment of whether the change affects form, fit, function, performance, manufacturability, inspection results, or characteristic accountability

• the specific reason the supplier concluded that a new or partial FAI was not triggered

• objective evidence supporting that conclusion, such as unchanged drawings, unchanged characteristics, validated equivalent tooling, unchanged manufacturing route, capability data, prior FAI records, engineering disposition, or customer direction if applicable

• cross references to the governing procedure, change record, risk review, and approval record

• approval by authorized functions such as quality and engineering, based on the supplier’s documented process

The documentation should be specific. Statements like “no impact to quality” or “minor change only” are usually too weak on their own. An auditor, customer, or internal reviewer should be able to understand the logic without relying on tribal knowledge.

What good documentation looks like

A practical record usually answers five questions:

1. What changed?

2. What FAI trigger criteria were reviewed?

3. Why did the change not affect accountable characteristics or the validated production method in a way that requires FAI activity?

4. What evidence supports that conclusion?

5. Who reviewed and approved the decision, and under what procedure or change control workflow?

If the answer depends on customer interpretation, supplier flowdown, delegated authority, or contract language, that dependency should be stated explicitly. In some programs, a supplier may still need customer concurrence even when the supplier believes no FAI is required.

Common evidence sources

• engineering change review showing no effect on product characteristics

• process change assessment showing no effect on qualified or validated output

• tooling replacement documented as like for like, with verification results

• inspection method changes shown to be equivalent and controlled

• material or source changes evaluated through approved change control

• prior FAI package and subsequent production evidence showing continuity

• customer communication or requirement matrix, if that is part of the decision basis

That said, evidence quality matters. A weak assessment wrapped in a well formatted form is still a weak assessment.

What to avoid

• informal email only, with no controlled record

• generic justifications copied across parts or programs

• no linkage to change control or revision history

• no identification of affected characteristics, tools, or process steps

• assuming ERP, MES, PLM, or QMS records are automatically sufficient without a clear decision narrative

In brownfield environments, the supporting evidence is often split across systems and spreadsheets. That is common, but it creates review risk. If the rationale depends on data from PLM, ERP, MES, QMS, metrology software, or supplier portals, the supplier should link those records explicitly and ensure revision alignment. Otherwise, it becomes difficult to prove that the decision was based on the correct configuration and current process state.

Suppliers also should not assume that system replacement is the answer. In regulated aerospace and other long lifecycle environments, replacing core quality or execution systems to fix documentation gaps often fails because of validation burden, downtime risk, integration complexity, and the need to preserve traceability across legacy records. A more realistic approach is usually to strengthen the decision workflow, evidence links, and approval controls across existing systems.

So the short answer is: document the no-FAI decision as a formal, evidence-based change control record with clear reasoning, traceable references, and authorized approval. If the rationale cannot be explained and defended from the record itself, it is probably not documented well enough.