Skip to main content

Compliance & Audit Records

Organizations exchange approvals, assessments, and compliance evidence across independent systems. Application-specific identifiers and audit logs complicate verification across organizational boundaries.

ALX Protocol represents compliance records as Blocks with deterministic identities and declared parent relationships. Organizations can independently validate exchanged records and their declared dependencies without a shared database.

The Problem​

Compliance workflows depend on records distributed across suppliers, customers, auditors, and internal systems. Different identifiers, data formats, and storage systems complicate record comparison and dependency verification.

Identical approval content can reference different supporting evidence. Application-specific identifiers cannot independently establish whether exchanged records contain equivalent content or declare the same dependencies.

How ALX Applies​

Create Blocks for compliance records requiring deterministic identity or declared lineage:

  • Evidence Documents: Metadata identifying supporting evidence or external documents.
  • Control Assessments: Assessments referencing evaluated evidence.
  • Approval Decisions: Decisions referencing supporting assessments.
  • Acceptances: Receiving-organization records referencing the associated approval.

Each Block declares direct dependencies through parentHashes. Earlier records remain reachable through the derivation Graph. Root Blocks use an empty parent set.

Example: Approval Record​

The approval Block contains application-specific content and declares the control assessment as a direct parent. The parent hash is an illustrative placeholder. A complete Block also contains protocolVersion, contentHash, and blockHash.

Identical content produces the same contentHash. Different declared parent sets produce different blockHash values, distinguishing approval records with different declared dependencies.

Canonicalization allows conforming implementations to reproduce deterministic identities from equivalent protocol inputs. See Block Identity for hashing and canonicalization rules.

Content
{
  "type": "approval-record",
  "decision": "approved",
  "scope": "quarterly-access-review"
}
Parent hashes
{
  "parentHashes": [
    "0x<control-assessment-block-hash>"
  ]
}

Graph Validation and Attribution​

ALX provides two functions for examining declared compliance dependencies:

  • validateGraph(seed, source, context) — Validates Block hashes and declared parent relationships. Returns valid, invalid, incomplete, or resource_limit_reached.
  • traceAttribution() — Returns a selected Block and reachable ancestors, including depths, path counts, and lineage completeness.

Missing parent Blocks produce incomplete lineage. Block validation and Graph validation do not establish whether declared dependencies represent actual approval or assessment procedures.

Optional Blockchain Commitments​

Organizations can independently record a blockHash or a Merkle root representing multiple Block hashes on a blockchain. Blockchain commitments record hash references, not Block content. Block creation and local validation do not require blockchain connectivity.

ALXAnchor, deployed on Base (chain ID 8453), provides:

  • isAnchored() — Checks whether a supplied hash has an anchor record.
  • anchoredAt() — Returns the block timestamp of the first anchor record.

Merkle inclusion proofs, verified offchain, confirm that a Block hash is included in the leaf collection represented by a supplied Merkle root. See ALX on Base for deployment details and commitment verification.

Protocol Boundaries​

ALX verifies deterministic identities and declared relationships. Organizations remain responsible for additional compliance requirements.

  • Approval Authority: Valid Block identities do not establish authorization, approval legitimacy, or the identity of an approving organization.
  • Content Validation: Hash verification does not establish factual accuracy, legal validity, policy compliance, ownership, or application intent.
  • Dependency Completeness: Graph validation cannot detect undeclared evidence, assessments, or approval inputs.
  • Storage and Discovery: ALX does not provide record storage, transport, indexing, or availability guarantees. XNDR Network provides separate discovery and indexing services for observed ALX Blocks.
  • Execution Order: Parent relationships define declared dependencies, not chronological execution order.
  • Blockchain Evidence: Commitments establish that hash values were recorded at blockchain positions, not the exact time of an external approval or the identity of the approving authority. Merkle inclusion proofs require a separately trusted root.
  • Trust Decisions: Applications determine acceptable signers, authorities, and commitments according to organizational policies.

Optional Block Attestations support Ed25519 or P-256 signatures over blockHash. See Signing and Trust Model for signature verification and trust considerations.