Argue both sides at full strength: a steelman that collapses on contact proves nothing. Each side below ends with the evidence that would settle it.
The bus genuinely changes only during initialisation in every system scenario the team knows; adding a synchroniser now touches frozen RTL near tape-out, and every edit carries regression risk; the destination samples the bus only when enabled by sequenced control, so even a torn sample may never propagate. The evidence demand: a constraint or assertion proving the bus stable across every destination sample, plus a review of the register interface confirming no runtime write path. If that proof exists, the waiver is cheap and honest.
No party enforces stability: the interface permits runtime writes, no constraint forbids them, and no qualification gate holds the destination while the bus moves. A torn sample into datapath control is silent corruption, not a flagged error, and field software will eventually use the permitted write path the hardware left open. The evidence demand: show the enforcement, not the intention. Absent enforcement, the "quasi-static" label is unreviewed optimism one ECO away from a respin. The anti-pattern catalogue in Waiver Anti-Patterns lists this exact shape.
Whether you can hold two technical positions without caricaturing either, and whether your verdict follows the evidence rather than the org chart. The common trap is deciding by seniority: the designer's experience, or the verification lead's caution, treated as technical input. Neither is evidence. Say so: "I respect both positions, and neither is a check result."
Not yet: scenarios describe current software, not the permitted hardware interface. The evidence must forbid runtime writes structurally, or qualify the capture, otherwise the next software release reopens the hole.