A discrepancy register

The system

• The system works: thirteen feature areas of a security firm run through it, from rotas to invoices, and some of its rules took real incidents to learn.
• Its shape is the problem: one table serving three concepts, a column named holiday_days_used that holds hours, two state fields on one row.
• A rebuild that copies the shape keeps the problem. A rebuild that ignores the behavior loses the rules.

Three verdicts

• 90-discrepancies.md lists every behavior the replacement changes, each under a verdict.
• FIX: the current behavior is wrong.
• KEEP: it is right and non-obvious, and is carried forward on purpose.
• DECIDE: it needs a business answer. The question stays in the entry beside the answer once there is one.

The KEEP list

• It is short, and it is the part most likely to be lost in a rebuild.
• A ban on a guard for a site or client is checked outside every override branch and cannot be lifted by an admin, though every other restriction can.
• Media is captured live, never chosen from a gallery.
• Overnight shifts are the norm, encoded today as an end time earlier than its start.
• The eligibility rules came out of incidents: license expiry, right-to-work documents, twelve hours' rest between shifts, a weekly hour cap for student visas. The current code applies the student cap the wrong way round.

The fixed consumer

The mobile app was rebuilt first and covers every feature area, so its contract, 40-api/openapi.yaml, is fixed. Where two models are equally correct, the one the app already consumes wins.

Where it stops holding

The register holds only the differences someone found. Where the old code enforces a rule nobody wrote down or noticed, the first evidence of it is the new system breaking it, and the register gains the entry afterwards.