The meeting has happened a hundred times this year, in a hundred organisations, with the same shape. The use case is good — genuinely good. The model needs to understand the warehouse, the finance workbooks, the BI estate, maybe the mailbox. Someone has scoped it properly: real value, real sponsor, real budget. Then security review starts asking its one question, and the question needs the model to have access to none of the things it just needed to understand. The meeting ends. The project enters the queue that never drains.

Most programmes only know two moves from here.

Starve it. Keep the model away from anything sensitive. Build the chatbot that answers questions from the public wiki and nothing else. It ships. It's safe. And eighteen months later the verdict lands: "AI can't help with our real work." Safe, useless.

Feed it. Wire the connectors in. Layer on behavioural guardrails. Hope. It's capable — genuinely, visibly capable — right up until the first incident review, or the first honest security audit, at which point the programme dies retroactively, and everyone who approved it explains, after the fact, why they thought it would be fine.

This book exists because there is a reader question underneath both failures, and it deserves a real answer rather than a trade-off:

Starve-or-feed is not a trade-off to optimise more carefully. It's a symptom. Somewhere underneath it sits a constitutional error, and the error has a fix that is neither starving nor feeding.

The consumer anti-pattern, at full scale

You don't have to imagine the failure shape. It's in your pocket. Give a consumer AI app a Gmail connector and watch what actually gets granted.

"On my phone I can give a Gmail connector to an AI app and it goes straight to the raw email — all of it, all the private information. It's a complete shitshow for governance. Try the same thing in a corporate and it would be a disaster."

That's not hyperbole about a hypothetical. It's a literal reading of the vendor's own scope catalogue. Google publishes exact wording for what each OAuth grant actually contains: the full-access mail scope reads "Read, compose, send, and permanently delete all your email from Gmail"; even the read-only variant is "View your email messages and settings" — the whole mailbox, not a folder of it. The Drive scope is blunter still: "See, edit, create, and delete all of your Google Drive files."¹

Read that catalogue looking for the scope you actually want — "the three threads relevant to this task" — and it isn't there. It was never going to be there. The atomic unit of grant is the container. The smallest thing OAuth can hand an agent that needs one class of message is the mailbox that holds it.

This isn't a new observation in our own corpus — it's the same conclusion reached from the blast-radius side, in different words: under a connector model, a compromised agent's reach is the union of container-shaped OAuth scopes, because that's the smallest unit the credential system knows how to issue. Two books, two entry points, the same wall.

Promise versus grant

To be fair to the vendors trying to do this responsibly: Anthropic's own connector documentation is honest about mitigating behaviourally. Claude, on their account, only reads and drafts through a Gmail connector, cannot send, accesses data only on explicit request, and "retrieves the minimum information needed."² That's a genuine, stated policy narrowing — not a strawman to knock down.

But notice what survives the fair reading. The vendor's own help page notes that "Google's OAuth screen mentions email sending permissions" even though the product declines to exercise them.² Policy narrows what gets used. The credential still spans the mailbox. When the behavioural layer holds, you get the polite product. When it doesn't — a jailbreak, an injection, a model update that shifts behaviour by a few percentage points — the blast radius that gets exposed is the grant, not the promise. Behaviour is revocable by an attacker who finds the crack. A credential is revocable only by you, and only after the fact.

Why the behavioural layer cannot hold

There's a reason this isn't a fixable-with-better-prompting problem, and it comes from the UK's own National Cyber Security Centre, in language precise enough to be the load-bearing sentence of this whole chapter:

"An LLM inherently cannot distinguish between an instruction and data provided to help complete the instruction."

NCSC's own architectural advice follows directly from that fact: design so that you are happy with the worst case of whatever the LLM-powered application is permitted to do — because you cannot design so that the worst case never arrives. Any component that reads attacker-authorable text cannot, itself, be the enforcement point for what it's allowed to do next. Asking prompt-level governance to hold the line is asking the defendant to keep custody of the evidence against them.

Security researchers have a name for the resulting shape, and it isn't subtle. Simon Willison calls it the lethal trifecta: private data access, exposure to untrusted content, and a channel to communicate externally. Any agent holding all three is exploitable — not "at risk," exploitable, as a matter of construction.⁴ Under the connector model, that combination isn't a misconfiguration somebody forgot to fix. It's what the agent is, by design, the moment you wire it up the way the demo showed you.

Even the industry's own risk catalogue reads like a confession. OWASP now names LLM06: Excessive Agency as a top risk category, with root causes it spells out plainly: "excessive functionality; excessive permissions; excessive autonomy." Its own mitigations are the tell — minimum-necessary extensions, minimum-necessary permissions, human approval for high-impact actions.⁵ When an industry's own risk register reduces to "grant less, permit less, ask a human," it is telling you, in its own words, that the default architecture it shipped was wrong.

So why does this keep happening at the enterprise scale too?

Because the default architecture makes one component — the probabilistic one, the one you can least predict and least fully inspect — responsible for all three jobs at once: it sees the raw world, it reasons over the raw world, and it acts on the raw world. All the discretion and all the privilege, concentrated in the single branch of the system least equipped to hold either responsibly.

This isn't a new problem in the history of institutions. Political design solved concentration-of-power centuries ago by refusing to let one branch hold every function. Computer security wrote its own version of the same insight fifty years ago, in language we'll return to properly in the next chapter. We didn't forget the doctrine. We suspended it the moment the program became fluent — because fluency read as trustworthiness, and nobody stopped to check whether that reading was earned.

The wall is not standing between you and AI value. It is standing between you and an architecture that never built a second branch.

Where this book goes

The fix is a separation of powers with four actors — a sensor, a model, a human, a compiler — where discretion and privilege move in opposite directions around the model instead of concentrating in it. Chapter 2 states that constitution in full, once, as the reveal the rest of the book builds from.

Part II then builds the inbound half of the system, organ by organ: what the sensor actually is and why it functions as the model's retina (Chapter 3); who writes it, and why letting AI author it makes the whole thing more governable, not less (Chapter 4); the manifest that lets a third party certify exactly what it can do (Chapter 5); the contract that governs what may ever cross into the model's view (Chapter 6); the specific trap in "metadata is safe" (Chapter 7); the difference between evidence and permission (Chapter 8); where the Model Context Protocol actually belongs in this stack (Chapter 9); and the assembled two-airlock system that results (Chapter 10).

Part III is the proof: one production sensor, walked end to end, tested blind so it can't fake a good result. Part IV turns the same tools on the book's own claims — a red team against our own packet — and closes with the build method for a reader who has to ship one.

Here is the claim this chapter defends in full, not as provocation but as design rule: the more capable and less predictable a component is, the narrower its access should be. The more constrained and inspectable a component is, the broader its access can safely be. That is the opposite of how most organisations wire an AI system together, and the gap between the two is the whole reason the wall in Chapter 1 exists.

"The deterministic sensor can see more but decide less. The AI can reason more but see less. The human can authorise because they own the consequence."

Say it shorter, and it becomes the rule you can actually apply when someone asks "should the model have access to X": discretion and privilege should move in opposite directions.

