Security & Access Model
How real money, identity documents, and access are protected.
Real money, real customer identity documents (USPS 1583s), real access credentials, and real signed agreements flow through this system for an actual operating business. Nothing here is a toy — three rules follow from that directly, and they don't get relitigated for convenience.
Financial correctness
Financial calculations — invoices, refunds, proration, tax — must be correct, auditable, and never silently approximate. If a number looks close-enough-but-not-exact anywhere in the product, that's a bug worth reporting, not a rounding quirk to shrug off.
Identity document handling
Form 1583s, government IDs, and signed agreements are sensitive data by default:
- Stored in a private S3 bucket — never public, never listable.
- Accessed only via short-lived presigned URLs, which genuinely expire — an expired link is rejected, not just hidden by the UI.
- Least-privilege: access to identity documents is scoped to operational need, not broadly available to every staff role by default.
Nothing ships blind
No feature that touches money, access, or compliance data ships without the operator reviewing it against how the real business actually runs. This isn't a formality — it's the reason a "possible bug" found in code review gets flagged and confirmed with the operator before being fixed, rather than silently patched.
Two account systems, deliberately separate
Staff and customers authenticate through two entirely separate Clerk applications — different keys, different policies (invite-only for staff, open sign-up for customers), no shared session. This isn't incidental; a bug that let a customer session pass as a staff session would be a serious access-control failure, so the systems are kept structurally incapable of that from the start rather than relying on a runtime check to catch it. See Staff & Roles and Roles & Accounts.
Audit trail
Anything touching money or access writes a permanent AuditLog entry —
actor, timestamp, and enough detail to reconstruct what happened. This
log is never edited or deleted, including for actions later reversed
(approving, then rejecting, a refund still leaves both events on record).
Guest checkout is a security-adjacent decision, not just a UX one
See Guest Checkout Policy — it's listed separately because it's genuinely a product decision, but it sits alongside these rules as something not to relitigate casually either.