Ricche Research Artefact 001

Governance Ledger Tamper-Evidence Demonstration

A Synthetic Verification of Hash-Chain Integrity

Status

Published

Data

Synthetic

Published

June 2026

Overview

Publication creates visibility. Validation creates authority. A claim does not become trustworthy because it has been published; it becomes trustworthy when it can be independently verified — when someone other than the author can check it, and when the check could have failed.

This artefact is a small, self-contained demonstration of one such verifiable property: the tamper-evidence of a hash-chained ledger. It is built entirely from synthetic data authored from scratch for this demonstration. It is the property — not the contents — that is being demonstrated. No operational records are used or disclosed.

What a hash-chained ledger is

A hash-chained ledger is an append-only sequence of entries in which each entry carries a cryptographic fingerprint (a SHA-256 hash) of its own contents, and also carries the fingerprint of the entry before it. Because every entry embeds the previous entry's fingerprint, the entries form a chain: each link depends on all the links before it.

Why each entry links to the previous entry

Linking each entry to the one before it makes the order and the history rigid. An entry's fingerprint is computed over its own fields and the previous entry's fingerprint, so changing any earlier entry would change its fingerprint, which would no longer match the value recorded in the next entry. A single alteration anywhere becomes visible everywhere downstream.

What verification means

Verification recomputes the fingerprints from the data and compares them with the values stored in the entries:

• the recomputed payload fingerprint must match the stored one;
• the recomputed entry fingerprint must match the stored one;
• each entry's recorded previous fingerprint must equal the actual fingerprint of the entry before it (the first entry links to a fixed genesis value).

If every check passes, the chain is intact. Verification depends only on the structure and the arithmetic — not on any secret and not on what the entries are about.

What tampering means

Tampering is any change to an entry after it was written: altering a value, reordering entries, or editing a stored fingerprint. Because the fingerprints are recomputed during verification, a tampered entry no longer matches its stored fingerprint, and the check fails at exactly the altered entry.

Why synthetic records preserve the property

The verification property is content-agnostic: it follows from the chain structure and the hashing arithmetic, not from the meaning of any field. Synthetic entries with neutral labels therefore exhibit exactly the same tamper-evidence as any other entries. A reviewer can confirm the property in full without ever seeing real records.

Why real records are not disclosed

The purpose of this artefact is to let a reviewer verify a property, not to expose internal records. The samples below were written from scratch for this demonstration; no operational data was read, copied, sampled, or redacted to produce them. Demonstrating the property does not require — and must not involve — disclosing the contents of any operational system.

The synthetic samples

Three small JSON Lines files (one entry per line) are provided. Download them and verify them yourself:

• intact.jsonl Expected: PASS An intact synthetic chain — every fingerprint and link is consistent.
• tampered.jsonl Expected: FAIL The same chain with one synthetic payload value altered while the stored fingerprints are left stale.
• appended.jsonl Expected: PASS The intact chain plus one additional synthetic entry; the earlier entries are unchanged.

Verification logic

Each entry stores its fields plus three derived values: payload_hash, previous_hash, and entry_hash. To verify, recompute the two hashes and check the links. "Canonical JSON" means JSON serialised with keys sorted and compact separators, encoded as UTF-8.

canonical(obj)  = JSON(obj) with sorted keys, separators ("," ":"), UTF-8

payload_hash    = SHA-256( canonical(entry.payload) )

envelope        = { schema_version, event_id, event_type, source, mode,
                    actor, subject, created_at, payload_hash, previous_hash }
entry_hash      = SHA-256( canonical(envelope) )

verify(entries):
    prev = "0" x 64                       # genesis value
    for e in entries:
        if e.previous_hash != prev:                      return FAIL
        if SHA-256(canonical(e.payload)) != e.payload_hash:  return FAIL
        if SHA-256(canonical(envelope(e))) != e.entry_hash:  return FAIL
        prev = e.entry_hash
    return PASS

This is standard cryptographic construction. It uses only a SHA-256 implementation and a JSON parser — no special software, no network access, and nothing specific to Ricche. A reviewer can implement it in a few lines in any language.

What a reviewer can verify

1. Download intact.jsonl, recompute the hashes, and confirm the result is PASS.
2. Download tampered.jsonl and confirm the result is FAIL, at the altered entry.
3. Download appended.jsonl and confirm: it is PASS; its first entries are byte-for-byte identical to the intact chain; and the new entry's previous_hash equals the intact chain's final entry_hash. Appending leaves the prior rows — and their fingerprints — unchanged.

The point of the exercise is that it could fail: a reviewer who alters any character in the intact sample will see verification fail.