Knowledge notes: what your business learned

In March, a music shop stopped stocking one supplier's guitar strings. There was a good reason: three faulty batches in a month, a distributor who would not replace them, a better line from someone else. By October, a regular asks for that brand again, and nobody behind the counter can say why it left the shelf. The decision was sound. The reasoning lived in a chat thread that has long since scrolled away.

That gap has a shape. The order, the return, the call to the distributor are all on the timeline, each dated and attached to the right contact. What is missing is the thing that tied them together: the conclusion the owner reached, and why. A business learns things all the time, and until it has a home, that layer lives in heads and dead threads, where it quietly evaporates. This is about giving what you learn a place to stay.

What is a knowledge note?

A knowledge note is a piece of your business's reasoning, written down where you can find it again. It is markdown, so it can be a sentence or a page: a title, a body, and the context that makes it useful later. To that you add up to twenty tags, up to twenty external sources (a link, with a label if you want: the distributor's email, a spec sheet, a supplier's terms), and links to the contacts and events it concerns, and to other notes. A note stays small on purpose: a title up to two hundred characters, a body up to twenty thousand.

Here is the strings decision, written as a note:

# Dropped the Aurora string line

Three faulty batches in March, all high-E breakage out of the packet.
The distributor declined to replace them, so we moved to the Lumen
line, which has held up since. Revisit if Aurora changes supplier.

That one is tagged decision, linked to the distributor and to the three return events behind it, with the distributor's refusal email saved as a source. Three tags carry a convention worth learning, because they name the three kinds of thing a business learns. A decision is a choice you acted on, kept with its context and its justification. A reflection is a living hypothesis or analysis, something you are still testing, like whether this district buys more in spring. An observation is a field fact: this distributor takes three weeks to answer. They are tag slugs, a shared habit rather than three buttons in the app, and a note can carry other tags beside them.

Most notes are not typed by hand. Your assistant captures them as you work, and a note it writes is marked ◆, the mark of entries added by an assistant: dated, signed, and correctable, so you always know what came from you and what came from it. The reasoning is written down, but it is never written behind your back.

The three memories: what happened, how you work, what you learned?

Historis already kept two kinds of memory, and knowledge notes are the third. It helps to see them side by side, because the mistake is asking one to do another's job.

The timeline remembers that the return happened on the fourth. A rule remembers to check the stock note before promising a date. Neither is built to hold the sentence 'we dropped that line because the batch was faulty and the distributor would not replace it.' That is not an event, and it is not a behavior. It is something learned, and it belongs in a note.

The dividing line is grammar, the same trick that sorts a fact from a rule. 'This happened' is an event. 'When X, do Y' is a rule. 'We decided X because Y', or 'X seems to be true', is a knowledge note. Get the split right and each memory stays legible instead of turning into a drawer where everything lands and nothing is found.

Where do notes live in the app?

Knowledge notes have their own screen, reached from Knowledge in the sidebar. It opens as a list you can search in full and filter by status (active or archived) and by tag. Open one and you get the note rendered from its markdown, its sources as links you can click, its linked contacts and events as chips you can follow, its visibility, and, if it has been replaced, a banner pointing to what replaced it.

Most notes arrive through your assistant over MCP, the same one-time connection the rest of Historis uses, at the moment the reasoning is fresh; the app also has a New note button for the times you would rather write one by hand. Either way, the app is where you read, refine, and archive: an edit modal reworks the title, the markdown (with a write tab and a preview tab), the tags and the sources, and archiving asks you to confirm. The principle is the house rule of the whole product: an assistant's writes apply directly, but they stay visible, attributed, and yours to correct. It writes the first draft of what the business learned; you keep it honest.

Each contact's page also gains a Knowledge tab, listing the notes linked to that person. So the strings decision does not only live on the knowledge screen; it surfaces on the supplier's own record, next to the orders and calls it grew out of.

Why is delete the exception, not the default?

Your assistant can never delete a note: the tool surface has no delete action at all. You can, from the app, but only once the note is already archived, a deliberate two-step so a live piece of reasoning never disappears in one click. For everything else the lifecycle is archive and supersede, and both keep the history rather than burning it: a business's reasoning is worth more as a record than as a clean slate.

Archiving is a status flip. The note stays readable, but it leaves active knowledge and the default search view. It is how a note retires: still there when you go looking, out of the way when you are not.

Superseding is for when a decision changes. It points the outdated note at its replacement in a single transaction: a replacement created in that same step inherits the old note's visibility, its tags and its links, the old note is archived, and the app shows a superseded banner linking the two. A decision that changed is still a decision you made. The old reasoning was not wrong to keep; it is how you got here. Deleting it would erase the why, and the why is the part worth having; superseding keeps the whole chain, dated.

How does your assistant find the right note at the right moment?

A memory only helps if it surfaces when you need it. Your assistant searches notes with search_knowledge, and the search has two halves. Full text always runs: it stems French and ignores accents, so a search for 'reparation' finds the accented spelling and the reverse. When your assistant also supplies the query as a vector, embedded on your side with the same provider your worker uses, a semantic branch runs beside the full-text one and the two rankings are fused, so an indexed note that means the same thing without sharing a word can still come back. You can narrow any search by tag, by status, or to a single contact or event.

The other half is that the right note often arrives unasked. When your assistant opens a contact with get_person_context, up to ten active notes linked to that person come inlined, with an exact total so it knows when there are more to fetch. At the organization level, the context tells your assistant how many active notes exist and to search them before asking you something the business already wrote down. The reasoning behind the strings decision is handed over the moment the assistant opens the supplier, not left for it to stumble on.

Does semantic search need setup?

That semantic branch deserves a plain account, because it is opt-in and it depends on you. Historis never computes an embedding. It runs none of that on the server. The semantic half is exactly as good as the vectors your own indexing worker produces, and no better.

Those vectors come from historis embed, a small command that runs on your own infrastructure with your own embedding provider. Your provider's key stays with you; Historis never sees it. historis embed run makes one pass and is happy on a cron; historis embed run --watch stays resident and sweeps again on an interval you choose; historis embed status tells you whether the stored contract matches and how many notes are pending. You declare the contract, your provider and its dimensions, once for the organization. Editing a note's content clears its embedding so the worker recomputes it next pass, and changing the contract clears every stored vector for the worker to redo, after it asks you to confirm.

Here is the honest part: if you never run the worker, nothing breaks. Full text still finds every note, because full text runs on every note. Semantic search is the branch you switch on when you want meaning-matching too, and its coverage grows exactly as far as your worker has indexed. It degrades gracefully; it never leaves a hole. The same principle runs under all of it: you bring your own AI, and the intelligence stays on your side of the line.

The business keeps its reasons

By October, the regular asks for the strings again, and this time there is an answer. The note is on the supplier's record: dropped, and why, with the returns linked and the distributor's email attached. The owner reads it back in a sentence and moves on. That is the shift. The memory of your business stops keeping only what happened and starts keeping what it learned, every entry dated and signed. Let an assistant write the reasoning down as it comes, and it stops leaving with the thread.