H33 vs Traditional Audit Logs
Logs describe events. Evidence proves them.
Traditional audit logs are write-ahead records of what a system claims happened. They can be edited, replayed, lost in version migrations, or contradicted by adjacent logs. H33 produces audit evidence: cryptographically signed, schema-versioned, replayable by anyone who downloads the bundle, and verifiable without contacting the originating system.
What traditional audit logs are good at
Traditional logs are the foundation of system observability. They are necessary for debugging system failures, forensic investigation after an incident, internal compliance dashboards, performance analysis, operational alerting, and capacity planning. Standard logging frameworks — syslog, structured JSON logging, centralized log aggregators, SIEM ingestion — are mature, well-understood, and widely deployed.
Where traditional audit logs fall short
External audit requires properties internal logs do not have. The log is mutable. A database administrator can modify entries. A retention policy can purge them. A version migration can change their format. An external auditor cannot trust the log to be the same log that was written at decision time. The log is vendor-coupled. Logs depend on the system that wrote them. When the vendor changes, the logs lose canonical interpretation. The log requires trust. Reading a log requires trusting the system that produced it. An auditor reading an enterprise's audit log has no cryptographic way to confirm the log entries are unmodified. The log does not survive cryptographic transitions. If the log is signed with RSA or ECDSA today and retained for a decade, future quantum computing breaks the signatures. The log does not anchor in time. A log entry has a timestamp the system wrote. There is no external proof the entry existed at that time.
How H33 audit evidence is different
H33 produces evidence bundles, not log entries. Each bundle is cryptographically signed — three post-quantum algorithm families sign the bundle: ML-DSA-65, FALCON-512, and SLH-DSA-128f. Modification invalidates the signatures. Schema-versioned — the bundle declares its schema version. Adding fields in future versions does not break verification of older bundles. Replayable — the bundle is deterministic. Rebuilding it from the underlying evidence produces byte-identical output. Independently verifiable — the open-source verifier accepts a bundle and returns a deterministic pass-or-fail verdict. Chain-anchorable — the bundle's 32-byte canonical commitment can be published to a public chain. Portable — the bundle is a self-contained JSON document. It travels with the customer.
Side-by-side
| Property | Traditional Audit Log | H33 Audit Evidence |
|---|---|---|
| Format | Vendor-specific | Open canonical JSON |
| Mutability | Mutable in database | Cryptographically tamper-evident |
| Signature | Optional, single-algorithm | Three-family post-quantum |
| Verification | Trust the vendor | Independent, offline, open-source verifier |
| Vendor survival | Tied to vendor | Survives vendor change |
| Cryptographic transition | Breaks at single primitive failure | Three-family redundancy |
| Time binding | Self-reported timestamp | Chain-anchored (optional) |
| Schema evolution | Breaks older entries | Schema-versioned, forward-compatible |
| Replayability | Logs describe; do not reproduce | Byte-identical reproduction |
| Privacy | Log contents visible | Bundle under customer control; 32-byte chain anchor only |
| Open source verifier | N/A | Yes |
When you need H33 audit evidence
You need H33 in addition to standard logging when: a regulator needs to verify what happened without trusting your systems; an auditor needs to confirm decisions decades after they were made; an insurer or reinsurer needs to assess incident evidence without redoing your investigation; a litigation discovery will surface decisions that must be verifiable to opposing counsel; an acquirer needs to confirm the basis of decisions made under prior ownership; a retention window outlives the cryptographic primitives the log was signed with. In each case, the standard log is necessary for your internal operations but insufficient for the external party's verification needs.
When standard logging is enough
Standard logging is sufficient when the downstream consumer of the log is your own team, the retention window is short, no external party will need to verify the log, the decisions logged do not affect compliance/regulatory/litigation exposure, and the original system is expected to be available indefinitely. Most operational logging falls into this category. H33 audit evidence layers on top of, not instead of, your existing observability stack.
Common questions
Do I have to replace my existing logging?
No. H33 evidence layers on top of your existing logs. Operational logs continue for debugging and observability. H33 bundles cover the decisions that require external verifiability.
Can H33 bundles be ingested into a SIEM?
Yes. Bundles are canonical JSON. Standard SIEM ingestion pipelines can index them. Verification runs separately.
Are bundles privacy-preserving?
Bundles can stay entirely under customer control. Only a 32-byte cryptographic commitment is published when anchored to a public chain.
Does this require blockchain?
No. Bundles are verifiable without any chain anchor. The chain anchor adds proof of existence in time but is optional.
Related: H33 vs RAG · H33 vs SIEM Evidence · H33 vs Blockchain Audit Trails