# Reviewing everything Connect knows about a person

Everything Connect holds about one person is readable in one sitting: four memory tiers in the viewer, the tags on each row, the identities that resolve to them, and the conversations on their timeline. The review is worth running when somebody asks what you hold, when behaviour towards an account has drifted, and before anyone deletes anything in bulk.

- **Status:** Available
- **Audience:** both
- **In the app:** #/relationships, #/data, #/timeline
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/workflows/memory-review/

## The stages

1. TRIGGER — a request from the person, a dispute about a reply, or a periodic review of an important account
2. USER / EXTERNAL EVENT — a colleague opens the person in relationships
3. AUTH / WORKSPACE RESOLUTION — every record read here belongs to one workspace, filtered by the allowlist, the ORM kernel and row-level security
4. INGEST / REQUEST — Customer 360 for the history, the memory viewer for the tiers, the memory sheet in the grid filtered to that person
5. CANONICAL RECORD — the Person, the Identities that resolve to them, and their threads, messages and calls
6. CLASSIFICATION / RESEARCH / REASONING — read the four tiers in resolution order and note which rows carry tags
7. KNOWLEDGE + MEMORY + RULES — separate what is memory about this person from Knowledge, which is about the business and is not personal data
8. AUTONOMY / APPROVAL — decide what changes; a do-not-contact entry is not cleared casually and the Assistant cannot clear one at all
9. ACTION / PROVIDER — edit, supersede, forget, merge a duplicate, or add a block
10. RESULT — the tiers as they now stand, which is what the next reply will read
11. RELATIONSHIP / TIMELINE / MEMORY — merging duplicates repairs identity everywhere at once; the timeline itself is unchanged
12. AUDIT / USAGE / NEEDS YOU — what was decided is recorded, refusals included

## Running it

1. Open the person and read the memory viewer top to bottom — workspace, channel, endpoint, contact.
   - Result: You see the whole context a reply to them is written against, in the order it is resolved. Empty groups are shown, so "nothing is set here" is part of the answer.
2. Look at the tags on every row, not only the text.
   - Result: A `block:<channel>` tag is the difference between a note and an enforced prohibition, and the body will not tell you which you are looking at.
3. Check the identities. One person should hold every address and number you know of for them.
   - Result: A second record for the same human is the usual explanation for context that seems to vanish between channels. Merging repairs it everywhere at once.
4. Read the timeline for anything the tiers do not explain.
   - Result: Conversations are history rather than claims, so a surprising reply is often explained by a thread rather than by a row.
5. Filter the memory sheet in the grid to that person and export if you need a copy.
   - Result: CSV export neutralises formulas, so an exported cell cannot execute when the file is opened in a spreadsheet.

## What to look for

| What you find | What it usually means | What to do |
|---|---|---|
| A contact tier with nothing in it | Replies have been generic because there was nothing personal to read | Write what the account team actually knows |
| A long contact tier of narrative | Somebody has been keeping notes rather than claims | Reduce to durable statements; the 600-character block will cut the rest on a call anyway |
| A row nobody recognises | Usually call-derived, on a person whose identity resolved differently from what you assumed | Check the identities before deleting it |
| A tag with an empty-looking body | A directive with no explanation | Write the reason in the body; it has no effect on behaviour and every effect on the next reader |
| Two person records | Cross-channel context has been split in half | Merge them |
| A workspace-tier row about this person | Something written at the wrong scope, applying to everyone | Rewrite it at the contact tier and forget the original |

## Answering a request to see what you hold

When somebody asks what a business holds about them, the memory tiers are only part of the answer. The conversations, the person and identity records and the timeline are the rest, and they are separate decisions with separate consequences — forgetting a memory does not remove a thread, and removing a thread does not remove a suppression that protects them.

> **Note** Nothing here is legal advice and Connect holds no certification. What this page describes is where the records are and what each action actually removes, which is the part a person answering such a request needs to get right.

The [Connect Assistant](/docs/assistant/) shortens the reading with `recall` and `customer_360`, both read-only and both bounded by the same workspace isolation as the screens. It is a faster way in, not a different set of records.

## Questions

### How often is this worth doing?

For most contacts, never — the viewer is there when a question arises. For accounts where the relationship matters and several colleagues write memory, a periodic read is what stops the tier filling with lines that contradict each other. Reading costs nothing and counts against no allowance.

### Does a customer workspace get the same audit?

Yes. The same screens over the same implementation, with a tenant's requests arriving on the customer API path. There is no reduced view and no capability here that belongs only to the operator.

### Can I see everything at once rather than person by person?

The memory sheet in the Data grid is the whole workspace in one table, with sorting, filtering, grouping and saved views. That is the right surface for a sweep; the viewer is the right one for a single person, because it shows the four tiers in resolution order.

## Related

- [Seeing what Connect knows](https://connectbyjbrh.com/docs/memory/viewing/)
- [Person memory](https://connectbyjbrh.com/docs/memory/person-memory/)
- [Forgetting something](https://connectbyjbrh.com/docs/memory/deleting/)
- [Where a memory came from](https://connectbyjbrh.com/docs/memory/provenance/)
- [Relationships in Connect](https://connectbyjbrh.com/docs/relationships/)
- [Files and data in Connect](https://connectbyjbrh.com/docs/files-data/)

## What this page is based on

- docs-source/sources/GENERAL.md §6 — the viewer, tiers and forgetting
- docs-source/sources/GENERAL.md §9 — the memory sheet, saved views, CSV export
- docs-source/sources/GENERAL.md §8 — recall and customer_360, and narrower rights
- docs-source/sources/GENERAL.md §2 — three layers of workspace isolation