Core Concepts
Understand why Blocklog exists and the cryptographic foundations of tamper-evident audit logging.
Model
Traditional observability tools such as Datadog and Splunk are optimized for speed, indexing, and operational debugging. That makes them excellent for searchability, but not ideal for non-repudiable evidence when administrators or compromised credentials can still alter log history.
Blocklog is designed for accountability. The goal is to preserve cryptographic proof of system state, decisions, and actions in a way that remains independently verifiable.
Architecture
API endpoints expose no edit or delete operations. The log stream is synchronized to WORM storage.
Logs are chained sequentially, so downstream tampering invalidates the integrity chain.
Periodic batches build Merkle trees so a single Merkle root can represent and prove inclusion for the batch.
Merkle roots are signed and anchored for long-term verification outside the operational database.
Why this matters
In AI and automated systems, it is rarely enough to know that something happened. You also need to know what context produced the action, what model or tool influenced it, whether a human approved it, and whether the record can still be verified later without trusting the operational database.
Decision logs preserve why an action was taken, including inputs, prompts, model versions, outputs, and authorizing actors.
Logs can be signed at the source or during server-side sealing, so verification does not depend on the mutable application database.
Replay sessions use lineage across events, tool calls, and decisions to help isolate the exact source of an anomaly.