Your data

What we keep, and who can see it

The store check

The store check reads the files you upload and builds the report in memory. It does not store your files or the report.
To use it you sign in. Your sign-in account, which is your email and a scrambled form of your password, is kept in CannAgent’s central database.
If you send a request through the demo form, what you type there is kept in that database too.
After a report, your own browser keeps a short summary of it on your device, so your next check can show what changed: for each check, how many items it flagged and the estimated dollar total. It keeps no product names and no rows from your files.
Your browser also keeps the job you picked in the store, if you picked one, and a count of how many times each step of the check was used. None of what your browser keeps is sent to CannAgent. It is kept separately for each signed-in account and the stores that account covers, so one account never sees another's. A Forget this button on the report removes all of it.
Your browser also keeps a short at-a-glance view of your last check: how many products were in the list built from your files, which money checks could run, how many findings carry a weekly loss or cash tied up and the largest estimated figure of each, which three checks to look at first, and, when one could not, whether a file or a column was missing. It keeps no product names, it is kept per signed-in account and store like the summary, and Forget this removes it too.
The reminder to check again next week is a calendar file your browser makes. CannAgent sends no reminder and does not keep the day you pick.
If you use the short note for your owner, it is made in your browser from the report on your screen. CannAgent does not send it or keep it. It goes where you paste it.
If your report shows your last checks, your browser keeps that same short summary for each of your last eight checks. “Forget this” removes them.
If you print your report or make a PDF of it, your browser makes that copy from the page on your screen. CannAgent does not receive it or keep it.
If you ask from the report for the check to be done for you every week, the name, email and store name you type are kept in that database, as with the demo form, with the description your browser sends of itself and the address of the page you sent it from. We email you to say we got it. Nothing from the report is sent with them.
It takes values only from the columns its checks need: product names, SKUs, pack sizes, quantities, costs and prices, dates, potency, and the error messages in CCRS result files. It also reads, on a sales line, the order or receipt number (to see which lines belong to one order), the discount, the line total and the tax (to tell whether an amount is before or after its discount), and the unit of measure (to spot a line sold by weight). None of these values is copied into the report. A CCRS error message is used only to sort it into one of a few fixed types; its text is not shown.
The names of the other columns in your inventory and product files are listed back to you as not used. Their values are not copied into the report. The report also names the column it used for each field.
The name of each CCRS result file you upload appears in the report beside its errors, cut to 120 characters.
It does not use a column whose header names a person. A header such as Customer Name, Patient Name, First Name, Member or Budtender is refused before any matching, and its values are not copied into the report.
The product name and the SKU are the only two things copied out as text. Each is taken only from a column whose header is on a fixed list, such as Product, Item, Description or Strain for the name, or, in an inventory or product file with no such column, the column you pick on the page. A column headed just Name is not accepted from a sales export, and you are not offered it there, because a sales export often uses it for the customer.
A column name that appears more than once in a file is not read at all, and the report says which. A unit mark counts: Total THC and Total THC % are two columns. A file whose first row does not look like column names is not read at all, and that row is not shown back.
The check cannot tell what is inside a column. Whatever a column with a product-style header holds is what the report shows.
When it cannot find a product column in a file, it reads no rows from that file and tells you which column names it saw. It lists them only when every cell of that first row reads as a column name. Otherwise it lists none. When there is such a list, the page asks you first which of those columns has the product names, before anything is sent.
The report goes back only to the signed-in person who uploaded the files.
It is read-only toward your store. It does not write to your inventory and it does not file anything to CCRS.

If you become a customer

