Administer Maia

Govern memory and skills

Separate corporate, team, and personal knowledge and review shared changes.

Maia separates knowledge by audience. Personal knowledge belongs to one identity; team knowledge belongs to assigned team members; corporate knowledge applies across the tenant. Shared layers require tighter change control.

Know the layers

Layer	Audience	Change control
Corporate memory and skills	All governed users	Human approval
Team memory and skills	Users assigned to that team	Human approval
Gateway user memory and skills	One stable platform identity	Isolated personal flow
Local CLI memory and skills	The local Maia profile	Local profile flow

Understand storage paths

<MAIA_HOME>/corporate/memories/
<MAIA_HOME>/corporate/skills/
<MAIA_HOME>/teams/<team>/memories/
<MAIA_HOME>/teams/<team>/skills/
<MAIA_HOME>/users/<identity-hash>/memories/
<MAIA_HOME>/users/<identity-hash>/skills/

Gateway user directories use a stable hash so raw external identifiers do not become filesystem names.

Review a shared change

Let Maia propose the corporate or team memory or skill change.
Open Knowledge in the local dashboard.
Confirm the target layer, affected teams, and exact content.
Approve, deny, or request a revised proposal.
Verify the new knowledge with a user who should receive it and one who should not.

Do not promote raw imports automatically.

Memories and skills copied from Hermes or another system remain untrusted until reviewed. Imported personal material must not silently become corporate policy or team knowledge.

Resolve conflicts deliberately

Approved corporate and team instructions establish the shared boundary. Personal memories and skills must not weaken those instructions. When two shared layers conflict, correct the source policy instead of adding personal exceptions that hide the problem.