Your four moves verify a check before it gets the veto. I'd add one for after: keep proving it in production, because a ruler can go wrong later without anyone touching it. A change to the normalisation step, a new document template or a library upgrade can change what the hash sees, and the check keeps its authority the whole time.
The cheapest version is a small set of known-repetitive and known-varied documents fed through the live pipeline on a schedule, each with its expected verdict. If a planted near-duplicate comes back clean, the check loses its veto until someone looks. I'd also watch the veto rate itself. A check whose override count drops to zero after a deploy looks like quiet success, which is exactly the shape of failure you described.
On shadow mode: disagreement between the rule and the judge tells you how often they differ, not which one is right. A sampled human read of the disagreements is what settles the direction.
Your four moves verify a check before it gets the veto. I'd add one for after: keep proving it in production, because a ruler can go wrong later without anyone touching it. A change to the normalisation step, a new document template or a library upgrade can change what the hash sees, and the check keeps its authority the whole time.
The cheapest version is a small set of known-repetitive and known-varied documents fed through the live pipeline on a schedule, each with its expected verdict. If a planted near-duplicate comes back clean, the check loses its veto until someone looks. I'd also watch the veto rate itself. A check whose override count drops to zero after a deploy looks like quiet success, which is exactly the shape of failure you described.
On shadow mode: disagreement between the rule and the judge tells you how often they differ, not which one is right. A sampled human read of the disagreements is what settles the direction.