Audit a plan's history

Every plan in IDDT carries a complete, immutable history of revisions and stage transitions. When a registrar asks why a plan was approved the way it was, the audit view is the surface that answers the question. This article covers how to open the audit view, what it shows, and how to export the log for a compliance review.

Open the audit view

From the admin rail, pick Plan administration. Use the search box at the top — student id, student name, or plan id all work. Click any result row to open the plan, then click the History tab in the plan header.

The history view is divided into two panels:

• Revision history — a chronological list of every saved revision of the plan body. Click any revision to see the snapshot.
• Transition log — a chronological list of every stage transition, with timestamp, the acting user, and the trigger that fired.

The two panels are aligned in time, so you can correlate a revision with the transition that followed it. A plan that was revised at 14:02 and transitioned out of revisions_requested at 14:05 shows both events on the same vertical band.

Snapshot detail

Click any revision to load the snapshot. The snapshot is read-only — you cannot edit a historical revision, even as an administrator. That is by design. The snapshot shows you the plan exactly as it appeared at the moment the revision was saved, including:

• The canvas layout.
• The requirement bucket pins.
• The rationale text.
• The attachment file list (and the file scan status at that point in time).

If you need to compare two revisions, open one snapshot and click Compare with… to pick the second. The compare view highlights added, removed, and re-pinned courses in colour.

Read the transition log

Each row in the transition log is a single state machine transition. The row carries:

• When — UTC timestamp and the local timestamp in the user's tenant zone.
• What — the trigger that fired (advisor_approves, committee_returns, etc.).
• From → To — the source and target stages.
• Who — the username and role of the user that fired the trigger. For system-driven transitions (SLA breach escalations, integration hand-offs) the row names the system actor.

The log is append-only. There is no edit affordance because there is no edit semantic — a transition that fired actually fired. If a transition was made in error, the corrective action is a new transition in the other direction, and both transitions stay in the log so the recovery is itself auditable.

Masquerade rows

If the row shows (via masquerade by <admin>) next to the actor, it means an administrator was acting as the named user when the transition fired. Masquerade rows are visually highlighted so a compliance reviewer cannot miss them; the audit log treats the masquerading admin as the responsible party for any action taken.

Export the log

For an external compliance review you almost always want to hand over the transition log rather than the full plan body. Click Export audit log in the action bar of the History tab. You will see a format picker:

• CSV — one row per transition. The header row names every column.
• JSON — the same data as a typed array. Useful if the reviewer is ingesting the log into another system.

The export bundles the plan id, the student id, and the tenant slug into the filename so a reviewer who collects logs from multiple plans can keep them straight. Exports are generated server-side and streamed to your browser; no copy of the export is retained on the server after the download completes.

Reading the export off-platform

Open the CSV in any spreadsheet tool. The columns are deliberately verbose:

• transition_at — ISO 8601 UTC timestamp.
• transition_at_tenant_zone — the same timestamp in the tenant's display zone.
• trigger — the slug of the transition trigger.
• from_stage, to_stage — both stage slugs.
• actor_user_id, actor_username, actor_role — the identity of the user that fired the trigger.
• masquerade_admin_id — populated only when the row was a masquerade action.

What to do next

If the audit reveals a workflow problem — a stage with no inbound transition, or a role gate that does not match policy — circle back to Configure workflow stages to adjust the graph. Workflow changes are versioned, so a future audit will be able to reconstruct the policy that was active at the time of any historical transition.