CNBS — Compliance & context engine

Why this matters in cannabis

Unlike general retail, every transaction in a licensed cannabis store is also a regulated event. The dispensary's software is, in effect, a real-time interface to the state's seed-to-sale system. If that interface drifts from reality, the store has a compliance problem before it has a revenue problem.

What "context" means here

For CNBS, context is the set of facts that must be true at the exact moment of an action:

• Who is the customer, what is their state (medical / adult-use), and what have they already purchased today and this month?
• What is the live legal limit for this customer in this state, given their basket?
• What is the live state of the package being sold — is it still active in METRC, has its lab result expired, has it been transferred or recalled?
• Who is the operator on the register, and which discounts and overrides are they authorized to use?

How CNBS holds it

1. Customer ledger. Per-customer purchase history, retained for the legally required period, queryable in O(1) at the register.
2. Package ledger. Per-package state, sourced from METRC and reconciled on every state-affecting action (receive, sell, return, adjust, transfer).
3. Operator ledger. Per-budtender / per-manager record of overrides and discount usage, attached to each transaction.
4. Rule layer. State-by-state purchase-limit, ID, age, and basket rules expressed declaratively so a new market can be opened without forking the register.

How it is enforced

• All limits are computed server-side before the basket is allowed to tender
• METRC writes happen synchronously with the sale so the state ledger and the store ledger never diverge by more than a single in-flight transaction
• Failures (METRC unreachable, lab result expired, customer over limit) surface at the basket, not at end-of-day reconciliation

Public website

cnbs.io