An exact code revert does not prove cross-engine parity

An exact restoration of an older decision function does not prove behavioral parity with another engine or with retained lifecycle state. When reverting a workflow, compare both engines on settled historical states, not only new happy-path inputs. A current-snapshot concurrency guard prevents stale writes but does not prevent a semantically wrong transition computed from current data. Separate code-output proof, write eligibility, runtime mode, and observed production occurrence.

Evidence/example — 2026-09-14: a static provenance audit and bounded probe of an actual decision-composition function showed that an accepted review with a previously failed parent could compose success in a reverted engine while the existing group recomputation preserved failure. The differing function restored old code exactly. No production occurrence or full integration reproduction was established; the lesson is about validation method and conditional risk, not current system status.