Scheduling: Change audit
Objective. Review the audit trail of who changed what, when and on which version, and read churn as a process signal - without mistaking the audit for proof that coverage is adequate.
The audit answers: who changed what, when, and on which version - is change owned? The key read is that it proves traceability and ownership, not coverage quality, and that heavy churn after publication is a forecast or process warning.
See it in the demo
What this screen answers
A Sales or CSM person opens the audit to answer: is change to the live schedule owned and traceable? It supports the CSM's core adoption deliverable - clean publication and change ownership - by showing the history of edits and republications against the schedule.
The task
Review the audit trail for the team and period: trace edits and republications to the people who made them and the versions they affected. Look for whether change is owned (a named person, a clear reason) and how much the schedule churned after publication.
How to read it
The audit shows change history and ownership - who, what, when, which version - not coverage quality. Heavy churn after publication is a process signal: it usually points to a weak forecast or an unowned change process, not just busy-ness. Read the audit alongside coverage, not instead of it: it answers 'who changed this', the coverage view answers 'is it covered'. The misread to avoid: concluding a quiet audit means a good schedule, or a busy one means a bad one, without reading coverage.
Honest limits
The audit records change; it does not evaluate whether the schedule is correct or covered. Confirm with product the granularity of the audit, retention and who can view it for a customer; the demo uses seeded data.
Interpretation check
The audit proves who changed what and when (ownership and traceability), not whether coverage is adequate - and post-publication churn is a process signal to read alongside coverage.
In the field
A multi-site operation where the live schedule kept changing: the audit showed unowned edits by several people, so the CSM used it to establish a single publication owner and cut churn.
Practical task
On the demo audit, trace one post-publication change to its owner and version, and write a one-line read of whether change looks owned and whether churn warrants a forecast check.
Self-check
The audit trail is quiet for this week. Does that mean the schedule is good?
Not on its own. The audit shows change and ownership, not coverage. A quiet audit on a stale-forecast draft can still be a poorly covered week. Read coverage too.
The schedule churned heavily after publication. What does that signal?
Usually a weak forecast or an unowned change process, not just activity. It is a warning to investigate forecast quality and publication discipline.
What question does the audit answer, and what does it not?
It answers who changed what, when and on which version. It does not answer whether the schedule is adequately covered - that needs the coverage view.
Verified vs demo. Screen is live in the demo at /#/audit; exact controls, labels and figures are SME-validation-pending.