Connect981 – Content Dev

RSC Cluster: AS9102 First Article Inspection and Net-Inspect

The AS9102 First Article Inspection and Net-Inspect Cluster breaks down how first articles are executed, reviewed, and submitted in real aerospace environments. It clearly explains Forms 1 through 3, partial FAI triggers, drawing changes, and inspection responsibility. The content also maps system handoffs between internal execution tools and Net-Inspect, helping teams avoid submission errors and audit findings. This cluster turns FAI from a recurring fire drill into a repeatable, auditable process.

  • FAIR (First Article Inspection Report)

    A First Article Inspection Report (FAIR) is the documented record of a formal First Article Inspection (FAI). It captures evidence that an initial production part or assembly has been manufactured and measured against all applicable design, drawing, and specification requirements, and that the results meet those requirements within defined tolerances.

    What a FAIR typically includes

    In regulated and aerospace-focused manufacturing, a FAIR commonly contains:

    • Identification of the part, revision level, drawing number, and related specifications
    • Manufacturer and supplier details, including lot or batch information
    • Ballooned (numbered) drawing characteristic list linking each requirement to an inspection result
    • Measured values for dimensional, material, and functional characteristics
    • Notes on special processes, treatments, or key characteristics when applicable
    • References to supporting records (e.g., material certs, process certifications, test reports)
    • Signatures or approvals from responsible quality and/or engineering representatives

    Where FAIR is used in operations

    Operationally, a FAIR is used to document that the manufacturing process for a new or changed part is capable of producing results that conform to requirements. It is often required:

    • For new part numbers or first-time builds
    • After significant design changes or drawing revisions
    • After major process, tooling, or manufacturing location changes
    • When required by customer, contractual, or industry standards such as AS9102

    In many plants, FAIRs are generated or managed within quality systems, MES, or dedicated FAI software and may be exchanged electronically with customers or prime contractors.

    Relationship to AS9102 and aerospace

    In aerospace, FAIR commonly refers to the standardized reporting format aligned with AS9102 First Article Inspection requirements. AS9102 describes typical forms and data elements for documenting FAIs on aviation, space, and defense products, but organizations may implement FAIRs in paper or digital formats as long as contractual and standard requirements are addressed.

    What FAIR is not

    • It is not routine in-process or final inspection for every lot, although it may reference those controls.
    • It is not a statistical process capability study, even though it can trigger further analysis.
    • It is not a general nonconformance report, although nonconformances found during FAI may be documented separately and referenced by the FAIR.

    Common confusion

    • FAI vs. FAIR: FAI refers to the inspection activity; FAIR is the documented report of that activity.
    • PPAP vs. FAIR: In automotive, Production Part Approval Process (PPAP) covers a broader submission package. A FAIR in aerospace is more narrowly focused on first article inspection results, though it can serve a similar verification role.

  • Ballooning and characteristics

    Ballooning and characteristics commonly refer to the practice of marking engineering drawings or models with numbered “balloons” and defining each unique, inspectable requirement as a discrete characteristic. This is widely used in first article inspection (FAI), production inspection, and ongoing quality control in regulated manufacturing such as aerospace.

    What ballooning is

    Ballooning is the process of visually annotating an engineering drawing or 3D model so that every requirement that must be verified is identified with a unique reference number (the balloon). Each balloon typically corresponds to a specific line item in an inspection report.

    In practice, ballooning may include:

    • Dimension callouts (linear, angular, GD&T features)
    • Notes and specifications that require verification (material, finish, treatments)
    • Hole sizes, locations, patterns, and thread details
    • Form, fit, and function requirements that can be inspected
    • Referenced standards or process requirements that must be confirmed

    Ballooning can be performed manually on paper, in 2D CAD/PDF, or through digital tools that link the balloons directly to a characteristic database or FAI software.

    What characteristics are

    Characteristics are the individual, measurable or otherwise verifiable requirements extracted from the drawing or model and associated with a balloon number. In AS9102 and similar frameworks, these are often called inspection characteristics or product characteristics.

    A characteristic definition usually includes:

    • The balloon or item number
    • Description of the requirement (for example, diameter of hole, surface finish)
    • Nominal value and tolerances, or acceptance criteria
    • Units of measure
    • Associated drawing zone or reference
    • Type of characteristic (for example, key, critical, major, minor) when applicable
    • Planned inspection method and frequency where defined

    Characteristics provide the structure needed to build inspection plans, first article inspection forms, and ongoing in-process or final inspection records.

    Role in AS9102 and FAI

    In aerospace, ballooning and characteristics are tightly linked to AS9102 first article inspection:

    • The ballooned drawing defines the complete set of product requirements that must be verified.
    • Each ballooned item is translated into a characteristic line on the AS9102 Form 3 (characteristic accountability and verification list) or equivalent digital record.
    • Inspection results, tools used, and any nonconformances are recorded per characteristic, enabling traceable evidence of conformance to drawing requirements.

    Digital FAI systems typically use structured characteristic data to automate form population, result capture, and traceability back to specific drawing requirements and revisions.

    Operational use in manufacturing systems

    In day-to-day operations, ballooning and characteristics may feed multiple systems:

    • PLM/CAD: Source of the design, where requirements originate.
    • FAI or quality systems: Store and manage the characteristic list, inspection results, and evidence.
    • MES: Use characteristics to drive in-process inspection steps and operator checks.
    • ERP/QMS: Reference characteristics for nonconformance records, deviations, and certificates of conformance.

    Consistent ballooning and characteristic definitions help align what is designed, what is manufactured, and what is inspected across different systems and locations.

    Common confusion

    • Ballooning vs. general markup: Ballooning is a structured, numbered system tied to inspection characteristics, not just informal comments or highlights on a drawing.
    • Characteristics vs. process parameters: Characteristics are typically product requirements on the drawing or model. Process parameters (for example, machine settings) may be controlled and recorded, but are not always defined as characteristics unless they appear as specific requirements.
    • Characteristics vs. critical characteristics only: While some organizations focus on key or critical characteristics, ballooning and characteristic listing usually cover all inspectable requirements, not only the critical subset.

    Relation to digital FAI preparation

    When preparing for advanced digital FAI capabilities, manufacturers often focus on cleaning and standardizing ballooning practices and characteristic data. This can include using consistent numbering rules, ensuring every inspectable requirement is captured as a characteristic, and structuring the data so it can be exchanged between PLM, ERP, MES, and quality systems without rework.

  • Delta FAI

    Delta FAI commonly refers to a partial or incremental First Article Inspection (FAI) that documents and verifies only the changes from a prior, approved baseline FAI. It is typically used in aerospace and other regulated manufacturing environments that follow AS9102 or similar requirements.

    Instead of repeating a full FAI on an unchanged part, a Delta FAI focuses on characteristics, features, or process steps that are affected by a design change, process change, tooling change, supplier change, or other defined trigger. The intent is to show objective evidence that the impact of the change has been understood and that the affected characteristics still meet requirements.

    What Delta FAI includes

    In practice, a Delta FAI usually includes:

    • Reference to the original, full FAI report used as the baseline
    • Identification of the specific change drivers (for example, engineering change order, revised drawing, new machine or program)
    • Updated ballooned drawings or characteristic listings limited to affected features
    • Measurement results and inspection records only for the affected characteristics
    • Updated process or routing references when manufacturing steps have changed
    • Signoff and date stamps that clearly differentiate Delta FAI from the original submission

    Delta FAIs can be recorded using the same forms or digital tools as a full FAI, with the scope and coverage clearly marked as incremental to an earlier report.

    What Delta FAI is not

    • It is not a full, start-to-finish First Article Inspection on every feature of the part.
    • It is not intended to bypass FAI triggers that would require a full re-FAI, as defined by customer or standard-specific rules.
    • It is not a generic in-process inspection; it is tied to configuration-controlled changes relative to a known baseline.

    Operational use in manufacturing

    On the shop floor and in quality systems, a Delta FAI typically appears as:

    • An additional FAI package linked to the same part number and revision, but associated with a new change notice or revision level
    • A focused inspection plan generated by MES, QMS, or FAI software containing only the impacted characteristics
    • A referenced attachment in customer portals or FAI management tools (for example, a new Delta FAI submission in Net-Inspect that points back to an earlier FAI record)

    Digital workflows often manage Delta FAI by versioning FAI records, preserving traceability between the original FAI and each incremental update so that auditors and customers can reconstruct the complete inspection history of a part or assembly.

    Common confusion

    • Delta FAI vs. full FAI: A full FAI covers all drawing characteristics and applicable requirements. A Delta FAI limits coverage to characteristics impacted by a defined change, with the original FAI serving as the baseline for everything else.
    • Delta FAI vs. routine inspection: Routine in-process or final inspection may occur on every lot or shipment, but a Delta FAI is a formal, documented event tied to configuration changes and often controlled by customer or standard-driven criteria.

    Context in AS9102 and aerospace

    In aerospace, customer specifications or quality agreements often define when a new full FAI is required versus when a Delta FAI is acceptable. Organizations typically maintain procedures that:

    • Define change events that trigger a Delta FAI (for example, drawing revision that affects only certain dimensions)
    • Describe how to identify and document affected characteristics
    • Ensure that both the original and Delta FAI records are retained and traceable for audits and customer review

    Although the exact term “Delta FAI” may not be formally defined in every standard, it is widely used in industry practice to describe this incremental FAI approach.

  • ballooning

    Ballooning in manufacturing and quality engineering commonly refers to the process of marking engineering or manufacturing drawings with numbered symbols (“balloons”) so that each requirement or characteristic can be uniquely identified and traced into inspection and quality records.

    Core meaning

    In regulated and aerospace environments, ballooning is typically applied to drawings, 3D models, or specifications used for First Article Inspection (FAI), in-process inspection, or final inspection. Each dimensional, geometric, material, or note-based requirement is assigned a balloon with a unique number. Those balloon numbers are then used as characteristic IDs in inspection reports, quality plans, or digital FAI forms.

    Ballooning includes:

    • Reviewing the drawing or model to identify all inspectable characteristics and notes
    • Assigning a unique balloon number to each characteristic
    • Placing balloons clearly near the relevant feature, dimension, or note
    • Maintaining a consistent mapping between balloon numbers and inspection line items
    • Managing revisions so that added, removed, or changed characteristics have traceable balloon references

    In digital workflows, ballooning may be performed using software that overlays balloons on PDF drawings or 3D models, automatically creates characteristic lists, and synchronizes those lists with FAI, inspection plans, MES, or PLM systems.

    Operational use in FAI and inspections

    Ballooning is a standard step in many aerospace and defense First Article Inspection (AS9102) processes. The ballooned drawing becomes the visual reference for:

    • Linking each balloon number to an AS9102 characteristic line item
    • Ensuring complete coverage of all applicable drawing requirements
    • Supporting traceability across multi-sheet drawings, zones, and configuration-controlled revisions
    • Clarifying which features have been inspected, waived, or not applicable

    Outside of formal FAI, ballooning is also used for incoming inspection, first-piece inspection, and complex part layouts where clear characteristic traceability is required.

    What ballooning is not

    Ballooning does not include the act of measuring the characteristics themselves or making pass/fail decisions. Those are inspection activities that use the ballooned drawing as a reference. Ballooning is also not the same as general mark-up or redlining of drawings; it is a structured, uniquely numbered identification of requirements intended for systematic inspection and traceability.

    Digital and multi-sheet considerations

    In digital environments, ballooning must account for:

    • Multi-sheet drawings where balloon numbers must remain unique and traceable across sheets
    • Sheet and zone references so each balloon can be located unambiguously
    • Integration with PLM, MES, or quality systems to keep ballooned characteristics aligned with the latest released revision
    • Change management when drawings or models are updated and characteristics are added, deleted, or renumbered

    Common confusion

    • Ballooning vs. characteristics: The balloons are the visual markers; the characteristics are the actual requirements (dimensions, notes, tolerances) referenced by those markers.
    • Ballooning vs. FAI report: Ballooning produces the numbered references used by an FAI or inspection report but is not, by itself, the report or the inspection record.
    • Ballooning vs. general annotations: Highlighting, comments, or informal marks on a drawing are not considered ballooning unless they follow a consistent, uniquely numbered scheme tied to inspection records.

    Context: aerospace and AS9102

    Within aerospace FAI processes following AS9102, ballooning supports characteristic identification and traceability between the engineering authority (drawing or model) and the FAI forms. Proper ballooning helps demonstrate that all drawing requirements have been accounted for in the inspection plan and that each measured result can be traced back to a specific, controlled requirement.

  • Can FAI requirements be triggered automatically from ERP or MES?

    Yes, FAI requirements can be triggered automatically from ERP or MES, but only if the underlying data, business rules, and integrations have been designed and validated to support it. There is nothing in AS9102 that prevents automation, but it does require rigor around when and how an FAI is required, and where that logic is implemented.

    Typical ways FAI triggers are automated

    In most aerospace environments, automatic FAI triggers come from a combination of ERP, MES, and sometimes PLM/QMS signals:

    In practice, this connects to digital AS9102 FAI when teams need to turn the answer into repeatable execution habits.

    • New part introduction: A new item or part number created in ERP/PLM is flagged as requiring a full FAI on first production work order.
    • Engineering change / revision change: When PLM or ERP releases a new revision, a rule can set a “FAI required” flag if the change is classified as affecting form/fit/function, key characteristics, or safety/critical features.
    • Routing / process change: MES recognizes a significant process or routing change (new operation, new machine group, new special process vendor) and sets FAI required for the next lot or work order.
    • Supplier or site change: ERP or supplier management systems can trigger FAI when a part moves to a new supplier, a new manufacturing site, or a new special processor.
    • Interruption in production: Some plants encode a rule that triggers a partial or full FAI if there has been a long lapse in production beyond a defined threshold.

    In practice, these triggers are implemented as flags or attributes on the part, revision, routing, or work order that MES or an FAI application can detect to create or require an FAI package.

    Where the logic usually lives

    Different plants choose different systems as the “source of truth” for FAI triggers:

    • ERP-centric: FAI required is driven off item master, revision, or sourcing/vendor data in ERP. Work orders carry a flag that downstream MES or inspection systems must honor.
    • MES-centric: MES owns the FAI rules based on routing, operation, machine, and process history. ERP sends basic work-order and part data, and MES decides whether an FAI is required.
    • PLM- or QMS-assisted: Classification of changes (e.g., whether a change requires FAI per engineering or quality) happens in PLM/QMS, which then marks the part/revision as FAI-required for execution systems.

    What matters is clear ownership: only one system should be the master for FAI decision logic, and the others should consume that status, not redefine it.

    Key dependencies and constraints

    Automatic FAI triggering is only as reliable as the data and rules backing it:

    • Change classification discipline: Someone must consistently classify changes (e.g., which ECNs or routing changes require FAI). If this is done informally in email or tribal knowledge, automation will be unreliable.
    • Clean part and revision master data: Item numbers, revisions, and alternates must be consistently managed. If the same hardware appears under multiple part numbers or internal/Customer IDs, FAI logic can easily misfire.
    • Machine, tooling, and process mapping: If FAI needs to respond to process changes (new machine, new fixture, new special process vendor), those must be modeled and maintained accurately in MES/ERP.
    • Supplier and site information: For supplier FAIs, sourcing and vendor data in ERP must be current and unambiguous, including site/location codes.
    • Integration quality: Interfaces between ERP, MES, PLM, QMS, and any FAI-specific system must be robust, with error handling, retries, and audit logs.

    Without this maturity, automatic triggers can be worse than manual ones, because they give a false sense of completeness while missing edge cases.

    Validation, traceability, and change control

    In regulated aerospace environments, the automation itself has to be managed under change control and, where applicable, validated:

    • Documented business rules: The exact FAI trigger logic (conditions, exceptions, part families, Customer-specific clauses) should be documented and controlled like any other quality-impacting process.
    • Versioned configuration: FAI rules embedded in ERP/MES configuration, workflows, or code must be version-controlled so you can reconstruct which rule set applied to a given FAI.
    • Testing and validation: Before going live, test scenarios should cover first builds, rev changes, process moves, supplier changes, and long gaps in production. Failures should be addressed before relying on automation.
    • Auditability: It should be possible to show auditors why a given work order did or did not require FAI, with evidence of the rule that applied at that time.

    Automating triggers does not remove the obligation to demonstrate that FAIs were performed when required; it only changes how the requirement is derived.

    Brownfield and coexistence considerations

    In brownfield environments with multiple ERPs, legacy MES, and mixed QMS tools, automatic FAI triggers usually have to coexist with manual steps and local workarounds:

    • Multiple systems of record: Different programs or sites may have different masters (e.g., one site ERP-driven, another MES-driven). A uniform global rule may not be feasible.
    • Legacy constraints: Older MES or ERP systems may not support fine-grained rules or additional flags. Workarounds (like dedicated item attributes or pseudo operations) may be required.
    • Partial automation: Many plants start by automating a subset of triggers (e.g., new part and rev changes) and keep manual or QMS-driven approvals for more complex or ambiguous cases.
    • Long equipment lifecycles: Replacing older systems solely to improve FAI triggering is rarely justifiable, given qualification burden, downtime risk, and integration complexity. Incremental integration and configuration changes are more common.

    Because of these realities, it is typical to have automatic triggers feeding a queue of “candidate FAIs,” with quality engineering making final decisions for edge cases.

    Common failure modes to watch for

    Even with automation in place, you should plan for and monitor specific failure modes:

    • Missed FAIs due to misclassified changes: Engineering marks a change as “no impact” when it actually affects form/fit/function, so no automatic FAI is triggered.
    • Over-triggering FAIs: Rules that are too aggressive can trigger FAIs for every minor routing edit or parameter tweak, causing unnecessary delay and cost.
    • Broken or lagging integrations: Interfaces fail silently and FAI flags are never updated, or are updated too late in the work-order lifecycle.
    • Site-by-site rule drift: Local admins change rules to handle special cases, so different plants interpret FAI requirements differently for the same Customer.
    • Manual overrides without traceability: Someone clears an FAI-required flag to keep production moving, but there is no documented rationale or approval.

    Mitigation usually involves periodic review of FAIs vs. triggers, exception reports where FAIs were done without a recorded trigger (or vice versa), and governance on who can change rules.

    Practical starting point

    For most organizations, a pragmatic approach is:

    1. Document your FAI trigger rules per Customer and internal standard (what conditions require full, partial, or no FAI).
    2. Decide which system is the master for FAI required status (ERP, MES, or QMS/PLM) and document that ownership.
    3. Implement a small set of high-confidence automatic triggers (e.g., new part, new rev with impact flag, new supplier) and route them into your existing FAI process.
    4. Validate and audit the automation on a subset of programs before widening scope.
    5. Add more nuanced triggers (routing changes, machine moves, long gaps) only after the basics are stable.

    Done this way, automatic FAI triggering from ERP or MES can reduce misses and manual tracking effort without creating unrealistic expectations of full automation or eliminating quality oversight.

  • Does moving production to a different machine always trigger a delta FAI?

    No.

    Moving production to a different machine does not automatically mean a delta FAI is required in every case. What matters is whether the move represents a change that could affect product characteristics, process capability, or the approved manufacturing method, and whether your customer, contract, or internal quality system treats that change as FAI-impacting.

    In practice, this connects to digital AS9102 FAI when teams need to turn the answer into repeatable execution habits.

    In practice, a machine change often can trigger a delta FAI, but not simply because the asset ID changed. The decision usually depends on factors such as machine equivalence, control software differences, fixture changes, tooling changes, CNC program transfer risk, process parameter changes, operator method changes, and whether the process is considered the same validated or qualified process after the move.

    What usually drives the decision

    • Customer or contract-specific requirements: Some customers are stricter than the baseline expectation and may require delta FAI for machine moves that another customer would not.

    • Whether the manufacturing process changed in a meaningful way: A move between truly equivalent machines with the same tooling, program revision, setup method, and demonstrated capability may be treated differently from a move to a different machine platform or control.

    • Impact on product characteristics: If the new machine could influence dimensions, surface finish, hole quality, material condition, or other characteristics, a delta FAI becomes more likely.

    • Qualification and validation status: In regulated and aerospace environments, process validation, equipment qualification, and change control can matter as much as the part drawing itself.

    • Risk classification of the part and process: Critical features, special processes, or tight capability margins raise the burden of evidence.

    When a delta FAI is more likely

    • The replacement machine is a different model, control platform, kinematic configuration, or capability class.

    • Tooling, fixturing, probing routine, offsets, or setup method changed.

    • The CNC program was reposted, modified, or adapted for the new machine.

    • Inspection results or capability on the new machine are not yet established.

    • The part has critical or tightly toleranced features sensitive to machine behavior.

    • Your internal procedure or customer flowdown explicitly lists machine changes as FAI-triggering events.

    When a delta FAI may not be required

    • The new machine is formally controlled as equivalent and uses the same approved method.

    • Tooling, program revision, setup, process parameters, and inspection method remain unchanged.

    • You have documented change assessment showing no expected effect on form, fit, function, or process capability.

    • Your quality system and customer requirements allow a justified no-delta decision with objective evidence.

    That said, a justified no-delta decision needs more than tribal knowledge. It typically requires documented review, traceable rationale, and supporting records. If the only basis is that the machines are “basically the same,” that is usually weak in an audit or customer review.

    Brownfield reality

    In mixed-vendor plants, this decision is often harder than it should be because machine identity, CNC revision, tooling records, setup instructions, inspection plans, and FAI history live in different systems or paper files. MES, ERP, QMS, PLM, and CMM software may not agree on what actually changed. That integration gap does not eliminate the requirement. It just means engineering and quality need a more disciplined change assessment and evidence trail.

    This is one reason full system replacement is rarely the practical answer. In long-lifecycle regulated environments, replacing core execution and quality systems to “clean up” FAI decisions often creates more qualification burden, validation work, downtime risk, and traceability gaps than the original problem. Coexistence with stronger change control and clearer system-of-record definitions is usually more realistic.

    Practical answer

    If production moves to a different machine, treat it as a controlled change and assess whether it could affect the part or approved process. Do not assume the answer is always yes, and do not assume it is automatically no. Review the contract, customer expectations, internal FAI procedure, machine equivalence, process risk, and available objective evidence before deciding whether a delta FAI is required.

    If there is any ambiguity, escalate the decision through quality and the responsible customer-facing authority rather than relying on an informal shop-floor judgment.

  • Can an aerospace supplier use its own FAIR template instead of the AS9102 forms?

    Yes, but only if the customer and your documented quality system allow it.

    AS9102 generally permits equivalent forms, not just the published standard form layout. The important point is not whether the document looks identical to Forms 1, 2, and 3. The important point is whether your format captures all required AS9102 content completely, accurately, and with clear traceability to the design data, part configuration, characteristics, results, and accountability records.

    In practice, this connects to digital AS9102 FAI when teams need to turn the answer into repeatable execution habits.

    In practice, that means a supplier can use its own FAIR template only when all of the following are true:

    • The customer contract, purchase order, quality clauses, and flowed-down requirements do not explicitly require the AS9102 forms or a specific portal format.
    • Your internal procedure defines the alternate format and when it is allowed.
    • The template contains all required AS9102 information with no omissions.
    • The mapping from your template to AS9102 requirements is clear enough for review, audit, and handoff.
    • The people preparing and approving FAIRs are trained on the alternate format.

    If any customer requirement says to use the AS9102 forms, Net-Inspect, or another mandated submission format, then the answer is no for that job. A supplier cannot unilaterally substitute its own template just because it believes the content is equivalent.

    What usually causes problems

    Most failures are not about the template branding. They are about missing fields, weak traceability, or inconsistent interpretation. Common failure modes include:

    • Characteristic accountability that does not clearly tie back to the drawing, model, or ballooned requirement set.
    • Incomplete material, special process, or functional test references.
    • Missing linkage between part number, revision, FAI scope, and lower-level detail parts.
    • Poor control of form revisions across sites or programs.
    • Custom spreadsheet logic that changes without review, validation, or version control.
    • ERP, MES, PLM, QMS, or inspection system integrations that populate fields inconsistently.

    Those issues matter more in regulated, long-lifecycle environments because evidence has to remain understandable and defensible long after the original team has changed.

    Brownfield reality

    Many aerospace suppliers use a hybrid approach. They keep customer-facing AS9102 output in the required format while generating portions of the FAIR record from existing MES, ERP, PLM, CMM, or QMS systems. That is often more realistic than replacing everything with a single new FAI platform.

    Full replacement strategies often fail when plants have legacy inspection workflows, validated quality processes, customer portal dependencies, and long equipment lifecycles. The qualification burden, change control overhead, downtime risk, and integration complexity are usually higher than expected. For that reason, many organizations standardize the data mapping and evidence trail first, then decide whether the front-end template itself needs to change.

    Practical test

    If you are considering a custom FAIR template, ask these questions:

    • Does any customer or prime require the standard AS9102 forms or a named submission system?
    • Can you demonstrate one-to-one coverage of AS9102-required content?
    • Is the template revision-controlled and governed through change control?
    • Can reviewers quickly find drawing accountability, objective evidence, and approval history?
    • Will the record still be understandable if reviewed months or years later by a customer, auditor, or a different internal team?

    If the answer to any of those questions is no, using your own template is high risk even if it seems operationally convenient.

    So the short answer is: yes, an aerospace supplier can sometimes use its own FAIR template instead of the AS9102 forms, but only where equivalent content is preserved and customer requirements do not mandate the standard forms or a specific system.

  • 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:

    In practice, this connects to digital AS9102 FAI when teams need to turn the answer into repeatable execution habits.

    • 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.