The table that runs the whole book

Everything from here forward — the sensor, the manifest, the contract, the metadata bands, the airlocks — is a working-out of one table. Read it once, carefully, because later chapters point back to it rather than re-explaining it.

Read it by column, and the inversion is right there: as you move down the "capability" axis toward the human, seeing narrows while mutating opens up; as you move toward the sensor, seeing widens while mutating closes down completely. Read it by row and a second property appears, quieter but just as load-bearing: no single actor both sees the raw world and changes it unilaterally. That absence isn't an accident of the layout. It's the entire design. It's what makes the system auditable instead of merely monitored, because there is never a component you have to simply trust with both halves at once.

Put those four rows together and you get a four-line creed — stated once here, in full, returning verbatim at the very end of this book:

Four actors, four verbs. Sensor: sees, never mutates. Model: interprets, never has authority. Human: decides, and is accountable for the decision. Compiler: executes exactly what was approved, with zero discretion of its own. Everything downstream in this book is one of these four actors getting its chapter.

This is not a new idea. It's an old one we stopped applying.

We didn't invent this table. We inherited it, and then quietly suspended it the moment the reasoning component in the middle got fluent enough to feel trustworthy. Computer security worked out the shape of this problem fifty years ago, and its founding text reads like it was written with this exact system in mind.

Saltzer and Schroeder, 1975, three principles, verbatim:

NIST's own current definition of least privilege says the same thing in modern regulatory language: a security architecture designed "so that each entity is granted the minimum system resources and authorizations that the entity needs to perform its function."⁷

None of this is new doctrine dressed up for AI. It's fifty-year-old security architecture, applied to a genuinely new kind of untrustworthy component: not a rogue program, but a probabilistic reasoner whose value comes precisely from the breadth of what it can understand. The mistake wasn't ignorance of the principle. It was assuming that because the model talks fluently about the business, it had somehow already earned the access the principle says it shouldn't get.

The deterministic code can do the thing that AI is not allowed to do — it becomes the sensor for the AI.

That line does the work of the whole top-left cell of the table in one breath. Wherever a task needs broad, privileged access to raw reality, and the reasoning about that reality needs to stay probabilistic and flexible, you split the job: a narrow, deterministic, inspectable component holds the access; a broad, flexible, uninspectable component reasons over what that access produces, never over the raw thing itself.

Why clients accept the code but never the model

There's a trust asymmetry here that's worth sitting with, because it's the seed of an idea this book returns to properly in Chapter 5:

"They don't want AI logging into their data warehouse and going berserk. But if you've written a Python audit function, they'd be happy with that. You could even hand the code to a third-party auditor to confirm it has no chance of changing anything."

Notice what's actually being trusted in the second half of that sentence. Not the intelligence that wrote the function — the artefact the intelligence produced, which can be read, tested, and certified by someone who owes the client nothing. Hold onto that seed. A whole chapter grows from it.

The third constitutional actor nobody else names

This book doesn't sit alone in our corpus, and it's worth being precise about where the boundary falls, so nothing gets re-argued that's already settled elsewhere. Our own Two Leashes framework names the model as a hypothesis engine sitting between two other systems: "It proposes. It does not own the world, and it does not own the gate." Wiki above the model, grounding what it believes. Authority below the model, gating what it can do. That's a complete and correct picture of two of the four boundaries in the table above — the AI+wiki row's interpretive ceiling, and the compiler row's authority floor.

What it doesn't name is who builds the world the wiki above the model is compiled from in the first place. That's the sensor — the top row of the table — and it's the actor this book exists to develop. Two Leashes presupposes a governed world already exists to ground the model in. This book is about how that world gets manufactured safely from privileged, ungoverned reality in the first place.

Our SiloOS framework is worth one clarifying sentence too, because the two ideas are easy to conflate. SiloOS contains the agent — tokenised data, scoped keys, a proxy that hydrates real values only at the moment of execution. This book constitutes the world the agent inhabits by construction — a step earlier and, in a sense, a stronger move: containment limits what a contained agent can reach; constitution decides what reality the agent is ever shown to begin with. The two are complementary, not competing, and Chapter 8 returns to SiloOS's own mechanism directly, because one of its patterns generalises further than its authors first intended.

Start by correcting the picture most people carry into this conversation. A sensor, in this book's vocabulary, is not a filter that sits downstream of "real" data access, quietly deleting the parts a privacy officer would object to. It is the component that manufactures the world the model is allowed to perceive in the first place. Everything the model will ever reason about, in this architecture, passes through it first. Nothing arrives any other way.

That reframing matters because Chapter 1's diagnosis depends on it: the wall exists because the default architecture never built this component at all. It wired the model straight to reality and hoped policy would hold the line. There was no retina between the eye and the world — just the world, unmediated, and a set of instructions asking the model to look away from the parts it shouldn't see.

The stack, in one diagram

Walk the arrows once. Privileged reality — the warehouse, the workbook archive, the BI estate — enters the sensor first. The sensor emits a bounded semantic projection, never the reality itself. The model reasons over that projection, and only that projection. The human reviews the resulting evidence and disposes of it. The compiler enacts only what was explicitly approved. This is Chapter 2's table, in motion instead of structure — the same four actors, now shown as a pipeline reality actually has to flow through.

Borrowing the right idea from the wrong regime

Our own Agent's Retina work already did the hard theoretical labour of describing how an agent perceives anything at machine scale, and it's worth quoting directly, because the framing is exactly right even though its territory is not this book's:

"An agent does not 'look at' a thirteen-gigabyte database. It engineers a view — and that craft is the hidden core of agent capability."

That book's chain — world → probe → representation → context → cognition — is the right theory of perception, at runtime. But its own opening chapter names its territory precisely, and disclaims exactly what this book owns: "how does an agent make reality legible at runtime, and how do you instruct it to look?" That's a book about an agent, already inside access it's been granted, forging a temporary probe for one question and discarding it when the question's answered.

This book's sensor is a different creature entirely, and the difference is the whole trust regime, not a matter of degree. It is compile-time, reviewed, and versioned — built once, audited once, deployed as a fixed artefact — and it holds credentials the model must never hold at all. That's exactly why it cannot be improvised the way a Retina-style probe can be improvised: improvisation and privilege don't mix. The moment a component needs to hold a credential to a genuinely privileged system, forging its access on the fly, in the moment, is precisely the move this constitution forbids. Runtime perceptual improvisation happens inside access already granted. This book's compile-time sensor is how privileged access ever becomes safely reachable to begin with — the step that has to happen before a Retina-style agent could ever be let loose on the resulting view.

Three jobs, one transform

Here is the synthesis the rest of Part II builds from:

"Security: remove what the model must not see. Perception: preserve what the model needs to understand. Compression: make the resulting world small enough to reason over."

The naive reading treats these as three competing goals you have to trade off against each other — more security for less perception, more compression for less texture. They aren't three goals. They are the same transform, done once, correctly. Raw business data is simultaneously sensitive and cognitively terrible — undifferentiated rows, no declared structure, no provenance, nothing telling you what any of it means. Stripping the sensitive values while adding semantic structure — the shape of a relationship, not its contents; the name of a rule, not the number it computes — is one operation that raises safety and raises density at exactly the same moment.

