Byte-identity / SACRED testing discipline

Every new physics feature must prove, with an explicit regression suite, that it leaves every existing solve path bit-for-bit unchanged (max|Δ|=0.0, or measured to machine precision where floating-point order differs) before it can ship — internally the shared kernels new work is required to leave untouched are called 'SACRED'.

• You're adding a new fluid mode, node type, or honesty detector and need to know the bar for 'safe to merge'.
• A code review is checking whether a change that touches shared solver code actually preserves old behaviour, not just whether new tests pass.
• You're deciding whether a numerical difference between two solves is a real bug or expected floating-point noise — SACRED tests establish which anchors must read exactly zero, not 'close enough'.

New physics is gated behind a no-op condition (an inactive feature must evaluate to the identical old formula) so the old code path is provably untaken when the feature is off, then a dedicated byte-identity test suite (EPANET benchmark networks, a fine-tolerance verification suite, split-pipe equivalence oracles) re-runs the OLD cases and asserts the numbers didn't move.