A compact public explainer for a recurring hardware gap: CAD, drawings, and BOMs can look ready while the next physical state is still unproven.
OSIRIS-REx and an electrical cabinet should not feel like random topics. They are two chapters of one idea: the next physical state was not fully proven before it mattered.
OSIRIS-REx brought Bennu material home. Later, access to the remaining sample slowed around two of 35 fasteners because work had to stay inside approved tool, glovebox, and curation constraints.
NASA later cleared the hurdle with approved custom tools. The transferable lesson is the hidden state: approved tool reach, tool arc, fallback removal, contamination control, and recovery path.
A cabinet package can include real electromechanical complexity: rails, ducts, terminals, cable glands, contactors, inverter/VFD space, wiring, service, cooling, and FAT constraints.
The visible symptom can still be basic: the door or cover state was not proven with the real component depth, cable bend, gasket, finish, and tolerance stack.
The COMSOL image should appear only where it explains a physical screen: a normalized public proxy for tool moment, local load path, constraint reaction, and stress concentration around a stuck-zone class of problem.
The page should say what the screen can and cannot prove. The selected image supports the failure-mode-class lesson: an approved service/tool state may need a bounded load/deformation sanity check before a real intervention. It cannot claim NASA geometry, NASA loads, root cause, or certification.
The output should not be "missing document" theater. It should name the physical state, the evidence gap, and the package change that can prevent late prototype rework.
Show approach angle, driver/socket envelope, hand clearance, fallback method, and any material or cleanliness limits.
Verify the real door, cover, gasket, bend radius, protruding components, finish, and tolerance stack together.
Define how the part is opened, removed, replaced, inspected, reassembled, and checked without improvisation.
Separate what is built, supplied, tested, accepted, excluded, and assumed before the supplier or shop guesses.
Tie the physical risk to a first-article or FAT check, not just to a comment in the CAD review.
Use a preliminary load/deformation sanity check only when scoped, with explicit assumptions and limits.
This Build Note uses official public NASA facts, a public-safe OSIRIS proxy screen, and public-safe cabinet CAD views. It does not use private customer evidence, NASA CAD, NASA loads, root-cause proof, certification, regulatory approval, formal engineering sign-off, or raw internal rule logic.
Each note should teach one hidden state. The pillar page holds the whole map, then every future post can point back to the same vocabulary.
Can a person remove, replace, inspect, and reassemble the part without destructive improvisation?
Does the package say what is built, tested, inspected, accepted, excluded, and assumed?
Is there a scoped load/deformation screen for the obvious load path before another physical loop?
Can the unit pass first article, FAT, pilot, or customer handoff without late interpretation?
Are inspection points physically accessible and tied to acceptance criteria, not just a note?
Which assumptions will be silently filled by the supplier, internal build team, or field technician?
A hardware package can have serious engineering work behind it and still miss the next physical state: the approved tool path, the closed envelope, the service path, the build scope, or the acceptance check.
Visuals are public-safe proxy/sample assets; claims are bounded to public facts and screening context only.