That's the equation this book keeps insisting on, and it runs directly against the industry's working assumption that "more access" is the only lever that makes AI "smarter." It isn't. Less raw data, plus more semantic structure, plus provenance, plus lower noise, equals safer and more capable — and the sensor is the place that equation gets engineered, not merely asserted from a stage.

That line is the counter-intuitive spine the rest of this book spends its time defending. It's also, in its first form, something closer to a hunch than a doctrine — and it's worth being honest about that, because the hunch's own correction is the subject of an entire later chapter:

"Perhaps metadata is the general case that's safer for AI to read — so I was extracting more metadata-type items from the warehouse and the workbooks."

Right instinct, wrong stopping point — and Chapter 7 walks the correction all the way through, on the vendor's own documentation. For now, hold the discovery and move past it.

The world rebuilt for AI to flex its muscles in

Two ideas anchor what the sensor is actually for, and they belong together because they're the same move seen from two directions:

"Text is the native language for AI. We did for workbooks what we'd done for images and web pages: turned them into a text-only format of the bits that were interesting."

And then, the emotional centre of this whole chapter:

"To some extent it's making the AI safe. To some extent the deterministic code rebuilt a world for the AI to flex its muscles in."

That second line is worth sitting with for a moment, because it's easy to read this whole doctrine as a security posture wearing a capability alibi. It isn't. The sensor isn't a cage. It's a purpose-built gymnasium — a world engineered so that the thing reasoning inside it can actually go as hard as it's capable of going, precisely because the walls are load-bearing and nobody has to worry about what happens if it pushes against them.

Neither blinded nor starved

One more discipline belongs here, in one paragraph, because it recurs throughout the rest of the book without being re-taught: the packet a sensor emits has to sit between two failure modes on the same axis. Too much world blinds — a hundred-thousand-line dump erases the pattern a human would have spotted instantly. Too little world starves — a lone count has no semantic texture to reason with at all. Our own Retina work names this the resolution axis, and its own diagnostic line applies just as much to a compiled packet as to a live probe: "Not too broad. Not too narrow. Not too verbose. Not too lossy. That is a cognition problem." A sensor designer owns this axis for the packet the same way a runtime forger owns it for a live query — the tuning loop itself belongs to that book, not this one; here it's enough to know the axis exists and that every chapter ahead assumes it.

Every security lead who looks closely at a sensor like the one this book is building eventually asks the same question, and it deserves a direct answer instead of a dodge: "Who is writing this? Nobody on my team can read the Excel binary format well enough to know if this extractor is safe." The honest answer is that AI wrote it. That's not a gap in the architecture. It is the architecture.

Five forms of AI, one system

The table that resolves the apparent contradiction is worth setting out in full, because it's the definitive placement for the rest of this chapter and the next:

Read this against Chapter 2's four-actor table and one thing stands out: it's the same four actors, plus a fifth — design-time AI — sitting entirely outside the runtime system. It never touches production data. It never runs against a live warehouse. It only ever produces the artefact that later runs inside the boundary, under review, as code.

The phase change

Here's the mechanism, stated as a sequence:

"The deployed result no longer improvises. It repeats a reviewed observation policy."

"There's AI in a live form, interpreting the wiki and making judgments — and there's a solidified version of AI in the deterministic code."

State the qualification carefully, because it's the whole safety argument in one sentence: the deployed sensor is not intelligent at runtime. It is prior intelligence crystallised — the design-time reasoning happened once, under review, and what ships afterwards is its residue, not a live mind that could be argued with, tricked, or drift mid-task. This exact phase change is stated once already, one level up in our own corpus, as a single stage inside a larger commercial pipeline; this book takes that one stage and builds an entire constitution around it.

Why the phase change changes which governance regime you're in

This is where the mechanism earns its commercial teeth, and the source material states it with a precision worth quoting at length. Picture a compliance officer facing two requests in the same quarter.

Same officer, same quarter, same underlying AI capability. The only variable is where the AI's output lands. That's the mechanism named as governance arbitrage: "regulated organisations have already solved governance for code. They haven't solved governance for live AI decision-making. The insight that changes everything: route AI value through the code path."

Restated in the source's own terms: AI at runtime is a "live decision-maker," its outputs "non-deterministic and unrepeatable," and it "needs governance invented from scratch." AI at design-time produces "code, configs, tests, docs" that are "inspectable, diffable, reviewable" and route through "existing SDLC governance." Land the line the whole chapter earns:

"The model can be clever; the organisation can remain conservative."

The formula, and the four constraints that keep it honest

The mechanism has a name and a formula: Organisational Context × Domain Priors × Code Synthesis = Reviewable, Testable, Versionable Artifacts. Translated into this book's own terms: organisational context is the target format's real structure — a client's actual workbooks, not a generic spec sheet; domain priors are the OOXML and spreadsheet-archaeology knowledge no engineer economically holds cold; code synthesis is the extractor itself, plus its tests, plus its declared schema.

The formula only holds under four constraints, and they are conjunctive — violate any one and the whole arbitrage collapses:

Where this book extends the argument, and where it stops

It's worth being honest about the boundary here, because the source material argued something adjacent but distinct: it made the case for productivity and governance-speed — get IT AI approved in weeks instead of quarters. This book takes the identical mechanism and turns it into a privilege argument instead: AI-authored deterministic code is precisely what makes AI safe in privileged environments, because review institutions attach to artefacts, not to intelligence. Fast approval and safe access turn out to be the same lever, pulled for different reasons — which is a genuinely useful thing to notice, because it means the commercial case and the safety case for this pattern are not in tension. They're the same case.

The loop, abstractly

One clean loop is worth sketching now, at doctrine level, before the specimen walks it concretely in Chapter 11: a model investigates the target format, writes the extractor plus its tests, a human or security reviewer inspects the result, the artefact gets versioned and hashed, and it deploys. Where the extractor misses something, the loop returns to step one — never to a quiet loosening of production access to compensate.

Read-only proves exactly one thing: the sensor can't write. It proves nothing about the list of harms a genuinely privileged extractor can still cause — expensive queries that hammer a production system, output that's technically read-only but far too wide in scope, sensitive values leaking into a debug log nobody thought to scrub, a network egress path nobody closed, or an inference the extractor never intended to enable but nonetheless does. "It's read-only" is necessary. It is nowhere near sufficient, and the gap between the two is this chapter's whole subject.

The manifest

Here is the complete artefact — every line earns its place, and every absent line is a harm the previous paragraph just named:

Name the move precisely, because it's the actual product this chapter is describing, not the code itself: this converts an unanswerable trust question — "what might the model do with this access?" — into an answerable engineering question — "what can this exact artefact emit?" A security review board cannot certify a model's judgement. No amount of red-teaming a live conversation produces a signature anyone can stand behind next quarter. It can certify a manifest, because a manifest is a claim about a fixed, hashed, tested artefact — the same kind of claim it already certifies about every other piece of production software.

