Teams & Access

3 min read

Access in MindFront is governed by Teams. A team is a named group of users — HR, FINANCE, SALES, IT, EXEC — and every resource that contains information (memories, conversations, documents, drafts, reports) is tagged with the teams allowed to see it.

There are no levels and no hierarchy. A user can see a resource if any of three things is true:

They are the originator of the resource — the human it was created for, or the human who created it.
They are explicitly added to the resource (e.g. added to a conversation).
They share at least one team with the resource’s tagged teams.

This is OR-semantics: one match anywhere is enough. Nothing else grants access — there is no policy engine, no role hierarchy, no exception clause to misconfigure.

Where a resource’s tags come from

Resources inherit their access tags from the context that produced them. A report generated in a Finance-team conversation carries the FINANCE tag; a draft written while handling one person’s request belongs to that person. Nobody files paperwork to classify output — the tags follow the work.

Resources MindFront produces on its own — scheduled jobs, background work — have no personal owner. They are visible only through their team tags.

Enforcement

Access is checked where the data is read, not where it is displayed. Every store MindFront reaches on a user’s behalf — memories, conversations, documents, business events — is filtered to that user’s grants before any answer is composed. When MindFront acts for a user, it holds exactly that user’s access: one person’s question can never surface another person’s data.

Two built-in teams

Team	Membership
`Everyone`	Every user in the org belongs. Membership is mandatory — there’s no way to remove a user from it. Use it to tag anything the whole org should see.
`Admin`	Operators of the system. Created at install; users are added by other admins. The Admin team is a normal team grant, not a god-mode bypass. Admins only see resources actually tagged with `Admin` (or shared via team overlap / explicit add). Personal resources stay personal.

The other teams in your deployment — HR, FINANCE, etc. — are whatever your administrator creates to match the access boundaries that already exist in your organization.

Example

%%{init: {'flowchart': {'defaultRenderer': 'elk'}}}%%
flowchart LR
    %% Users
    Alice((Alice
Everyone + HR + FINANCE))
    Bob((Bob
Everyone + SALES + IT))
    Carol((Carol
Everyone + EXEC + HR +
FINANCE + SALES))
    Admin((Admin
Everyone + ADMIN))

    %% Resources
    HRM[HR Memories
tagged: HR]
    FINM[Finance Memories
tagged: FINANCE]
    SALESM[Sales Memories
tagged: SALES]
    ITM[IT Memories
tagged: IT]
    EXECM[Executive Memories
tagged: EXEC]
    PRIV[Alice's Personal Notes
no teams, originator: Alice]

    Alice --"HR"--> HRM
    Alice --"FINANCE"--> FINM

    Bob --"SALES"--> SALESM
    Bob --"IT"--> ITM

    Carol =="EXEC"==> EXECM
    Carol =="HR"==> HRM
    Carol =="FINANCE"==> FINM
    Carol =="SALES"==> SALESM

    Admin -."ADMIN".-> HRM
    Admin -.->|"no team overlap"| PRIV

    Alice --"originator"--> PRIV

    style Alice fill:#f9f,stroke:#333
    style Bob fill:#bbf,stroke:#333
    style Carol fill:#fcf,stroke:#333
    style Admin fill:#ffa,stroke:#333

    style PRIV fill:#ddd,stroke:#999

Note the Admin user in this example sees the HR/Finance/Sales/IT/Exec memories only because those memories are also tagged with the Admin team. Tag a memory exclusively with HR and even an admin won’t see it without HR membership. Alice’s personal notes have no team tags at all — only Alice (the originator) sees them, full stop.

Access table

	Required to access
Another user’s resource	At least one team in common with the resource’s tagged teams, OR you are added to it.
A memory	At least one team in common with the memory’s tagged teams.
A conversation	You are the originator, an added user, or in one of its teams.
A draft / approval	Same as the conversation it belongs to.

How team membership works

Teams are created and assigned by your administrator. When a user joins the organization, the administrator adds them to the teams that match their role — HR for HR staff, FINANCE for finance staff, and so on. Adjusting access later is a matter of changing team membership, not relabelling every resource.

Ask your administrator to create new teams, change membership, or grant access at any time.