The customer's supplier quality engineer arrives at 8 a.m. on a Tuesday with a laptop, a coffee, and a list. She is here because your plant ships a safety-relevant bracket into her assembly line, and three months ago one of your parts with a hairline crack got past inspection and stopped her line for four hours. The containment cost her side roughly forty thousand dollars in idle labor and expedited replacement freight. She has read your corrective action. She knows you installed an AI vision system on the final inspection station. Now she wants to see whether that system is something she can trust or something she has to write you up for. She opens with a question that decides the whole audit: "Show me the record for the part you inspected at 2:14 p.m. last Thursday. I want to see the image, the decision, the threshold the model used, who reviewed it, and what happened to the part." If you can pull that record in under a minute and it is complete, the audit is essentially over and you passed. If you cannot, it does not matter how good your model's accuracy is on a slide. The lesson of this chapter is the one most vision deployments learn the expensive way: the customer does not audit your model, the customer audits your records, and a vision quality decision that is not documented to the part level did not really happen as far as the auditor is concerned.

The Auditor Audits Records, Not Models

There is a comforting story that engineers tell themselves about machine vision quality, and it goes like this: if the model is accurate enough, the governance takes care of itself. That story is wrong, and the audit is where it falls apart. A machine vision system is a camera and a trained model that grades parts at line speed, calling each one a pass or a reject against the quality standard the customer set. The model's accuracy is a real and important number, but it is not the thing under examination when the customer shows up. What is under examination is whether every decision the system made can be reconstructed, defended, and traced to a human who owns it.

Consider what the supplier quality engineer actually does during an audit. She does not ask to retrain your model. She does not ask for your precision and recall on a public dataset. She asks for evidence that your quality system is in control. Under IATF 16949 (the automotive quality management standard that governs most discrete automotive suppliers) and its aerospace cousin AS9100, control means traceability: you can show what was inspected, by what method, against what acceptance criteria, with what result, and you can show that nonconforming material was contained and dispositioned by an authorized person. The standard does not care whether the inspection was done by Dave with a go/no-go gauge or by a camera with a neural network. It cares that the record exists and that a human is accountable for it.

This is the same cardinal rule that runs through every floor-AI program, stated in vision terms: the customer audits you, not the vendor. When the part with the hairline crack escaped, the customer did not send a corrective action request to the camera manufacturer. She sent it to your plant. "The model passed it" is not an answer she will accept, the same way "the model said no" is not an answer a lending examiner will accept. The accountability for the decision stays with the plant and the quality engineer who signs the record, and the only way to honor that accountability under pressure is to have built the record-keeping before the audit, not during it.

Here is the worked number that makes this concrete. Suppose your line runs 1,200 parts per shift across two shifts, so roughly 2,400 inspected parts a day, about 600,000 a year. If your vision system logs a complete record for every one of those parts, the audit is a retrieval exercise. If it logs nothing, or logs only the rejects, or overwrites yesterday's images to save disk space, then on the day the customer asks for the 2:14 p.m. part you have a gap, and a single unanswerable record turns a routine surveillance audit into a major nonconformity. A major nonconformity on an IATF 16949 audit can trigger a new-business hold, and for a plant doing eight million dollars of annual business with that customer, a new-business hold is not a paperwork problem. It is a survival problem. The records cost you pennies per part to keep. The missing record can cost you the account.

The customer does not audit your model. The customer audits your records, and a decision you cannot reconstruct to the part level is a decision you cannot defend.

The Anatomy of an Audit-Grade Inspection Record

If the record is the thing being audited, then the design of the record is the most important design decision in the whole vision deployment, more important than the choice of camera or the architecture of the model. An audit-grade inspection record is a specific, complete object, and most plants discover its required contents the hard way. Let us build it field by field, the way you would build it if you knew the supplier quality engineer was coming.

The unique part identity. Every record must tie to a single physical part through a serial number, a date-and-time stamp, a traveler number, or a 2D data matrix code read at the station. The traveler is the paper or digital sheet that follows a part or batch through the process and records what was done to it. If your record says "a part was inspected at 2:14 p.m." but cannot say which part, you have a log, not a traceability record. For safety-relevant parts the customer will expect part-level serialization, not batch-level, because if a field failure occurs they need to find every affected part, and "we inspected the batch" does not let them do that.

The image as captured. The record must retain the actual image the model graded, not a thumbnail and not a reconstruction. This matters for two reasons. First, when the customer asks why a part passed, the image is the evidence. Second, when you investigate a drift event or an escape, the image is what lets you see whether the lighting changed, the camera moved, or the part was genuinely good. A vision system that grades and discards is a vision system that cannot defend itself. Storage is cheap. At a few hundred kilobytes per image and 600,000 parts a year, full image retention runs well under a terabyte annually, which is a rounding error against the cost of one escape.

