What the Framework Missed, and the Browser Found

Part two of two. Part one put one model call into a shipping product, wrapped it in seven layers of harness, and watched the Manifest catch a design defect nothing else would have. This is everything it did not catch, and who did.

F-002: the test double that hid it

The local harness stands in for the model and for the API. Its apply handler checked only that a grant was present:

if (!sent.grant) return send(400, ...)

The real server checked that the grant was valid for exactly these pieces. The double was therefore permissive in precisely the dimension the Authority layer exists to constrain, so the browser test edited a title, pressed apply, and reported success on a path that would have failed in production.

A test double must be strict in the dimension its layer constrains. A double that is permissive about authority tests everything except authority, and does so while looking green.

For each harness layer, ask what the double would have to get wrong for the layer to go untested, and make the double strict there specifically. A double may be simple about behaviour. It may not be lenient about permission.

F-003: the honest accounting

Here is the part most case studies leave out.

The framework caught one. Pressing buttons caught four.

The four browser findings share a property: each one looked like working software. Nothing threw. Nothing logged. Reading the code would not have found them, and three of them produced a plausible wrong answer rather than an error.

The harness governs what the model may do. It does not govern whether the software around it works. Those are different failure classes and they need different instruments.

The framework's contribution was specific and real: it caught the one defect that was about authority rather than about correctness, and it caught it at the one moment (writing a description for an outside reader) when an internal inconsistency becomes visible.

That is a genuine argument for the Manifest layer, and it is stronger for not being overstated.

Why Bedrock, and why not Bedrock Agents

The model runs on Amazon Bedrock in eu-west-1. Not because Bedrock is cheapest (it usually is not) but for three reasons that have nothing to do with tokens.

No new subprocessor. Bedrock is inside the AWS account the product already runs in. Calling a model vendor directly means a new data processing agreement, a new name on the subprocessor list, and a new paragraph in the privacy notice. "No processor outside AWS" is a sentence worth keeping.

"It stays in Europe" is a permission, not a promise. The execution role is granted bedrock:InvokeModel on arn:aws:bedrock:eu-*::foundation-model/* and on European inference profiles only. A global profile may route across continents; IAM refuses it. That is a claim you can demonstrate in a console rather than assert in a contract.

No API key. Authentication is the Lambda's role. There is no secret to store, rotate, or leak.

We do not use Bedrock Agents, Prompt Management, Knowledge Bases, Flows or Guardrails. Those console screens are empty and should stay empty. For one prompt and one JSON answer they would move the Kernel and part of the Guardrails inside AWS (where they stop being testable code) and buy a console screen.

The moment a capability needs multiple steps, real tools, or retrieval over your own documents, that calculation flips, and Agents and Knowledge Bases earn their keep. What does not flip: Authority, Manifest, Receipts and Rollback have no AWS equivalent. Adopting Bedrock Agents does not let you delete the harness. It moves two layers and leaves four, and the four it leaves are the ones that matter most the moment an assistant can act rather than suggest.

The two design rules this release earned

1. The model proposes; the code decides; the person presses.

The planner that chooses when something happens stayed rules: constraint satisfaction is exact and testable, and a model there would be a guess nobody could verify. The model was given the one job rules cannot do: turning a title into named pieces. Drawing that line first is what made the harness small enough to be worth building.

2. What leaves the building is a list, in code, with a test on it.

The prompt builder sends one task title and one number. A test asserts the prompt contains no @, no "booking", no "guest". The same list is in the published manifest. A boundary that exists in two places which are tested against each other is a boundary; one that exists in a policy document is a hope.

What this is not

It is not a compliance claim. We have not completed a conformity assessment, we hold no declaration of conformity, and we have not established whether this feature is high-risk under the EU AI Act. Those are legal conclusions and no engineering document reaches one.

What engineering can do is make every claim you eventually want to make evidenced rather than asserted: the technical documentation is generated from the source on every build, the guardrail evaluation is dated and fails the build if it moves, and the manifest is published where anybody can read it without asking us.

That is a smaller claim than most AI posts make. It is also one we can stand behind line by line.

---

The capability ships switched off. GET /health reports model.enabled: false until somebody deliberately turns it on.