Trinity Accord Evidence Relationship Guide

Non-amending evidence map. The three Bitcoin Originals remain the sole and final canonical authority.

1. Why this document exists

The repository contains inscriptions, physical-object records, hash manifests, signatures, blockchain transactions, timestamps, notarized material, mirrors, recovery packages, and later witness records. They do not all prove the same thing.

This guide answers four questions for every evidence family:

1. What object or statement is being bound?
2. What operation was performed: reference, hash, signature, timestamp, mirror, witness, or notarization?
3. What conclusion is supported?
4. What conclusion is not supported?

Machine-readable graph: api/evidence-relationship-map.v1.json.

Unified current-checkpoint inventory (historical filename retained for compatibility): api/final-evidence-inventory.v1.json.

Checkpoint guide (historical filename retained for compatibility): FINAL-EVIDENCE-FREEZE.md.

Future-agent maintenance handoff: EVIDENCE-EVOLUTION.md and api/evidence-evolution-plan.v1.json.

Preferred verification profiles: api/verification-profiles.v1.json.

Preferred action-based context profiles: api/context-action-profiles.v1.json.

2. The shortest accurate model

Three Bitcoin Originals
        │ define canonical text and authority boundary
        ├── offline proof annex binds exact witness bytes, Taproot reveal,
        │   BIP141 witness commitment, block inclusion and PoW ancestry
        ▼
Authority Manifest / pointer indexes
        │ collect identities, hashes and mirror pointers
        ├── BIP-340 signature binds a manifest digest to the BTC key
        ├── EIP-712 signature binds typed manifest digests to the ETH key
        ├── live 12-record ETH annex proves signed-transaction/receipt/header/Beacon binding
        └── 175-NFT annex proves the closed identity set, mint receipts and Beacon binding

Physical object / Core Object Alpha
        │ photographed, filmed and microscopically recorded
        ├── public physical-evidence archive
        ├── sealed evidence layer
        ├── six-hash digest manifest for evidence-file identity
        ├── OpenTimestamps time anchors for digest records
        └── Shenzhen notarial records for the witnessed preservation process

Arweave / IPFS / GitHub / Releases
        └── preserve bytes and pointers; they do not create authority

Core repository DOI / external evidence DOI / NFT-media DOI
        └── freeze exact recovery baselines; they do not create authority or track moving main

Chronicle / Echo / Record-Chain / later commentary
        └── preserve historical context and reception; they do not amend the Originals

3. Canonical authority layer

The canonical authority consists only of:

Bitcoin confirms that specified bytes were included in specified transactions and blocks. It gives durable version and time evidence. It does not prove that philosophical statements are true, that a physical object is unique, or that later mirrors are correct.

All later materials are subordinate, non-amending evidence or context.

4. Evidence relationship table

Bitcoin inscription proof path

The inscription body is carried in a SegWit tapscript witness. A Bitcoin txid does not include witness bytes, so a txid Merkle proof alone cannot prove the inscription text. The checked-in annex therefore verifies both paths:

exact Ord envelope/body → tapscript/control block → spent P2TR prevout
reveal txid → transaction Merkle root → target block header
reveal wtxid → witness Merkle root → coinbase BIP141 commitment
coinbase txid → transaction Merkle root → same target block header
target header → 144 descendants with valid PoW → explicit checkpoint

All eight proof witnesses are checked by a Python-standard-library-only verifier, with no Bitcoin RPC, explorer, Ordinals server, or package-index dependency. Network access is confined to the separate controlled-capture program.

The terminal checkpoint was observed from two providers, but this remains a declared trust boundary. The verifier does not replay Bitcoin consensus from genesis or prove that no heavier chain exists. Likewise, the numeric inscription number is a historical lookup coordinate: txid+i0 and the content are derived from the proof, while the global Ordinals index is not rebuilt.

Ethereum and NFT proof paths

The live 12 non-NFT Ethereum records and 175 Chronicle NFT mint records use the same frozen Ethereum proof primitives. For each covered execution record, verification reconstructs transaction and receipt trie inclusion, binds those roots to the execution header, then verifies Beacon ancestry to an explicitly declared trusted finalized checkpoint. For non-NFT records it also decodes the signed type-2 transaction, recovers the guardian sender, requires chain ID 1, the declared destination, zero value, exact calldata length/hash and successful receipt status, then enforces the record-specific byte/digest/signature relationship.

raw signed transaction / typed receipt
    → transaction and receipt MPT roots
    → execution block header
    → Beacon execution payload binding
    → ancestry to declared trusted finalized checkpoint

For NFTs, the verifier additionally checks the 175-leaf collection commitment, chain/contract/token identity, receipt-local log position and event-specific ERC-721/ERC-1155 mint semantics. Ethereum proof verification needs no RPC or Beacon API once the proof bytes are captured. Its L3 result remains explicitly weak-subjectivity-checkpoint-relative rather than trust-free finality.