The decision and the score. The record must capture not just pass or reject but the underlying model output: the confidence score or anomaly score the model produced, and the threshold it was compared against. This is the field that separates a real quality record from a green light. If the model called a part a pass with a score of 0.91 against a pass threshold of 0.85, the record shows the decision had nine points of margin. If it passed at 0.86 against 0.85, the record shows the decision was a coin flip, which is exactly the kind of marginal call an auditor and an engineer both want to see flagged.

The model version and the configuration. The record must name the exact model version and the inspection recipe in force at the moment of the decision. Vision models get retrained. Thresholds get tuned. Lighting recipes get adjusted between product variants. Six months from now, when an escape investigation traces back to a part inspected last Thursday, you must be able to say which version of the model graded it and what its settings were, because the model running today may behave differently. Without the version stamp, every retrain erases your ability to investigate everything that came before it.

The disposition and the human owner. Finally, the record must show what happened to the part and who decided. A pass that flows to the next operation, a reject that goes to the scrap bin, a marginal part that an inspector reviewed and overrode: each disposition needs a named, authorized person attached to it, especially any override. The disposition field is where the human accountability lives. It is the field that lets you tell the auditor, truthfully, that a person owns this decision and the AI was the tool, not the authority.

Put those five fields together and you have the object the auditor wants: part identity, image, decision with score and threshold, model version and recipe, and disposition with a human owner. A plant that retrofits this into a system that was shipping bare pass/reject signals will spend real engineering effort, but the effort is finite and it is the difference between an audit you control and an audit that controls you.

The Override Is the Most Important Record You Keep

If you study real vision-QA audits, a pattern emerges: the auditor spends the least time on the parts the model passed cleanly and the most time on the parts where a human disagreed with the model. The override, the moment an inspector overrules the green light or the red light, is the single most scrutinized event in the system, because it is where machine judgment and human judgment collide and someone has to be accountable for which one won.

There are two kinds of override, and the record has to distinguish them. The first is the inspector who overrides a reject to a pass. The model flagged the part, the inspector looked at it, decided the flag was a false reject, and shipped the part. This is the dangerous override, because if the inspector was wrong, a defect just escaped, and it escaped with a human signature on it. The record must capture who overrode, when, the reason in their own words, and ideally a re-inspection or measurement that supports the override. An override of a reject to a pass with no documented justification is, to an auditor, an admission that your operators routinely bypass the quality system, which is one of the worst findings you can hand them.

The second is the inspector who overrides a pass to a reject. The model called it good, the inspector saw something the model missed, and pulled the part. This override is your friend at audit time, because it demonstrates that the human is still genuinely in the loop and not just rubber-stamping the green light. But it carries its own signal: a rising rate of pass-to-reject overrides is telling you the model is missing defects it should be catching, which is a drift or a recall problem you need to investigate before the customer does.

Here is the false-reject economics worked through the override lens, because this is where the money hides. Suppose your model runs a false-reject rate of 3 percent on a line doing 2,400 parts a day. That is 72 good parts a day flagged as rejects. If an inspector has to stop and manually review each false reject, and each review takes two minutes, that is 144 minutes of inspector time a day, roughly two and a half hours, consumed by parts that were fine all along. Over a year that is more than 600 inspector-hours spent disproving the machine. At a loaded labor rate of 35 dollars an hour, the false-reject burden alone is over 21,000 dollars a year in review labor, before you count the good parts that get scrapped because nobody had time to review them. This is why the brief insists that false-reject economics are real money: an operator who is buried under false alarms will stop reviewing, start blanket-overriding, or quietly disable the system, and any of those three outcomes turns your audit-grade record into a fiction. The override log is where you watch for it, because a spike in fast, unjustified reject-to-pass overrides is the fingerprint of an operator who has given up on a model that cries wolf.

The governance rule for overrides: every override is logged, every override carries a named owner and a reason, reject-to-pass overrides on safety-relevant parts require a second authorized reviewer, and the override rates in both directions are tracked on the same chart you use to watch for drift. The override is not a failure of the system. The unrecorded override is.

Control Plan, FMEA, and the Paperwork the Customer Already Expects

Here is a piece of good news that most vision deployments miss: the customer's quality system already has a slot for your AI inspection, and your job is to fill it correctly, not to invent a new framework. Automotive and aerospace suppliers already live inside a documentation structure built around the PPAP, the FMEA, and the control plan. AI does not get to opt out of those documents. It has to appear inside them, described honestly, or the auditor will conclude you bolted an ungoverned technology onto a governed process.

