Alteration
Editing any field of any past record changes that record’s SHA-256 hash, so it no longer matches what the next record recorded as its predecessor.
Most audit logs ask you to trust the provider. Ours doesn’t. Every security action is written to an append-only, SHA-256 hash-chained trail—so altering, deleting, or reordering any record is mathematically detectable and pinpointed to the exact entry. An auditor, underwriter, or counsel can confirm the record’s integrity independently, with their own tools, without taking our word for it. That’s what turns a log into evidence.
Example responses from the verification endpoint. A single altered byte anywhere in the trail flips intact to false and reports where.
GET /audit/verify
{
"intact": true,
"checked": 14732,
"legacy_records": 0,
"broken_at_seq": null,
"reason": "chain intact"
}GET /audit/verify
{
"intact": false,
"checked": 8815,
"broken_at_seq": 8814,
"reason": "prev_hash mismatch (a prior record was altered or removed)"
}Example GET /audit/verify responses. The verifier localizes any failure to the exact sequence number—not merely that something is wrong, but where.
Editing any field of any past record changes that record’s SHA-256 hash, so it no longer matches what the next record recorded as its predecessor.
Removing a record leaves a gap in the strictly increasing sequence and breaks the prev_hash link at the following record.
Records out of order fail the contiguous-sequence check—the chain expects each seq to follow the last by exactly one.
The chain is anchored at sequence zero to a fixed genesis value (64 zeroes), so removing records from the start is detectable too.
Each record carries three integrity fields beyond its content. Because each record’s hash incorporates the previous record’s hash, the entries form a chain anchored at the start to a fixed genesis value — so a break anywhere is detectable, and localizable.
A monotonic sequence number from zero. A gap or repeat reveals a deleted or reordered record.
The SHA-256 hash of the immediately preceding record, linking each entry to its predecessor.
SHA-256 over this record’s full canonical content, including its prev_hash — so one changed byte changes the hash.
Independently reproducible: the canonical form is deterministic — the record serialized as JSON with keys sorted and the hash field excluded, hashed with SHA-256. Given the records, any third party can recompute each hash and confirm the chain with standard, publicly available tools. That is what makes the trail evidence rather than assertion — its integrity depends on no secret held by the provider.
What this establishes, honestly. An intact result is a cryptographic guarantee that the records verified were not altered, deleted, or reordered after they were written, and that each action is attributable to an actor and timestamp. It does not certify compliance with any law or framework, does not attest that every real-world event was observed (detection coverage is finite), and is not legal advice. Where a formal certification is required, this supports — but does not replace — an accredited assessment.
Plain-language answers to the questions buyers ask most—readiness and evidence, not certification or legal advice.
Every audit record is append-only and cryptographically chained to the one before it: each entry stores a strictly increasing sequence number, the SHA-256 hash of the previous record (prev_hash), and its own SHA-256 hash computed over its full content including that prev_hash. Because each hash depends on the one before, altering, deleting, or reordering any historical record breaks every link from that point forward—and the verifier reports the exact sequence number where the chain first fails. It doesn’t prevent someone from trying to change a record; it makes the change mathematically detectable.
This is the right question to ask of any “immutable log.” The protection is twofold. First, the trail is append-only with no edit or delete interface, and verification pinpoints any break. Second—and this is the point—integrity is verifiable independently of the provider: the canonical form hashed for each record is deterministic (JSON, keys sorted, hash field excluded, SHA-256), so an auditor who has retrieved the records can recompute the entire chain with their own standard tooling and confirm it, without trusting us. Where an auditor holds a previously exported copy or anchor, any divergence is detectable. It is evidence you can check, not an assertion you must believe.
Two read-only endpoints. GET /audit/verify walks the entire trail, recomputes the hash chain end to end, and returns a structured result—intact (true only if every sequence, prev_hash link, and recomputed hash is correct), checked (records verified), broken_at_seq (the exact failure point, or null), and reason (a plain-language explanation). GET /audit retrieves the underlying records so they can recompute the SHA-256 chain independently with their own tools. Any pre-chain legacy records are reported separately and honestly, not silently passed.
No. This evidences the integrity of the record—that the entries verified weren’t altered, deleted, or reordered after they were written, and that each action is attributable to an actor and timestamp. It does not certify compliance with any law or framework, and it isn’t legal advice. Where a formal certification is required, this supports—but does not replace—an accredited assessment: a C3PAO for CMMC, a licensed CPA firm for SOC 2.
Book a 15-minute review and we'll show you the audit trail your environment produces—and how anyone can verify its integrity independently.
Schedule your 15-minute review