# Check what Connect knows about a person

Open the memory viewer from the person's record. It shows four tiers — workspace, channel, endpoint and contact — and returns each one even when it is empty, so 'nothing is set here' is a visible answer rather than an absence you have to infer. The narrowest tier that holds something is the one shaping behaviour.

- **Status:** Available
- **Audience:** both
- **In the app:** #/relationships, #/mailboxes
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/how-to/check-what-connect-knows/

## The four tiers and why order matters

Memory resolves narrowest-first, the same hierarchy autonomy uses: workspace, then channel, then endpoint, then contact. Something set against one person overrides the channel-wide note, which overrides the workspace one. This is why a correction made at the wrong level appears to have no effect — it was made, it is stored, and something narrower is still winning.

| Tier | Scope | Typical content |
|---|---|---|
| Workspace | Everything | How the business describes itself; standing preferences |
| Channel | One channel | How to behave on the phone versus in writing |
| Endpoint | One mailbox or one number | A line's own conventions |
| Contact | One person | What this customer prefers, and what to avoid with them |

> **Note** Every tier is returned, including the empty ones. That is a deliberate design choice: an empty tier shown as empty answers a question, while a tier omitted from a list leaves you guessing whether it was checked.

## Reading it

1. Open the person's record and launch the memory viewer from it.
   - Result: The viewer is reachable from the mailbox row, the channel screen and the contact panel, so you can come at it from whichever screen raised the question.
2. Read the contact tier first, then work outwards.
   - Result: You are looking for the narrowest entry that explains the behaviour you are investigating. Reading outward from the narrowest finds it in the first place it can be.
3. Check the tags on each entry, not only the text.
   - Result: Directives are read from the tag list rather than from the body. A block on a channel is a tag; a sentence in the body saying 'do not contact this person' is prose that nothing enforces.
4. Note the provenance on anything surprising.
   - Result: Memory recorded from a conversation or a call reads differently from memory somebody typed, and knowing which it is decides whether you correct it or correct the source.

## Correcting what is wrong

- **Edit it** where the substance is right and the detail is wrong. The entry keeps its place in the hierarchy.
- **Forget it** where it should never have been recorded. Anything at any tier can be forgotten.
- **Supersede it** where the truth has changed. The new entry replaces the old rather than sitting beside it, which is what stops two contradictory notes both being in play.
- **Move it** where the content is right and the tier is wrong — a preference recorded against one contact that actually applies to the whole channel.

Then check the correction reached behaviour. Reopening the viewer proves the record changed; it does not prove anything downstream changed. The stronger test is to look at the next reply or the next call on that relationship and see the difference, because a correction that only lives in a viewer is a correction that did not stick.

> **Careful** A block is memory, not a setting. It is a row against the contact tagged for the channel, which is precisely what makes it hold across channels and into future conversations — and also why removing a block means removing that entry rather than looking for a switch.

## What the viewer will not show you

**Knowledge** — Material the workspace supplied for grounding answers is separate from memory. If an answer quoted a policy, that came from Knowledge.
**The conversation history itself** — Memory is what was distilled and kept, not the transcript. The timeline holds the events.
**Another workspace's memory** — Isolation applies here as everywhere: the kernel and row-level security both filter, so there is nothing to leak.
**Anything about a person Connect has not met** — An empty contact tier on a new relationship is correct, not a fault.

## Questions

### I deleted a memory and behaviour did not change. Why?

Almost always because another tier still holds something similar, or because the behaviour was coming from Knowledge rather than memory. Read outwards through the tiers first, then check whether a grounded source is saying the same thing.

### Can a customer ask what Connect knows about them?

Everything memory holds about a person is readable in the viewer, at every tier, and any of it can be forgotten. That is the mechanism behind answering such a request; the policy around it is yours to set.

### Does memory expire?

Entries are not aged out automatically. Superseding is the intended way to keep it current, which is why a periodic read of the contact tier on your most active relationships is worth the ten minutes.

## Related

- [The four memory tiers](https://connectbyjbrh.com/docs/memory/tiers/)
- [Seeing what Connect knows](https://connectbyjbrh.com/docs/memory/viewing/)
- [Superseding a memory](https://connectbyjbrh.com/docs/memory/superseding/)
- [Block and guidance directives](https://connectbyjbrh.com/docs/memory/directives/)
- [Correct something Connect got wrong](https://connectbyjbrh.com/docs/how-to/correct-a-mistake/)
- [Making a correction actually change behaviour](https://connectbyjbrh.com/research/memory-correction-that-sticks/)
- [Knowledge and memory](https://connectbyjbrh.com/docs/compare/knowledge-vs-memory/)

## What this page is based on

- Connect source pack: overview (docs-source/sources/GENERAL.md §6 — memory)
- Connect source pack: channels (docs-source/sources/CHANNELS.md §1 — triage and blocking)
- Connect capability registry (docs-source/facts.py — memory_tiers, block_directive)