Start with the control plan. The control plan is the document that lists, for every characteristic of the part that matters, how you control it: the specification, the measurement method, the sample size, the frequency, and the reaction plan if it goes out of control. When a vision system replaces or supplements a manual inspection, the control plan line for that characteristic must be updated to name the vision system as the control method, state the acceptance criteria the model enforces, define the sampling (every part, or a sample), and, critically, define the reaction plan when the vision system itself is suspect. That reaction plan is the part most plants forget. What does the operator do when the camera image looks wrong, when the lighting fault alarm trips, or when the override rate spikes? If the control plan does not answer that, the auditor has found a hole.

Now the FMEA. The PFMEA, the process failure mode and effects analysis, is the document where you list how the process can fail, how bad it would be, how likely it is, and how well you would detect it. When you introduce a vision system, you introduce new failure modes, and an honest PFMEA must name them. The camera can drift out of focus. The lighting can change between shifts and shift the model's scores. A new lot of raw material with a different surface finish can fool the model. The model can degrade silently after a retrain. Each of these is a failure mode with a detection rating, and the detection controls you list are exactly the governance mechanisms in this lesson: the drift monitor, the daily reference-part check, the override-rate tracking, the model-version log. The PFMEA is where governance stops being a slide and becomes a rated, auditable control with a number attached to its effectiveness.