Which brings the trust asymmetry from Chapter 2 back around, now with something concrete to hand over:

"They don't want AI logging into their data warehouse and going berserk. But if you've written a Python audit function, they'd be happy with that. You could even hand the code to a third-party auditor to confirm it has no chance of changing anything."

The manifest is what turns that hand-off from a nice idea into a literal, sign-off-able document. The auditor signs the manifest. Not a promise about the model's good behaviour — a claim about exactly what one hashed artefact can and cannot do.

A vendor already ships this shape

It's worth being explicit here that this next section crosses into case material earlier than the rest of Part II — deliberately, because this is vendor documentation functioning as precedent, not this book's own specimen. The specimen proper arrives in Chapter 11.

Microsoft's own Fabric governance tooling already ships a Proof-Carrying-Sensor-shaped surface for its own estate, and it's worth reading the vendor's own words closely:

"Metadata scanning facilitates governance of your organization's Microsoft Fabric data… using a set of Admin REST APIs that are collectively known as the scanner APIs."

"With the scanner APIs, you can extract information such as item name, owner, sensitivity label, applied tags and endorsement status. For Power BI semantic models, you can also extract the metadata of some of the objects they contain, such as table and column names, measures, DAX expressions, mashup queries."

The access posture is exactly as tightly bounded as this book's own manifest asks for: "the user must be a Fabric administrator or authenticate using a service principal"; "maximum 500 requests per hour, maximum 16 simultaneous requests."⁹ And Microsoft graduates the escalation from structure to business logic in two explicit, dependent steps — one tenant setting enables "low-level semantic model metadata… for tables, columns, and measures"; a second, which can only be enabled if the first already is, "allows the API response to include DAX expressions and Mashup queries."¹⁰

Microsoft never called this a Proof-Carrying Sensor. But it ships the same shape, for its own estate, because the industry's largest data-platform vendor already discovered — independently — that this is what a governed deterministic sensing surface has to look like. The manifest this chapter describes generalises and hardens a pattern already running in production, at scale, today.

The reusable trust object

Once a sensor version is certified, it doesn't need re-certifying from scratch for every new engagement. Trust accumulates the way it accumulates for audited open-source libraries, not the way it accumulates for individual promises — the manifest, the hash, and the receipts travel with the artefact, under different client-local credentials each time it's deployed.

Run receipts — the manifest's last line — are what make every single observation attributable to an exact version: which sensor, against what source, emitting what schema, at what time. That turns "the extractor probably behaved" into an evidentiary record a security review, or an incident post-mortem eighteen months later, can actually use.

Redaction is subtractive: given a document, what do we take out? Declassification is declarative: given a purpose, what world should the model be permitted to inhabit while it serves that purpose, and no other? The distinction sounds academic until you notice what it implies: nothing is "AI-safe" in the abstract. Safe for which principal, for which purpose, to answer which class of question — safety is always a relation, never a property some piece of data simply carries on its own.

Ten dimensions, worked in full

This is the chapter's spine, and each dimension earns its own question, not a bare list entry:

The reframe this table buys is worth naming directly: "declassification" stops being an adjective loosely applied to a dataset, and becomes a schema a reviewer can actually check, row by row, the same way they'd check a database migration.

Three bands, not one blocklist

The rule the bands exist to enforce: the packet must be explicitly allowlisted, never produced by "remove the obviously sensitive things." Allowlists fail closed. Blocklists fail open — they only ever stop the categories someone thought to name in advance.

Why the model can't judge its own boundary

The argument for allowlisting isn't taste — it follows directly from a fact this book already established in Chapter 1:

"An LLM inherently cannot distinguish between an instruction and data provided to help complete the instruction."

The consequence is specific to this chapter: a component that cannot tell instruction from data cannot be trusted to decide, mid-task, what it should never have seen in the first place. When the boundary exists to guard exactly that component, failing closed — an explicit allowlist — is the only defensible default. Call it the defendant/judge line: you do not let the defendant rule on the admissibility of the evidence against them.

Edges are in scope, not just values

A claims-and-edges graph can disclose what no single value ever would. An unnamed executive, cross-referenced against a redundancy programme, cross-referenced against an acquisition date, can identify a specific person without a single name field ever crossing the boundary. That's exactly why relationships gets its own dimension in the table above, rather than being folded quietly into "values" as an afterthought.

Our own BI for Soft Data work already states the corresponding access rule, and it's worth citing directly rather than re-deriving it: "the map must inherit source ACLs" — access classes travel with edges the same way they travel with values. If a bookkeeper's assistant can't open the salaries folder, the compiled view can't let it ask about salaries either. Chapter 13 attacks this exact leak channel properly; here it's enough to know why relationships earned a dimension of their own.

"Get rid of the governance nonsense" — only ever quoted with its correction

"Transform the data into text, strip out the private data it doesn't need, reshape it into what's useful — and then turn the AI up to 11."

That line, on its own, sounds like an argument for deregulation. It isn't, and it never ships without the correction that keeps it honest:

"Do not remove governance. Remove governance from the model's discretion."

Name exactly where the governance went, because you can point at every piece of it: the three allowlist bands, the declared output schema, ACL inheritance from source systems, the identity and value policies on each of the ten dimensions, the drill-down gate, the provenance requirement, the run receipt. Once you can point at where each piece landed, "get rid of the governance nonsense" stops sounding reckless and starts sounding like exactly what it is — a relocation.

And it's why the whole system stops feeling like a committee sitting in on every prompt: the governance decisions get made once, at contract-authoring time, the same way a database schema gets decided once instead of re-argued at every query.

Chapter 3 planted a discovery and deliberately left it unresolved: "Perhaps metadata is the general case that's safer for AI to read — so I was extracting more metadata-type items from the warehouse and the workbooks." That instinct is right as a default. It is dangerously wrong as a guarantee, and this whole chapter is the anatomy of the difference — the correction that has to travel with the discovery, every time it's invoked.

Why metadata-first is right, as a default

Structure, topology and relationships genuinely are the lower-risk candidate representation — and usually the higher-density cognitive one too. That's Chapter 3's security/perception/compression synthesis paying its dividend precisely here: metadata is where that transform's benefit is highest. Even the industry's own governance tooling defaults to metadata shape — Microsoft's Fabric scanner, walked in Chapter 5, returns "item name, owner, sensitivity label" and table/column names as its baseline extraction. Structure, not values. That's not a coincidence; it's the same instinct, independently arrived at.

Why metadata-safe is wrong, on the vendor's own words

Here's where the correction earns its weight, straight from Microsoft's own Document Inspector documentation — the tool built to find exactly what a workbook is carrying that its author never intended to disclose:

"Hidden names that might store hidden data in the workbook."

"Cached data for PivotTables, PivotCharts, slicers, timelines, and Cube formulas that might not be visible."

The same page's Excel table also names hidden rows, hidden columns that contain data, hidden worksheets, document properties including the author's user name, links to other workbooks and inactive external connections, macros and VBA and user-defined functions, and custom XML data that might be stored inside the file. Several of these categories are payloads wearing metadata's name. A cached PivotTable fragment isn't "structure about the data" — it is data, sitting one inspection category away from where a well-meaning extractor would stop looking.

