Navigator keeps the audience split precise because the authorization model is precise. persons.role has five stored
values in authority order (and anonymous is the public visitor with no row):
owner — the system owner and highest tier. Owner inherits Admin and Lawyer authority; only Owner governs Owner.admin — a licensed lawyer with system administration authority. Admins manage installation-wide settings and can see
every Project without per-Project assignment, but cannot manage Owner identities.lawyer — a person licensed to practice law. Lawyer users work assigned matters through /lawyer and AIDA; the
legal workflow still records which lawyer advanced each step.clerk — a supervised non-lawyer worker. Clerk's /clerk surface provides a read-only list of supervised
Projects and their lawyer DRI; Clerk receives no legal advice, approval, Git, MCP, or /lawyer authority by
inheritance. Any upload or preparation task remains a narrow, supervised Project capability.client — a person represented on one or more matters. Clients use /app/projects to see reviewed documents,
Engagements/Notations, invoices, signatures, and other client-facing matter surfaces.
Project participation is separate from role. A client sees a matter through the client lens because the Project records
them as a client participant. A Lawyer user sees a matter through the firm lens only when the Project has a firm-side
participation row for that lawyer; the is_lawyer_dri marker rides that same participation row, so naming the lawyer
DRI and recording their firm-side participation are one act. Clerk work begins with /clerk: the Clerk's own firm-side
participation and a disclosed Lawyer DRI are both required for its limited coordination view. That is why the
application can delegate preparation without turning a Clerk into a lawyer.