You are told: twenty reset-domain crossings are open in the structural report, all classified low or medium severity by the block teams. The programme asks for waivers on all twenty before the milestone in 36 hours. Verification evidence is partial: some items have reset-aware simulation, most have designer statements. The integration team adds that one product variant sequences its resets differently from the others, and nobody has checked the twenty items against that variant's order. The reset intent document exists but predates three recent ECOs.
The twenty are not one decision but four piles. First, items whose reset intent is stale after the ECOs: these cannot be waived or fixed until intent is refreshed, and the refresh is the critical path. Second, items on the variant with the different sequence: these need re-analysis against that order before any discussion. Third, items with real simulation evidence and current intent: these are waiver candidates. Fourth, items with designer statements only: these are unprovable in 36 hours and must be refused or deferred with containment. Sorting into these piles is the first hour of work; debating all twenty as a bloc is the trap.
Before touching any pile, ask for the chip-level reset dependency graph: which resets must release before which others, per Release Order Across Domains. An item "low severity" in isolation can be the missing rank in a release chain, which makes it a boot failure on exactly the variant the integration team fears. Severity without the graph is a guess.
Every verdict hangs off intent: severity, classification, and evidence are all relative to which resets exist and in what order they release. Stale intent makes all twenty verdicts unreliable, including the comforting ones.