Microsoft's own caution on the same page is, if anything, the strongest first-party statement available that metadata is not a safe harbour: "We highly recommend that you use the Document Inspector on a copy of your original workbook, because it is not always possible to restore the data that the Document Inspector removes."¹² A vendor doesn't warn you a removal might be irreversible unless the thing it's removing is a genuine payload.

Schema discloses too

Work through it concretely. A column named Salary sitting next to a column named Employee discloses the shape of a sensitive relationship with every single cell blank — the schema alone tells you what question the workbook was built to answer. Formulas and DAX expressions encode business rules — margin calculations, discount logic, risk thresholds — as structure, not values. Lineage metadata names source systems. Owner and path fields identify people and internal infrastructure by themselves, with no value field required. None of this is "data" in the naive sense the metadata-first heuristic assumes is safe. It's metadata that happens to encode exactly what values would have encoded, one level of abstraction up.

The regulatory closure

Australia's own privacy regulator states the rule that makes all of the above non-optional to address:

"Some information may not be personal information when considered on its own. However, when combined with other information held by (or accessible to) an entity, it may become 'personal information'."

The OAIC adds a second clause worth sitting with: "information holdings can therefore be dynamic, and the character of information can change over time."¹³ The factors that determine identifiability, in the regulator's own language, include "the nature and amount of information," "who will hold and have access to the information," and "the other information that is available, and the practicability of using that information to identify an individual."¹³

Read that as this book needs it read: the test is about the combination available to the holder — and the holder, now, includes whatever a model can derive from the packet you handed it. A field that's innocuous alone is not innocuous once it sits beside everything else the model has been shown. "We only extracted metadata" is not, by itself, a compliance answer — it's the beginning of a question the regulator is explicitly asking you to keep asking.

Graduated disclosure, generalised

The conditional band from Chapter 6 has a working model already: Microsoft's own two dependent tenant switches, from Chapter 5 — structure first ("low-level semantic model metadata… for tables, columns, and measures"), expressions only as a second, explicitly separate escalation ("DAX expressions and Mashup queries"). The vendor treats "what the columns are called" and "what the formulas actually compute" as two different consent decisions, not one blanket switch. The generalisable pattern: admit structure by default; admit anything that encodes business logic — formulas, DAX, lineage, owners — only under a declared, purpose-scoped escalation. That's the conditional band's job, stated as a working precedent rather than a hypothesis.

The rule, restated for the contract

Metadata enters the packet through the same three bands as everything else. It's where the sensor starts its allowlisting work — never what it waives review to skip.

Here's the trap, stated directly: the packet cites bronze evidence — a pointer to an original cell, document, or record, kept precisely so a human can verify a claim later. May the model follow that pointer and read the source directly, since it's "just evidence, and evidence is supposed to be reachable"?

No. The rest of this chapter is why that's not pedantry.

Bronze answers "what evidence exists — can an auditor eventually reach it?" It never answers "what may the model read, right now, in this task?" A pointer is addressability, not permission. Conflating the two turns the evidence store — kept for exactly the opposite reason — into a back door the model can walk through whenever the packet happens to reference it.

The second half of the rule is this chapter's operating principle, and it reappears everywhere this book touches "what if the model needs more":

"The AI can decide what it needs to know, but an approved deterministic sensor decides how the raw system may answer."

Agency over the question, not the credential

Work the pattern concretely. The model's legitimate request looks like a question — "do these three measures depend on an undocumented source?" — never a credential request. That question routes to an approved sensor, a named function such as inspect_measure_lineage, which returns a bounded packet: source types, relationship paths, expression fingerprints, masked endpoints, evidence IDs, and known absences. No arbitrary SQL, ever, at any point in the exchange. No warehouse password. No unrestricted protocol access granted just because the question sounded reasonable.

The reframe: the model's agency is over what it wants to know. The sensor's agency is over how the underlying system is ever allowed to answer. Those are two different kinds of authority, and this chapter's entire argument is that they must never collapse into one.

It's worth being precise about why this feels unsatisfying the first time you hear it, because the objection is a good one and deserves a real answer rather than a dismissal. A model that wants to investigate an anomaly — a measure that doesn't reconcile, a lineage path that dead-ends somewhere unexpected — genuinely does better work the more it can poke at the underlying system. Cutting that off at "ask a named function" feels like cutting off exactly the exploratory reasoning that makes the model valuable in the first place. The answer isn't that exploration doesn't matter. It's that exploration belongs to a different actor entirely: the design-time AI from Chapter 4, which can investigate as broadly as it likes against a development copy, and whose findings then become a new approved sensor function through the missing-view protocol below. Runtime exploration against production is where this book draws its hardest line, and it draws it precisely because runtime is where the credential lives.

A pattern that generalises further than its own authors intended

Our own SiloOS framework already solved a version of exactly this problem for identity values, and it's worth quoting the mechanism directly, because it generalises much further than its original scope:

"The agent doesn't need to see the data. It needs to know if the data matches. That's a fundamentally different request."

SiloOS's worked example is a phone-number validation: the agent sends two tokens, the proxy compares the real values internally, and the agent gets back a boolean — { "match": true } — "without ever seeing actual phone numbers." The design principle behind it, in the source's own words: "Nothing in the agent operating system ever sees real data, or real privacy data. It might see balance and chat history, but it won't see customer name, address, phone number, email address."

SiloOS applies this move to identity values inside one operating system. This book applies the identical move to entire worlds — warehouses, BI estates, workbook archives — treating "does this exist," "does this match," and "what shape is this" as the class of question a privileged estate may always answer, and "show me the row" as the class it must never answer directly. Same principle, one level up.

The missing-view protocol

Sometimes the sensing surface genuinely doesn't cover the question a task needs answered. Here's how the surface is allowed to grow — and how it isn't:

The property this protects: the sensing surface expands like case law — each new capability is argued, reviewed, and precedent-setting — never like shadow IT, where a runtime workaround quietly hardens into a permanent, unreviewed access path. Runtime authority never grows silently. Only the reviewed sensor library grows, and only through the front door Chapter 4 already described.

Draw the contrast once, then drop it, because the boundary is unambiguous: an agent forging its own SQL against production in the moment — because the sensing surface didn't cover the question — belongs to a different trust regime entirely, the one Chapter 3 assigned to runtime perceptual improvisation. Inside a privileged estate, improvisation against production is exactly what this constitution forbids.

Notice what the protocol buys beyond safety, too, because it's easy to read all of this as pure cost. A sensor added through the missing-view protocol comes with tests, a manifest, and a review record attached from the moment it exists — which means every expansion of what the system can see is, for free, an expansion of what it can explain to an auditor eighteen months later. Compare that with the alternative: a runtime workaround that quietly became load-bearing, that nobody remembers approving, that shows up in an incident review as "we're not sure why the agent could reach that." The reviewed path is slower on the day you need the new capability. It's the only path that's still legible a year later.

Here's a joke that turns out to be a correct architectural decision:

