Skip to main content
EventDBX bakes auditability into the storage model. Every event carries human-readable metadata, snapshots supply quick checkpoints, and Merkle proofs give you cryptographic evidence when regulators ask “how do you know?”.

Build complete timelines

Use metadata to capture actor, channel, and reason for each event (metadata keys must start with @ and stay within the size limit):
dbx aggregate apply person p-110 person_address_changed \
  --payload '{"city":"New York","country":"US"}' \
  --metadata '{
    "@actor":"csr-22",
    "@ticket":"INC-4922",
    "@source":"support-portal"
  }'
Later, fetch the state and events together:
dbx aggregate get person p-110 --include-events
Include snapshots when sharing with audit teams so they can see derived state without replaying the entire list:
dbx aggregate snapshot person p-110 --comment "quarterly review"

Verify integrity

Recompute the Merkle root and share it with auditors alongside the snapshot:
dbx aggregate verify person p-110 --json > verify.json
verify.json contains the aggregate type/id and Merkle root. Pair it with the exported snapshot so auditors can detect tampering. Per-event proof paths are not emitted; use the Merkle root as the checksum.

Schema change audit log

Schema versions carry an audit trail of who published or activated them and why:
dbx tenant schema history payments --audit
The audit log entries capture the actor (overridable via --actor) and optional reason (--reason) supplied to dbx schema publish / dbx schema activate.

Tamper-evident exports

When exporting data for regulators or partners:
  1. Generate a domain backup: dbx backup --output /backups/eventdbx.tar.gz.
  2. Sign the archive (e.g., gpg --detach-sign /backups/eventdbx.tar.gz).
  3. Provide the signature plus aggregate Merkle roots in the transfer manifest.
Anyone can verify the signature plus the Merkle proof to ensure nothing changed in transit.

Operational playbook

  • Incident review: pull the relevant aggregates, replay commands, and attach proofs to the RCA.
  • Access review: compare aggregate histories and schema audit logs with token issuance records to confirm only authorized actors touched sensitive data.
  • Policy enforcement: reject events that violate schema (set --restrict strict) and require metadata keys so context is always captured.
Because EventDBX never mutates prior events, you always have the source data needed to answer “what happened, when, and who did it?”.