All of it is stored on your workstation, scoped to a company file.
Coding rules
When you correct a coding decision, make it stick: “Remember that AMZN MKTP always goes to Shop Supplies for this company.” A rule fills in coding that was left empty on future batches. It never overrides a value the agent worked out from an actual receipt. Rules are scoped to one company file. Charts of accounts differ between clients, and a rule that crossed files would post to a plausibly-named wrong account in the other file — an error that reconciles cleanly and gets found months later, if at all.Suggestions and auto rules
A rule is one of two kinds, and the difference is how much coding happens without anyone reading it:- Auto fills an empty account or class during planning and notes that it did.
- Suggest is offered to the agent and can be ignored.
Knowledge
Knowledge holds what a coding rule can’t express: a vendor that bills two months in arrears, a customer whose remittances arrive net of a credit, a look-twice cue on an account someone keeps miscoding. “Remember that Coastal Supply invoices two months behind — a March bill is usually January work.” Each entry is anchored to the parties it’s about and surfaces on its own when they come up. A note aboutAcme Fast Fuel appears when a bank feed line reads ACME FAST FUEL #4417 BROOKLYN NY, because anchors match on normalized names. Nobody has to remember to look anything up.
An entry can be marked always relevant instead. Then it’s delivered once at the start of every session, whoever comes up. Use that for standing facts about the client, not for anything a vendor name would find.
Results carrying knowledge label it as knowledge. It’s a colleague’s note about the books rather than something read out of the company file, and the agent is told to say so if it acts on one.
Playbooks
A playbook is a procedure written down so it runs the same way every time and can be handed to someone else — a month-end close, a recurring reconciliation. Use{{named}} slots in the body for values supplied when it runs, and declare each one. Running a playbook returns its steps with the values filled in. It changes nothing by itself; the agent carries the steps out with the ordinary tools, so every posting still goes through plan and approve.
A playbook with no company applies to every client on the workstation. That’s the common case — a practice runs one close, not seventeen.
Drafts
Knowledge entries and playbooks land as drafts. A draft does nothing — it’s visible, but it never surfaces on its own, and a draft playbook can’t be run.
The work log
Knowledge needs guarding against entries nobody read. The work log has the opposite risk: entries that never get written. The run journal records what posted and how to reverse it. It can’t say which document a batch came from, why an account was chosen over the obvious one, or what’s still open — and a month later, those are the questions people ask. “Log that I finished March for Ridgeline: bank feed through the 31st, two vendor bills still waiting on approval from Dana.” Two things push the log toward getting written. A session that changes a lot without logging starts seeing a reminder on its results. A session that ends without logging gets a skeleton entry at the next startup, built from what it changed and labelled as machine-written, so it reads as the placeholder it is. Read the log in the console’s Work log page, filtered by company and period, and add entries there by hand.Where it’s stored
All four live in%LOCALAPPDATA%\Zeno\qb-mcp\qb-mcp.db, alongside the run journal. Point DataDirectory at a network path and a whole practice shares one set — see installing across a firm.