Who did what, when — reading a project's activity¶
Audience: quality managers and administrators answering an auditor's question; anyone who needs to know what happened in a project and when.
Admin → Activity shows a whole project's audit trail: everything the system has recorded there, newest first. Document releases and approvals, configuration changes, staffing moves, provisioning acts — one stream, in the order it happened.
This is a reading surface. Nothing on it can be changed, and nothing on it was written by it: every line was recorded, at the moment it happened, by the act that caused it, in the same transaction as the act itself. That is what makes it evidence rather than a log.
1. Choosing what to read¶
The trail is per project, and this page has its own project picker — deliberately not the toolbar's project switcher that every other screen follows.
The reason is the installation's base scope (GLOBAL). Provisioning acts — a customer created, a
project created or renamed, a document type or role activated, an element kind declared — are recorded against the
installation, not against the project they created (at the moment a project is created it does not yet
exist to record anything against). So "when was this project created, and by whom?" is answered on the
base scope's trail. Selecting it in the toolbar would repoint your whole session — the document
list, search, every project-bound view — at a scope that holds no project content. Reading a trail is
not choosing somewhere to work, so the choice stays on this page.
Arriving from a project preselects that project, as a starting point. Changing it here never moves the toolbar.
The picker offers exactly the projects you can see. You can read the trail of a project you are a member of; a project you are not a member of is not offered, and asking for one directly is refused — with the same refusal a project that does not exist gets, so the answer can never be used to find out which other projects exist.
2. Reading a line¶
Every line carries when, what, and who:
- When — the moment it happened, in your language's date format.
- What — the act. Familiar acts are named in words (Released, Approved, Project renamed, Role
assigned). Acts the interface does not have a name for show their raw recorded token — e.g.
QUESTIONNAIRE_CLEARED. That is on purpose: an invented label would be a claim about what the system recorded, and the token is what is actually stored, so it is the honest and searchable thing to show. The set of named acts grows as surfaces are built; nothing about the record changes when it does.
The common acts — the document lifecycle, staffing, and the provisioning acts — are named in
plain words; rarer acts show their internal token (such as ACK_FANOUT), which is honest
rather than polished: the token is exactly what the record stores.
- Who — the person, by display name. An act with no person behind it — a scheduled sweep, the
installation bootstrap — reads System. It is never blank: an unattributed line in an audit trail
should look deliberate, not broken.
Under the line comes the payload, and there are exactly two shapes:
- A lifecycle transition renders as a before → after pair: In review → Released. The transition is the event, so a release without it would read as a bare word.
- A change renders as a compact list of what moved:
name: QMS Ops → QMS Operations. A value that did not exist before (or no longer exists after) shows as an em-dash — "— → Sam Okoro" reads as added, exactly as recorded.
No line carries both: an act either moved a document through its lifecycle or changed something, and the trail shows whichever it was.
3. Reading the whole trail¶
The stream loads a page at a time, newest first. Load more continues exactly where the loaded set ends; the button sits where the next entries will appear, and it is replaced by a quiet "The beginning of the trail." line once the oldest entry is in.
There is deliberately no total count. The trail is append-only and grows for the life of the installation, so a number would be expensive to produce and out of date by the time you read it. "Is there more?" is answered exactly, by whether the button is still there.
If the list ever reloads itself from the newest entry and says so, that is the recovery from a page marker the server no longer accepts — nothing is lost; scroll and continue.
4. What this trail is, and is not¶
- It is complete for its project, and only for its project. There is no installation-wide "everything that ever happened" view. That is a boundary, not a missing feature: keeping every read inside one project keeps the separation between customers a real one, on the very surface whose subject matter is who did what across them.
- It cannot be edited or deleted, by anyone. The application has no privilege to change or remove an audit row — only to add one. That property is enforced by the database, not by good behaviour.
- It is not filtered or searchable yet. No filter by person, act or date range. Today you read the stream. (Filters are additive and cost the record nothing.)
- It is not the only trail. A single document carries its own history — the Audit trail card on the document page — which shows that document's transitions. This page answers the wider question: what happened in this project.
- It does not name entities by id. A recorded change names what it touched the way a human reads it (a project by code, a person by name, a role by name), because a bare identifier is the one thing a reader can do nothing with.
5. What you will find there¶
A non-exhaustive orientation, by question:
| Question | Where to look | Typical acts |
|---|---|---|
| When was this document released, and by whom? | the project's trail | Submitted for review, Approved, Released, Rejected, Release revoked |
| Who changed how this project is governed? | the project's trail | Project settings changed, review-policy and acknowledgement-policy acts |
| Who staffed whom? | the project's trail | Role assigned, Role assignment removed, Accountable holder named |
| When was this project created, and by whom? | the base scope's trail | Organization created, Project created, Project renamed, Document type activated, Role activated |
| Who has read this? | nowhere — opening a document is not recorded | — |
That last row is worth stating plainly: the trail records acts, not views. Opening a document leaves no line. Producing something does: exporting a document as PDF, or pulling a project's audit pack, is itself a recorded act. The question "who has taken notice of this document" is answered by training and acknowledgement obligations instead — see training & acknowledgements.
6. Who may read it¶
Membership of the project — the ordinary permission that lets you see its documents. It is not an administrative privilege: what happened in a project is readable by the people working in it.
The base scope's trail follows the same rule, which makes a neat symmetry: exactly the people who can cause an installation-level record are the people who can read it.
Governing decisions: ADR-0029 (the append-only audit trail — recorded with the act, in the same transaction, never mutable), ADR-0097 (why provisioning acts are recorded against the installation, and the permission symmetry that follows), ADR-0012 (per-scope permissions, enforced server-side), ADR-0007 (the UI reflects; the server decides), ADR-0093 (the one shared project context — and why this page deliberately stands outside it). Regulatory frame: ISO 13485 §4.2.5 (control of records — records stay legible, identifiable and retrievable), and the computerised-records audit-trail expectation (21 CFR Part 11 / EU GMP Annex 11) that ADR-0029 realizes as the append-only guarantee.