"It's funny what I used MCP for in this project: I gave it to Python. It's meant for agent access — I turned it into deterministic code."

One sentence of that provocation is enough; the rest of this chapter explains why the placement is correct, not comic, and Chapter 12 walks the actual instance end to end. For now: why "model-facing MCP against business data" is a real failure, without MCP itself being the thing at fault.

What the protocol actually standardises

Anthropic's own announcement calls MCP "a universal, open standard for connecting AI systems with data sources, replacing fragmented integrations with a single protocol."¹⁴ The spec itself is precise about its own scope: "Model Context Protocol (MCP) is an open protocol that enables seamless integration between LLM applications and external data sources and tools," standardising hosts, clients, and servers over JSON-RPC 2.0.¹⁵

What it explicitly disclaims is just as important, and it's in the spec's own words: "While MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD: 1. Build robust consent and authorization flows into their applications… 2. Provide clear documentation of security implications… 3. Implement appropriate access controls and data protections."¹⁵

Representation, necessity, semantic grain, inference limits, caller authority, what may be admitted to model memory — none of it is the spec's job, by its own admission. That's the implementor's responsibility, and this book's sensor is exactly that job, done properly.

This is worth dwelling on, because it's easy to mistake "MCP is widely adopted" for "MCP has been vetted for this purpose." It hasn't, and it says so about itself. A protocol that standardises how a client and a server exchange JSON-RPC messages has made no claim whatsoever about whether the server should be allowed to hand over a customer's salary column. That question sits one layer up, in whatever code decides what the server is permitted to expose in the first place — and if nobody wrote that code deliberately, the server just exposes whatever it was pointed at, standard-compliant and ungoverned at the same time.

The protocol's own security catalogue

The spec's own security-best-practices page reads like a catalogue of what happens when the plug gets mistaken for the safety layer. Token passthrough is "explicitly forbidden in the authorization specification" because "a malicious actor in possession of a stolen token can use the server as a proxy for data exfiltration."¹⁶ Broad scopes create "expanded blast radius: stolen broad token enables unrelated tool/resource access."¹⁶ Proxy misuse creates "confused deputy vulnerabilities," letting "malicious clients… obtain authorization codes without proper user consent."¹⁶

The point this catalogue proves isn't that the protocol is broken. It's the opposite: the protocol's own maintainers have written down, in detail, exactly what happens when someone treats the plug as the safety mechanism — which is the strongest possible evidence that safety was never the protocol's job to begin with.

"MCP standardised the plug, not the content."

That's the distinction the industry keeps reaching past. It defaults to the first noun when what it actually needs is the second.

Four placements, and where MCP is strong

Two motives, one architecture

Here's the convergence that makes this placement robust rather than merely principled. Anthropic's own engineering team reaches the identical architecture — code between the model and the MCP servers — for reasons that have nothing to do with governance:

"Once too many servers are connected, tool definitions and results can consume excessive tokens… a solution is to present MCP servers as code APIs rather than direct tool calls."

"Intermediate results stay in the execution environment by default. This way, the agent only sees what you explicitly log or return."¹⁷ And the published headline figure for this pattern, from our own corpus's treatment of the same architecture: a 98.7% token reduction from routing MCP through code rather than direct tool calls.

Anthropic and Cloudflare reach this shape for tokens and latency. This book reaches it for governance. Same architecture, two entirely different motivating economics — which is exactly why the placement is robust rather than fragile: it wins on efficiency and on safety, not on safety alone at a performance cost someone will eventually try to optimise away.

Where MCP direct-to-model is genuinely fine

The correction stays sympathetic rather than absolutist, because there's a real, bounded set of cases where the direct pattern is exactly right: "MCP Playwright is awesome" for browser automation and testing, where the tool count stays under 20 and "formal schemas enforce consistent test patterns"; bounded sub-agent orchestration, where each sub-agent "uses <20 MCP tools, writes findings to a MD file… like a subroutine"; and enterprise multi-vendor governance registries, where "governance/compliance requires formal tool registry" and the token cost is accepted deliberately in exchange for auditability. None of these place MCP against a privileged estate's raw data. They place it against small, stable, already-safe toolsets — and that's the difference that actually matters.

"MCP should usually sit below the sensor, not be mistaken for the sensor."

One more way to state the same rule, because it's the sentence a reader can actually carry into a vendor conversation: ask not "does this MCP server support authentication" but "what decided the schema this server is allowed to return, and who reviewed that decision?" If the honest answer is "whatever the underlying API happened to expose," the server is a raw connector wearing a modern protocol, and the placement table above says exactly where that belongs — nowhere near a general model with access to anything you'd mind losing.

Everything Chapters 3 through 9 built — the sensor, the manifest, the contract, the metadata bands, the bronze/permission split, the MCP placement — is one half of a system. This chapter assembles the whole thing, not by introducing new mechanism but by naming what all of it has been, the entire time.

"The inbound airlock decides what reality may become model-visible. The outbound airlock decides what model output may become real."

Every mechanism this book has built so far belongs to the inbound half. The book has been building one side of the system this entire time — deliberately, because the other side already has its own published doctrine, and this chapter names it rather than re-deriving it.

The outbound, named and not re-derived

Our own Two Leashes framework owns this territory completely, and it's worth quoting its own creed directly, in one page, before returning to the inbound side that's this book's real subject:

"Wiki above the model. Authority below the model."

The action leash below it, quoted directly: "Shouldn't is weaker than can't." Decision Authority Infrastructure "treats the model as a proposer and puts a deterministic, in-path authority between proposal and reality: may this matter, who has authority, may this execute, where is the evidence?" And a distinction worth keeping precise: containment answers "what can the agent even touch?"; authority infrastructure answers "given that something is reachable, who may decide it now?" This book has spent nine chapters on a third, earlier question — what may the agent ever be shown to begin with.

The trifecta, dismantled leg by leg

Recall the shape from Chapter 1: private data access, exposure to untrusted content, a channel to communicate out. "If your agent combines these three features, an attacker can easily trick it into accessing your private data and sending it to that attacker."⁴

The third leg — exposure to untrusted content — gets typed rather than trusted at entry: the contract's authority dimension (Chapter 6) marks every claim as observed, declared, inferred, or unknown, so attacker-authored text can be represented as a low-confidence claim, never as silent policy the model just believes. Each airlock kills one leg of the trifecta by construction, not by behavioural promise.

It's worth being precise about what "by construction" actually buys you over "by policy," because the difference is the whole reason this chapter exists rather than a paragraph in Chapter 1. A policy is a sentence someone wrote, that a model reads and is asked to obey. A construction is a fact about the system that holds whether or not anyone reads anything — the model cannot leak the warehouse through the inbound airlock because it was never handed the warehouse's credential, full stop, not because it was told not to. That's the entire difference between "we don't think this will happen" and "this cannot happen without a component failing in a way we'd notice."

This is not a safety tax

Land the conviction unhedged: this architecture is not a cost paid for safety. It is what makes "turn the AI up to 11" claimable rather than reckless.

"Turning the AI up to 11 — that's the unlock. And you only get to do it inside a world you've made safe first."

