The system failed. Every subsystem passed.
Why interfaces are engineering objects — and why interface evidence is the layer component certificates cannot replace.
1. The pattern: valid parts, invalid meeting
Ask integration engineers where the hardest uncertainty lives, and the answer is remarkably consistent: not in any single component's datasheet, but in the joints between subsystems — where tolerances, nonlinearities, and assumptions from different owners meet for the first time. Every component arrives with its own evidence: the bearing with its stiffness map, the drive with its bandwidth, the structure with its modal analysis. Each certificate is genuine. None of them says anything about the meeting.
The balancing world has known a version of this for decades: a component balanced to grade does not produce a balanced assembly, because fits, clocking, and fastener state alter the vector. Earlier notes formalised that as the assembly-transfer problem. This note generalises it — the same transfer failure happens at every boundary in the machine, mechanical, thermal, electrical, data, control, and for the same reason. The evidence was produced on one side of the boundary. The failure lives on the boundary itself.
2. An interface is an object, not a line on a drawing
An interface is a controlled boundary across which geometry, load, energy, heat, information, control, or manufacturing responsibility passes. Treated as an object, it carries its own requirement set, its own configuration state, and its own evidence. Treated as a line on a drawing, it carries nothing — and the failures follow a recognisable catalogue.
| Interface class | Typical hidden failure |
|---|---|
| Mechanical / structural | Local flexibility at a mounting changes the system's modes; the load path differs from the model that cleared each part. |
| Thermal / fluid | The component passes its bench test and overheats after installation — the bench never reproduced the installed conduction path. |
| Electrical / power | Nominal power fits, but transient demand or voltage drop at the boundary breaks operation. |
| Data / signal | Both systems transmit valid data; timing or state semantics are incompatible. |
| Software / control | Form and fit unchanged while function changes silently with a parameter or version revision. |
| Dynamic / vibration | Subsystems pass separately; a coupled resonance appears only after integration, because damping and excitation belong to the pair. |
| Manufacturing / supplier | Nominal geometry matches while the datum chain or inspection basis quietly changed between suppliers. |
Different physics, one structure: each side holds evidence about itself; nobody holds evidence about the boundary.
3. What interface evidence records
An interface evidence record is short, and every field exists because its absence has a known failure mode: the identity of the boundary and the two configurations meeting at it — an interface verified between Rev C and Rev D is not verified between Rev C and Rev E; the requirement set for both sides, with units, frames, and sign conventions stated rather than assumed; ownership and approval authority — who may change each side, and who must agree; the analysis and test evidence with its applicability; and the compatibility status with an explicit claim boundary.
4. Change propagation: when is an interface change closed?
The most expensive interface failures are not design errors — they are closure errors. A drawing is revised, the change looks local, and the paperwork closes. But an interface change is not closed when the drawing is revised. It is closed when the affected requirements, configurations, models, tests, and release authority on both sides have been re-evaluated — and the compatibility status has been re-earned, not carried forward.
This is the same rule that governs every gate in this series, applied to boundaries: evidence expires when the context changes, and a revision on either side of an interface is a context change by definition.
5. What this adds to the evidence chain
The AURA gate sequence so far runs from application fit through geometry and clearance, coefficient provenance and validation, rotor dynamics, balance and assembly, and operating envelope — the life of one rotor system's evidence over time. Interface evidence extends the chain along a second axis: from component to assembly to system. A machine-level release inherits not only the narrowest envelope of its component evidence, but the weakest compatibility status of its interfaces.
For integration-heavy machinery — precision motion systems, turbomachinery trains, any product where several suppliers' evidence must compose into one release decision — this is usually the layer where attribution later fails. When the integrated system misbehaves, each supplier's certificate is genuine, each party is plausible, and the boundary that actually failed was never anyone's deliverable.
6. Boundary
Related AURA evidence gates
Source basis
- AURA TN04. “Residual Imbalance Is Not Release Evidence.” Component-to-assembly transfer of balancing evidence.
- AURA TN05. “Release Evidence Has an Operating Envelope.” Evidence validity bound to the state that produced it.
- Breshev, O. “A Balancing Result Is Not Plane-Free.” Zenodo, 2026. DOI: 10.5281/zenodo.21433390. Formal treatment of assembly transfer and claim bounds.