Trust starts at the audit log.

Most operators who’ve been in this industry a few years have a story about a Saturday POS outage and ringing on paper. Here’s what happens at your store if our platform has an issue — written plainly, no bravado.

• Per-store database, not multi-tenant. Your Postgres is yours alone. An issue affecting another customer’s DB doesn’t reach yours.
• Offline cache at the register. The register keeps the last-known cart state, so an in-flight transaction completes even if the connection blips.
• You hear about it from us first. SMS escalation is in build; today we alert your admin contacts by email the moment we detect a critical-path issue, back it with the live /status probe rollup, and follow with a written postmortem — not a tweet, not a status-page color change you have to refresh.
• Postmortem in writing within 5 business days for any incident affecting POS, payroll, or compliance. We tell you what broke, what we fixed, what we’re changing so it doesn’t recur.
• Direct escalation path: support@cannagent.ai. Not a ticket queue, not a bot. If it’s broken, we want to know first.

Audit-trail coverage is being expanded mutation-by-mutation. The compliance-relevant events you’d expect to see — age-verification attempts, dob mismatches, manager overrides, role changes, voids — write to the audit log today. Full coverage of every server action is on the roadmap, disclosed honestly.

• Server-side actions call writeAudit() before revalidatePath() — pattern, not a guarantee on every mutation yet
• Existing audit rows include actor (user_id), action (verb), entity (table + row), and request context
• Manager, admin, and bookkeeper each get scoped read access to the audit surface
• Real-time SMS escalation for critical events (sale-to-minor block, large void) is in design — today these surface in the alerts inbox + manager-on-duty digest

RBAC checks live in src/lib/roles.ts — every access decision flows through one of nine canonical helpers, not ad-hoc string compares scattered across the codebase.

• Nine roles: admin · general manager · manager · inventory manager · purchasing · lead · budtender · bookkeeper · vendor
• Helpers: isAdmin / isManagerPlus / canSeeStoreProfit / canSeeProductCost / roleRank — never compare role strings directly
• Role embedded in an HMAC-signed session cookie: a staff session logs out after 2 hours idle and never lives past 7 days from sign-in; a role change takes effect at the next login
• Cross-store SSO uses ranked-role HMAC warp tokens that refuse name-fallback escalations

Cannabis rules are mapped feature-by-feature — Washington’s WAC 314-55 family is the reference implementation shipped today. The platform refuses to do certain things — sale to minors, sale during prohibited hours — at the code level, not as a policy.

• WAC 314-55-079 (retailer privileges) — excise math, and the age-21 restriction in -079(1) enforced at scan time
• WAC 314-55-083 (security) — the employee ID badge on record (‑083(1)) is in the hiring flow. CannAgent does not connect to your cameras or alarm, so the 45-day recording rule (‑083(3)) stays on your side
• WAC 314-55-087 (recordkeeping) — sale records and employee records kept five years on the licensed premises
• WAC 314-55-155 (advertising) — efficacy and medical-advice claims are blocked at the template layer; there is no override path that publishes one

Each store gets its own Postgres database. Cross-store reads are explicit and auditable, not implicit and silent.

• Per-store Neon Postgres — every location gets its own separate, isolated database, never a shared multi-tenant table
• Database snapshots backed up nightly with point-in-time recovery up to 7 days
• Customer can request a full SQL export at any time — operator owns their data, no exit penalty
• TLS in transit, AES-256 at rest, secrets via Vercel encrypted env vars — never committed

Some features ship with their implementation details held back on the public site. The demo shows how each one works.

• Crown-jewel features marked PROPRIETARY with a black-bar visual treatment + 'proprietary technology' caption
• When your demo is approved we draft a non-disclosure agreement. We may ask you to sign it before your sandbox opens.
• Held back here means not printed on a public page. Ask on the demo and we show you.

Operator-direct communication is the policy. Live 5-minute probes run against every canonical URL we ship; we notify affected operators within 24 hours of any incident touching their data, and the written postmortem follows within 5 business days.

• Email to admin contacts when the platform detects a critical-path issue — SMS escalation is in build, not live yet
• Postmortem written for any incident affecting POS, payroll, or compliance — shared with affected operators
• No 'no comment' policy — if your data was touched, you hear it from us before you read about it elsewhere
• /status surfaces a live 5-minute probe rollup against every canonical URL we run + per-target 24-hour uptime % — verify our story instead of taking our word for it