Trust posture

Trust starts at the audit log.

The platform that runs your store should be transparent about what it does with your data, who can see it, and what happens when something breaks. Here is ours — written plainly, no buzzword fog.

01

Audit log: build-out in progress, WSLCB events covered today

Audit-trail coverage is being expanded mutation-by-mutation. The WSLCB-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
02

Roles enforced at the helper, never the call site

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 HMAC-signed session cookie (12-hour TTL); rotation = next login
  • Cross-store SSO uses ranked-role HMAC warp tokens that refuse name-fallback escalations
03

WSLCB rules coded into the platform, not bolted on

Washington WAC 314-55 family is mapped feature-by-feature. 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, lab-test 5% passthrough, age 21+ enforced at scan time
  • WAC 314-55-082 (security) — surveillance retention, alarm requirements surfaced as enforced gates
  • WAC 314-55-095 (records) — transactions retained 3 years, video 30+ days, employee records 24 months
  • WAC 314-55-155 (advertising) — no efficacy or medical-advice claims pass through without manager-PIN override + reason
See the WA compliance rollup
04

Your data, your database, your own Neon project

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

  • Per-store Neon Postgres — Wenatchee and Seattle have separate, isolated DBs even today
  • 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
05

Proprietary tech held back from public pages — disclosed on demo

Some features ship with their implementation details deliberately held back on the public site. The demo discloses everything; the page-print-protection is a wedge.

  • Crown-jewel features marked PROPRIETARY with a black-bar visual treatment + 'proprietary technology' caption
  • Patent strategy in development with experienced cannabis IP counsel
  • Customers under a signed NDA see the full implementation on the demo call
  • Proprietary posture is an honesty signal, not obfuscation — the matrix stays mostly ✓/✗
Read the patent-posture FAQ
06

When something breaks, you hear it from us first

Operator-direct communication is the policy. Manually-curated status page is live; automated probes are next on the roadmap.

  • Direct SMS + email to admin contacts when the platform detects a critical-path issue
  • 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 page lives at /status — manually curated today, automated probes shipping next
See current platform status

Sub-processors

Vendors that may process your data on our behalf. Listed by name with scope and agreement status — no anonymous “third parties.”

VendorPurposeAgreement
VercelHosting + edge runtime + analyticsDPA on file
NeonPostgres database + nightly backupsDPA on file
AnthropicAI features (write-up assistant, demo-scope generation)DPA on file
ResendTransactional email (demo confirmations, receipts, manager alerts)DPA on file
TwilioSMS (loyalty, manager alerts, two-factor)DPA on file
StripeSubscription billing (CannAgent SaaS fees)DPA on file
GoDaddy / CloudflareDNS for store-owned domainsnot required
Sumo Logic / SentryError monitoring + log aggregationin negotiation

What gets audited (selected)

Not exhaustive — these are the actions a regulator or auditor most often asks about. Each row writes inside the same transaction as the change it records.

CategoryActionRetention
AuthLogin attempt (success or failure)24 months
AuthRole change24 months
AuthManager-PIN override36 months
POSSale to minor block triggered60 months (WSLCB)
POSVoid above $10036 months
POSCash variance > $5 at till close36 months
InventoryManual quantity adjustment36 months (WSLCB)
InventoryCost-basis edit36 months
ComplianceSurveillance gap detected60 months (WSLCB)
ComplianceWSLCB-shaped manifest export60 months
PeopleWrite-up created or edited24 months
PeopleTermination or hire-date change24 months

In progress — disclosed honestly

We don’t put “SOC 2 compliant” on the site until the report is in our hand. Here’s what’s actually in flight, with timing.

Need the trust packet for procurement?

Schedule a demo and ask. We email a packet with the security questionnaire, sub-processor list, sample audit-log export, and DPA template — same day, every time.

Schedule a demo
30 minutes · register, write-up, Form 941