On this page you will learn:
- which visibility levels a record can have in an organization and who sees each;
- what visibility a new record gets;
- how to change visibility, and why an agent cannot get around the rule.
Levels
Section titled “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.
Visibility of a new record
Section titled “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
Section titled “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:
searchand 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, 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.
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
Section titled “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
Section titled “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.
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:
PATCH /api/v1/org/memories/4d428a41-e7b0-4f81-a886-f40c6f6c766cX-MMW-Space: <organization ID>Content-Type: application/json
{ "visibility": "author" }Response:
{ "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.