> ## Documentation Index > Fetch the complete documentation index at: https://zenorent.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Knowledge & rules > Teaching Zeno how your books work — deterministic rules, judgment-call knowledge, and the log of what was done You train Zeno's AI on how your books work. What it knows is data you own, edit, and audit — three layers on one page at **Zeno → Knowledge & rules**. They're deliberately kept apart, because merging them makes both worse. | Layer | What it holds | When it runs | | - | - | - | | **Rules** | Deterministic pattern → vendor and GL mappings | At ingest, no AI, no cost | | **Knowledge** | Judgment calls, quirks, and cues | Read when relevant | | **Log** | What was done and why | After each unit of work | ## Which layer does a thing belong in Ask whether the answer requires judgment. **No judgment → a rule.** "Metro Water Utility always posts to Water & Sewer." Deterministic, so it should fire at ingest for free and land the same way every time. See [Rules](https://zenorent.com/docs/rules.md). **Judgment → knowledge.** "Garden State Building Supply bills two jobs on one invoice; split by the line-item job codes, and if there's no code, the delivery address decides." A person has to read the document and decide. Writing a mapping as knowledge instead of a rule costs a model call every time it comes up and leaves room to read it two ways. Writing a judgment call as a rule produces confident wrong answers. ## Authoring knowledge Each entry has a category, and the categories are opinionated about what belongs in them. The names are deliberately judgment-shaped — quirk, hint — to keep them from turning into a second, worse copy of the rules engine. * **Vendor quirk** — something about a vendor's documents that affects how fields are *read*: invoice-number formats, several invoices batched per page, line-item splits, ambiguous memos. Not a vendor → GL mapping. * **Doc signature** — what kind of document a sender sends. "Garden State Building Supply sends statements, not bills." "This sender is always a property-tax bill." * **Card routing** — a card → person, location, or category mapping the rules can't easily express, like a shared card with mixed use. * **Review hint** — an anomaly cue an eagle-eyed bookkeeper would catch and a matcher won't: refunds disguised as charges, duplicate invoices under different numbers, period-end accruals. * **Routine** — a recurring procedure, like the monthly Amex Business Gold reconciliation steps. * **Schedule** — something that happens on a calendar. * **Fact** — a standing piece of context that isn't any of the above. * **Story** — a dated narrative of what happened in a period. Useful for the context a future reader won't have. Entries follow a fixed shape, so they still read clearly a year later: ``` **When:** the trigger or scope, in one line **Then:** the rule or action, in one line **Why:** the reason, in one line **Notes:** caveats and exceptions ``` A story entry skips that and takes a window and a summary instead. You can write entries by hand, or work a job through with Zeno and ask it to save what it learned. Either way it goes through the same code path. ### Draft and confirmed An entry starts as a **draft**. A human promotes it to **confirmed**, and only confirmed entries are ever pushed into a session or handed to the parser — a draft is a proposal, not yet how your org works. That gate is enforced in the query, not by convention, so an unconfirmed entry cannot quietly start steering anything. Deleting an entry is recoverable; a delete hides it rather than destroying it. A proposal you dismiss is kept too, so the same suggestion isn't made to you twice. Zeno proposes what it learned; you decide what becomes house policy. ## How knowledge reaches a session Two mechanisms. Which one you pick changes how you write the entry. **Always inject.** Mark a confirmed entry to be pushed into every session. Use this sparingly — for the handful of things that are true of every job, like how your org handles intercompany transfers. Everything pushed this way competes for attention with the work in front of it. **Anchored retrieval.** Anchor an entry to what it's about, and it arrives whenever that thing does — nobody has to remember to go and ask. From the knowledge page you attach a **vendor**, which covers most of what a day needs. Working with Zeno in chat, it can also anchor an entry to a customer, a GL account, a document, a bank-feed item, or a property. Anchoring is the better default. An entry about Garden State Building Supply anchored to that vendor appears exactly when one of their invoices does and stays out of the way otherwise. Injection per result is capped, so a handful of tightly-anchored entries beat a pile of loosely-anchored ones. Entries can also carry attachments — a sample invoice, an agreement — so the context travels with the instruction. ## Teaching the document parser The chat agent isn't the only reader. When a document is uploaded, what you know about that vendor is handed to the parser that reads it — which is how a vendor's quirks stop being something a person has to remember. Two categories reach the parser, and they're used at different moments: * **Doc signature** goes into the *classification* prompt, which decides what the document is. Extraction quirks would be noise before the type is even known, so they're held back. * **Vendor quirk** goes into the *extraction* prompt, once the type is known and the parser is pulling out amounts, invoice numbers, and line items. The other categories stay with the chat agent. A story about last January doesn't help read an invoice. Alongside your entries, the parser is given the facts that help it disambiguate: vendor aliases — the name printed on the paper is often not the name in your books — and known utility account numbers mapped to a property or project. **Only the relevant slice is sent.** Zeno doesn't hand the parser your whole organization. Accounts and vendors are filtered to the entities the document actually mentions, matched against its text by name, address, or account number. A parse carries the knowledge about *that* document and nothing else, and the whole block is bounded so it can't crowd out the document itself. > [!NOTE] > > Only **confirmed** entries reach a prompt. A draft is a proposal sitting behind the human-confirm gate — it changes nothing about how documents are read until someone promotes it. ## It learns from your corrections Every time you fix something on a parsed document, that correction is recorded, and three learners turn the pattern into something reusable: * **GL lines.** A confirmed bill line with a GL account records the vendor and line description that went with it. From the second confirmation on, the parser suggests that account when the same line shows up. * **Vendor aliases.** A parsed vendor name that resolved to one of your vendors is remembered, so a spelling you've seen before matches faster next time — GARDEN STATE BLDG SUPPLY on a bank line and Garden State Building Supply in your books stop being two different things. * **Document type.** When a vendor's documents keep getting retyped to the same thing, Zeno drafts a **doc signature** entry anchored to that vendor — the classification it kept getting wrong, written down. That last one arrives as a **draft** for you to confirm, not a live instruction. And none of this ever overwrites a value a human set: the learners only accumulate evidence and propose. Correct a vendor twice and you've trained your bookkeeper on another vendor. ### Proposals waiting for you What the learners work out shows up as proposals in the document queue, in three kinds: * **What a sender sends** — a note about a vendor whose documents you keep retyping to the same thing. * **A default account for a vendor** — offered once their bill lines have settled on one account often enough to be a pattern rather than a coincidence, and only when you haven't already set one. * **A rule** — when the same vendor-to-account correction recurs. This one counts across surfaces: fixing it on a scanned bill and again on a bank line is two instances of the same correction, not one of each. Confirm a proposal and it goes live. Dismiss it and it stays dismissed — the same suggestion isn't made to you twice. ### Why did it read it that way Any parsed document can tell you which knowledge entries and rules were in play when it was read. When a document comes back wrong, that's the difference between guessing and knowing whether the cause was a rule, an entry, or neither. ## The log Every unit of work leaves a dated entry: what was done and why. The register and the audit log record the raw changes; the log explains them. Three months later, "why is this categorized to Repairs?" is answered by the log entry, not by a diff. Entries are tagged with the session that wrote them, so machine and human work are told apart. Zeno writes these as it goes rather than at the end, so an interrupted session still leaves a record. ## Working the queue with Zeno The **Inbox** under Zeno is a workspace over the pending bank-feed queue: one person and Zeno processing items together. You open a session, pull in a batch, and Zeno proposes categorizations grouped by pattern, so a hundred items come down to a handful of decisions. You approve groups, skip what needs a human later, leave notes on anything ambiguous, and close with a summary. Two things hold underneath: * **Posting is never a shortcut.** Batch approval loops the same approval path the one-by-one UI uses, so the audit trail and constraint checks are identical whether you clicked once or approved forty. * **Splits are atomic.** Categorizing one item across several accounts or cost centers approves and reposts in a single transaction, and the amounts must sum to the item's total. A rejected split leaves nothing posted. Items are grouped by payee before you see them, so a queue of a hundred charges arrives as a handful of clusters. The grouping splits by cardholder as well as merchant — on a shared card, who spent decides which cost center it belongs to. > [!NOTE] > > The Inbox is badged **Beta**. The rules, knowledge, and log layers underneath it are not — they drive the everyday bank-feed review whether or not you use this workspace. ## Everything is yours The rules, the entries, the anchors, and the log are your organization's data. You can read them, edit them, export them, and delete them. Nothing Zeno knows about your books is a black box you can't open. Judgment stays as text you wrote, not weights someone else trained. ## Where to go next * [Rules](https://zenorent.com/docs/rules.md) — conditions, batch apply, provenance, and promotion. * [Zeno in Claude](https://zenorent.com/docs/zeno-mcp.md) — the same knowledge, from your terminal. * [AI Bookkeeper](https://zenorent.com/docs/ai-bookkeeper.md) — the in-app chat surface. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.