Building this across three AI coding tools

The design work for this system happened in one long session, overnight, across roughly ten planning documents. What came after is arguably the more interesting part: the build was deliberately handed between three different AI coding tools in sequence — each one picking up where the last left off, reading not just code but the previous tool's own written record of what it did and why. All eleven original planning documents are preserved verbatim in the repo, specifically so nothing downstream would be working from a lossy summary of the original thinking.

Codex: the first working version

Codex took the eleven planning documents and a directory scaffold and built the first real implementation: the Go assessment container and the FastAPI carrier-side receiver. Fast, functional, and — like most first passes translating a night of design thinking into code — carrying forward a few assumptions from the planning docs that hadn't been pressure-tested yet.

Claude Code: the bug that would have broken every real submission

The most concrete finding of the whole build came from Claude Code's pass. The carrier-side receiver's strict schema allowlist — the thing that validates every incoming assessment JSON before accepting it — had the hallucination vector spelled "hallucination". The canonical ID used everywhere else in the scoring logic is "hallucination_ood".

That single mismatch meant every real assessment upload containing that vector would have failed schema validation and been rejected with a 422 — and because no tests existed yet for the receiver, nothing would have caught it before it reached a carrier in production. It's a small diff. It's also exactly the kind of bug that survives code review, survives a demo, and only surfaces the first time real data hits it — which, for an insurance data pipeline, is a bad place to find out.

Claude Code fixed the mismatch, added a regression test for it, and added the tests that were missing more broadly: SQLite persistence, the local portal end-to-end path, and — notably — a test that specifically asserts the scores-only export can never leak local evidence, the same boundary described in the architecture piece.

Reading the planning docs skeptically, not just implementing them

The most valuable output of this phase wasn't new code — it was a document, DECISIONS.md, that reads the original planning material skeptically instead of treating it as ground truth, and records exactly where engineering reality corrected the pitch:

• The score-direction bug. The planning docs' "40% technical + 60% governance" blend, applied naively, would make stronger governance raise the reported risk score — because governance maturity is scored high-is-good while risk is scored high-is-bad, and a straight weighted average doesn't know that. Fixed formula: combined = 0.4 × technical_risk + 0.6 × (100 − governance_maturity).
• A second, subtler math error in the governance-multiplier formula: an inline comment claimed maturity 90 produced a multiplier of 0.73, but the formula as written actually produces roughly 0.91 at maturity 30 — not what the comment implied. Caught and corrected before it shipped.
• An execution boundary, corrected. Dynamically downloading connector code onto a participant's device was rejected: a checksum shipped beside a payload does not authenticate its publisher. The beta still requires dynamic telemetry packages because evidence sources are not known in advance. IC Cloud retains and distributes the signed catalog; the participant verifies, explicitly authorizes, and executes the exact package locally. OpenClaw/Open Cloud and other hard-data integrations can fit that model.
• A rejected claim. The planning docs suggested that calls to OpenAI or Anthropic APIs "from the container" could still count as staying local. They can't — anything sent to a remote provider has left the perimeter. The beta connects to IC Cloud, but that requirement does not authorize sending participant documents to an external LLM.
• An overclaim, walked back. "5% risk change triggers automatic premium adjustment" moved from a v1 feature to an explicitly deferred later milestone — see what's next.
• The framing itself, corrected. The original pitch leaned on language like "opaque actuarial scoring." The system's own scoring documentation now opens with the opposite claim on purpose:

This is an evidence intake and deterministic screening implementation, not an actuarial model. Scores do not estimate claim frequency, expected loss, premium, legal compliance, or certification.

What's next

Google Antigravity (Gemini) is the next tool in the handoff chain, working from the same kind of written record Claude Code left for it. What it's picking up — and what's still honestly unfinished — is the subject of the last piece.