The PPAP, the production part approval process, is the package you submit to the customer to prove a part is ready for production. When AI vision is part of how you control that part, your PPAP package should describe the system honestly: what it inspects, how it was validated, what its measured performance is on your parts (not the vendor's benchmark), and how it is monitored in production. The deep instinct from the brief applies directly here: treat vendor performance figures as benchmarks to verify, never as guarantees to repeat. The number that belongs in your PPAP is the one you measured on a holdout set of your own parts, with your own lighting, on your own line, because that is the number you will be held to when the customer's part fails in the field.

The reason this matters is that an auditor who sees AI vision named correctly in the control plan, with its failure modes rated in the PFMEA and its real performance documented in the PPAP, sees a plant that treats AI as a controlled process. An auditor who sees a vision system humming away on the line with no mention of it in any of those documents sees a plant that does not understand its own quality system. The first plant passes. The second plant gets written up, and the finding is not about the AI, it is about the absence of control.

Drift Monitoring Is a Governance Control, Not a Data Science Hobby

A vision model is not a gauge. A gauge that is calibrated stays calibrated until something physical changes, and a calibration sticker tells you when to recheck it. A vision model degrades for reasons that leave no sticker: the morning sun comes through a skylight and changes the lighting on the second shift, the camera mount loosens half a millimeter over a month of vibration, the supplier ships a slightly shinier batch of stock, and the model that was excellent in validation starts grading differently with no announcement. Drift is the slow, silent change in the model's behavior caused by the world changing around it, and from a governance standpoint drift monitoring is not an optional data-science refinement. It is the control that keeps your audit-grade records from becoming a record of decisions made by a model nobody was watching.

The customer will ask about drift, in plain language, even if they do not use the word. The question sounds like: "How do you know the system is still working as well today as it was when you validated it?" If your answer is "the model is very accurate," you have not answered the question, because you described the past. The answer the auditor wants describes an ongoing control. There are three drift controls worth building, and together they form the monitoring story you tell at audit.

The reference-part check. The cheapest and most convincing control is a set of known golden parts, some good, some with deliberate defects, that you run through the system on a defined schedule, say at the start of every shift. If the model grades the golden good part as a reject or the golden defect as a pass, you have caught drift before it touched a customer part, and the check itself is a dated, logged record you can hand the auditor. This is the vision equivalent of running a check standard through a measurement instrument, and auditors love it because they already understand it.

The score-distribution monitor. Every decision in your audit-grade record carries a confidence or anomaly score. If you plot the distribution of those scores over time, drift shows up as a shift in the distribution before it shows up as a wave of escapes. If the average pass score has been sliding from 0.92 toward 0.86 over three weeks, the model is getting less sure of itself, and that is your early warning to investigate the lighting, the camera, or the material before the marginal calls start becoming wrong calls. This monitor costs nothing extra to build because the scores are already in the records you are keeping for the audit.

The override-rate monitor. As covered earlier, a rising rate of pass-to-reject overrides means humans are catching defects the model is missing, which is drift in the recall direction. A rising rate of reject-to-pass overrides can mean the model is over-flagging, which is drift in the false-reject direction, or it can mean operators have stopped trusting the system. Either way, the override rate is a free, human-powered drift detector that lives in records you already keep.

Here is the worked number on why drift monitoring pays. Imagine the model drifts silently for two weeks before anyone notices, and during those two weeks its escape rate climbs from near zero to half a percent on a line doing 2,400 parts a day. That is roughly 12 escaped defects a day, 168 over the two weeks, and if even one of them reaches the customer and triggers a containment, you are back to the forty-thousand-dollar line stop from the opening story, plus the corrective action, plus the damaged relationship. A reference-part check that costs an inspector ten minutes a shift would have caught the drift on day one. The math on drift monitoring is not close. The control is cheap and the failure it prevents is enormous, which is exactly why a serious auditor treats the presence of a documented drift control as a sign of a mature system and its absence as a red flag.

Walking the Auditor Through a Single Part

The real test of your governance is not the binder of procedures. It is the live demonstration, the moment the supplier quality engineer points at a timestamp and says "show me." A plant with audit-grade governance can walk an auditor through the complete life of a single inspected part in a few minutes, and that walkthrough is the most persuasive evidence you can offer, more persuasive than any policy document. Let us walk it, the way you would on audit day, so the standard is concrete.

The auditor picks the part: serial number ending 4471, inspected at 2:14 p.m. last Thursday. You query the system by serial and the record appears. First, identity: the record confirms part 4471, the data matrix code that was read at the station, the traveler number, and the timestamp, so there is no doubt this is the physical part the auditor is thinking of. Second, the image: you display the actual frame the model graded, and the auditor can see the part as the camera saw it, with the inspection regions overlaid. Third, the decision: the record shows the model called it a pass with a score of 0.89 against a pass threshold of 0.85, four points of margin, a clean call. Fourth, the configuration: the record names model version 3.2, the lighting recipe for that product variant, and confirms both were the released, validated versions in force at 2:14 p.m. Fifth, the disposition and human owner: the part flowed to the next operation as a pass, no override was required, and the shift quality lead's name is attached to the station's released configuration and the day's reference-part check that passed at shift start.

Then the auditor pushes, because good auditors push. "Show me a reject from that shift." You pull part 4488, flagged at 2:31 p.m. with a defect score above the reject threshold, image showing a visible scratch, dispositioned to scrap with the inspector's name and a one-line confirmation. "Now show me an override." You pull part 4502, a reject the inspector overrode to a pass at 2:47 p.m., with a recorded reason ("flag was a reflection from the new lighting, re-inspected under hand light, surface clean"), a re-measurement, and because it was a safety-relevant part, a second reviewer's name. The auditor sees that even your overrides carry justification and dual sign-off. Finally: "Show me how you know the model still works." You display this week's reference-part log, all green, and the score-distribution chart showing the pass scores holding steady around 0.90 with no downward drift.

That sequence, identity to image to decision to configuration to disposition to override to drift control, is the whole governance story told through one part and its neighbors. Notice what the auditor never had to take on faith. She never had to trust that the model is accurate, because she saw the evidence of individual decisions and the controls that keep them honest. The accuracy of the model became almost beside the point, which is precisely the goal. You did not ask her to trust the AI. You showed her a quality system in control that happens to use AI, with a human accountable at every decision that matters and a record for every part. That is what passing a customer audit with AI in the loop actually looks like, and it is built entirely from the records you decided to keep before she ever walked in.

Key Takeaways

• The customer audits your records, not your model. A vision quality decision that cannot be reconstructed to the individual part, with image, score, threshold, model version, and a human disposition, is a decision you cannot defend, no matter how accurate the model is on a slide.
• An audit-grade inspection record has five required fields: unique part identity, the image as captured, the decision with its score and threshold, the model version and recipe in force, and the disposition with a named human owner. Retrofitting these into a bare pass/reject system is the core engineering work of governance.
• The override is the most scrutinized event in the system. Every override needs a named owner and a reason, reject-to-pass overrides on safety-relevant parts need a second reviewer, and override rates in both directions are tracked as drift signals. The unrecorded override is the finding that says your operators routinely bypass the quality system.
• False-reject economics are real money. A 3 percent false-reject rate on a 2,400-part-a-day line burns over 600 inspector-hours and 21,000 dollars a year in review labor, and an operator buried in false alarms will blanket-override or disable the system, turning your audit-grade records into fiction.
• AI vision must appear honestly in the documents the customer already expects: named as the control method in the control plan with a reaction plan for when the camera is suspect, with its new failure modes rated in the PFMEA, and with its real measured performance (not the vendor benchmark) documented in the PPAP.
• Drift monitoring is a governance control, not a data-science hobby. The reference-part check, the score-distribution monitor, and the override-rate monitor together answer the auditor's real question: how do you know the system still works today. A documented drift control is a sign of maturity; its absence is a red flag.
• Treat every vendor performance figure as a benchmark to verify on your own parts, your own lighting, and your own line. The number you will be held to when a part fails in the field is the one you measured on a holdout set of your parts, and that is the only number that belongs in your PPAP.
• Passing a customer audit with AI in the loop is not about proving the model is smart. It is about walking the auditor through one part, from identity to disposition to drift control, and showing a quality system in control that happens to use AI, with a human accountable at every decision that matters. You build that the day you decide what to record, not the morning the auditor arrives.