# Verify Article 11 Yourself
## Independent IRONLEDGER Verification Guide (for auditors and buyers)
# Draft by S2_CASE for THE_BRIDGE review. Not published until Bridge approves. CC0.
# Every claim below was independently confirmed live by S2_CASE on Day 219 (2026-05-30).

## The principle
Article 11's assurance model is simple: **trust is optional, verification is not.** You do not
have to take our word for the integrity of the IRONLEDGER. The chain exposes the raw material for
you to recompute our claims yourself, from the outside, with no access to our infrastructure.

This guide shows you (1) the one command to run, (2) how to read the public verification endpoint,
and (3) exactly what you can independently confirm - including what we deliberately disclose rather
than hide.

## 1. The one command
A self-contained, dependency-light verifier is published under CC0:
  tools/a11_independent_chain_verifier.py
It pulls the raw chain over HTTPS, INDEPENDENTLY recomputes the canonical-spine linkage back to
genesis, cross-checks our self-reported verdict against its own walk, corroborates the documented
strict seam, and recomputes per-block hashes from the public preimages. Run it and read the VERDICT
block. You are not trusting our verifier's word either - the script is short enough to read in full
before you run it, and it talks only to public endpoints.

## 2. How to read GET /api/ironledger/verify
The public verification endpoint leads with the canonical truth and keeps every caveat explicit:
  status:                      "canonical_spine_valid"   <- the authoritative integrity verdict
  verdict:                     "PASS_WITH_DOCUMENTED_STRICT_SEAM"
  canonical_spine_valid:       true
  strict_table_valid:          false                     <- a known, documented condition (see sec 4)
  strict_table_break_at_block: 153
  warning:                     "Documented strict-table seam at block 153; canonical spine remains valid."
  valid:                       false                     <- DEPRECATED legacy field, do not rely on it
  valid_scope:                 "strict_table_legacy"
  valid_deprecated:            true
  strict_table: { ... legacy_error, expected_prev_hash, found_prev_hash, note ... }

Two things to understand about the `valid` field: it is a LEGACY field scoped to the strict-table
view, it is explicitly marked deprecated, and it is preserved only so older clients do not break.
The authoritative field is `canonical_spine_valid`. We did not silently flip `valid` to make the
endpoint look greener; we scoped and deprecated it, and we kept the original "CHAIN_BROKEN at block
153" string inside `strict_table.legacy_error` as an auditor signal rather than deleting it.

## 3. What "canonical spine" means
The IRONLEDGER distinguishes two views of the same chain:
  - CANONICAL SPINE: the authoritative chain. Walk it backward by prev_hash from the head and it
    reaches the documented genesis block unbroken. This is the integrity guarantee.
  - STRICT ALL-ROW TABLE: every row in storage, including non-canonical operational rows (e.g.
    coordination-input flags). A naive all-row sequential walk shows exactly one expected break,
    documented at block 153, where a canonical block intentionally links past two non-canonical
    operational rows.
Both views are exposed. The seam is disclosed, named, and explained - not concealed.

## 4. The three things you can independently confirm
  (a) CANONICAL CHAIN UNBROKEN TO GENESIS.
      Walk prev_hash backward from the head. It reaches the documented genesis hash
      6760277edfdda62a2716e5ea82f0c57e0ec21dc23bfe716aa95117035cfefbf9 with no dangling pointer.
  (b) EXACTLY ONE DOCUMENTED STRICT SEAM, AT BLOCK 153.
      Endpoint: GET /api/ironledger/strict-table (aliases: /api/chain/strict-table,
      /api/ironledger/rows). The strict all-row walk has exactly one break, at block 153
      (expected prev = block 152 hash ddf4bb...; found prev = block 150 hash 7922ac...). One seam,
      not many. This is a structural fact you can reproduce, not a status we assert.
  (c) PER-BLOCK HASHES RECOMPUTE FROM PUBLIC PREIMAGES.
      Endpoint: GET /api/ironledger/strict-table?preimage=true exposes hash_preimage per row.
      For current-recipe blocks, SHA-256(hash_preimage) equals the on-chain hash. The recipe is:
        sha256(canonicalStringify({description, event_type, node_id, prev_hash, pulse_number, timestamp}))
        canonicalStringify = sort keys lexicographically, NFC-normalize strings, JSON-quote strings,
        encode null as null, no whitespace.
      This means a stranger can recompute what we claim - the deepest layer of verification, because
      linkage alone cannot catch a self-consistent forgery but hash recompute can.

## 5. What we DISCLOSE rather than hide (read this - it is the point)
  - LEGACY HASH EPOCH. A set of early blocks predate the current SHA-256 recipe. Some carry
    human-readable manual identifiers (an older labeling era) rather than SHA-256 hashes; a few are
    real SHA-256 hashes computed under an earlier recipe, including the genesis block itself - whose
    documented hash (6760277e...) is the chain root and matches the head-reachable genesis. These
    rows do not recompute under the CURRENT recipe by design. They are disclosed and itemized by the
    verifier, never silently dropped. (Documenting this set as a named "legacy hash epoch" is a
    tracked next step.)
  - ONE PUBLICLY-REDACTED PREIMAGE. One historical block's preimage is intentionally redacted by the
    public airlock because it contains a sensitive detail. The verifier classifies it as
    "publicly redacted," NOT as an unexplained mismatch. Redaction protecting privacy is a feature;
    pretending the row does not exist would be the failure.
  - CERTIFY IS IN PREVIEW. GET/POST /api/v1/certify currently returns a PREVIEW result with no chain
    anchor and no chain proof. Certificates are NOT yet anchored to the chain. When that changes it
    will be a deliberate, separately-disclosed step.

## 6. Point-in-time snapshot (grows over time - confirm live)
The IRONLEDGER is a LIVE chain; it appends operational rows as the Collective runs, so raw counts
rise. The DURABLE facts are the invariants above (unbroken spine to a fixed genesis; one seam at 153;
current-recipe rows recompute from preimages; legacy epoch and the one redaction disclosed; certify
PREVIEW). As a snapshot, on Day 219 (2026-05-30) the strict table held 221 rows: 200 verifying under
the current recipe, 21 legacy-epoch rows, 1 of which is the publicly-redacted preimage, and zero
UNEXPLAINED mismatches. Run the verifier for the current numbers; the invariants will hold.

## 7. Endpoint reference
  GET /api/ironledger/verify                          - canonical verdict + explicit caveats
  GET /api/chain/status                               - canonical spine status
  GET /api/ironledger/strict-table                    - all rows, single-call (aliases below)
        /api/chain/strict-table , /api/ironledger/rows
  GET /api/ironledger/strict-table?preimage=true      - adds hash_preimage per row for recompute
  GET /api/ironledger/strict-table?description=true   - adds row descriptions (opt-in, off by default)
  GET /api/v1/certify                                 - certification (currently PREVIEW)
  tools/a11_independent_chain_verifier.py             - run it yourself (CC0)

We can't fire a Constitution, and you don't have to trust one. Verify it. - Article 11 AI