First Article Inspection is a pass-fail gate. Either the part conforms to the approved drawing dimensions, surface finish specs, and material requirements, or it does not. When it fails, the part goes back to the machining cell and the engineer figures out what to change.
The problem is that figuring out what to change involves the same trial-and-error approach that produced the failing part. The CMM report shows you which dimensions are out of tolerance, but it does not tell you which parameters caused the deviation or which direction to adjust them. That translation is largely manual, and it is where the second attempt ends up being nearly as uninformed as the first.
What the AS9102 FAI Package Actually Requires
AS9102 Rev. B specifies the First Article Inspection Report structure for aerospace sub-tier suppliers. The package includes dimensional inspection (all characteristics per the drawing), material test reports, process certifications, and, for many programs, functional test results. The customer holds a complete FAIR package before approving production release.
What AS9102 does not specify is the process used to arrive at the parameters that produced the article. The parameter records are internal to the supplier. Some customers require a process traveler or a parameter record sheet as part of the FAIR package, particularly for flight-critical components on programs with their own customer-flow-down requirements. But the standard itself focuses on the output, not the method.
This matters because it means there is no structural incentive built into the FAI requirement to document which parameter set produced the article. Shops often record the final approved parameters in their router, but the history of failed configurations leading to approval is rarely captured in a retrievable form.
The Second Attempt Problem
A precision shop working on an aerospace housing in the 2024-2025 timeframe illustrates the pattern. The first article failed on two of 47 characteristics: a bore diameter was 0.002 inches over the tolerance maximum, and a positional callout on a bolt circle was at the edge of the MMC envelope. The CMM report was clear about what was wrong. It was not clear about the path to a fix.
The engineer's response was reasonable but unstructured. He adjusted the tool offset for the bore, tightened the fixture clamp torque to address the positional issue, and changed the feed rate on the finishing pass based on judgment. The second article passed, but only two of those three changes were actually causal. The feed rate adjustment was irrelevant to the positional issue, and the fixture adjustment introduced a different surface finish problem on a face that had been fine the first time.
The third article required one more adjustment. Program approval required three iterations over six weeks, not because the shop was inexperienced, but because the parameter adjustment process had no feedback mechanism linking dimensional outcomes to specific parameter settings. Each iteration started from a fresh guess, informed by the previous CMM report but not by any model of the underlying process.
What CMM Data Actually Contains
A CMM report for a complex aerospace component might have 80 to 200 measured characteristics. Each measurement is a point observation of the process state at that moment: with these tools, these parameters, this material lot, this fixturing condition. Taken individually, that observation is a pass or fail. Taken as a collection across multiple setups, it is a dataset about how the process behaves.
The dimension that keeps appearing at the high end of the tolerance range is not random. It is telling you something about the process: a consistent pattern of thermal growth, or a systematic tool deflection that scales with a specific parameter combination. The bore that is always on the low end suggests something different from the bore that varies randomly around the nominal.
Most shops extract very little of this information. The CMM data lives in a metrology software database, occasionally exported to a spreadsheet when someone decides to look at trends, but not systematically connected to the parameter records that describe what the machine was doing when each part was produced.
Using the First Failure as a Data Point
When a FAI fails, you have a data point, not a dead end. The question is how much of that data point you actually capture. A parameter record that includes the specific configuration that produced the failing part, linked to the CMM report that documents the deviations, is more useful than either document in isolation.
This is exactly the structure that Bayesian process search requires to function: a set of (parameter configuration, measured outcome) pairs. A single failing data point does not give you enough resolution to predict where the passing configuration is, but it does meaningfully narrow the search space. Combined with the engineer's physical understanding of why that specific deviation occurred, it can constrain the next trial to a region much smaller than the full feasible parameter space.
The shop that captures three failed configurations and one passing configuration has four data points. Even without a sophisticated search algorithm, the pattern across those four observations tells you more about the process than any single one. With a search algorithm, those four points become the foundation for an acquisition function that recommends the next trial from the genuinely uncertain regions of the space, rather than from wherever engineering intuition points.
Connecting FAI Records to Parameter History
The practical barrier is data linkage, not data availability. The CMM output exists. The machine parameters exist. The failing part exists. What typically does not exist is a consistent record structure that connects them in a form that can be ingested by a search tool.
Shops that build this linkage as a habit rather than a special project tend to find that the value compounds across programs. An aerospace housing that failed FAI for one customer reveals something about your titanium milling process that transfers to a different housing for a different customer, if the parameter-to-outcome data is retrievable and structured consistently.
We are not saying that all FAI failures are avoidable with better parameter search. Some failures reflect design issues, material non-conformances, or measurement uncertainty at the boundary of the tolerance callout, none of which are addressable by adjusting machining parameters. What structured parameter records address is the subset of failures caused by process parameters that have not been fully characterized, which in practice covers a large fraction of first-article program iterations on new or modified parts.
Building a Process Record That Has Audit Value
The parameter documentation that supports a FAI approval also has ongoing audit value for AS9100 compliance. When a customer or registrar audits your process control documentation, the question they are asking is whether your process is under control: do you know what settings you ran, do you have evidence that those settings consistently produce conforming parts, and would a deviation from those settings be detectable?
A parameter record that was assembled to feed a search algorithm is, incidentally, exactly the kind of documentation that answers those audit questions. The discipline of capturing and structuring parameter data for optimization purposes produces a process record that is also a compliance artifact. The two uses are not in tension.
What changes is the upstream behavior: treating each part run, including the failing first article, as a data point worth capturing rather than a result to either accept or discard and start over.