Constraint-Aware Design

All real systems operate under limits — time, resources, capacity, competing demands that don't disappear just because a design assumes otherwise. Coherence has to survive inside those limits, not just work in the version of the plan where none of them apply. A hiring process designed for a team with time to interview eight candidates for every role doesn't get more coherent when the team is understaffed and needs to fill a role in a week — it just gets skipped, worked around, or quietly abandoned, and the coherence it was supposed to protect goes with it. A system that only holds together under ideal conditions was never actually designed for the conditions it has to operate in.

These failures usually show up as a tradeoff between performance and alignment, not as an obvious break. A team under deadline pressure starts skipping the review step that used to catch misaligned decisions before they shipped — not because anyone decided alignment didn't matter, but because the constraint intensified and the structure wasn't built to hold under that pressure. Each shortcut looks reasonable in isolation. The distortion is cumulative, and it's rarely visible until coordination has already broken down.

This is what keeps coherence from being conditional on things going well. It connects directly to Structural Translation, which requires roles, processes, and information flows built to function under real limitations rather than ideal ones — and to Tradeoff Navigation, where competing constraints have to be balanced without breaking alignment at the system level. A design that only works when nothing is under pressure isn't really a design for coherence; it's a design for the absence of constraint, which no real system gets to have.