Proof Material

Elsewhere on this site, a FORAY record is hashed, and that hash is bound — together with fresh random proof material — into a commitment anchored to Kaspa. The chain never sees the record; it sees only the commitment. Matching an anchor back to the record it came from is therefore a holder-side check: whoever holds the record body and its proof material can redo the binding and compare it to what is on-chain. Anyone can do this. Nobody needs to trust DUNIN7 to do it correctly.

This page exists to make that check reproducible for two demonstration records, in full — nothing withheld. Each exhibit below carries the record body, the salt used to bind it, the lane it was anchored under, and the Kaspa transaction it was anchored in. The verification recipe is the same for every record FORAY ever anchors:

body bytes → SHA-256 → commitment (with leafSalt and lane) → compare to the on-chain payload.

Salts are ordinarily consumer custody, never published — that is FORAY's standing design (a body owner proves their own record; nobody else needs to see the salt). The two exhibits on this page are demonstration records built for exactly this purpose, so their salts are published here by design, not by exception.

The body files below are the exact bytes — download and hash them; do not copy from the rendered page.

The F-wire migration (Protocol v4.2, accepted 2026-07-24) moved FORAY's wire to flat, F-coded records. The demonstration exhibits on this page were anchored before that break, so their bodies are pre-migration wire — frozen evidence, correct exactly as anchored. They are not updated, because anchored evidence never is: the anchors commit to these bytes, and these bytes reproduce those anchors. Newly originated records use the 4.2 F-coded wire; the validator accepts pre-4.2 records permanently, converting them through the ruled migration chain and labeling the result legacy. The ops log and custody sheets below are likewise unchanged evidence of what was done at the time it was done.

A fabricated invoice-settlement record, mapped from realistic accounting-system columns into the current FORAY wire shape, then anchored to Kaspa mainnet on 2026-07-24. The evidence record identifier (F1) carries the originating system's own transaction key verbatim, not a manufactured id — at the time this record was anchored, the wire had no dedicated source-reference field, so F1 carried the linkage from this evidence back to its source record. The F-wire migration has since given that linkage its own fact — the source record reference (F2) — and the ruled migration of a record like this one sets F2 to exactly this value.

Rows read across — one fact, three vocabularies: the originating system's own column, the value this record carries, and the ratified canonical implementer name. Row order is F-number order — since the F-wire migration, the order the 4.2 wire carries. Facts with no client-system column of their own show —. Four columns wide — scroll right within the table to see the canonical name column on narrower screens.

F25 and F29 carry no row — no residue and no external artifact digest apply to a routine AP settlement. InvoiceNo and PmtTerms ride in the Arrangement's free-text fields and are not F-coded facts.

Location of record: the custody sheet and record body, served on this site under /proofs-material/. An earlier version of this exhibit anchored the same record under a manufactured identifier (tx f997e394…, 2026-07-23) — that anchor remains valid and verified but is superseded here as demonstration material.

A fabricated agentic-governance record — a delegated grant, a policy evaluation against it, and the agent action that followed — mapped from realistic log-system columns into the current FORAY wire shape, then anchored to Kaspa mainnet on 2026-07-24. The evidence record identifier (F1) carries the originating system's own log-entry key verbatim, not a manufactured id — at the time this record was anchored, the wire had no dedicated source-reference field, so F1 carried the linkage from this evidence back to its source record. The F-wire migration has since given that linkage its own fact — the source record reference (F2) — and the ruled migration of a record like this one sets F2 to exactly this value.

Rows read across — one fact, three vocabularies: the originating system's own column, the value this record carries, and the ratified canonical implementer name. Row order is F-number order — since the F-wire migration, the order the 4.2 wire carries. Facts with no client-system column of their own show —. Per the agentic/governance mapping in the Root Data Set: a grant is an Arrangement, the agent action is an Action referencing it, the policy check is an Accrual, the expected behavior is an Anticipation, and the verdict is F15. Four columns wide — scroll right within the table to see the canonical name column on narrower screens.

F9's settled amount and F7's amount share one source figure, BudgetCeilingUSD, in this fabricated example — F9's cell is left — to avoid implying a second, independent client column exists. F16, F21, and F25 carry no row: a payment method does not apply to a non-monetary governance verdict, there is no monetary allocation to distribute, and no non-Root residue is carried.

This record's formula output (F20) and probability factor (F28) share one underlying confidence figure (PolicyConfidenceScore), for narrative economy in a fabricated example. The catalog does not require these facts to coincide — a real policy engine would typically produce them independently.

Location of record: the custody sheet and record body, served on this site under /proofs-material/. An earlier version of this exhibit anchored the same record under a manufactured identifier (tx ebb75c73…, 2026-07-23) — that anchor remains valid and verified but is superseded here as demonstration material.

The bytes anchored for every record on this page are the pre-migration wire register — the field spellings shown in each exhibit's Panel 1 originating columns, mapped through the wire shape in force when they were anchored. They remain correct exactly as anchored. The F-wire migration (Protocol v4.2, accepted 2026-07-24) has since moved the wire to F-codes: the catalog numbers shown in each exhibit's Panel 3 are now the wire for newly originated records. The foray_* names shown in Panel 2 are the canonical implementer register — the readable layer adaptor authors work in — and are never the wire, before or after the migration. The mapping shown throughout this page is the ratified catalog; for these exhibits it describes what the ruled migration produces from them, not what was anchored.

Earlier test-era anchoring transactions predate the custody discipline demonstrated above; they are documented in the ops log.