The latency reframe matters here too: the engagement, not the browser interaction, is the unit of time that matters. Batch-deep cognition inside the boundaries is affordable precisely because the boundaries make it safe to run long and hard over a compiled world, instead of live and shallow over raw systems you'd be too nervous to leave a model alone with for more than a few seconds.

"Up to 11" is not "dump the whole safe wiki in"

Here's the second, quieter narrowing this book insists on: even a fully governed, allowlisted, provenance-carrying semantic world is not something you hand the model in its entirety, per task. The room where cognition actually gets turned up is smaller than that — the task world: purpose, role, as-at date, access scope, attention budget, all declared per act of work.

"Models reason from attention-resident worlds, not the whole graph."

And the boundary clause that keeps this from quietly becoming a fifth authority channel: "the task world grounds cognition; it does not license consequence." This book adds one rule on top: the task world must never widen access or mint authority beyond what the two airlocks already granted. It's a view over the governed world, never a side door around it. Compile the business — the sensor, the contract. Compile the task — the task world. Then, and only then, maximise cognition.

Notice the specific failure this second narrowing prevents, because it's the one that catches teams who did everything else right. Suppose the inbound airlock is genuinely well built: the sensor is certified, the contract is declared, the packet is clean. It's still possible to hand a model the entire governed packet for every task, regardless of what that particular task actually needs to know — and that is its own failure, quieter than a raw connector but real. A customer-support task doesn't need the finance team's declassified structure sitting in its context window just because that structure passed review once, for a different purpose. The task world is what stops "well-governed" from silently becoming "well-governed, and dumped in wholesale anyway."

Everything so far has been architecture, deliberately kept clean of any one client's story so it could be lifted and reused. This chapter breaks that discipline on purpose. Here is one production sensor, built for one real system, carrying full case weight for the first time in this book.

"Call it an application and it needs rigour, a project, governance. Call it a spreadsheet and somehow it doesn't. They had massive databases living in spreadsheets, and two meetings out of three were about reconciling the spreadsheets to themselves or to the real world."

That scar is from a large insurance programme, and it's the formative memory behind why spreadsheets are the perfect first specimen for this doctrine. They are the governance escape hatch — the shadow application everyone treats as informal precisely because it's "just a spreadsheet," while it silently carries declared business intent, structure, and rules that a real application would never be allowed to hide from review.

The specimen, introduced honestly

The specimen is FDE BI — the author's own Power BI evidence and architecture-reconciliation workbench. It exists to do a specific job: take a Power BI estate that's been audited and inventoried, take a client's own workbooks describing what they believe their target architecture should be, and work out what maps, what's missing, and what needs a human's judgement to resolve. It deliberately stops short of building the target architecture itself — that's a separate engagement, with a separate scope, and keeping the boundary explicit is part of what makes the evidence trustworthy rather than aspirational.

One production-shaped system, not a survey of deployments across many clients. State the honesty clause here, at first mention, rather than burying it until later: the blind-comparison runs walked in the next chapter are against synthetic fixture workbooks, not live client data. This is n=1, flagged now, developed properly in Chapters 13 and 14.

The extraction contract, walked in full

The sensor at the heart of this specimen is called XLSX.evidence v2, and its IN/OUT split is concrete, not aspirational:

The design principle this realises is Chapter 3's security/perception/compression synthesis, now shown as a concrete extraction contract: the packet is built around what a workbook means, not what a workbook contains.

Typed absence, as a first-class citizen

Every category the sensor examines reports one of four states — found, absent, truncated, or detected-without-decoder — never silence. The model is told what the sensor could not see, in the same breath as what it could, so a gap in coverage reads as a typed fact rather than an invitation to guess.

"Not observed" is not "does not exist."

A workbook feature the sensor couldn't decode is reported as detected but not decoded — present, bounded, and honestly unresolved — rather than silently dropped. Silent drops are the failure mode that would let the model hallucinate its way across the gap.

The worked declassification contract, instantiated fully

Chapter 6's ten dimensions aren't theoretical here. This is what they look like for one real packet:

What that buys, concretely, without ever seeing a figure: the model can recognise that a sheet implements a customer-profitability model; it can spot that an expected dimension — product line, say — is absent from the structure; it can count declared measures and named ranges. All from structure. None from a single number.

The phase change, running for real

This is Chapter 4's phase change, not as a diagram this time but as an actual build: the model did the spreadsheet archaeology no engineer economically holds cold — OOXML structure, cached-pivot quirks, hidden-name behaviour — wrote the extractor and its tests, and was revised under review as coverage gaps surfaced.

Worth noting honestly: the extractor evolved through at least one hard correction. An earlier version reported structurally-present-but-empty features as "partial," which the accepted status contract later corrected to keep missing value-level detail a validation question rather than invented implementation scope. The correction itself is evidence the review loop actually works — not a flaw to hide from the reader.

There's a second correction worth including for the same reason, because it's a genuinely different kind of failure and this book's honesty clause covers both. An early build of the surrounding knowledge system let source descriptions containing words like "fixture" and "smoke test" get promoted straight into business-facing pages — a knowledge-hygiene failure, not a security one, but a failure of exactly the kind this book's discipline is supposed to catch. The fix wasn't to patch the individual page. It was to change the authoring prompt so the distinction between capture provenance and business semantics couldn't collapse the same way again, while leaving the original wording untouched in the immutable evidence layer underneath. That's the pattern this whole book keeps returning to: when something goes wrong, the fix moves upstream into the reviewed artefact, not sideways into a one-off patch nobody will remember next quarter.

What this specimen is not claiming

It would be easy to over-read a working system into a general proof, so it's worth stating the boundary here rather than only in the red team. This chapter demonstrates that the sensor pattern from Chapters 3 through 8 is buildable, that the phase change from Chapter 4 runs on a real target format, and that the resulting packet can carry enough meaning for a model to do genuinely useful reconciliation work. It does not demonstrate that every privileged system yields as cleanly to this treatment as a workbook does, or that the economics hold at a scale beyond one engagement's worth of sensors. Those are exactly the questions Chapter 13 takes on directly.

An uncomfortable fact has to be stated before this chapter can prove anything: a sensor is easy to make look good, unless the test that judges it is genuinely blind. An earlier version of the comparison this chapter describes parsed a known workbook contract into pre-derived target rows and checked them against a database. It proved the parser worked. It proved nothing about whether the packet carried enough meaning for a model to reason with — because the model was never actually asked the question. The answer was already sitting in the fixture waiting to be matched.

The rebuild starts from raw XLSX bytes. No precomputed target. No expected count. No mapping case handed to the model in advance.

It's worth sitting with why the first version's failure is so easy to fall into, because it isn't a beginner's mistake — it's the natural shape a test takes when you build it to check that the parser works before you've thought hard about what "the model can reason with this packet" actually means as a separate claim. Parsing correctness and perceptual sufficiency are two different properties, and a test built to verify the first will quietly convince you it verified the second, because a parser that already knows the answer will always agree with itself.

The blind comparison, step by step

The results, stated exactly, with their status

