Appendix A — The Action Catalogue

This guide teaches the common journeys; the Action Catalogue is the complete, role-by-role reference for every action in Aegis — and this appendix shows you how to read it.

The chapters in this guide walk you through the tasks most people do most of the time — drafting a policy, logging an incident, handling a data-subject request — in the order you are likely to do them. They are deliberately selective. They do not list every screen, button and permission for every role, because that would make a reference, not a guide.

That exhaustive list is the Action Catalogue (a structured reference of every action in the application, recorded role by role). Where this guide says “a Contributor can upload evidence”, the catalogue is where you confirm the full set of evidence actions for every role, down to the individual permission and the exact control it lives on.

This appendix points at a document, not a screen

The Action Catalogue is not a page inside Aegis. It is a long reference document that ships with the product, so there is no screenshot to annotate here. What follows orientates you to the document’s layout and walks you through looking an answer up in it.

Where to find it

The catalogue lives in the Aegis repository at docs/USER_ACTIONS_BY_ROLE.md. It is a single Markdown file of roughly 17,000 lines, so open it in an editor or a Markdown viewer that gives you a search box and a table of contents rather than reading it top to bottom.

It is generated from the application’s own source — the route files under src/app/(app)/, the API permission checks under src/app/api/, and the role-to-permission map in src/lib/permissions/index.js — and is regenerated after large interface or permission changes rather than continuously. Always read the dated header line before relying on a detail. The current edition records four milestones: a base generation on 1 July 2026, a delta refresh on 16 July 2026, a drift reconciliation on 21 July 2026, and a preservation reconciliation on 22 August 2026 against the develop branch.

What’s in the document

The file runs in a fixed order, from broad to narrow. Knowing that order is most of the work of using it.

Roles & permission model — the four-role hierarchy in one table, plus a warning about pages whose on-screen guard is stricter than the underlying API permission. Read this once; it explains most surprises later in the file.
Contents — a linked index of the domain sections, so you can jump straight to Policies, GDPR, Vendors and the rest. It is not quite complete: four sections that exist in the catalogue — Action Items, Audits, Programs, RACI & Quality Measures and Threat Actors — have no entry here, so search the file by name if a domain has no link.
Capability maps by role — four long sections, one each for Admin, Manager, Contributor and Viewer. Each opens with a paragraph on what that role can do and, more usefully, what it notably cannot do compared with the role above it, then lists its actions grouped by area.
Action count by domain — a table of domains against the number of catalogued actions in each, ending in a stated total. It is the fastest way to gauge how much surface a module has. The same four sections are missing here as from Contents, so do not read a domain’s absence from this table as an absence from the catalogue.
Detailed action catalog by domain — the bulk of the file, spelled in the file with the American catalog. One section per domain, each action numbered and written out in full.
AI actions by role — every AI-assisted action gathered in one place, because they share a common permission and licensing pattern.
Catalogue deltas — the two Catalog Delta sections at the very end, recording what changed at the 16 July refresh and the 21 July drift reconciliation.

On scale, the file gives three different figures, so treat none of them as an audited count. The domain table lists 58 domains and a total of 1,237 actions. The header line records a wider tally — 66 domains and roughly 1,669 rows plus 278 reconciled notes. The detailed catalogue itself holds 62 domain sections. The file does not reconcile them; read them as a sense of scale and find your domain by searching, not by counting.

Looking up whether a role may do something

This is the question the catalogue answers best. Work from the domain, not from the role — domain sections carry the full detail, while the role maps are summaries.

Open docs/USER_ACTIONS_BY_ROLE.md and check the dated header line at the top. If the date is older than a release you know changed the screen you care about, treat what follows as indicative and confirm in the application.
Jump to the Contents index and follow the link for the domain you are asking about — Policies, Incidents, GDPR and so on. The section opens with a paragraph describing the whole area and the routes it covers. If the domain has no link, search the file for its name: a few sections are missing from the index but present in the catalogue.
Search within that section for the action in the words you would use for it — “approve”, “export”, “delete”. Each match is a numbered entry with its own heading, so you land on a complete record rather than a fragment.
Read the Roles line of that entry. It lists every role permitted to perform the action, resolved against the live permission map, and names the exact permission constant behind it.
Read the Notes line before you conclude anything. This is where the catalogue records the qualifications — a licence feature that must be active, a module that must be switched on, a confirmation dialogue, or a page whose on-screen guard is stricter than the permission itself.

