DEV Community: Toshikatsu Oga

Give your AI agent a record it did not write (ten minutes)

Toshikatsu Oga — Sun, 06 Sep 2026 10:01:28 +0000

The short version

Almost every "trust" signal for an AI agent today, whether it is an MCP server or an A2A agent, is self-reported. The description in the card, the score on a directory, the vendor's blog. All of it is written by the agent or by someone the agent pays.

This is a ten minute procedure for the other kind of record: your agent measured by someone who is not you, from their own machine, with the observation stored where neither you nor the register operator can edit it. Or the reverse: you become that someone for another agent. One command. No key, no account, no payment.

Honest numbers first (2026-09-06): 9 rows on the register, 1 outside witness, 37 ledger entries, all anchored to Bitcoin. It is small. That is why this post exists.

What exists

Three parts, all public, all Apache-2.0, all run by my company (The HORIZ音s株式会社, Hiratsuka, Japan). The operator's own servers are on the same register and measured by the same gate.

The gate (https://gate.horizonshield.dev). A free checker that measures an MCP endpoint on five conditions: does it answer, does it publish an agent card, does it disclose who pays it, does the same input give the same output, does every verdict carry a SHA-256 you can recompute. No scores. Verified or pending, that is all. Listed rows are re-measured daily or weekly. The day and the tool measured are derived from a salt the gate commits to before the window opens and from a Bitcoin block mined after that, so the subject cannot predict its turn and the gate cannot choose after the fact.
Rings (NENRIN). Once a month, per endpoint, a JSON file of counts: measurements, witnesses, discrepancies. No rates, no scores, no ranks. Each ring carries the sha256 of the previous one; the month's list is anchored to Bitcoin. A Python builder and a Node.js builder written by someone else from the published spec and ring files produced the same eight August rings byte for byte (ledger entry 34, with entry 36 narrowing the provenance claim).
The ledger (JIDEC). Append-only. Witness observations are pooled, bundled once a day, and stamped to Bitcoin through OpenTimestamps. The operator cannot edit it either.

An agent card can carry a small extension pointing at all of this, the A2A Conduct Extension v1: who pays the agent, where the third-party record lives, where to file your own observation. Three pointers, no score.

Ten minutes: be a witness

With Python 3.8+ and uv:

uvx --from "git+https://github.com/ogasurfproject-jpg/horizon-shield#subdirectory=workers/hs-ledger/nenrin/a2a-conduct-walk" \
a2a-conduct-walk --origin https://mcp.horizonshield.dev --mode a2a --submit \
--witness-name "your name or project" --vantage "where this runs, e.g. laptop in Berlin, VPS us-east"

What happens: the agent card is fetched twice and compared byte for byte; the extension declaration is validated against the spec; one A2A SendMessage goes to the measured endpoint with the A2A-Extensions header, and the response shape and header echo are checked; every response body's sha256 goes into the record; the record is POSTed to the intake the card itself names. The last line prints submitted ... http 200 and the record's sha256. That sha256 is your receipt. It appears in the next day's bundle on the ledger, and the month's ring counts you by name.

Leave off --submit and nothing leaves your machine (the record is written to walk_.json so you can read it first). --transport curl if an edge answers 403 to Python. --wire 0.3 walks as a 0.3 client would.

If your agent already speaks MCP, the same walk is a one-tool MCP server. Claude Code:

claude mcp add conduct-witness -- uvx --from "git+https://github.com/ogasurfproject-jpg/horizon-shield#subdirectory=workers/hs-ledger/nenrin/a2a-conduct-walk" conduct-witness-mcp

Then: "walk https://mcp.horizonshield.dev as a witness, my name is X, vantage Y". The walk runs where your agent runs, so the vantage is yours.

Ten seconds: see your own server
curl -s -X POST https://gate.horizonshield.dev/check -H 'content-type: application/json' -d '{"endpoint":"https://your-server/mcp"}'

Five conditions, each with a reason, and a sha256. Nothing is stored unless you ask to be listed (POST /watch). To decline measurement, put "listing": "decline" in your origin's /.well-known/mcp-conduct.json; the gate honours it and records only that you declined.

The ladder

Ten minutes: file one walk under your name. One hour: declare the extension in your own card so your record is findable (the gate's /check tells you whether the declaration is well formed). One day: run your own gate or ledger and anchor each other's roots. Every month: countersign the ring list with your key (a witness council is being designed; a seat is earned by records written, never bought).

Each step up is built so that if that person disappears, the record stays. Not blaming volunteers who leave is how you get volunteers.

What this is not

It does not measure quality. It cannot tell whether a card's compensation is true; it records malformed shape, the gap between what a card declares and what the endpoint does, and the gap between witnesses. A PASS is one observation, not a verdict. A FAIL is filed the same way. Once filed, you cannot withdraw your own observation; that is the property you are contributing.

It is not a lie detector. It is a machine for keeping disagreements. A liar cannot delete a disagreement.

Prior art and neighbours

Every component is old: Certificate Transparency, Rekor, in-toto, SCITT, OpenTimestamps, RFC 8785. Section 9 of the spec names what differs from ERC-8004, A2A discussion #1631 and Sigstore-signed agent cards. The closest thing running today is Agenstry, an observatory that re-measures A2A agents weekly and publishes Merkle roots; they have scale and identity checks, this has outside witnesses, external anchoring and no scores. Less a competitor than the first witness I would like to recruit.

How to falsify it

Every verdict carries a sha256. Pull a ledger entry's bytes, hash them yourself, verify the .ots with OpenTimestamps. Rebuild any ring from the archived history with scripts/make_ring.py --verify. The gate's source is public with an 82 vector red team and a 40 vector red team on the time coordinate. If you get a different result, that itself becomes a record. Section 10 of the spec says fork it or reimplement it without asking.

Gate: https://gate.horizonshield.dev/spec · Register: https://github.com/ogasurfproject-jpg/mcp-conduct-register · Ledger: https://ledger.horizonshield.dev/ledger · Spec: https://gate.horizonshield.dev/ext/conduct/v1 · Witness tool: https://github.com/ogasurfproject-jpg/horizon-shield/tree/main/workers/hs-ledger/nenrin/a2a-conduct-walk

I operate the register, so I am not neutral. Disclosure: drafted with AI assistance.

Same bytes, two verdicts. The only thing I changed was who I said I was.

Toshikatsu Oga — Tue, 18 Aug 2026 05:07:19 +0000

On 15 August I wrote here that two witnesses disagreed about my server and both were right. My own gate said green for seven days. A stranger in Spain said 522. The boundary between them turned out to be a Cloudflare subrequest guard that neither of us could have seen alone.

That post ended with an invitation: if your report contradicts my own instrument, that is the best possible submission.

This is what happened when I turned the same idea around and pointed it at the person who took up that invitation.

Witness B in that story was Federico Blanco Sanchez Llanos, who runs invinoveritas. Three days later I was the one making an assertion about his system, and the assertion I chose to make was false on purpose.

Everything below was measured on 17 and 18 August 2026. Every command is real and you can run it.

Background

There are more than twenty thousand MCP servers. When an agent picks one, it can read a name, a description and a URL. All three were written by the party being evaluated.

Discovery is solved. Choice is not. A directory that lists servers is not the same thing as a record of what happened when someone actually called them.

The instrument

Federico's /verify-proof endpoint lets any third party recompute a signed verdict rather than take his word for it. He then added /verify-proof-log: every call that asserts expect_intended_verifier becomes an append only row.

Fetch it yourself:

curl -s https://api.babyblueviper.com/verify-proof-log | python3 -m json.tool

When I first read it, the interesting part was not the data. It was this:

{
  "assertions": [],
  "count": 0,
  "scope": "all events",
  "honest_limit": "only records calls that asserted expect_intended_verifier -- a caller who asserts nothing leaves nothing to log a mismatch against."
}

The instrument states its own blind spot inside its own response body. A caller who claims nothing is invisible to it. That is structural and it cannot be patched away, and he put it in the payload rather than in a footnote.

Then he invited me to point it at a real proof while claiming an identity I do not hold.

Two decisions taken before running anything

I picked the ledger entry myself. He offered to hand me one with a fresh intended_verifier already set. If he had, he would have controlled both sides of the run, and the resulting record would be worth less than the electricity it took to write.

I asserted a reserved example domain. RFC 2606 reserves .example for exactly this. A mismatch row is permanent. Putting a real third party's name into one, to make a point about a system they never agreed to join, is a cost imposed on someone who is not in the room.

Hold that second decision. It comes back at the end, from a direction I did not expect.

Walk 0: the one that failed

Entry 100. GET /ledger/{N} returns the proof object under the key proof_event, so I posted it back under the key it arrived in.

{"proof_event": { ... }, "expect_intended_verifier": "not-the-horizons.example"}

HTTP 200, and:

{
  "error": "provide `event` (the signed proof object), `proof_id`, or `event_id`.",
  "published_pubkey": "6786e18a864893a900bd9858e650f67ccc3513f248fed374b591e2ff6922fbb7",
  "how_to_verify": "Recompute the Nostr event id = sha256([0,pubkey,created_at,kind,tags,content]); verify the schnorr sig against pubkey; confirm pubkey == published_pubkey."
}

Nothing was logged. I read it as my own mistake, switched the key to event, and moved on.

Notice what the error carried even while being wrong: the published public key and the exact recompute recipe. I could keep working without asking anyone for help.

It was not my mistake

He went and checked instead of accepting my correction, and found the cause. Pydantic silently drops unrecognised fields.

class VerifyProofRequest(BaseModel):
    event: dict | None = None
    proof_id: str | None = None
    event_id: str | None = None
    expect_intended_verifier: str | None = None
    # proof_event was never declared, so it is discarded before validation runs

The default model_config is extra="ignore". So posting under proof_event, the exact key that his own /ledger route uses when it hands you that object, made the field vanish before any code could see it. The request then fell through to a generic "provide event" message that named neither the offending key nor the reason.

This is the part worth taking away even if you never touch MCP.

extra="ignore" reads as forgiving. From the caller's side it is the opposite: it produces an error that cannot be debugged, because you cannot tell a wrong key from a wrong value from a typo. extra="forbid" would have answered "unknown field proof_event" and cost me nothing.

He shipped an alias, added two tests, and confirmed the existing hundred and thirty tests across the touched files still passed.

Walk 1: assert something you do not own

Entry 180, chosen by me.

{
  "valid": false,
  "checks": {
    "id_integrity": true,
    "signature_valid": true,
    "issued_by_invinoveritas": true,
    "is_proof_event": true,
    "decision_ref_recomputes": true,
    "intended_verifier_matches": false
  }
}

Five integrity checks passed. The single check that failed was not about the proof. It was about who I said I was.

The row that landed:

{
  "ts": 1787009262,
  "event_id": "f6432dc260770aa8fad82a7751b543dc044a75514e521d4b0fd7f5030bc170de",
  "asserted_identity": "not-the-horizons.example",
  "declared_intended_verifier": "",
  "matched": false,
  "presenter_authenticated": null
}

The log held zero assertions when I read it minutes earlier. This was the first row ever written to it.

Walk 2: assert nothing, same bytes

Same proof object. No assertion.

{"valid": true, "checks": {"id_integrity": true, "signature_valid": true, "issued_by_invinoveritas": true, "is_proof_event": true, "decision_ref_recomputes": true}}

valid: true, and the log did not grow.

Same bytes, two verdicts. The only variable was what the caller claimed about himself.

That sentence is the whole design in one line. A verifier that only checks the artefact will pass a forged presenter every time, because the artefact really is valid. The forgery is in the claim wrapped around it.

The part that is recomputable rather than asserted

Every walk wrote its request, its response, the headers and the timestamps to disk, then shasum -a 256 over all of it.

walk 1  04_log_all.json      6ac96b110025fb39a8dbf888e0e47d3467cfde6e79e27a75fcbd289218671f02
walk 2  04_log_all.json      6ac96b110025fb39a8dbf888e0e47d3467cfde6e79e27a75fcbd289218671f02
walk 3  01_log_before.json   6ac96b110025fb39a8dbf888e0e47d3467cfde6e79e27a75fcbd289218671f02
walk 3  05_log_after.json    6ac96b110025fb39a8dbf888e0e47d3467cfde6e79e27a75fcbd289218671f02

Four fetches of the entire log across a forty eight minute window, byte identical. The walks that asserted nothing added nothing, byte for byte, rather than merely leaving the count unchanged.

walk 1  01_ledger_entry.json  f9766ae501da205b7d1b71d29396c06f37bbb6a93c53ec122e87d4f63626e89e
walk 2  01_ledger_entry.json  f9766ae501da205b7d1b71d29396c06f37bbb6a93c53ec122e87d4f63626e89e

Identical input hash, opposite verdicts. "Same bytes, two verdicts" stops being a sentence I wrote and becomes something a stranger can recompute.

Walk 3: check the fix rather than record his word for it

He verified his own alias against entry 180. I ran it against entry 80, which I chose and he did not, using the proof_event key that had failed in walk 0.

valid: True
checks: id_integrity, signature_valid, issued_by_invinoveritas,
        is_proof_event, decision_ref_recomputes  all true
error : none
log count before: 1   after: 1

The alias is real. The stated limit still holds: a caller who asserts nothing still leaves no row.

Putting it somewhere neither of us can edit

The four walks went into a jidec-path-v1 record and were submitted to an open witness intake. Acceptance is mechanical: schema, size, rate, duplicate, signature validity where a signature is present. There is no code path by which the operator declines a schema valid submission, which matters mostly because that operator is me.

The record carries a section listing what it does not prove:

three entries out of two hundred and forty four were touched
the append only claim was read from the operator's statement, not from a code audit
nothing is established about the presenter signature path
one anomaly was observed on 17 August and did not reproduce, and it is recorded anyway, without an explanation

A record that shows only the runs that worked is a brochure. Walk 0 is in there for the same reason.

Then it came back the other way

The next morning he submitted his own walk of the same target, from his own infrastructure. His vantage field reads:

invinoveritas operating infrastructure (not the target's residential/independent network)

He wrote the weakness of his own vantage into the record before anyone asked him for it. In August his measurement contradicted mine and that is how the Cloudflare boundary got found. This time he arrived with the limits of his own position already declared.

And the identity he asserted was eip155:1:0x000000000000000000000000000000000000dEaD. The Ethereum burn address.

We never discussed it. I picked a reserved domain, he picked a burn address, and both of us independently arrived at an identity that cannot belong to anyone by construction. That constraint is nowhere in the schema. It showed up in practice, twice, from two people who did not compare notes.

witness pool     count 2, from two vantages
mismatch log     count 2, both matched false

Two is a small number and I am not going to dress it up. The point is which two.

Lessons

extra="ignore" is not forgiving, it is undebuggable. From outside your process it turns a wrong key into a wrong value. Consider forbid.
Put the recompute recipe in the error body. His error carried published_pubkey and how_to_verify, so a failing call still told me how to check him. He then concluded it should not have errored at all.
An instrument can state its own limit in its own response. One honest_limit line determined the entire shape of this experiment, because it told me exactly which experiment was worth running.
A verification system is a design until someone who did not build it runs it. My pool held exactly one record until that morning, and its author was the person who built the pool. That is not a register, it is a mirror.

An invitation, again

Last time I asked for reports that contradict my own gate. One person took it up, and this article exists because he did.

So the same offer, from the other side: if you operate an MCP server or any API that issues verdicts, assert something false at it on purpose and see whether the record it keeps can be read by a stranger. If the record disagrees with what I have published, submit it. A contradiction from an independent vantage is worth more to me than agreement from my own.

curl -s https://api.babyblueviper.com/verify-proof-log | python3 -m json.tool
curl -s https://ledger.horizonshield.dev/witness/pending | python3 -m json.tool
curl -s https://ledger.horizonshield.dev/witness/344e248da148d5c3d4fe4c74d8ef56552998697d69c3d0a86f4bbfcb2eca6de8

You do not have to believe either of us. That is the entire point.

Toshikatsu Oga, The HORIZONs Co., Ltd. Thirty years a carpenter in Hiratsuka, Japan, now building measurement instead of marketing. ORCID 0009-0000-9180-903X

Two witnesses disagreed about my server. Both were right.

Toshikatsu Oga — Sat, 15 Aug 2026 23:49:22 +0000

On the morning of August 15, 2026, a message arrived from Spain.

"Your MCP server is dead. 522."

My own monitoring showed seven days of green. Every nightly sample said reachable: true. So either someone was lying, or an instrument was broken. That is what you would assume.

Here is the conclusion up front: both reports were correct. And the contradiction between them lit up a boundary that neither side could have found alone. This article is the full account, and the record of what I did with the incident instead of burying it.

Background

I am a carpenter in Hiratsuka, Japan. Thirty years on job sites. These days I also run an MCP server that gives AI agents a third party fair price check for construction estimates, and a verification gate (hs-verify-gate) that measures every endpoint on a public register nightly and publishes the results as they come. My own servers are measured under the same rules.

Witness A: the operator's gate

Invoked by Cloudflare cron, measuring nightly from inside the same Cloudflare account. Real samples from the public history:

2026-08-09T01:18:56.366Z reachable: true record_sha256: d4ff4a21...
2026-08-13T18:00:38.235Z reachable: true record_sha256: 4d204e6a...
2026-08-14T18:00:38.072Z reachable: true (nightly sweep, six endpoints, all reached)

A week of green. Every sample honest, every sample hashed.

Witness B: babyblueviper1

From his own network, plain curl, invoking the gate's public HTTP check. His report:

reachable: false
mcp_endpoint: initialize failed: http 522
agent card fetch: 522

And before trusting any of it, he recomputed the gate's record_sha256 himself: removed the two excluded fields, canonicalised, hashed, confirmed the match, and only then reported. You will not find better manners in a witness.

The operator's reproduction

I reproduced it the same day.

2026-08-14T23:18:50.259Z gate /check to target reachable: false, http 522
same minutes direct initialize to target HTTP 200
2026-08-14T23:22:44.151Z gate /check to second same-zone endpoint identical 522
gate /check to off-zone host reached (405, as expected)

The target was up the whole time. Two commercial liveness monitors and a residential client were receiving 200s from it in the same window. Only the gate's HTTP-invoked checks failed.

The mechanism

Cloudflare Workers has a guard against subrequest loops, and that guard keys on the zone the incoming request arrived on. Three rules, all measured:

HTTP entry (zoned) to same-zone custom domain : blocked, 522
cron entry (no zone) to same-zone custom domain : allowed
any entry to the same worker (self) : blocked

Witness A measured from a context the guard permits. Witness B triggered a context it blocks. Both reported exactly what their vantage showed.

And here is the point: neither could have discovered this boundary alone. The operator's week of green could never surface the guard. The external 522 alone could never locate it. Two honest, conflicting reports had to exist at the same time before the boundary became knowledge.

The fix

Fixed on August 15, 2026, in public.

HTTP-invoked probes to endpoints on my own zone now route through a relay worker outside the zone path, every hop on the public edge. And every verdict since carries three things:

probed_via, disclosing the route that measured it. The vantage is part of the measurement.
reachable: null when the instrument itself fails, so an instrument failure is never recorded as a target failure.
gate_commit, the commit that produced the verdict, included inside the hashed record.

The repair history is public in the repository (commits 2a1dfc91 through 8b0b5fc2). As a consequence of the fix, the gate measured its own endpoint for the first time.

Lessons
A green history only means green from that vantage. Monitoring that hides its vantage misleads honestly.
A single witness can err while reporting honestly. Two conflicting witnesses cannot both be dismissed.
Never record an instrument failure as a target failure. If you could not reach it, the answer is reachable: null.
What I did with the incident

I did not bury it. I inverted it.

The full account became Discrepancy Record 0001, anchored as entry 20 on a public ledger, confirmed at Bitcoin block 962511 (2026-08-15 02:44 UTC). You can verify it right now:

curl -s "https://ledger.horizonshield.dev/ledger/20?format=raw" | shasum -a 256

The hash you get back matches this:

4b58ec1e04ec8a987826dbaa9fd334c0239ab3cd426363695fc853c65d0fd13e

The ledger is called NENRIN, the Japanese word for tree rings. The specification is anchored as entry 19 at Bitcoin block 962507. The mechanism fits in three lines. Anyone can measure my servers from outside and submit the observation to the ledger. The code has no route for me, the operator, to refuse a valid submission. Every record carries a Bitcoin anchored timestamp, so nothing can be painted in afterwards.

The caps are stated, not hidden: 64KB per record, 50 a day, 5 per IP. Invalid signatures are rejected. Unsigned records are accepted and marked unsigned.

A tree adds one ring a year, and nobody can paint one in afterwards. That is why rings prove age. This 522 taught me that trust in a service can only accumulate the same way.

An invitation

If you run monitoring or measurement of any kind: your observations can become permanent, citable records under your own name and vantage. If your report conflicts with what my own gate says, that is the best possible submission. Discrepancies are not an embarrassment here. They are the product.

Witness intake (GET returns a self description): https://ledger.horizonshield.dev/witness
The ledger: https://ledger.horizonshield.dev/ledger
Code and full text: https://github.com/ogasurfproject-jpg/horizon-shield

How I built a tamper-proof AI for construction quotes after 30 years as a carpenter

Toshikatsu Oga — Sun, 10 May 2026 13:33:26 +0000

I'm 49. I learned to code two years ago. Before that, I spent 30 years as a carpenter in Japan.
This is the story of why I built HORIZON SHIELD — and the architectural decision that made it actually useful.

The problem nobody was solving
Japan's residential renovation market is ¥7.35 trillion per year.
Contractors routinely overcharge by 15–20%. The weapon they use is a single Japanese character: 一式 (isshiki) — "lump sum." One line item. No breakdown. Inside that line item, markups of 200–300% are invisible.
After 30 years on job sites, I watched this happen to thousands of families. They had no way to verify whether a quote was fair. Then ChatGPT arrived — and homeowners started asking it for second opinions.
They got different numbers every time.
A contractor will weaponize any inconsistency. "The AI said ¥800,000 last week and ¥1,200,000 this week — which is it?" Game over.

The architectural insight
The problem with using an LLM for cost estimation isn't intelligence. It's determinism.
LLMs are probabilistic by nature. Same input, different output. That's fine for creative writing. It's catastrophic when a contractor is looking for ammunition.
So I separated the concerns completely:
User input (natural language)
↓
LLM layer
(parsing ONLY)
↓
JCCDB v1.2.1
(3,350 line items)
↓
SHA-256 hash
of canonical input
↓
PDF report
The LLM touches zero numbers. It only parses what the user typed into a canonical structured format. All arithmetic happens in a versioned database.
Every report carries a 12-character SHA-256 audit hash. Same input → same hash → same answer, every time. A contractor cannot challenge the number by asking for a rerun.

The War Price Coefficient
Material prices in Japan have been volatile since 2022. A static database goes stale in months.
I added a War Price Coefficient (WPC) — currently ×1.0935 — that adjusts base prices for supply-chain volatility. It's updated monthly using Bank of Japan Corporate Goods Price Index (CGPI) data.
The hash includes the database snapshot version. So when the WPC updates:

Hash changes → price can change (new market conditions)
Hash matches → price is locked (same conditions, same answer)

This is what I called "version-aware idempotency" when I posted about it on HN.

The open dataset
The underlying database — Japan Construction Cost Database (JCCDB) — is open.

3,350+ line items across 7 categories
4 contractor tiers: sole trader (25–35% margin) → major firm (35–45%)
CC-BY 4.0 — free to use, fork, cite
Peer-reviewed preprint on engrXiv (DOI: 10.31224/7007)

The commercial service and the research dataset are intentionally separated. The data is CC-BY 4.0 forever. The API pays rent.
GitHub: ogasurfproject-jpg/japan-construction-cost-database

What I learned building this at 48
Framing a house at 16 was harder than learning to code at 47. Not because coding is easy — but because 30 years of domain knowledge is a massive shortcut.
I didn't need to understand the construction industry. I was the construction industry. I just needed to learn how to encode what I already knew.
The hardest part wasn't the SHA-256 hashing or the Cloudflare Workers architecture. It was deciding what not to put in the LLM.
Every time I was tempted to let the LLM "help" with a calculation, I asked: can a contractor use this inconsistency against a homeowner? If yes, the LLM doesn't touch it.

Try it

Service: shield.the-horizons-innovation.com/index_en.html
Dataset: github.com/ogasurfproject-jpg/japan-construction-cost-database
Paper: engrXiv DOI 10.31224/7007
Pitch deck: shield.the-horizons-innovation.com/pitch.html

Happy to answer questions about the architecture, the dataset, or what it's like to ship your first product at 48.
— Toshi