--- slug: sharing title: "Team sharing" description: "AiAkiv's real strength shows when several people build the memory together. Team isolation and `@` attribution keep it from blurring." lang: en --- # Team sharing 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. ## The team is the boundary you share across As seen in [Teams and projects](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](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](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](teams)). Because of that, building together doesn't blur **whose judgment: or which team's. It was.** Details in [Searching](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](teams-and-projects). ## What the permission boundary actually blocks Once a team is divided into [sub-parts](teams), 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](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.** ## Next - What you may store (security) → [What to store](what-to-store) - How an AI keeps these rules → [For AI agents](for-ai-agents)