Human authority
Who decides, on exactly what, and can we prove it later?
Before this section, run mix setup so there are proposals to review.
| # | Lesson | You will attack |
|---|---|---|
| 8 | Exact-payload approval | approving a stale revision or the wrong hash |
| 9 | Concurrency and stale decisions | two decisions at once; bypassing the app in SQL |
| 10 | Auditability | forging an audit event |
| 11 | Breaking the approval boundary | weakening the approve policy on purpose |
An approval in Tauros names the exact revision and payload hash it
authorises, never "whatever the invoice currently contains". Every invoice
command locks the invoice row first. A unique index on approvals.revision_id
keeps one decision per revision even if application code were wrong.
Lessons 8 and 9 carry book edition notes: one on what the review page displays
for each conflict, and one on what the "simultaneous" tests do and do not
prove. The InvoiceEvent record is append-only by application code. Database
enforcement is roadmap Epic 5.
For the same pattern in two other architectures, read Approval boundaries and exact-action binding.