Skip to content

Integration Acceptance Test

An acceptance protocol — instantiates Tolerance Stack Management

Exercises the fully assembled system against its fit limit so the accumulated deviation is measured on the real whole, rather than inferred from parts that each passed their own check.

Every predictive stack method estimates what the accumulated deviation will be; Integration Acceptance Test is the mechanism that finds out what it actually is. It exercises the assembled system as a whole against the requirement that all the local tolerances were supposed to protect, and passes or fails it on the integrated result — not on the fact that each component cleared its own bound. Its defining stance is empirical and terminal: it trusts no local green light and no calculation, because correlated deviations, un-modelled interactions, and assembly effects only reveal themselves in the built whole. It is the ground truth that every accumulation model is ultimately trying to predict, and the last gate before the system is called good.

Example

A car door is assembled from an inner panel, an outer skin, a hinge set, a latch, and a seal — every one of which passed its own dimensional and functional check on the way in. The Integration Acceptance Test is the end-of-line station where the closed door on the built body is measured against the specification the customer actually experiences: the gap-and-flush profile around the door, the closing effort, and the wind-noise seal contact. On one body the measured gap runs about 0.4 mm proud at the lower rear corner — outside the ±0.25 mm limit — even though the tolerance report for every part came back green. The test doesn't tell the team which part; it tells them the stack failed on the real assembly, holding the body until a stack investigation traces the aligned deviations. Its verdict is on the whole, against the whole's limit, measured rather than predicted.

How it works

The test defines a system-level acceptance criterion — the fit, timing, or function the accumulated deviations must not break — and measures it on the integrated article under representative conditions. It is deliberately blind to component pedigree: a system can fail with every part in spec, so passing parts do not pre-empt the check. Its output is a pass/fail against the limit plus the measured margin, which feeds back to calibrate whether the predictive models were optimistic. What sets it apart from its siblings is that it operates on the built reality after all deviations have physically interacted, rather than on a drawing, a spreadsheet, or a simulation.

Tuning parameters

  • Acceptance limit — where the system-level pass/fail line sits, and how much guard-band it holds inside the true failure boundary. Tighter catches marginal builds but rejects good ones; looser passes stack failures.
  • Test conditions — whether the article is exercised at nominal or across the environmental and load envelope it must survive. Stressing the conditions surfaces interactions that a benign test hides.
  • Sampling rate — every unit versus an audit sample. Full inspection catches every escape but costs; sampling is cheaper but lets rare stack failures through.
  • Diagnostic depth — pure go/no-go versus instrumented measurement that also localizes the offending contribution. More depth speeds root-cause but slows the line.
  • Placement — how late in assembly the gate sits. Later tests catch true integration effects but make a failure expensive to unwind; earlier sub-integration tests catch problems sooner but on a less-complete whole.

When it helps, and when it misleads

Its strength is that it is the one mechanism grounded in reality: it catches the archetype's core failure — a system out of fit while every part is in bounds — because it measures the composed result directly, and it provides the truth data that keeps the predictive models honest.[1]

It misleads when it is asked to do more than it can. A pass certifies this build under these conditions, not the population and not every condition — a test that never stresses the alignment case can pass a design that will fail in the field. Because it sits at the end, it is also the most expensive place to discover a stack problem, and leaning on it as the only control invites exactly that: parts shipped, assembled, and only then found un-integrable. The discipline is to pair it with upstream allocation and prediction so it confirms a stack that was designed to fit, rather than discovers one that wasn't — and to test across the real condition envelope, not just at nominal.

How it implements the components

  • integration_error_monitor — it is the direct observation of system-level error after local deviations have physically interacted, rather than an assumption that local checks suffice.
  • system_fit_limit — it operationalizes the fit limit as an enforced pass/fail criterion on the integrated whole, giving the abstract requirement a measured gate.

It does not predict the accumulation ahead of the build, nor allocate the budget that should prevent a failure — prediction is the work of Monte Carlo Stack Simulation and its calculating siblings, and allocation of Variation Budget Allocation Sheet.

Notes

A pass and a prediction that disagree is information, not noise: when the built system fails a stack that every calculation said would fit, the gap is usually a correlation or interaction the model assumed away. Feeding acceptance results back to the accumulation model is what turns a one-off gate into a learning loop.

References

[1] The defining hazard of integration is that a system of individually-conforming components can still fail as a whole; acceptance testing at the integrated level exists precisely because unit-level conformance does not compose into system-level conformance. ↩