Setting up a new customer’s database from a signed quote is built and not switched on yet.
The system is built to give each customer a database created for that customer, not one shared with other customers.
That is about customers only. The store check stores no files and no report, so it has no database of yours.
CannAgent also has a central database that all customers share. The lines below list what it holds for a customer or a group of stores.
Your account: its legal name and state licence number, status and billing dates, invoices, payments, billing emails sent to you, the modules you asked for, a list, not yet in use, of the parts of CannAgent your account has with where each came from and when it ends, and, for a store on CannAgent’s store app, how far each is set up on that store’s own database, a table, not yet in use, for which database updates each new release would give a store whose register CannAgent runs, your settings, any referral commission paid on your account, where your account stands in payment collection and each change of that, and your signed contract with the signer’s typed name and IP address.
For automatic payment: a card token, the card’s brand and last four digits, and a record of who agreed and from what IP address. The full card number is not kept.
Your POS connection details, encrypted; an encrypted token for your Google Business Profile, Search Console or Yelp listing if you connect one; and a record of each check of your METRC connection, including your facilities list.
People: your staff list (email, name and role), copied from your store’s database by a scheduled job; portal and group sign-in accounts (email and role, and for a group account a scrambled password and a log of password changes); your account contacts (name, email, phone and notes); and a record of each invite link that was used.
Support and correspondence: support tickets with the name, email, message, any screenshot and the caller’s phone number; a log of calls, emails and notes on your account; emails drafted to you; questions and error reports raised from your system; and a note of each message held back while a store is in practice mode.
A list of the documents on your account. The documents themselves are in file storage.
A record of each purchase line used for purchase-limit checks: a scrambled form of the shopper’s state-card or loyalty ID, the last four characters of that ID, whether the sale was medical or recreational, the sale, the category, the quantity and the time. The full card number is not kept there.
Totals and usage: each store’s revenue total and on-hand unit count; the AI usage and cost on your account by day; each time an in-app offer was shown, clicked or dismissed, with the ID of the staff user who saw it; and stored copies of public-record lookups made for your account.
Compliance records: transfer manifests with both licence numbers and names and package and lab counts; the full content of each incoming delivery message; the results of CCRS file comparisons, including a sample of rows that differ; one row for each sale sent to METRC, with the sale ID, licence number and receipt ID; one row for each CCRS file CannAgent files for your store, with the file name, licence number, a checksum of the file and what WSLCB answered; for an Arizona store selling medical, one row for each medical sale or refused medical request, with the patient, caregiver, agent and dispensary registry numbers and what the agent confirmed in the state system; findings from checks that your setup matches its template; and an append-only record of who removed or suspended a tenant, released a purchase order or exported leads.
For a group of stores: the group’s record, a shared catalogue and its links to each store’s products, a vendor list with licence numbers, purchase orders with negotiated unit costs and each store’s share, transfers between stores with package tags and quantities and a log of each step of a transfer, encrypted signing keys, and each request a store makes to see a vendor’s menu, with the store’s name, the vendor’s answer and a record of who asked or answered and when.
From before you became a customer: your enquiry (name, email, store name and what you told us); quotes and their line items, with notes to you and the record of acceptance; your onboarding plan and its task list; demo access links and demo bookings with the booker’s name and email; the answers you gave in discovery calls; which suppliers or stores you work with, as our staff recorded them; which vendors you pay now and roughly what you pay them, as you told our staff; a sign-up you started yourself, with your contact name, store name and licence number, and, if you asked us to confirm it by hand, the name, role, phone, email and note you gave and our team’s decision on it; once your licence is confirmed, how long you spent on the page we show your store and which parts of it you opened; the steps you took on your store’s portal page, such as opening a preview or asking for a module, with the module and the time; a request you made there for a module, with the modules, whether you asked for a demo and the note you added; the first lookup of your licence, with the email and IP address it came from; and a record of each sales step, such as a demo booked or a quote sent, with dates and record numbers, and for a lost or stalled deal a reason and a short staff note.
Messages: emails sent to you; emails received from you with their text, and replies drafted to them; chat sessions with the name, company and email you gave, and the text of each chat message; voicemail calls with the transcript, caller name, company, email and callback number; a schedule of follow-up emails; notes passed to staff; feedback filed about your account; and internal test runs on your enquiry.
For a vendor organisation: the plan assigned to it.
Tables for a separate growing and processing product, for a producer or processor and not a store: its licensed premises, rooms, strains, plants and plant batches, plant events, transfers and waste, products, harvests and their weights, lots and lot adjustments, lab samples and what they were taken from, lab results, confirmations that results were reported, sale holds, and each line prepared for a state file. This page does not say whether any of them holds a record today.
Tables for a separate payments product: payments and vendor payment routes, shopper loyalty balances and top-ups, sanctions screening results with the subject’s name, linked bank accounts with a provider token and account mask, advances to vendors, and staff payroll enrolments and payouts with wallet addresses. This page does not say whether any of them holds a store’s records today.
That covers every table in the central database’s design that carries a customer, store-group or enquiry key, or hangs off a table that does. The design is read from every place a table is defined: the table definitions in the code and the database’s own change scripts. A test fails when a new one is added without a line here.
Other tables hold records by licence number or email address and carry no customer key. For a store that is a customer they can hold: the public licence record and the licensee’s name, email and phone; contacts found for the licence, with name and email; a table, not yet in use, of email addresses and phone numbers for a licence from the state registry and the store’s own website, with where each came from and any name guessed from an address; sales notes and a log of each contact made; which vendors a licence appears to use; which suppliers delivered to a licence each month, with the dates and counts from the state’s transport manifests; changes to a licensee’s contact details; attempts to find a licence’s website; a partner’s link to a licence; emails received at CannAgent’s own inboxes, with the sender’s name and the text; each acceptance of terms, with the name, email and IP address; each claim to a licence, with the claimant’s email; people suggested for a licence from those records, with the records each came from, and which licences were checked; and the violation notices and warnings the state regulator publishes for the licence.
The test also fails when a new table with a licence, email or phone column is added and is not on that list. A table that named a store in some other way, with none of those, would not be caught.
CannAgent holds the connection to each customer database, stored encrypted.
Over that connection CannAgent’s own systems can read and write a customer store’s database. It is how the database is set up and kept updated.
Today one scheduled job opens every active customer database once a day and copies the staff list: each person’s email, name and role.
Two other jobs run only for stores named in the code, not for every customer: a CCRS file comparison and a quarterly sales report. The CCRS comparison reads sales lines, products, the medical-exempt flag on a sale and the name of the staff member who rang it.
A built-in data reader can run read-only queries against a store’s database. It refuses a query that is not a read.
There is no access wall for store accounts yet. Only vendor accounts have one.

