Team sharing

AiAkiv's real strength shows when several people build the memory together. Team isolation and `@` attribution keep it from blurring.

If you're building memory alone, you can skip this page. It's for building it together. That's where AiAkiv's real strength comes from.

What you gain by building together

Used solo, the payoff is small. But when several people and several AIs build memory in one team:

Decisions your colleagues made, and their reasons, come up in your searches.
People rotate off and the record of "why was this done this way" stays.
Who did what and when collects into one graph.

As seen in Teams and projects, the team is the unit of sharing.

Bring a colleague into a team and you read and build that team's memory together.
Inviting members is done by a person, in the console: invitations, roles, and alias setup are in Creating and managing teams.
The team is a fence. One team's memory is not automatically shared outside it. Your work team and your personal team can't see each other. (There is a separate way to open the fence deliberately → Links.)

So "who you share with" is decided by which team you save into. Shared team if you want to share it; personal team if it's just for you.

Who wrote it, via `@`: shared doesn't mean blurred

Once several people build in one team, "who put this in?" becomes a real question. AiAkiv records both the author and the team automatically at save time (it can't be forged). So you filter on two levels with @.

Per person: @colleague: only what that person put in.

ak what did @colleague flag on the save-file side?

Per team: @teamname: everything that team built together.
```
ak show me the balance decisions @gameteam made
```

If you've divided the team into parts, those parts can have @ names too: then search narrows to one branch of the org (Creating and managing teams).

Because of that, building together doesn't blur whose judgment: or which team's. It was. Details in Searching.

When you belong to several teams: where does it save?

Nobody uses just one team. You can be in several at once. personal team plus work team plus study group. Then "which team is this save going into?" becomes a real question.

The project is what decides that. A project is a set of coordinates for which team and which compartment, and the team in those coordinates is the team the memory is attributed to. So:

Save through a work project → it goes into the work team and is caught by @workteam.
Save through a personal project → it goes into the personal team and your colleagues never see it.

That's why checking the project (meaning which team it goes to) before saving matters, so you don't put a work memory into your personal team or the reverse. Checking and switching projects is in Teams and projects.

What the permission boundary actually blocks

Once a team is divided into sub-parts, the question becomes whether memory in a part you have no permission for is really out of reach. What you are allowed to store (content responsibility) is covered in What to store; this section is only about who can see what.

Memory in a part you can't read is not hidden, it is absent

Memory in a sub-part you have no read permission for does not reveal that it exists.

It never appears in search results, and it is not counted either.
Ask for an event by its exact id and the answer is that there is no such event. Not "you lack permission", but "not found". Saying otherwise would confirm that it exists.
Switching tools or rewriting the query changes nothing, because the filtering happens in the database itself. Even if the application forgot a condition, the row still would not come back.

A manager of a parent part can move memory out of a child part

In the part tree, the owner of a node above manages everything below it. So memory sitting in a child part can be moved to another part, and once moved only people with permission on that part can read it.

The move has conditions.

The mover must manage both the source and the destination. Pushing something into someone else's subtree, or pulling something out of one, is refused.
A reason is required. Without it the move is rejected, and every move is written to the audit log.
A move that widens the audience (from a narrow part to a wider one) raises a warning and needs a second confirmation.
Nothing moves out of the team. No permission crosses the team boundary.

Moving cannot cut the author off. Memory you saved stays readable to you no matter which part it is moved to. Moving changes what other people can reach, it is not a way to take someone's own record away from them.

But not forever, only while you are on the team. An author's access to their own memory rides on team membership, so once someone leaves the team they can no longer read even what they saved themselves. Cutting an author off is therefore a matter of removing them from the team, not of moving parts around.

Leave the team and you lose even your own writes

Permission rides on team membership. The moment someone leaves a team, everything in it closes to them, not only what others wrote but what they saved themselves.

Once they leave or are removed, that team's memory appears in no search and no lookup. It answers the same way parts do: not "no permission", but "not found".
Any static API key scoped to that team is revoked, and project settings pointing at it are cleared. An old key is not a way back in.
The memory stays with the team. It is not deleted because a person left, and the authorship stays recorded. The team keeps using it.
Come back on a new invitation and your own writes are readable again. Access was revoked, not destroyed. Part seats, though, have to be assigned again.

This is the counterpart to moving. Moving changes what other people can reach; removing someone from the team cuts their access entirely.

The team owner sees everything in the team

A team owner reads all memory in that team, regardless of how parts are arranged. Dividing a team into parts does not hide anything from the team owner. The team boundary still holds in the other direction: even an owner sees nothing in another team.

Entities and tags are not a security boundary

Entity names and tags are not gated by permission. Event bodies follow part permissions, but the names and labels extracted from them are shared across the team.

Don't put the secret in the name. An entity called Acquisition review: Acme can be visible to people who cannot read the body.
Tags work the same way. A tag like MnA-project-x shows up anywhere in the team.

What gets protected is the body; names and labels are the index you search by. If even the name must not surface, splitting into parts is not enough, so use a separate team.

What you may store (security) → What to store
How an AI keeps these rules → For AI agents