Who may do what, and what was recorded
Two surfaces, and they are the same argument twice. Access rules are data with a stated basis, evaluated in order with an explicit Deny that wins — which is the fix for the warning already attached to R-S-02, that LOOMS RBAC is additive-only with no Deny. And the log records refusals, not only successes.
Access rules (RuBAC) →
13 rules, 4 of them denies. Every one carries the requirement it implements. The page includes a trace explorer: choose a persona, an action and a resource, and see which rules matched, which was decisive and why.
This is the real code path, not a picture of one — the platform’s own permission checks run through this evaluator.
Audit log →
14 events, including refusals — the whole log, because Internal Audit and the CEO are the readers an access review is written for.
⚠ Not immutable in the prototype. What it demonstrates is the schema, the vocabulary and that denials are rows.
- Persona
- Vu Tuan Minh (CEO)
- Role
- exec
- Layers
- L1, L2, L3
- Org-unit scope
- ACF and below
- Write access
- read-only
- Employee record
- — none: this persona is a role, not a person
In the prototype this comes from the persona switcher (A-26). At fullstack it comes from Entra ID group claims and the scope predicate moves into the database (A-21, R-S-15) — the rules on the next page do not change, only where the subject comes from.