Audit trail
Objective. Explain what an audit trail is for in Time Champ terms and where the demos show auditability, so you can speak to accountability and change-tracking honestly without asserting retention, immutability or compliance guarantees you have not verified.
Auditability is a recurring ask from operations leaders who need to know who changed a schedule or a figure, and from security teams who need evidence of accountability. This teaches what the audit concept covers, what the demos actually show, and the hard line at retention, immutability and compliance claims.
See it in the demo
What an audit trail is in Time Champ terms
An audit trail answers 'who did what, and when'. In operational terms it is how a customer can see that a schedule was published by a named person, that an action was taken and logged, or that a figure changed and who changed it. This matters because the applications drive decisions and interventions - and a decision nobody can trace is a decision nobody can defend.
The demos surface auditability in a few concrete places: Scheduling has an explicit audit area alongside publication; Intraday Management keeps an action log of interventions; Value Leakage tracks a finding from baseline through action and verification. These show that the product treats operational change as something to record, not something that happens invisibly. That is the honest, demo-grounded version of 'yes, there is accountability built in'.
What a Sales or CSM person can say confidently
Safe to say: 'Operational change is recorded - for example, schedule publication is audited, intraday actions are logged, and a value-leakage finding is tracked from baseline through action to verification - so you can see who did what and when.' That is grounded in the demos.
Safe for CSM: use the action log and audit views to build accountable operating routines (C06) - an action log with ownership is how a QBR shows follow-through rather than just intentions (C08).
Safe to position: auditability supports a customer's own governance by giving them traceable operational history to review.
Do not assert how long audit records are retained, whether they are tamper-proof or immutable, whether they satisfy a named compliance standard, or exactly which events are captured for a given customer. Those are security and product facts.
What always escalates to security or product
Route to a specialist:
- Retention period and storage of audit records.
- Immutability or tamper-evidence of the audit log.
- Whether the audit trail satisfies a specific compliance or regulatory requirement (never name or imply a certification).
- The exact completeness of captured events - which fields, which user actions, which system changes - for a specific customer configuration.
- Export, SIEM integration or legal-hold behaviour of audit data.
From F09: never guess on compliance. An operations leader's 'can we see who changed this' is answerable from the demo; a security team's 'is the audit log immutable and retained for N years to satisfy standard X' is not - escalate it.
The honest limit
Demo-supported: the product records operational change - audited schedule publication, an intraday action log, and baseline-to-verification tracking of value-leakage findings.
Confirm with product/security: retention, immutability, event completeness, export/SIEM integration, legal hold, and any compliance or regulatory sufficiency claim.
Separate cleanly: 'operational change is tracked so you can see who did what and when' (safe) from 'the audit log is immutable, retained for seven years and meets standard X' (confirm with product/security). Never convert a visible action log into a compliance guarantee.
Interpretation check
Showing that operational change is recorded (audited publication, action logs, finding-to-verification tracking) is demo-supported accountability; it is not a claim about retention, immutability or compliance sufficiency, which are always product/security confirmations.
Practical task
Using the Scheduling audit view and the Intraday Management action log, write the two-sentence answer you would give an operations leader about accountability, and separately list the audit questions (retention, immutability, compliance, export) you would route to a specialist.
Self-check
An operations leader asks 'can we see who published this schedule and when?' Is that safe to answer?
Yes - Scheduling has an explicit audit area and intraday actions are logged, so you can confirm operational change is recorded with who and when, grounded in the demo.
A security reviewer asks whether the audit log is immutable and retained long enough for their regulator. What do you do?
Route it to a specialist - retention, immutability and compliance sufficiency are security facts you never assert, no matter how the question is framed.
How does a CSM use audit and action-log views in a QBR?
To show follow-through: an action log with ownership turns a business review from stated intentions into traceable completed actions and verified outcomes.
Which audit facts are demo-supported and which escalate?
Demo-supported: operational change is recorded via audited publication, action logs and finding tracking. Escalate: retention, immutability, event completeness, export/SIEM and any compliance claim.
Verified vs demo. Audited schedule publication, an intraday action log and baseline-to-verification finding tracking are shown in the demos; retention, immutability, event completeness, export/SIEM integration and any compliance sufficiency are product/security facts to confirm.