Skip to content

Writing

Your AI Agent Does Not Know the Law (and How to Fix That)

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.

Sixteen Versions of Metadata Nobody Read

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.

Sixteen Versions of Metadata Nobody Read: a circuit board blueprint showing KCP v0.21, Temporal Validity, and Ed25519 JWS Signatures as three input connectors feeding into a central processor — but the connection is broken with an X. Diagnostic: the gap between organized data and intelligent infrastructure.

Discoverable Is Not Navigable

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.

Stale Knowledge Is Worse Than No Knowledge: KCP v0.19 and v0.20 Close the Temporal Gap

Closing the Temporal Gap: the problem with timeless knowledge (compliance risk, deprecated-vs-temporal), v0.19's bi-temporal model (valid time vs transaction time, superseded_by link, manifest-level defaults), v0.20's as_of query parameter (audit mode vs production mode, critical use cases), and the new four-step search flow (semantic scoring → not_for filter → temporal evaluation → final selection).

The previous post ended with a list of gaps still visible after v0.18: federated trust delegation, transport integrity, digest cost budgets. The one I left off the list, because it was already in progress, was time.

Not performance. Not latency. Actual calendar time — the question that turns out to matter enormously for knowledge that agents load into context: when is this unit valid?

v0.19 and v0.20 answer that question. v0.19 lets manifest authors declare temporal validity. v0.20 lets agents query against it.

2026 06 12 kcp 0.18 unit integrity

Signing the Map, Not the Territory: KCP v0.18 Adds Unit Content Integrity and Origin Evidence

KCP v0.18 — Signing the Map, Not the Territory: a JWS signature covers the manifest YAML, but not the files the units point to. v0.18 adds per-unit content hashes and origin evidence classes to close the gap.

The previous post showed how KCP v0.16 gives manifests a trust model: cryptographic signing, trust tiers, a render pipeline that fails closed. The signature covers the manifest -- the YAML bytes that describe your knowledge units. It does not cover the files those units point to. The signature says "this map is authentic." It says nothing about the territory.

That gap has a name: T9, the manifest relocation attack. v0.18 closes it.

Down the Rabbit Hole: How a 33-Tool-Call Bug Became a Knowledge Standard

The evolution of KCP: from the 33-tool-call incident and the comprehension gap (January 2026), through Skill-Driven Development and "agents need a map, not just a table of contents" (February), to the KCP stack — knowledge.yaml, kcp-memory, kcp-commands (March) — and the governance and trust layer of v0.10–v0.17 (April–June).

It started with a question no one expected to be hard.

Day seven of the lib-pcb build. January 2026. A single developer, eleven days to produce what the industry does in ten to eighteen months. The AI was generating code at a pace that defied every estimate. Features that should take a week arrived in hours. The skill library -- YAML files encoding project-specific context for Claude Code -- had grown to over forty entries. Everything was working.

And then everything stopped.

"What fields does the DrillHit class have?"

The AI did not know. The class had been written four days earlier. It was central to the entire parsing architecture. It had been discussed in multiple sessions. But the context was gone -- fresh session, blank slate. The AI started searching. Grep for the class name. Read the file. Follow the imports. Check the parent class. Read that file. Check the serializer. Follow another import. Back to grep. Thirty-three tool calls to answer a question that any developer on the project for a week could answer in ten seconds.

Eleven minutes. For one question.

That was the moment something broke open. Not the code -- the assumption underneath it. The assumption that making AI faster at creating code was sufficient. Creation had been accelerated by an order of magnitude. Comprehension had not moved at all.

Beyond RAG: How KCP 0.16--0.17 Give Agents Trustworthy, Self-Describing Knowledge

Overview: KCP v0.16 closes the trust gap with the Trusted Render Pipeline — signing, trust tiers, and sanitization. KCP v0.17 closes the content gap with content structure metadata and subtractive not_for matching. Together they compose a precision retrieval pipeline.

When a compliance agent evaluates a supplier against NIS2 Article 21, it needs two things: the supplier's security documentation to evaluate, and the regulation to evaluate it against. KCP, as described in the previous post, gives the supplier documentation a shape. The evaluation result gets a shape. But the regulation itself -- the specific requirements of Article 21(2), the interpretive guidance from ENISA, the national implementation notes -- lives where it has always lived: as prose in the system prompt.

That worked when agents consumed knowledge from a single, trusted source. It does not work when your agent pulls context from four federated manifests across two organisations, one of which was generated by an automated crawl three weeks ago. The question is no longer "does this knowledge have a shape?" It is: "can I trust this knowledge, and is it even the right content for what I need?"

KCP v0.16 and v0.17 answer those two questions. v0.16 introduces a trust model -- cryptographic signing, trust tiers, a render pipeline that fails closed. v0.17 introduces a content model -- structural metadata that tells you what a unit contains before you fetch it, and subtractive matching that tells you what it is explicitly not about. Together, they close two gaps that have been open since the beginning of the series.

This post walks through both releases. The examples are concrete. The threat model is explicit. If you are building systems where agents ingest knowledge from sources you do not fully control, this is the machinery that makes that safe.

Explorative Development

Practitioner notes on engineering as a sequence of experiments — and on who does what in the loop.

Before we wrote the production code for a recent platform feature, we ran a fictional organization through two years of using it.

Twenty-four simulated months of compliance life: onboarding, supplier churn, audits, incidents, people leaving with their knowledge. The simulation produced fifteen architectural findings — wrong assumptions and missing pieces, discovered while every fix was still cheap and no customer existed yet. Sibling simulations took the total to twenty-five. A design meeting on the same material would have produced opinions.

That run is the clearest recent example of how I've worked for years, and of what I've started calling the approach out loud: explorative development. An idea becomes a hypothesis. The hypothesis becomes the cheapest implementation or simulation that could prove it wrong. The result gets verified. What survives is kept — and what was learned gets encoded, either way.

It is not a new method. It's the scientific method wearing a hoodie. Two things are new: the price list, and the fact that I no longer run the loop alone.