Overview
Every significant action in PreStartGo is recorded in an immutable, append-only audit trail that no user — organisation owners and PreStartGo administrators included — can edit or delete. This article covers what's recorded, the mechanics that make "immutable" a checkable property rather than a promise, and how the trail serves an audit.
What gets recorded
- Inspections — every pre-start submission: item responses, the derived result, photos, and where and when it was performed.
- Unlock and bypass events — the unlocks the app reports, and every emergency bypass made in the app and every service-mode session, with the person and the reason. A bypass made with the Interlock's own button is the exception: it is recorded on the device only, and never reaches the platform.
- Defect and service transitions — every lifecycle move, with actor, timestamp and notes.
- People and access — sign-in events, role changes, invite acceptances, licence grants and revocations.
- Device lifecycle — commissioning, release, configuration observations, and fault conditions.
- Billing and organisation changes — plan transitions, setting changes.
The rule is structural: in our own build gates, a change that writes data without writing its audit entry fails the build. "It happened but there's no record" isn't a state the platform can reach quietly.
Append-only, precisely
- Records are inserted, never updated or deleted — status changes are new transition records beside the old state, never overwrites of it.
- This applies to the compliance tables themselves, not just the log: inspection results, bypass logs, defect transitions and photo evidence are all immutable once created.
- Any entity's full history reconstructs by replaying its records in order.
Two timestamps, both kept
Field work happens offline, so every audit record carries two times: when the action happened (on the phone, at the machine) and when it reached the platform. They legitimately differ for every offline sync, and keeping both is what lets an auditor distinguish "inspected at 6:05, synced at 9:40" from anything murkier.
The hash chain — tamper-evident, not just tamper-resistant
Beyond append-only storage, the audit trail is hash-chained: each organisation's monthly sequence of events is cryptographically linked, so inserting, deleting, or reordering a historical entry breaks the chain arithmetic. A scheduled job re-verifies every organisation's chains nightly, so tampering doesn't wait for an audit to be discovered — it surfaces within a day, flagged to our engineering team.
That converts "trust us, it's immutable" into a property that is mechanically checked every night, which is a materially stronger claim to put in front of an auditor.
PII redaction
Log entries redact personal identifiers — emails to ***@domain.com, phone numbers to their last digits, secrets to [REDACTED] — balancing the completeness an audit needs against the privacy your people are owed. The unredacted operational data lives in the primary records, behind role-based access.
Where you read it
- The console's Audit Log — the day-to-day window for your organisation. See Using the Dashboard and Audit Log.
- Reports and exports — the audit-ready artifacts: reports for the recurring questions, data export for the full record.
Certifications
SOC 2 Type II and ISO 27001 are in progress — the audit trail above is designed against both frameworks' requirements (completeness, integrity, availability, confidentiality), and the certification status itself is stated precisely in Security Overview.
Troubleshooting
| Symptom | Likely cause | What to do |
|---|---|---|
| An action seems missing from the Audit Log | Field-side and not yet synced, or further back than the page shown | Check after the phone syncs; page back through older entries |
| A record's time looks wrong | Reading recorded-at where you want happened-at | Open the detail — both timestamps are kept |
| Need to "correct" an audit entry | By design, you can't | Record the correction as a new action; the trail keeps both |
| An auditor wants evidence of immutability | — | Point them here: append-only tables, hash chains, nightly verification |