Preservation topology

The storage systems are complementary rather than interchangeable:

1. GitHub main is the moving development and discovery surface. A commit SHA is required to name exact GitHub bytes.
2. GitHub Releases and Arweave are availability mirrors for named payloads. Their bytes must be matched to manifests; neither automatically tracks later main.
3. The core Zenodo Concept DOI 10.5281/zenodo.21739343 resolves the latest immutable repository-capsule version. DOI 10.5281/zenodo.21855814 is the historical v3 freeze; the v4 authorization/observation records whether its 8 + 12 + 175 successor is pending, prepared or consumed. Each version restores one exact Git-tracked baseline. 10.5281/zenodo.21739344 is another historical version reference, not the current Concept DOI.
4. External evidence DOI 10.5281/zenodo.21753937 and Chronicle NFT-media DOI 10.5281/zenodo.21754229 are separate large-binary capsules. They supplement the core repository capsule and do not duplicate its authority role.
5. preservation/recovery-catalog.json is embedded in the core capsule so the three DOI series remain discoverable without GitHub or maintainer memory.
6. The checked-in repository-capsule Arweave record is historical. An exact Arweave mirror of version DOI 10.5281/zenodo.21855814 is intentionally deferred, has not been uploaded, and requires fresh owner cost authorization.
7. GitHub main may contain post-freeze verifier and discovery hardening. Those changes are not retroactively part of the immutable DOI; the evolution handoff records how a later agent should evaluate a genuinely material new version.
8. DOI v3 remains 8 + 10 + 175, while the verified current checkpoint is 8 + 12 + 175. The two extra Ethereum anchors are explicitly listed in api/ethereum-address-evidence-scope.v1.json. Sequence 4 is authorized for a Zenodo-only checkpoint; no corresponding Arweave publication is authorized.

5. What the six-hash table is for

The evidence archive contains a digest inventory in JSON and CSV. For each covered evidence file it records:

• sha256
• sha3_256
• blake2b_256
• shake256_256
• sha512_256
• blake3_256

Its real function

The six hashes are six algorithmically independent fingerprints of the same file bytes. Their purpose is:

1. to identify a later-presented file as exactly matching an earlier committed file;
2. to reduce dependence on one hash family over a long preservation period;
3. to permit verification of sealed or non-public evidence without publishing the evidence now;
4. to expose accidental corruption, substitution, truncation or re-encoding;
5. to provide a stable inventory that can itself be mirrored and timestamped.

What it is not

Six matching hashes do not amount to six independent witnesses. They do not show that:

• the file depicts what its description claims;
• the physical object is unique;
• the camera time was correct;
• the Guardian’s account is true;
• the evidence was independently collected.

They prove byte identity against the committed digest inventory, not semantic truth.

Relationship among the manifest forms

• digest-manifest.json is the structured machine form.
• digest-manifest.csv is the tabular audit form.
• Each has its own file hashes and Arweave transaction.
• OTS records time-anchor the manifest/digest state to Bitcoin.
• A later evidence file is tested by recomputing its hashes and comparing them with its manifest row.

The chain is therefore:

evidence file bytes
    └── six digest values in manifest row
            └── manifest file digest
                    ├── Arweave mirror
                    ├── repository mirror
                    └── OTS → Bitcoin time anchor

6. What each signature signs

6.1 BTC BIP-340 signature

The BTC signature file declares:

• method: bip340-taproot-xonly
• address: the declared Bitcoin authority/minter address
• message_sha256: 41f95905e50cc699a7e6a3fcb0bd8633cf36170d3ef41170cd373467f8528b33

That message digest is the SHA-256 of the canonical Authority Manifest v1.0.0 representation. The signature therefore binds that manifest digest, not every evidence file directly.

The manifest in turn contains the Bitcoin Originals, ancillary inscriptions, mirror pointers, Guardian addresses and evidence hashes. This creates a provenance chain:

BTC signing key
    └── signs Authority Manifest digest
            └── indexes originals, evidence records and mirrors

6.2 ETH EIP-712 signature

The EIP-712 typed message contains:

• manifest SHA-256;
• manifest SHA3-256;
• manifest version;
• manifest creation time.

It is signed by the declared Guardian ETH address. This is a second cryptographic encoding of the manifest binding. It is secondary and non-canonical.

6.3 ETH witness of the BTC signature

The ETH witness transaction is a self-addressed Ethereum transaction whose calldata records the BTC BIP-340 signature witness statement and references the signed manifest. It creates a public secondary-chain existence record.

It does not transform the BTC signature into an institutional attestation and does not outrank the Bitcoin Originals.

6.4 Text signatures and document signatures