What a supplier can see, and what it does not get

Supplier logins are not offered to stores on CannAgent yet. No supplier sees your store’s sales, stock or sell-through. Read the vendor portal page
The vendor portal’s published description says a supplier never sees another supplier’s product, price or sales. This page has not checked that against the portal’s code, which is in a separate codebase.
Nothing in the store check is sent to a supplier.
The order messages built to pass between a store and a vendor carry only the two parties and the facts of that one exchange, such as the products, quantities and unit prices on an order.
A message is refused if it has a field for on-hand stock, sales, how fast something sells, a discount, a ranking or another account’s details.
Three kinds of text in a message are typed by a person and are not inspected: the note on an order line, a document’s file name, and product names. They can carry whatever is typed.
A vendor account is its own database with a fixed list of tables. None of them holds a store’s retail sales or the people who shop there.
A vendor account does record whether each store it sells to is a CannAgent subscriber.
Vendor accounts are built and not switched on yet.
The order messages are built too. Nothing in CannAgent sends them yet.

Who owns CannAgent

CannAgent’s owner also operates licensed retail stores in Washington.
Those stores do not receive your uploads or your report from the store check. It returns its report only to the person who uploaded the files.

What this is not

It’s a check, not a compliance guarantee. You remain the licensee responsible for compliance.
The privacy policy and the terms cover how long records are kept.