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

DEV Community: Toshikatsu Oga

Two witnesses disagreed about my server. Both were right.

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