Skip to content

Identity & Roles⚓︎

This document defines the identities in DMS and the boundary between platform operations and the decision domain.

System Identities⚓︎

DMS separates people who use the decision memory from people who operate the platform.

User (The Participant)⚓︎

The only identity allowed inside the Decision Domain.

Create and participate in Topics
Hold specific roles (Owner, Advisor, etc.)
Influence decisions and, when authorized, make them

Admin (The Operator)⚓︎

Responsible for the Platform only.

Manage accounts and organizations
Enforce security and legal policies
Strictly forbidden from seeing or participating in Topics inside the Decision Domain

System (The Automation)⚓︎

The automated background identity.

Enforces auto-archiving and retention
Triggers notifications and reminders
Can create operational audit entries, but never human-authored reasoning

Identity Boundaries⚓︎

To protect trust, DMS enforces three hard boundaries:

  1. No Silent Access: Admins cannot "shadow" a topic. Access must be granted via an explicit Role.
  2. Zero-Knowledge Ops: The platform is designed so that Operators (Admins) manage the theater but never see the play.
  3. Attributed History: Every action in a Topic is signed by a User or the System. Admins never appear in decision history.

Trust Principles⚓︎

  • Participation is explicit: You always know who is in the room.
  • Authority is explicit: Capabilities are tied to visible roles.
  • Memory is protected: Decisions cannot be altered once finalized.