Governance and roles
Who may do what, and how every change is recorded.
Roles
| Action | Member | Admin | Owner |
|---|---|---|---|
| Ask decision questions, read history and conflicts | yes | yes | yes |
| Capture text and records | as candidates | yes | yes |
| Approve, reject, revoke decisions. Resolve or dismiss conflicts | no | yes | yes |
| Approve ontology proposals | no | yes | yes |
| Invite members and change roles | no | yes | yes |
| Organisation deletion | no | no | yes |
The table describes reviewed governance, the default. An owner can switch the organisation to peer governance in Settings → Team: every member then approves, rejects, revokes and retracts candidates and resolves or dismisses conflicts, and records a member captures as approved are stored approved when their evidence is found verbatim. Ontology approval, invitations, roles and organisation settings keep the roles above. Every action is attributed to the person who took it and recorded in the append-only review and audit history whichever mode is active.
Review
Memory → Needs review lists candidates and open conflicts with the reason they are there. Approve, reject, revoke, resolve and dismiss each require a reason and are recorded with the actor and the time. The same actions are available from the client through review_decision and resolve_conflict. Review history is append-only.
Audit
Successful resolver calls are recorded as usage. Audited writes, OAuth consent and team changes produce audit events. State and review history cannot be edited or deleted. Rows leave only with the workspace that owns them.