Every verdict HORIZON SHIELD issues is meant to be recomputed by a stranger who trusts none of our infrastructure. This document states exactly what each receipt binds, how to recompute it from public data, and, just as plainly, where the binding is not yet as strong as it will be.
Read this first. A verified hash proves a declaration was not tampered with. It does not prove the audit ruleset behind it is still current. Our verifier reports that limit in every response (audit_ruleset_recheck: not_performed), and the input digest is currently truncated (see Section 3). We would rather name these than let the word "verified" carry more weight than it earns.
One immutable receipt per verdict, served at a stable address, next to its own timestamp proof.
Each verdict lives at /souba/<case>/v/<audit_hash>/ and carries three files: a human page (index.html), the machine payload (claim.txt), and its OpenTimestamps proof (proof.ots). The payload is a single line of JSON. This is a real receipt, verbatim from production:
{"type":"hs_verdict_claim","version":"1.0","audit_hash":"B9qY5eH2cN7j",
"work":"水回りリフォーム","presented_amount_jpy":3850000,
"corrected_amount_jpy":3220000,"reduction_amount_jpy":630000,
"reduction_rate_percent":"16.4","dataset":"HORIZON SHIELD 診断事例データセット v3.0",
"dataset_anchor":"Bitcoin Block #949356",
"permalink":"https://shield.the-horizons-innovation.com/souba/kajou-seikyu-jirei-20/v/B9qY5eH2cN7j/",
"claim_created":"2026-07-16"}
| field | meaning |
|---|---|
| audit_hash | Stable identifier for this verdict. Also the address segment. |
| presented / corrected / reduction_amount_jpy | The verdict itself: quoted amount, fair amount, the gap, in JPY. |
| dataset | The comparison basis this verdict ran against, by name and version. |
| dataset_anchor | The Bitcoin block the dataset declaration is timestamped into (Section 4). |
| permalink | Self locating: the receipt names its own canonical address. |
The paired proof.ots is the OpenTimestamps proof that this exact claim.txt existed at or before its anchored block time. It is served raw at /souba/<case>/v/<audit_hash>/proof.ots, no wrapper, exactly the bytes an ots verify needs.
A second, tool-checkable representation whose posture is distrust by default.
Alongside the receipt, an audit emits a signed integrity claim: a signed_payload string and its claim_sha256. Verification is complete on its own. Recompute SHA-256 over the raw signed_payload string and check it equals claim_sha256. No call back to the issuer, no price layer, no trust in us.
The public MCP tool verify_integrity_claim does exactly this, fail closed, and returns a contract-shaped result:
skipped if you did not pass one.not_performed. Verified means untampered, not that the ruleset is still valid. We will not let that ambiguity hide.The tool is read only, needs no API key, and can be pointed at any claim, including ones we did not issue. That is the point. A check you can only run through us is not a check.
This is the load bearing question, so here is the honest answer.
The claim binds both sides. The verdict numbers are in the payload. The input is bound through estimate_version, a SHA-256 digest of the raw estimate text. So a verifier who holds the original quote can confirm the verdict was issued for exactly that document, then re-run the comparison against the same public dataset. The line items themselves stay out of the payload on purpose. Quotes carry private detail, so we commit to them by hash and reveal only to whoever already holds the document.
The caveat, named plainly. Today estimate_version is truncated to the first 8 hex of that SHA-256. Eight hex is enough to bind scope for a holder who is checking one known document. It is not enough to resist a determined search for a second document that collides. So today it gives scope binding, not grind resistance. The fix is in Section 6, and it is not cosmetic. It is the difference between the two claims.
The dataset behind every verdict is fixed by the PTKA Declaration (Pre-Transaction Knowledge Anchoring): our methodology statement, timestamped into the Bitcoin blockchain via OpenTimestamps so it cannot be quietly rewritten after the fact.
# PTKA Declaration
SHA-256 : 596da30ba4ca731f21efaa1c4a6537290e996e0f039cbe57704de1674e4a0282
Block : Bitcoin #949356
Confirmed: 2026-05-14 JST
Via : OpenTimestamps (https://opentimestamps.org)
Each receipt names this same anchor in its dataset_anchor field, so the chain from a single verdict back to a public, timestamped methodology is followable without contacting us.
The whole claim is that a stranger can run this. So here is the run.
# A. verify the timestamp proof on a receipt curl -sO https://shield.the-horizons-innovation.com/souba/kajou-seikyu-jirei-20/v/B9qY5eH2cN7j/claim.txt curl -sO https://shield.the-horizons-innovation.com/souba/kajou-seikyu-jirei-20/v/B9qY5eH2cN7j/proof.ots ots verify -f claim.txt proof.ots # confirms this exact claim.txt existed at or before the Bitcoin block time # B. verify a signed integrity claim (no trust in us) printf '%s' "$SIGNED_PAYLOAD" | shasum -a 256 # the output must equal the claim_sha256 the audit reported
If step A fails, the receipt was altered after stamping. If step B does not match, the declaration was altered. Either way the correct answer is to reject it, which is the same posture our own verifier takes.
What closes the gap in Section 3, stated as commitments, not as done.
estimate_version from 8 hex to the full SHA-256. This is the change that turns scope binding into grind resistance./v/<audit_hash>/ layout. An estimate level rollup, if it comes, is a convenience index, never the trust anchor.proof.ots route, so the receipt is machine followable end to end without knowing our path convention, the same shape peer ledgers already expose.This spec is a draft and will move. Conformance notes and independent review are welcome. The contact below is real.