Docs / Guides by role / Auditor
Guide by role For auditors

Auditor

There is no auditor role in the permission table, and none is needed: every role can read every page, because a governance tool whose trail is hidden from half the organisation is not doing its job. What you decide is nothing — reading is never one of the decisions here — so this guide says where to look instead.

What you decide

Nothing that dpf/domain/rbac.py names. Reading is open to every role, so signing in with any of the four is enough to see all of what follows.

Where you work

  • a product's Overview — the Settled column
  • a phase page — the gate's "closed by", and the Activity rail ("Full log →")
  • Records (/governance/record) — every document and every version, filterable by product, kind, and "Current only" or "Every version ever written"
  • Log (/governance/log) — every event, filterable by product, actor and object; ?action=release.promoted and the like work by URL
  • the Evidence tabs on a product — Documents, Releases, Quality, Traceability, Changes, Cycle time
  • a release's own page — the approval comment, every check, The SQL that ran, and its history
  • Workflow — the process in force, its revision, and a product's own changed since this was started badge if it was built under an earlier one

Step by step

This is where to look for a given question, not an order to follow.

1. Did the right person decide this? The gate's "closed by" on the phase page, and the Settled column on the overview, name who and when. The RACI beside the gate says who should have.

2. What exactly did they agree to? Open the document on Records. An edit is a new version; the one somebody agreed to is kept, never overwritten.

3. Is a decision real, or a demo? A badge says "simulated", or "answered in the simulator", wherever one exists, and promotion is refused on it — a stuck release's own page says why.

4. What ran, and did it pass? A release's own page: every check, its severity, and The SQL that ran, stored on the run rather than regenerated — a rollback replays that exact text.

5. Has the process itself moved? Workflow shows the revision in force now; a product's own badge says if it was built under an earlier one.

6. Watching from outside? Poll /api/v1/events from a cursor with a service token — see Read API and MCP — or write every document to files: python -m dpf export <product>.

What the record keeps about you

Nothing: reading is not an event, and the log records decisions, not visits. What you read there: every event carries an actor (the name credited) and a principal (who was actually signed in) — they differ when somebody is acting as a role, and a same-hand check reads the principal to stop one person approving their own request. The log is append-only: a correction is a new event, never an edit to an old one.

Important

Two honest gaps. Switching "Act as" is itself not written to the log, so the record shows what a role decided, not which session chose to become it. And the same-hand check reads the signed-in principal — in open mode, where nobody signs in at all, there is none to check, so it cannot stop one person acting out both sides.

Documentation for version 0.2.0 Reviewed 2026-10-19 Covers dpf/domain/rbac.py, dpf/audit.py, templates/product.html, templates/phase.html, templates/log.html, templates/record.html, templates/release.html, templates/workflow.html