Module 07

Permissions and people

Permissions that match your org chart, because reporting lines are records rather than an assumption.

What it does

A role with its permission matrix, drawn schematically

112 codes, 7 record-level scopes: A permission says what you may do, and a scope says which records it reaches: your own, your reports, your group, projects you run, projects you belong to, or the organization.
Nine role templates, seeded as editable copies: A role is a starting point rather than a fixture. You cannot grant a permission you do not hold yourself, you cannot edit a role that outranks you, and you cannot assign yourself one.
Reporting lines are records: A manager sees their reports and a group lead sees their group because the org chart says so, not because somebody remembered to tick a box.
An append-only audit trail: Entries are hash-chained, so a gap is detectable rather than invisible. Removing an entry would break the chain that makes the rest of it verifiable, which is the point.
Four layers of tenant isolation: Application authorization sits over row-level security in the database, so a permission bug does not become a cross-tenant read.

Naming the ceiling is what makes everything above it credible. The roadmap says which of these are deferred and why.

Log a real week of your own hours and put it through approval. That is a better test than any feature list, and it takes an afternoon.