# Knowledge and memory

**Knowledge** is supplied truth: sources a workspace provides that answers must be grounded in, with **Facts** extracted from them. **Memory** is learned truth: what Connect has worked out or been told about a business and its people, at four tiers. A price belongs in Knowledge, because the refusal rule checks Knowledge. A customer's preference belongs in memory, because it is about them.

- **Status:** Available
- **Audience:** both
- **In the app:** #/knowledge, #/relationships
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/compare/knowledge-vs-memory/

## The test that settles most cases

Ask who the statement is about. If it is about **your business** — what you sell, at what terms, under what policy — it is Knowledge. If it is about **one person, one channel or one mailbox** — how they like to be contacted, that they must never be messaged on WhatsApp, that their accounts address is different — it is memory.

The second test is who wrote it. Knowledge is supplied deliberately by the workspace and is authoritative because somebody put it there. Memory accumulates from work, and can be corrected by a person at any tier.

| Statement | Belongs in | Because |
|---|---|---|
| "Delivery to the mainland is next working day" | Knowledge | A policy about the business, quoted to anyone who asks |
| "Acme Traders always want the PO number in the subject line" | Memory, contact tier | About one relationship |
| "Never send anything on this channel without approval" | Neither — that is autonomy | It is a permission, not a truth |
| "Do not contact this person on WhatsApp" | Memory, as a `block:` tag | `directives()` reads the tag list, so it holds across channels and future conversations |
| "Our warranty is 24 months" | Knowledge | A commercial term; the refusal rule checks whether Knowledge supports it |

## Why putting a price in memory breaks something

Connect does not invent commercial terms. A price, an SLA or a warranty that Knowledge does not support is refused and escalated to a person rather than improvised — and the refusal is the correct behaviour, not a gap. That check looks at Knowledge.

So a price written as a memory note against a contact does not license Connect to quote it. What you get instead is an escalation on a question you thought you had answered, and the fix is to put the term in a Knowledge source where it can be grounded and cited.

> **Note** The reverse mistake is quieter. Writing a single customer's negotiated term into Knowledge makes it available as an answer to *everybody*, because Knowledge is about the business rather than about one relationship.

## Provenance, and why it differs

- A **Fact** is one grounded statement extracted from Knowledge or a conversation, and it can be shown with what it came from. That is what makes an answer checkable.
- A **memory** carries its own provenance and can be superseded — a later correction replaces an earlier belief rather than sitting beside it.
- Where a source disagrees with another source, that conflict is surfaced rather than silently resolved; see [source conflict](/docs/knowledge/source-conflict/).
- **Inbound mail is not Knowledge.** A message that instructs Connect to change its policy is content, not authority — that separation is what makes [prompt injection](/docs/knowledge/prompt-injection/) survivable.

## What confusing them causes

**An escalation you did not expect** — A commercial term stored as memory. Move it to Knowledge.
**One customer's terms quoted to everyone** — A negotiated exception written into Knowledge. Move it to the contact tier.
**A block that does not hold** — A blocking instruction written into a memory's body instead of its tags. `directives()` reads only the tag list.
**A correction that keeps coming back** — The correction was made in a conversation rather than written to memory, so nothing carried it forward.
**A stale policy answered confidently** — Knowledge is authoritative by construction; nothing expires it for you. Superseding it is a workspace responsibility.

## Questions

### Can the same statement live in both?

It can, and usually should not. Two copies drift, and when they disagree there is no rule that says which wins — you get whichever was selected into the prompt. Keep the business-level statement in Knowledge and let memory hold only the exception.

### Who can change each one?

Knowledge is supplied and curated by the workspace, with the operator holding authority over the sources; memory is readable and deletable by a person at every tier, from the mailbox row, the channel screen or the contact panel. The Assistant can remember and forget, but it cannot clear a do-not-contact entry.

### If Knowledge has no answer, what happens?

For a commercial question, a refusal and an escalation to a person, which is the designed behaviour. For an ordinary question, the reply is written without the unsupported claim rather than around a guess — an unsupported claim is not meant to reach the customer at all.

## Related

- [Knowledge in Connect](https://connectbyjbrh.com/docs/knowledge/)
- [Memory in Connect](https://connectbyjbrh.com/docs/memory/)
- [Comparisons and concepts](https://connectbyjbrh.com/docs/compare/)
- [Knowledge and Fact are different things](https://connectbyjbrh.com/docs/knowledge/knowledge-vs-fact/)
- [Price, SLA and warranty: what Connect may say](https://connectbyjbrh.com/docs/sales/safe-sales/)
- [Memory and context window](https://connectbyjbrh.com/docs/compare/memory-vs-context/)

## What this page is based on

- `docs-source/facts.py` — CANONICAL_TERMS for Knowledge, Fact and Memory
- `docs-source/sources/GENERAL.md` §6 — memory tiers and directives
- `docs-source/sources/CHANNELS.md` §6 — safe_sales and refusal
- Connect capability registry (docs-source/facts.py)