Sentinel QMS v4 · AuditLog.AI · Technology

How AuditLog.AI Proves Evidence Integrity Without Custody

AuditLog.AI uses a deterministic, hash-first pipeline: every file is dual-hashed, frozen, and compared using blinded manifests. A human gate enforces oversight, and only compact cryptographic digests are anchored to Bitcoin via the SENTINEL OP_RETURN schema.

Evidence always remains local — no PHI or trial data leaves the node.
Every file receives paired digests (SHA-256 + RIPEMD-160).
Reproducibility is enforced by deterministic QMS comparators.
Anchoring converts sessions into SENTINEL|SESSION|<r160>|<sha8> payloads on Bitcoin.

For end-to-end reproducibility results, see the Reproducibility page; for concrete payload examples and TXIDs, see Anchors.

End-to-End Proof-of-Unchanged Pipeline

The Sentinel QMS v4 pipeline can be summarised in five steps. Each step is deterministic, hash-first, and enforceable without access to underlying raw data.

Assemble & review

QA-approved evidence bundles (1–10,000+ files) are selected for freeze. No hashes are computed until the bundle is stable.

Freeze & dual-hash

Each file is hashed locally: SHA-256 then RIPEMD-160(SHA-256). Sidecars (.hash, .2ha) and optional OTS proofs (.hash.ots) are created.

Zero-custody · cryptographic proofs only

Deterministic manifests

Sentinel QMS v4 builds manifests that reference every hash. Blinded Bates IDs and multi-entity prefixes preserve structure without exposing content.

Human gate (HVT layer)

A human approver confirms the session using signed PDFs. HV START/END timestamps later define Human Verification Time (HVT).

Mandatory human oversight

Bitcoin anchoring

The frozen session log is reduced to a compact payload SENTINEL|SESSION|<r160>|<sha8> and anchored via OP_RETURN on Bitcoin L1.

OP_RETURN parity · CME Rule 4

Hashing, OTS, and OP_RETURN payload

Each file passes through a chain of cryptographic attestations:

File-level digests: SHA-256(file) → RIPEMD-160(SHA-256).
OpenTimestamps (OTS): optional .hash.ots proofs attest that a given hash existed before a certain set of Bitcoin blocks.
Session-level payload: the frozen session log itself is hashed; digests are encoded in the SENTINEL v4 OP_RETURN schema:

SENTINEL|SESSION|<ripemd160>|<sha8>

This design keeps raw evidence local and ensures that any subsequent verifier can recompute digests from the same evidence, match payloads, and confirm that neither logs nor outputs have changed.

Blinded HMAC tamper engine

The HMAC tamper engine (used in Stage IIIB) selects files for deletion based on a secret key:

Builds a canonical ID per file (RUN ID + Bates path + hashed name).
Applies HMAC-SHA256(SALT, canonical_id) to obtain a score.
Selects top-K candidates per run subject to per-run caps (e.g. 20 files / arm).
Moves selected files into _HMAC_DELETED/, leaving a blinded gap in the working-tamper manifests.

Crucially, the SALT is hidden from the operators and from downstream AI systems. Only the final manifest differences and dual-hash mismatches are exposed.