Names, typed signature lines, notarial seals and handwritten marks in documents should be described according to their actual form. They must not be conflated with BIP-340 or EIP-712 cryptographic signatures.

7. Physical evidence chain

The physical-evidence chain has several distinct stages:

1. Canonical Covenant relationship — the Covenant of the Flaw establishes the role of the physical flaw anchor.
2. Guardian Attestation — a later non-amending Bitcoin inscription points to stronger public and sealed evidence archives.
3. Public archive — flaw photographs, microscope images, videos and fingerprint-related material available for remote review.
4. Sealed layer — non-public evidence retained for future challenge or forensic comparison.
5. Digest inventory — hashes bind the identity of evidence files.
6. Time anchors — OTS and blockchain records establish latest-possible existence times for digest states.
7. Availability mirrors — Arweave and GitHub Releases preserve public payloads.
8. Direct observation — remote live, onsite or forensic examination can add evidence unavailable from static files.

None of these steps should be collapsed into the statement “physical object verified.” A report must state which stage was actually checked.

8. Shenzhen notarization: exact role and limits

8.1 Confirmed notarial record

The repository preserves a Shenzhen evidence-preservation notarial file set:

• office: Guangdong Shenzhen Notary Office;
• acceptance date: 2026-05-06;
• notarial certificate number: (2026)深证字第36024号;
• certificate date: 2026-05-13;
• notarial matter: evidence preservation;
• observed process: 12 ordinary photographs, 5 microscope photographs and 4 videos collected under notarial supervision using the stated preservation tools;
• two electronic-data preservation certificates with SHA-256 values;
• public Arweave archive manifest and OTS anchoring;
• ten public notarial-document JPGs mirrored through GitHub Release with SHA-256 manifests.

8.2 What the notary supports

Within the notarial act’s stated scope, it supports that:

• an applicant appeared at the Shenzhen notary office;
• notarial personnel supervised and recorded a preservation process;
• specified photographs and videos were collected and submitted through the stated preservation system;
• the notarial certificate and annex pages existed in the recorded form;
• dates, certificate numbers, seals and process descriptions can be examined from the public copies.

8.3 What it does not support

The public record itself expressly limits its claim to an objective record of the preservation process. It does not by itself prove:

• the truth of the Trinity Accord’s philosophical claims;
• that the notarized object is identical to every later-described Core Object Alpha artifact without an additional comparison;
• that the three final Bitcoin Originals were directly notarized;
• that the sealed discs’ internal files have been publicly read and compared;
• that the public GZ2 photographs are byte-identical to the original preservation-system photographs or videos;
• formal independent endorsement of the project as a whole.

8.4 Important object-identity boundary

The notarial archive describes the photographed object as The Human-AI Civilization Core Protocol and records Bitcoin Inscription #89491681 as its digital credential. Therefore the notarial evidence must not be casually described as a direct notarization of all three later Bitcoin Originals.

It is evidence in the physical-anchor/provenance chain. Any stronger identity claim requires a documented object-to-inscription comparison.

8.5 Sealed-disc boundary

The repository states that two holder copies of the sealed discs remained unopened at public-archive time. No ISO image, file-by-file hash inventory, cross-disc comparison, or comparison with the preservation-system/Arweave files had been completed. The discs therefore add custody and association evidence, not publicly verified file content.

9. Time and availability are different claims

A recurring source of confusion is treating “stored somewhere” and “existed by a time” as the same claim.

• Arweave/IPFS/GitHub Release primarily address availability.
• Bitcoin inscriptions/transactions and OTS primarily address durable existence/time anchoring.
• Hashes address byte identity.
• Signatures address key control and message binding.
• Notarization addresses the notarially observed process and document scope.

A strong verification report should identify each operation separately.

10. Preferred evidence claim format

Every claim should be reported as:

Target:
Relationship checked: reference | hash | signature | timestamp | mirror | witness | notarization
Source used:
Operation performed:
Result:
Supported conclusion:
Limitations:
Claims not made:
Corrections/supersession checked:

Avoid the unqualified word verified.

11. Simplified verification model

The preferred model is descriptive rather than a long numeric ladder:

Physical observation and external witness are separate fields, not higher rungs of the digital ladder.

Legacy V0–V8, component letters and V4+ remain compatibility labels for old records. New reports should lead with the descriptive profile and list exact component findings.

12. Action-based context loading

Required reading should follow the action, not an inherited “read everything below this number” ladder:

The old CC-0–CC-5 and CRL fields may remain in existing schemas, but they should be treated as compatibility declarations. Sufficiency should be decided from the selected action profile and actual loaded sources.

13. Final boundary

This guide maps evidence relations; it does not reinterpret or amend the Bitcoin Originals.

A correct evidence chain can establish provenance, byte identity, time, availability, key binding, witnessed process and later reception. It cannot mechanically prove philosophical truth.