Holding the permission is not the same as reaching the screen

Some pages add a stricter guard than the underlying API permission. A Viewer may hold the read permission for a record and still be unable to open the page that shows it — most EU AI Act and DORA pages require Contributor to open at all. The catalogue flags these cases in Notes, and it is the single most common reason a permission table and the real screen appear to disagree.

How to read one entry

Every action in the detailed catalogue follows the same shape, so once you have read one you can scan the rest quickly.

Part	What it tells you
Roles	Which roles may perform the action, resolved against the live permission map, together with the action’s category (view, create, execute and so on) and the exact permission constant it requires. Admin holds every permission and is listed explicitly rather than implied.
Where	The screen and the control — the `/route` plus the button, menu item, filter or form field, often with the test identifier used to target it.
Flow	The full path from navigation to result, in the same shape as the numbered steps in this guide, including which request the screen makes and what the loading, empty and error states look like.
Notes	Anything that gates or qualifies the action — a licence feature, a module switch, a rate limit, a confirmation dialogue, or a place where the screen and the underlying permission differ.
Expected	What a correct run looks like, and what a refused one looks like — which control is hidden, and which error the request returns. This line is what makes the catalogue usable as a test script.

The four roles it maps

The catalogue resolves every action against the four-role hierarchy. Each higher role inherits everything the role below it can do.

Role	What it can do
Admin	Every action, plus the administration surface that no other role reaches — users and roles, single sign-on, API keys, webhooks, licence, framework enablement, and Trust Center publication.
Manager	Manage records across the whole compliance surface, approve policies, procedures and documents, and configure connectors and governance. No tenant administration.
Contributor	The day-to-day operator: create, edit and progress policies, risks, incidents, evidence, vendors and procedures, and run AI assists. No final approval, no administration.
Viewer	Read, search and open records, and export reports from data it can already see. It can manage its own account and acknowledge policies, but it authors nothing.

One result of that hierarchy is worth knowing, because it looks like a mistake and is not: there are twelve actions an Admin cannot perform. They are the external-collaborator and public-share actions — viewing, commenting on or reviewing a shared document as an outside magic-link collaborator, and redeeming an invitation link. Those belong to people who hold no role in Aegis at all, so no in-app role covers them.

The AI actions section

AI-assisted actions are gathered into their own section as well as appearing in their domain, because they share one pattern. The current edition records 48 registered AI actions, and each one passes the same ordered set of checks: the module must be on, the caller must hold the permission, a per-user rate limit applies, the AI assist feature must be licensed, the transparency notice must have been acknowledged, and the monthly AI allowance must not be exhausted. If any one of those fails, the entry tells you exactly which response you get.

The section also records what you can do with a result — copy it, run it again, save it as a record where the screen supports that, and turn it into action items. It is explicit that not every AI screen offers saving, and that creating action items is hidden from Viewer. In every case a person reads the result and decides what to do with it; no AI action changes a record on its own.

Tips and limits

Read the dates first. The catalogue is regenerated in batches, not continuously. Between regenerations a newly shipped screen may be missing and a reworked one may be described in its old form.
The counts do not all agree. The header says 66 domains, the count table lists 58, the catalogue below holds 62 sections, and the Viewer capability map opens by saying 46. They were tallied at different regenerations. Treat any of them as scale, not as an audited figure.
It describes; it does not grant. The catalogue is a reference, not a control panel. Listing an action against a role does not assign that role to anyone, and editing the file changes nothing in the application. Roles are assigned under Settings → Users by an Admin; the permission map in the code is what the application enforces.
Some entries have no control. A number of actions exist only as requests with no button anywhere in the interface. Those are marked as such in Where, and you should not go looking for a screen that shows them.
The deltas at the end matter. If an entry reads oddly, check the reconciliation sections at the foot of the file — they record where a description was corrected and why.

Two documents, two jobs

Reach for this guide when you want to learn how to do a task. Reach for the Action Catalogue when you need to confirm, precisely, whether a particular role is allowed a particular action — for example, when deciding who to invite at which role.

Where this connects

For a plain-language explanation of the four roles, the permission matrix and how roles are assigned, see What each role can do. To change someone’s role once you have decided, see Settings. For the meaning of a term used in any catalogue entry, see Appendix B — Glossary. If the catalogue and the screen in front of you disagree and you cannot work out why, see Appendix C — Getting help.