Giving a colleague access

What you open is an area, together with everything under it.

— Give my colleague read access to work/antarius/suppliers.

An invite code comes back. Hand it over; your colleague tells their own assistant:

— Accept an invitation to somebody's memory: code

From then on the area shows up in their answers, marked as somebody else's.

Why a code and not an email address: the server knows about an account, its areas and its licensed services — an address is not in that set. An unclaimed code can be cancelled; a claimed one stays in the list so it is visible who took it.

Read and write

With write access your colleague writes into your memory, and their rows are signed with their name — in your own answers you can see what you did not write. You can still edit them: otherwise a granted write could never be taken back in practice.

Read access does not carry write. An area is covered at a path boundary: access to work does not open work-archive.

What is visible and what is not

Visible is what conclusions rest on: events, facts, and the names of the entities at the ends of those facts.

Not shared: instructions, pinned notes and bookmarks for recurring jobs. A pin is mixed into every answer on its subject and instructions are followed — handing those over is not "read my memory" but "steer my assistant".

Taking it back

— Show me who has access to what. — Close this one's access.

The list shows who, to which area, with which right. A revocation takes effect on your colleague's next call.

Shared entities

Inside one organisation the directory of things is shared: two people writing about the same supplier land on one card, while a company of the same name in another organisation stays theirs.

The facts, events, instructions and todos stay personal — a colleague sees them only through access you granted.