ZDI — Signature & Approval Workflow

Internal requisitions ran on paper and email. A signature pasted onto a PDF proves nothing about who approved what, on which version, or in what capacity — and in a regulated insurer, an approval you cannot evidence is an audit finding.

Requester (secure link, no login) → submit + sign → manager review (approve & sign / return / reject) → Accounts review (approve & sign / return / reject / forward to a colleague) → archive_pending → worker renders PDF, stores it, hashes it → archived. A return issues a correction link; the resubmission becomes a new revision and the route restarts, so an approval of revision 1 never carries over to revision 2. Each step writes the mutable requisition status, an append-only workflow event and an append-only audit event in the same transaction; notifications go through a transactional outbox so a mail outage cannot block an approval. An evidence check recomputes the signing events, event hashes, document hash, attachment and PDF hashes on demand.

1. 01

   A signature is a record, not an image: signer, role and capacity at signing, explicit intent, method, timestamp and a SHA-256 of the canonical content are bound into one append-only, hash-chained event.

2. 02

   Two independent tamper-evidence layers: database triggers reject UPDATE and DELETE on evidence tables, and a global hash chain detects changes made outside the database.

3. 03

   Signers bind a canonical, fixed-precision form of the content, not the PDF bytes — so re-rendering never breaks verification.

4. 04

   When two parallel signature designs grew in separate working copies, they were reconciled in an ADR: one canonical signing-event mechanism, with the stricter evidence checklist and intent rule carried forward.

5. 05

   Workflow state is mutable; evidence is append-only. Corrections create a new revision and new events — history is superseded, never edited.

6. 06

   Routing is configuration, not department if-statements, so later approval workflows are data, not new code.

7. 07

   Segregation of duties uses two mechanisms: a capability table (fails closed on unknown capabilities) and workflow guards for rules a role cannot express, e.g. a requester can never approve their own request.

8. 08

   Honest about limits: the evidence is tamper-evident within the database's controls, not a cryptographically signed PDF; no AI touches approvals or payments.