Three synthetic fixture workbooks, three outcomes — this is not a survey, and the chapter says so plainly:

Why the misses matter as much as the hits: a packet that could only ever say "found" would be an oracle wearing a sensor's clothes. The complete-miss result — eight honest not-founds against a workbook sharing nothing with current gold — is the result that proves the packet isn't pattern-matching its way to a plausible-sounding yes. A sensor that cannot say "not found" cannot be trusted when it says "found."

What the blindfold actually proves

Two claims, kept deliberately separate:

Consultant steering — free-text guidance an engagement lead can add — is passed through a separate channel from workbook evidence entirely, with its own author, time, and scope metadata. That's deliberate: it means a leading hint from a human never contaminates the test of whether the packet itself carries the meaning. There is no leakage channel between what the human said and what the workbook evidence actually supports.

The other constitutional branches, seen working

Two other parts of the constitution are visible in this same specimen, briefly — each owned by an earlier chapter, not re-explained here:

The Power BI MCP handed to deterministic Python — Chapter 9's placement doctrine, now visibly running rather than argued abstractly: Microsoft's own Modeling MCP server supplies read-only discovery and DAX execution; the calling code around it is deterministic Python, not a general agent wielding the raw protocol.

The junior/senior wiki-authoring run — one instance of Chapter 2's table, live: a junior model explores with no write terminal and must finish by requesting review; a senior alone emits one governed save; deterministic validation applies it. One retained run produced ten pages, eighteen typed edges, and seven review flags after forty-one junior tool calls. Human dispositions on material findings are immutable once made, and scope compilation is blocked until every material finding has one.

Read that against Chapter 2's table directly: sees, interprets, signs, compiles — the whole separation-of-powers table, not diagrammed this time, but running.

One more detail from that same run is worth keeping, because it's a small fact that carries a lot of the book's argument in it: forty-one junior tool calls happened before a single governed byte of state was written anywhere. That ratio — forty-one reads for one write — is what "the sensor may see more but decide less" looks like as an actual number instead of a design principle. Almost all of the system's activity in that run was reading, exploring, checking; only the very last, single, senior-authored action ever touched anything a later run would depend on.

Every chapter so far has been building the case that this constitution works. This one turns the same tools against the specimen from Chapters 11 and 12, on the record, before the book hands over a build method anyone could run unattended. The rule that's been implicit since Chapter 6 becomes explicit here: anyone claiming a categorically safe representation is selling redaction with better marketing.

It would be easy to skip this chapter — nobody enjoys attacking the thing they just spent twelve chapters building — and that ease is exactly why it has to be here. A doctrine that only ever gets defended, never attacked by its own author, hasn't earned the confidence it projects. This chapter is where that confidence gets tested against the same standard the rest of the book has been applying to everyone else's architecture.

Four channels a "safe" packet can still leak through

What the manifest's tests actually probe, and what they can't

State this plainly, without hedging: the manifest's redaction and adversarial tests from Chapter 5 narrow these four channels. They do not abolish them. The honest standing assumption for anyone operating this constitution: the contract in front of you has a hole you have not found yet. That's not a weakness to manage away quietly — it's the posture that keeps the whole system honest.

n=1, stated as n=1

This book's evidence boundary, restated without softening it: one production sensor, one worked declassification contract, synthetic retained runs. This is architectural evidence — these properties hold by construction — not statistical evidence across a fleet of deployments.

Two convergent sibling instances are worth naming honestly, as convergence rather than replication: a business-advisory deployment running nightly deterministic collectors with PII tokenisation applied before any model contact, and a development-knowledge compiler with deterministic preparation and a gated, review-only mutation path. Both are the same architect converging on the same shape from different starting problems — that's corroborating design instinct, not independent statistical replication, and this book says so plainly rather than dressing it up as a survey it didn't run.

Honesty as a design property

Land the belief plainly: an architecture that preserves typed uncertainty in its outputs — "not observed" as a first-class state, never silently dropped — has to preserve that same uncertainty in its own marketing. A book that argued for typed absence and then oversold its own packet's safety would be violating its own doctrine in the very act of describing it.

There's a practical test that follows from this, and it's worth stating as something a reader can actually apply to any vendor pitch, including this book's own: does the pitch include a chapter like this one? A vendor whose sensor, contract, or "AI-safe data layer" has never had someone from inside the project try to break it, on the record, with the results published rather than fixed quietly and forgotten, hasn't done the work this chapter just did. The presence of a serious red team isn't proof the architecture is flawless. It's the minimum evidence that anyone actually looked.

Everything from Chapter 2 to Chapter 13 was doctrine and proof. This chapter is what you actually do next. Nine steps, each with its own artefact — not a week-by-week timeline, a build sequence.

One thing worth saying before the steps themselves: this method is deliberately narrow in scope on its first pass. It is not a plan for governing every AI system in your organisation at once. It's a plan for shipping one sensor, for one privileged source, serving one purpose — because that's the version of this project that can actually be reviewed by a human being in a reasonable amount of time, and reviewed is the entire point. Everything that compounds later compounds from having done the narrow version properly first.

The adoption asymmetry

Here's the reframe that actually unlocks the security-review conversation, and it's the whole commercial payoff of the method: you are not asking a review board to trust an intelligence. You are asking them to review a mechanism through institutions they already run — code review, testing, version control, rollback. Lead with the manifest, not the model. This is Chapter 4's governance arbitrage, restated as a conversation script instead of a mechanism.

The scale note, honestly bounded

Callback to Chapter 13: sensor-library economics at n=1 are genuinely unknown. Don't oversell what a single production build can prove about long-run maintenance cost. What compounds if the doctrine holds, stated as a hypothesis rather than a promise: certified sensors get reused across engagements; contracts become templates instead of bespoke documents written from scratch each time; run receipts accumulate into an audit substrate nobody had to design specially for that purpose.

The honest risk on the other side of that hypothesis deserves a sentence too: a sensor library is still a library, and libraries need maintenance as the systems underneath them change. A schema upgrade in the source system, a new workbook format, a vendor API version bump — each of these can silently invalidate a certified sensor's assumptions without anyone noticing until a run receipt looks wrong. The discipline this book asks for isn't "build it once and trust it forever." It's "build it once, under review, and keep the review cadence alive for as long as the sensor stays in service" — which is a real ongoing cost, not a one-time investment, and any adoption plan that doesn't budget for it is quietly reintroducing the trust-without-verification problem this whole book exists to remove.

Where this sits in the larger stack

One paragraph each, no re-derivation:

The capstone category. AI-Constituted Services is the commercial consequence of this architecture — this book is the organ that category deliberately left underdeveloped, referencing the sensor as a stage in its own pipeline rather than building it out.

The compiled knowledge layer. BI for Soft Data owns the wiki-as-compiled-layer doctrine this book's packets ultimately feed into — cited throughout, never restated.

The outbound airlock. Two Leashes, named throughout this book, never re-derived.

The temporary task world. Intent-Conditioned Task World governs what actually becomes attention-resident once the two airlocks have done their work — cited in Chapter 10, not restated here.

The creed, returned

Compile reality before cognition.
Compile authority before action.