Teams & Access
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.
The check itself has no override: a grant comes from being the originator, being named on the resource, or sharing one of its teams. There is no path that returns true simply because the caller is an administrator. Administrators do get broader visibility at the application layer, on specific operational surfaces such as module inventory and connected-client listings. That is an explicit, enumerable set, not a blanket read of everyone’s conversations and documents.
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
Worked example
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.