A contractor is hurt on your site. Three months later, an inspector asks the obvious question: was this person actually allowed to be working that day? You pull the record. It says their High Risk Work Licence was current, their induction was complete, and their company’s insurances were in force. Good — except the inspector’s next question is harder. How do you know that record says today what it said back then? How do you know nobody quietly edited it after the incident to make the story cleaner?
That second question is the one most compliance systems can’t answer. Lattice Look Contractor Management can, and this post is about how — stated precisely, including where the claim stops.
The claim, stated precisely
Every compliance record in the contractor audit trail is immutable and Merkle-sealed. The accurate word for what that buys you is tamper-evident: if any past record is altered, deleted, or back-dated, the seal breaks and the break is detectable.
It is worth being careful here, because tamper-evident is often confused with tamper-proof, and they are not the same thing.
- Tamper-evident (what we claim): you can prove a record has not been altered since it was written, and you can detect it if one has.
- Tamper-proof (what we do not claim): a promise that storage is physically unbreakable and no byte can ever be touched. No honest system claims that.
We don’t tell you the data is impossible to attack. We tell you that if anyone does touch the history, you’ll know — and so will the inspector.
Why this matters for a contractor record specifically
Under Australia’s model WHS laws, a PCBU’s duty of care is non-delegable. You cannot contract it away to the labour-hire firm or the head contractor. If someone works on your site, you are obliged to independently verify, monitor and document their compliance — and that documentation has a long tail. WHS records get read after an incident, during an audit, in an insurance dispute, sometimes in court.
In every one of those settings the value of the record depends on a single property: that it reflects what was true at the time, not what was convenient to assert later. A folder of PDFs fails this test completely — a PDF can be re-saved with a different date and nobody is the wiser. Even a normal database fails it, because a database row is designed to be updated in place. The whole point of an audit trail is that it should be the one thing in your system you cannot rewrite.
So the contractor audit trail is append-only. The six-check right-to-work decision at sign-in, the PASS/BLOCK/WARN result and its reason, the certification that was current, the induction that was complete, the geofenced check-in — each is written once and sealed. You don’t edit history; you add to it.
How Merkle sealing works, at a high level
The mechanism is hash chaining, the same family of construction used by Certificate Transparency logs.
- Each record is hashed. A cryptographic hash is a fixed-length fingerprint of the record’s content. Change a single character anywhere in the record and the fingerprint changes completely and unpredictably.
- Records are linked. Each new record’s hash is computed over both its own content and the hash that came before it. That produces a chain: record N depends on record N−1, which depends on N−2, all the way back to the first entry.
- The chain rolls up into a tree. Hashes are paired and re-hashed, level by level, until the whole log reduces to one value at the top — the Merkle root. That single root is a fingerprint of the entire history.
The consequence is the useful part. If someone alters one old record, its hash changes; that breaks the link to the next record; that cascades up every level of the tree; and the Merkle root no longer matches. To hide a single edited line you would have to recompute and replace every dependent hash up to the root — and the root is signed and anchored away from the records it describes, so a rewritten history won’t reconcile against the value already committed. One changed byte invalidates the seal for everything after it. That’s what “tamper-evident by construction” means: the property is a result of the data structure, not of a policy we promise to enforce.
The honest scope of the claim
Cryptographic sealing is one control, not a security strategy. Here is the rest of the picture, stated accurately and without inflation — the same wording you’ll find on our trust centre.
- Australian-sovereign hosting. Primary infrastructure in Melbourne with a Sydney standby — two-state geo-redundancy, with point-in-time recovery. The data, including the audit trail, stays under Australian jurisdiction.
- Encryption in transit. TLS 1.2 and above for data moving between you and the platform.
- Internal, AI-augmented security testing. We run continuous internal adversarial testing of our own attack surface. We do not claim a completed external penetration test; where an engagement requires one, it is commissioned as a separate, contracted deliverable.
- ISO 27001 is on our roadmap. We are aligned to the controls and working toward certification. We are not certified yet, and we won’t say we are until we are.
What sealing the audit trail does not do is make the rest of the system invulnerable, and we won’t pretend otherwise. It does exactly one thing, and does it well: it removes “the records were edited after the fact” as a credible objection. Combined with sovereign hosting and the controls above, that turns your contractor history from a folder you assert is accurate into evidence you can demonstrate is unaltered.
What you actually get
When an inspector, an insurer, or your own board asks whether a contractor was compliant on a given day, you don’t have to ask them to trust your filing. You can show the sealed entry and the maths that proves it hasn’t moved since it was written. For a duty you can’t delegate, recorded for years and read under pressure, that difference — between we say so and we can prove it — is the entire point.
You can read more about how the contractor module enforces compliance before it records it in the six-check right-to-work gate and one matrix, two workforces, see how the broader platform fits together on features, or review the full security posture on the trust centre.