Every POS in. Every agent out. Draft tools only.

• 01 · CAPABILITY MANIFEST

  Each adapter declares what it can read, what it can write and how fast.

  Every adapter version ships a signed manifest covering its auth model, read and write surfaces, change feed, rate budget, sandbox and the vendor's data-use rules. A probe checks each surface at connect time, nightly and after any authorization error. A surface the key can't reach is shown as "key lacks permission", never as "unsupported", and the features that depend on it show "Partial data".

• 02 · ONE RECORD

  One source-tagged record, reconciled to Metrc.

  Locations, items, packages, receipts, lines, taxes, tenders, customers, employees, discounts, deliveries, tills and POs are normalized into canonical objects, and every row carries its source vendor, connection, version and as-of time. When a POS receipt is missing its Metrc receipt id, package tags or tax split, BudAlly matches it in Metrc and badges the filled fields "from Metrc". Matches below 0.90 confidence go to a review queue.

• 03 · FILES AND METRC-ONLY

  A POS without an API still connects.

  CSV and SFTP exports and emailed reports are mapped per tenant, with a drift detector for when a file layout changes and a completeness check on every file window. In Metrc-only mode, sales, tags and taxes come from Metrc receipts, and tender, till and staff fields show "Partial data" rather than an estimate.

• 04 · SYNC SCHEDULER

  Syncing leaves headroom for your POS's own Metrc uploads.

  A global scheduler meters every vendor, credential and endpoint and plans at 70% of each documented ceiling. Sales come first, then read-backs after approved writes, transfers, incremental sync and backfill; agent live reads are capped at 10% of any budget and otherwise read the mirror. Start times are staggered per tenant, and rate-limit responses are honoured.

• 05 · DATA-USE RULES

  Each vendor's data terms are enforced on every query.

  Every row is tagged with the system it came from, and that tag follows it through joins. At query time, a policy engine checks the purpose, the kind of client, the source tags and the scopes, and returns allow, aggregate-only or deny, logging the rule ids it applied. When a question can be answered from Metrc data alone, it is re-planned onto Metrc and the answer is badged "from Metrc".

• 06 · BUDALLY MCP

  One MCP server for Claude, ChatGPT or your own automation.

  The server uses OAuth 2.1 with PKCE, and each user approves each client on a consent screen that shows the client, its redirect, its scopes and the licenses it can see. Scopes are read per area plus draft, the customer-PII scope is off by default, and a grant lasts 90 days at most. What a client can do is the narrowest of its scopes, the user's role in BudAlly, the licenses on the grant and any kill switch.

• 07 · DRAFT, NEVER EXECUTE

  Agent tools create proposals; execution happens only inside BudAlly.

  A draft tool creates a proposal with a payload hash, an evidence snapshot, preconditions and a preview, and returns a link to Approvals. Execute tools exist only for BudAlly's in-app executor, need an approval whose payload hash matches, and are never listed for any OAuth client, BudAlly's own agents included. A direct call to one is refused and logged.

• 08 · AUDIT AND KILL SWITCH

  Every agent call is logged, and any client can be cut off within a minute.

  Each call records the client, user, tool, a hash of the arguments, rows returned and touched, the rules applied and the decision. The log is hash-chained, anchored daily to write-once storage and exportable per retailer. Kill switches work per tenant, vendor, connection, tool or client and take effect within 60 seconds, and offboarding a user revokes every agent grant they held.

Questions