Learned rules: how an agent remembers your corrections without guessing

AI tools for dispensary back offices now promise that you only have to tell them once. Winston's public material describes exactly that: correct it once, for example that a vendor bills in cases, and it remembers (Winston's website). Its customer stories describe saved formatting rules being applied to later invoices (Winston, Customer stories). That is useful. The question this post answers is what "remembers" should mean when the thing being remembered sets prices and creates SKUs in a regulated store.

The problem with "it remembers"

When a correction disappears into a model's memory, nobody can answer the three questions that matter later. What exactly is the rule? Who agreed to it? Which outputs did it shape? If the answer is "the agent picked it up", a wrong rule spreads silently through every invoice afterwards, and you can't tell which drafts it touched.

BudAlly treats a correction as a record you can read, not as model memory. On the retail intelligence page we say it in one line: learned rules only after approval.

What a learned rule is

A learned rule is a small object with a fixed set of fields:

It lives in the mapping-review governance view next to the other mappings, where anyone with access can read it.

Illustrative examples

Hypothetical, for illustration. These are the kinds of rules a store builds up in its first months:

• Naming — "Brand · Strain · Form · Size" for every new SKU.
• Unit of measure — "This distributor bills pre-rolls per 5-pack; stock them as 5-pack units."
• Pricing — "Shelf price = cost × 2, rounded up to the next whole dollar."
• Vendor alias — "'ABC Dist.' on an invoice is the same vendor as 'ABC Distribution'."
• Category map — "This brand's 'vape' line maps to the cartridge category."

Every one of these is something a receiving lead or buyer already knows and currently types in by hand.

How a rule is proposed

There are two ways a rule starts:

1. The agent notices a pattern. Suppose, hypothetically, you've corrected the same unit of measure on three invoices from one distributor. The agent drafts a rule from those corrections and shows the evidence.
2. A person writes one. Someone who already knows the store's naming convention enters it directly.

Either way, the result is a proposed rule. It does nothing yet. Until someone approves it, drafts are made without it, and nothing written before approval is quietly re-run.

How it is approved and versioned

• Approval is by a named person, and it is recorded with the date. There's no approve-all.
• Editing a rule creates v+1, and v+1 needs its own approval. In the invoice-capture design the edit link says exactly that: edit rule → creates v+1, needs approval.
• Past drafts are never rewritten. A bill drafted under pricing v2 stays a v2 bill. If v3 changes the formula, the drafts from now on use v3, and the history still shows which version produced which number.

That last point is why versioning matters. The question you'll be asked months later is not "what is the rule?" but "what was the rule when this price was set, and who agreed to it?"

Shown where it's used

A rule nobody sees on the work it affects isn't really auditable. So every draft that a learned rule shaped shows the rule beside it, with its ID, version, approver and date. An invoice-capture draft, for example, carries a learned rules card listing the naming, unit-of-measure and pricing rules it applied, each one written as rule, version, approver, date.

When a proposed new SKU arrives already named and priced, the reviewer can see why it's named and priced that way. If the reason is wrong, they fix the rule rather than the SKU, and every later draft gets the fix.

What a learned rule can never override

Learned rules are limited to five kinds on purpose. None of them is a compliance kind, and no rule you or the agent writes sits above the state rule pack. Every draft goes through the rule pack checks after the learned rules have shaped it:

• Price floors. A learned pricing rule can't produce a proposal below landed cost plus the floor you set. The price check blocks it whatever formula made it.
• Metrc truth. A learned alias can't make an invoice tag match a manifest it isn't on. That line is held, a corrected-invoice request is drafted, and "accept as-is" is disabled. BudAlly never edits a tag.
• Copy and claims. A naming or category rule can't get a product description past the claims linter that blocks health claims and other banned wording before a person reviews it.
• Gaps fail closed. Where the rule pack has no answer for a state, the result is UNKNOWN and goes to a person. A learned rule doesn't fill the gap.

A learned rule changes how the agent drafts. The rule pack decides whether the draft is allowed to exist.

Sharing rules between companies

Learned rules are scoped to the vendor, store or state you set. Whether a rule learned at one company should ever be offered to another as a suggestion is an open product question. Until that's settled, a rule stays inside the company that approved it.

A short checklist for any vendor that says "it remembers"

• Can I read every rule it has learned, in words?
• Does a rule apply before or after a person approves it?
• Does editing a rule create a new version, and does old work keep its old version?
• Does every draft show which rules shaped it, and who approved them?
• Is there anything a learned rule is not allowed to change?

If the answer to the last question is "no", the agent's memory is part of your compliance system, and somebody needs to be able to audit it.

BudAlly's invoice capture is the first agent to use learned rules. See retail intelligence for the full set of agents, and our post on what an audit trail should contain for the record each approval leaves behind.