Skip to main content

Compliance & Audit Records

Two organizations that exchange approvals and evidence need a common identifier for the same record, not a row number that resolves in only one system.

ALX lets each side represent a shared approval, audit record, or piece of compliance evidence as a Block with deterministic identities and declared parents. The record carries its own identifier and declared lineage rather than a row number in one party's database. Any organization holding the same protocol data can recompute the same identities, so the parties can agree on what a record is and on the derivation it declares without sharing a database. Identity computation is defined in Block Identity and worked through for independent recomputation in Software Provenance. ALX verifies deterministic identity, declared lineage, and graph structure; content semantics, permissions, trust decisions, ownership, governance, and storage remain the responsibility of those applications.

The Problem​

Organizations that exchange records rarely share a database, and each side assigns its own identifiers. A supplier's approval reference cannot be resolved inside the customer's audit system, so both sides maintain a mapping only they can check.

A payload re-exported from another system can reorder object keys, so a byte-for-byte comparison fails on two copies of the same record. The opposite failure also occurs: two records can look identical while resting on different evidence, because the inputs behind them live in workflow tools the other party cannot read.

Timing is a third gap. Months later, each side is asked to accept the other's logs as the record of when something was produced, with no reference either party can check independently.

How ALX Applies​

Each exchanged record becomes a Block whose content is the application-defined JSON payload and whose parentHashes declare the direct records it was produced from. A referenced evidence document becomes a root Block with an empty parent set, a control assessment declares that Block as a parent, an approval decision declares the assessment, and the receiving organization's acceptance declares the approval.

contentHash identifies the canonicalized content, so the parties can compare content without lineage context. blockHash identifies that content together with the normalized parent set, so the same approval wording resting on a different evidence set is a different Block. Both sides must still reproduce canonicalization exactly and preserve string code points without Unicode normalization.

The example below is application-defined content. A complete Block also carries parentHashes, contentHash, and blockHash.

{
  "type": "approval-record",
  "decision": "approved",
  "scope": "quarterly-access-review",
  "approver": "application-defined",
  "decidedAt": "2026-07-28T14:30:00Z"
}

To give both parties an independently checkable reference to a record, a party can optionally commit the blockHash, or a Merkle root over many Block hashes, to a blockchain. A counterparty can read the recorded Merkle root from the selected chain and verify a sorted-pair Merkle proof, confirming that the Block hash is included in the leaf collection represented by that root. ALX on Base publishes the status of the Base implementation.

Key Concepts​

  • Shared identity without a shared database is the point of this use case: both parties recompute the same contentHash and blockHash from exchanged protocol data.
  • Declared Parent Relationships are the direct dependencies a Block lists in parentHashes; earlier ancestors stay reachable through the graph.
  • Graph Validation detects self-references, duplicate parent relationships, missing parent Blocks, and cycles with validateGraph() before an application relies on a received lineage.
  • Blockchain Commitments are optional: each records one blockHash or one Merkle root at a blockchain position, without putting Block content on-chain.
  • Merkle Inclusion Proofs show that a Block hash is included in the set committed by a trusted Merkle root.
  • Block Attestations are EIP-712 messages specified in Signing. The current package does not implement the Block-attestation helpers the specification names.

What ALX Does Not Do​

A matching identity confirms canonicalized content and a normalized parent set, not that the declared parents are the inputs actually used. Verification does not establish factual accuracy, ownership, authorization, policy compliance, legal validity, safety, or application intent, so neither organization can treat a passing check as an approval decision. ALX defines no storage format, availability guarantee, transport, or API, and no dependency ordering beyond an unordered parent set; a party loading only part of a graph should treat the result as incomplete lineage. Indexing, querying, and the Block Explorer belong to XNDR Network, a separate product that observes ALX.

A commitment shows only that a value was recorded at a blockchain position, and chain timestamps establish approximate ordering rather than exact external time. A Merkle proof alone does not show that its root was recorded on-chain, and an empty proof confirms only direct equality between the Block hash and the root. Applications still decide which signers, roots, and authorities they accept, as described in the Trust Model.