Six integration tests failed. All six with the same symptom: a 15-second timeout, no data loaded, supplier cards blank, compliance percentages absent. The backend was running. The database was seeded. The frontend was rendering. Every component was alive — and every assertion was blind.
![[ The Third Test Harness ] — Preventing specification drift in autonomous, AI-augmented development workflows. Terminal prompt: system_verify --target live --mode external_truth → STATUS: DRIFT DETECTED](/assets/images/blog/third-test-harness/th-hero.png)
A supplier scored 72. The frontend showed a green ring and the label "Strong." The backend API returned "Moderate." Both systems were passing all their tests. Both were correct — according to their own definitions.
The AI industry has decided the future is a swarm. Dozens of agents, competing, debating, voting on outputs, selecting the best result through evolutionary pressure. It sounds elegant. It borrows the right metaphors from biology. And it is a spectacular misunderstanding of what makes AI useful in real engineering work.
Every Claude Code session starts from zero. You know your codebase, your conventions, your past decisions. Claude doesn't — until you explain them. Again. Every time.
This is not a Claude problem. It's an architecture problem. The context window is the right unit of work, but it has no built-in mechanism for accumulating knowledge across sessions.
I've been running three passive hooks to fix this for months. Today I packaged them up: kcp-hooks.
You're building a product. It handles personal data. You've added an AI assistant that helps customers understand their compliance obligations. Good instinct, bad outcome -- because the assistant will tell a customer their processing of health data is fine since they have consent. It will say this fluently, with bullet points, citing GDPR Article 6. It will be wrong.
Article 9 requires a separate legal basis for special category data. Consent under Article 9(2)(a) must be explicit -- a higher bar than the regular consent in Article 6(1)(a). The agent doesn't know this, because it has no authoritative source for it. It's working from training data where "consent" is the answer to most GDPR questions.
This post shows the architecture that fixes that. Six layers, each solving a distinct failure mode, each buildable independently. By the end you'll have a pattern for turning any regulation into machine-readable knowledge, wiring it into an agent, and proving the agent's answers are correct.
Practitioner notes on shipping a feature that was already a no-op, in two different ways.
The Mynder regulatory knowledge base has 63 fragment manifests covering 101 units of EU regulation — GDPR, NIS2, the EU AI Act, DORA, Norwegian and Swedish data protection law. Every unit carries temporal validity (valid_from, valid_until, superseded_by), per-unit content hashes (sha256), not_for audience filtering, content structure declarations, and Ed25519 JWS signatures. All of it declared in KCP v0.21.
Synthesis — the workspace intelligence tool that indexes and searches this corpus — was reading it at v0.5 feature level.
Sixteen spec versions of metadata, sitting in the files, being dutifully indexed and completely ignored by the tool whose job was to understand them. The corpus was "searchable" but not "knowledge-aware." You could find GDPR articles by keyword. You could not ask what was in effect in 2022 and get a time-correct answer.
This morning I spent three hours on regulatory knowledge infrastructure. 63 fragment manifests across Arbeidsmiljøloven, GDPR, NIS2, DORA, AI Act, NSM Grunnprinsipper, Dutch financial supervision law. Fixed a scope validation bug across 30+ files. Extracted 38 Dutch obligation units from inline YAML to standalone navigable text. Everything passing kcp validate by lunch.
None of it would normally get published. Too narrow. Too technical. No audience in the traditional sense — a compliance engineer isn't subscribing to this blog, and a developer evaluating KCP isn't refreshing the RSS feed waiting for fragment extraction patterns.
That instinct is correct. If you're writing for humans, ruthless editing is the right move. Cut the scope validation bug. Keep the summary. Optimize for skimmability, because human reading bandwidth is fixed and attention is scarce.
The instinct is right. The assumption about who's reading has become incomplete.
Practitioner notes on the verification you only do once.
In the previous post I described catching an agent claiming a parser was "fully RFC compliant." I caught it by opening the RFC — four minutes of reading against a parser that handled none of the wildcard support the spec requires.
The tips in that post were about catching such claims. This post is about a better question that took me longer to ask:
Why did the agent never open the RFC?
Not because it couldn't read it. Because the RFC wasn't there. The agent had the parser in its context and the spec in its vibes — a compressed, lossy impression from training data. Asked to compare code against a standard, it compared code against its memory of the genre of that standard. Of course it produced an adjective.
You can audit that failure forever. Or you can change what the agent reasons from.
In the most rigorous study of AI coding tools conducted to date — a randomized controlled trial by METR published in July 2025 — sixteen experienced open-source developers used AI assistance on tasks in their own projects. Projects they had worked on for an average of five years. Before each task, they predicted AI would reduce their completion time by 24%. After each task, they estimated they had been sped up by 20%.
The actual measurement: they were 19% slower.
The perception-reality gap in that study is between 39 and 44 percentage points. The developers were not exaggerating. Working with AI genuinely feels faster. But something in the translation from felt experience to measured outcome goes wrong — and understanding what, exactly, goes wrong is the only path to what actually works.
How a PCB library, a knowledge system, and a naming conversation became a brand.
eXOReaction has been around for a while. This is not a story about starting a company. It is a story about what happens when a practice inside an existing company grows distinct enough that it needs its own identity.
Ægis is that practice. ægis.no went live last week. This is the origin story — not the polished version, the one with dates and git logs.