# Record visibility

> The four visibility levels of a record in an organization, the rule the server applies on every read, and how to change visibility.

On this page you will learn:

1. which visibility levels a record can have in an organization and who sees each;
2. what visibility a new record gets;
3. how to change visibility, and why an agent cannot get around the rule.

## Levels

| Visibility | In the account | API value | Who sees it |
|---|---|---|---|
| Author only | "only me" | `author` | The author alone. This is a draft: neither the head nor the admin sees it while the author works there |
| Unit | "the unit" | `unit` | People in the record's node and every node below it; heads and the admin whose subtree contains that node |
| Project | "the project" | `project` | Active members working in the record's project, contractors included. A key bound to a different project does not find it |
| Whole organization | "the whole organization" | `organization` | Every active member of the organization except contractors |

Role exceptions:

- a **contractor** sees only their own records and "project" records;
- an **auditor** sees no records at all;
- a person being offboarded or already gone, and a person whose access term has ended, sees nothing;
- the **recipient** of a departed employee's knowledge sees all of that person's records, drafts included — see [Offboarding](/organizations/offboarding/).

## Visibility of a new record

The server sets visibility on `remember`; the agent does not choose it:

| Who saves | Visibility of the new record |
|---|---|
| Member, head, admin | "the unit" — the node the author is attached to |
| Contractor | "the project" |

The author and node come from the key used for the call. That is why every person needs their own key: a shared team key mixes up authorship and breaks knowledge handover on offboarding.

## Where the rule is enforced

The rule is turned into a condition of the SQL query and applied inside the query, not as a filter afterwards. This holds on every read path:

- `search` and the graph relations in search results;
- `validate_memory`;
- `forget` — you cannot delete a record you cannot see;
- the account: the organization's Memory tab and Handed-over knowledge;
- the [archivist](/memory/archivist/), which links a new record only to records its author can see.

A record you cannot see appears neither in results nor in graph relations. Asking the agent to "search harder" does not help: the server simply never returns someone else's draft.

```text
  Ben's agent ── search("how do we deploy staging") ──► MMW
                                                          │
                    SQL: organization records where
                    (author = Ben)
                    OR visibility = organization
                    OR visibility = project
                    OR (visibility = unit AND node ∈ Backend, Engineering, Northwind)
                                                          │
  ◄──────────────── permitted records only ───────────────┘
```

## Worked example

Northwind has four records:

| Record | Author | Visibility |
|---|---|---|
| "Staging is deployed via the systemd unit app-staging" | Anna | the unit (Backend) |
| "Candidate to replace the queue: NATS, still comparing" | Ben | author only |
| "Client X API: limit of 100 requests per minute" | Vera | the project |
| "Releases go out on Tuesdays" | David | the whole organization |

Who finds what:

| Person | Staging | NATS | API limit | Releases |
|---|---|---|---|---|
| Ben (member, Backend) | yes | yes, his own | yes, if in the project | yes |
| Anna (head of Backend) | yes, her own | no | yes, if in the project | yes |
| David (admin, root) | yes | no | yes, if in the project | yes, his own |
| Vera (contractor) | no | no | yes, her own | no |
| Grace (auditor) | no | no | no | no |

Neither Anna nor David sees Ben's NATS draft. If Ben is offboarded and his knowledge is handed to Anna, she will see that draft too.

## Changing visibility

**A departed employee's knowledge.** The recipient opens Handed-over knowledge → "Open records" and, for each record, picks a value under "Visible to": only me, the unit, the project or the whole organization. Each such change is written to the [audit log](/organizations/audit-log/).

**Your own records.** The server lets an author change the visibility of their own records through the account API; the account UI has no separate switch for your own records yet. The request is sent on behalf of the user signed in to the account, and the organization is selected with the `X-MMW-Space` header:

```http title="Turn your own record into a draft"
PATCH /api/v1/org/memories/4d428a41-e7b0-4f81-a886-f40c6f6c766c
X-MMW-Space: <organization ID>
Content-Type: application/json

{ "visibility": "author" }
```

Response:

```json
{ "id": "4d428a41-e7b0-4f81-a886-f40c6f6c766c", "visibility": "author", "org_node_id": "…" }
```

Allowed `visibility` values: `author`, `unit`, `project`, `organization`. With `"to_my_unit": true` the record moves to your current node, so "the unit" now means your new unit. You can change only your own records and records handed over to you; for anyone else's record the server answers `memory_not_found`.

An `mmw_…` API key does not work for this request: it is an account action, not an MCP tool. Visibility cannot be set through MCP tools.

"Holding" visibility and sharing between legal entities of a holding are currently switched off: such records stay with their author.

## Next steps