On 29 July 2026 the repository began as a factory for a disposable Windows Power BI environment. By 30–31 July it had also become an evidence and architecture-reconciliation workbench for a consulting engagement. The live application sits at https://fde-bi.leverageai.com.au. Its health endpoint answers. That is the calendar fact — and the fact that tempts the wrong story.

The wrong story is: someone who did not know Power BI yesterday became a Power BI developer overnight because AI is magic. That story flatters the model and erases the product. It also cannot explain the two places where working software was overruled for solving the wrong problem, the authority classes that stop a model finding becoming client truth, or the retained numbers that refuse to be rounded for LinkedIn.

The right story is harder and more useful.

Compile time is not creation from nothing

I did not learn Power BI from scratch and somehow become a conventional platform specialist in a day. Power BI was the final local vocabulary needed by a system of thought and capability that was already substantially assembled. I already knew how to recognise a commercially important problem; read a CFO as buyer; treat spreadsheets as undocumented applications; map a baseline architecture against a target; separate an observed fact from an inferred conclusion; decide where AI judgment belongs and where deterministic control belongs; manufacture a disposable technical environment for an unfamiliar platform; define evidence and acceptance tests; convert findings into a scope and statement of work; and package the whole thing as a product a consultancy could sell more than once.

The 24 hours were compile time. The source was 45 years.

That sentence is the spine of this book. Everything else is the specimen that makes it falsifiable: organs, corrections, receipts, career components, and honest limits.

Compounded Execution Capital already names the asset shape — experience converted from tenure and memory into a callable substrate that conditions live discovery and construction. Executable Worldview already names the closed composition: archive as source, wiki as cognitive intermediate representation, agent as runtime, authority independent of the model, write-back from paths and outcomes. This book does not re-mint those frameworks. It is their production evidence — rung two on the positioning ladder, a credibility object, not new IP.

The question and the takeaway

Here is the only question this book is allowed to answer cleanly:

How does one person ship a governed, deployed consulting product in a day — and what did the AI actually contribute versus the human?

After this book you should be able to do two things without me in the room. First: distinguish compile-time from source — AI supplied Power BI's nouns, APIs, file formats and tools; the author supplied the evaluation function. Second: name what a compiled career changes about project speed — not typing rate, but starting altitude, because judgment, tests, rejected paths and commercial instinct are already callable.

What this book owns — and what it does not

This is the full biography of one instrumented build: FDE BI. The general claim that some services only exist because AI is inside them is developed in AI-Constituted Services — that piece left FDE BI as a summary pointer; this piece owns the organ. The sensor and privilege architecture is developed in Separation of Powers for Cognition. The commercial protocol for fixed-price certainty products is developed in Buy Certainty First. Cite them. Do not expect them restated here.

We also will not re-derive Compounded Execution Capital, Orientation Capital or Executable Worldview as if this were their first publication. We will thread them where the specimen makes them concrete.

Where we go

Part I states the claim, allocates credit between AI and human, and locks the n=1 honesty contract.

Part II is the heavy middle — the two centres of gravity, the doctrine-to-instance table, the two corrections, the receipts, and the decision surface. A sceptical reader who doubts the claim should start here.

Part III walks the career as compiled components, inherited orientation, and authorship without typing.

Part IV states limits and next proofs without tapering, then returns the takeaway on project speed.

Why "day" is the wrong unit — and still the right headline

Calendar time is a terrible measure of intellectual capital and a useful measure of assembly cost. Both facts can be true. The headline "twenty-four hours" earns attention because assembly used to be the bottleneck: environments, glue code, report shells, integration probes. That bottleneck moved. The bottleneck that remains is whether you have source worth compiling — evaluation functions, doctrines, commercial objects, tests that detect wrong-problem greens.

Readers who only hear the headline will think this book is about hustle. It is not. It is about the difference between a day of compile time over a compiled career and a day of improvisation over a blank mind. The second can produce demos. The first can produce a vessel with authority classes. Keep that distinction in your head for every chapter that follows.

Credit allocation is where most AI project write-ups go soft. They say "collaboration" and hope the reader will not ask who overruled whom. This chapter refuses that mush. It is the proof plan for the rest of the book: every heavy chapter either shows an AI contribution, a human evaluation move, or the boundary between them.

What AI contributed

Be concrete.

• Power BI's nouns. Desktop objects, DAX shapes, Modeling MCP tools, Desktop Bridge capture, PBIR validation paths, the vocabulary of an estate I had not lived in. Microsoft's own documentation describes Power BI as the suite that turns data into insights across Desktop and service — that is the local vocabulary the build needed, not the product thesis.¹
• Workbook archaeology. Complicated extractors over OOXML, formulas, structure, connections, Power Query indicators, pivots, embedded models, VBA — written at design time into deterministic sensors a security reviewer can still read.
• Implementation volume. Host scripts, guest provisioning loops, FastAPI routes, wiki tools, comparison harnesses, report generators — the cheap assembly that made a day-scale build possible at all.
• Semantic work under constraint. Junior and senior model runs that synthesise significance over safe evidence, propose mappings, draft readable gold and report language.

None of that is trivial. None of it is the evaluation function.

What the human supplied

The evaluation function is the scarce object. It is the set of judgments that decide whether software that runs is software that solves the right problem.

• Product thesis and commercial object. Not "AI builds dashboards" — an evidence-backed consulting transaction compiler that stops at readiness and scoped next engagement.
• FDE framing. Client-contained vessel, human forward-deployed judgment, software as the engagement membrane.
• Terminal-value reason to build. Not faster status meetings — a possible AI-native successor to part of the traditional labour model of data consulting.
• Architecture state machine. Observed current, declared target, interpreted target, agreed target, scoped transition — TOGAF-shaped stages made non-collapsible by software.
• Deterministic versus probabilistic allocation. Where enumeration of semantic rules is futile versus where identity, mutation and authority must never improvise.
• Bronze and gold provenance rules. What is immutable evidence versus what is regenerable meaning.
• The two corrections. Wiki as brain not report; spreadsheet test as blind reconciliation not answer key. Working code overruled both times.
• Which tests count. Acceptance of the held-out oracle contract; refusal of parser-regression cosplay as intelligence proof.
• Career-shaped recognition. Spreadsheets as governance escape hatches; SOWs as the bottleneck that limits how much work a services firm can even write up.

AI filled in Power BI's nouns, APIs, file formats and tools. I supplied the evaluation function.

Why this split matters commercially

If you allocate credit wrong, you buy the wrong next hire and the wrong next tool. Hire only for Power BI depth and you get audit utilities. Hire only for "prompt engineering" and you get fluent demos without authority architecture. The specimen required simultaneous backgrounds — accounting, architecture, systems administration, consultancy ownership, sales instinct, recent AI governance research — compiled so an agent could inherit them. Chapter 10 walks that table. Here it is enough to say: the evaluation function is not a system prompt. It is a career that finally became executable.

A cameo, not a sibling book

There is a subtler split visible in the build. Design-time AI wrote complicated deterministic extractors; those crystallise into reviewable code; runtime AI then operates only inside the safe representation those sensors manufacture. That is the privilege and sensor architecture owned by Separation of Powers for Cognition. This book will point at it when the specimen uses it. It will not re-derive the full stack.

How the rest of the book uses this split

Chapters 6 and 7 are the two corrections — pure evaluation-function exhibits. Chapter 8 is receipts — what the ledger retained after AI assembly and human gatekeeping. Chapter 12 returns to authorship as an operational claim, not a philosophical mood. If you only remember one sentence from Part I, make it this: assembly is cheap; evaluation is scarce.

Evaluation function as a portable object

Think of the evaluation function as the thing that remains when you subtract autocomplete. Autocomplete can propose a wiki renderer from SQL. Autocomplete can propose a spreadsheet parser that matches a known fixture. Autocomplete cannot tell you that both of those successes are product failures. That judgment has to be prepaid — trained by prior projects, prior frameworks, prior commercial scars — and then applied at the moment green tests appear.

This is why "I did not type every line" is an uninteresting confession. Modern software is full of people who did not type every line: compilers, libraries, code generators, interns, offshore teams. Authorship has always been about what you accept, reject and bind into a system of responsibility. AI changes the volume of candidate implementations. It does not abolish the evaluation seat. If anything, it makes the seat more visible, because the candidates arrive faster than your old review rituals were designed for.

Chapter 6 and Chapter 7 will show the seat in action. Chapter 8 will show what the ledger kept after the seat did its work. If you find yourself wanting a hero narrative about overnight Power BI mastery, re-read the split above until the hero narrative dies. The hero here is not typing speed. It is refusing wrong-problem greens.

There is a case-study shelf in this corpus for a reason. The Tesla Service AI case study built a whole argument from one wrong seat part and a man at a desk who said the AI got it wrong — not as an exposé, but as a complete map of receiptless authority if you refuse both only-gloom and only-hype.

This book sits on that shelf. One build. One specimen. Synthetic retained test runs. Live deployment. Real architecture. Honest limits. I will not invent a portfolio to sound serious. Seriousness is the opposite move: state n=1 as n=1 and still carry the proof burden the brief demands.

The evidence package is part of the product

Product of One is explicit: if the product is the proposal, the product must clear the credibility bar the proposal used to clear with research receipts. An agent saying "approved" is hearsay until the listing resolves. Ten minutes of receipts convert a great story into a demonstrable one; without them you sell vibes with a marketplace costume.

For this specimen the receipts package is:

• Live deployment URL and health endpoint
• Implementation and test ledger numbers for wiki authoring
• Blind comparison outcomes with held-out oracle discipline
• Report honesty: zero consultant decisions carried into draft scope language
• Explicit non-claims: synthetic runs, not client-production-ready

Chapter 8 is the ledger. This chapter is the contract that makes the ledger meaningful: we will not launder synthetic proof into client production proof.

What we will prove

1. The architecture of two centres of gravity and five non-collapsible states
2. The doctrine→instance table — frameworks as generators of organs
3. Both corrections with before/after architecture
4. Exact retained run numbers with provenance
5. Career capabilities as compiled components and inherited orientation
6. Authorship evidenced by overruling working software
7. Limits and the next proof increments specified enough to run

What we will not claim

• A completed multi-year client production engagement on this vessel
• Authenticated multi-user decision operations under a finished client data policy
• Adversarial and prompt-injection evaluation as complete
• Windows service packaging inside the disposable guest as production delivery
• That engagement two already proves another consultant can operate with far less dependence on the original expert
• Any named insurer, named mid-sized consultancy sales narrative, or identifying engagement detail

Named-entity discipline is a hard gate, not a style preference. FDE BI, LeverageAI, fde-bi.leverageai.com.au, the Microsoft WinDev2407Eval appliance, AWS Marketplace, The Simpsons and Milhouse, and the Data Readiness Review may be named. A multi-year spreadsheet-driven programme at a large insurer is generalised. A mid-sized data consultancy is generalised. Role descriptors only for any other firm. No leakage.

Siblings are doors, not chapters

If you want the general economics of services AI constitutes rather than merely accelerates, read 202. If you want the full privilege architecture, read 203. If you want the commercial protocol — buy certainty before implementation — read 204. This book is the instrumented specimen those pieces point at. Stay with the specimen.

Why synthetic proof still counts — and how far

Synthetic fixtures are not worthless. They are how you pin contracts: authority classes, citation boundaries, held-out oracles, atomic promotion. Engineering cultures that refuse synthetic proof never get to production; they drown in "real data" anecdotes that cannot be replayed. Engineering cultures that worship synthetic proof never leave the lab; they ship green ledgers that die on the first real workbook.

This book uses synthetic proof for what it can carry: mechanism, architecture, evaluation design, deployment path. It refuses synthetic proof for what it cannot carry: client conversion, multi-user production operations, engagement-two operator independence. That refusal is itself part of the Product of One evidence package — a confession of what could not be verified is not optional colour. It is how hallucination is prevented from compounding through the publishing chain of a consulting offer.

If you need a portfolio study, this is the wrong book. If you need an inspectable specimen that makes a compile-time claim falsifiable, you are in the right place. Chapter 13 specifies the next proofs precisely so this n=1 does not become a permanent alibi.

FDE BI is one repository with two successive centres of gravity. The common doctrine is easy to say and expensive to implement honestly: generated environments and generated knowledge are replaceable; locked inputs, evidence, prompts, decisions, tests and receipts are the assets.

That sentence is the operating law of the specimen. Everything polished you see on the deployed surface is regenerable. Everything that must survive a teardown is pinned, hashed, decided or tested.

Centre one — the VM is a test instrument, not the product

The first system builds and operates a disposable Windows guest for Power BI discovery. Host scripts create tuned ZFS datasets, manage VM lifecycle through Proxmox, build unattended configuration media, and pin external inputs in a versions lock file. Destructive commands resolve exact VM and dataset targets rather than accepting broad teardown requests. That is systems administration discipline applied to AI-assisted platform discovery: if you cannot destroy and rebuild, you do not own the environment — you are nursing it.

The verified 29 July run used Microsoft's expired WinDev2407Eval appliance as an integration probe, not as the supported long-term base. It proved the path end to end: Power BI Desktop, Modeling MCP, Desktop Bridge, PBIR validation tools, SQL Server fixtures, Python and the coding CLIs were provisioned; the MCP protocol exposed the required tools; a guest-side Python loop used the host LiteLLM endpoint without persisting its credential; live Desktop DAX returned the four expected finance totals; Desktop Bridge captured the report page. A current evaluation or licensed Windows ISO remains the clean rebuild input. Microsoft publishes developer virtual machines for exactly this class of evaluation work — the project record treats the appliance as a public technical probe, not a production OS strategy.²

Discovery deliberately runs on two tracks. A deterministic harness produces repeatable inventory and aggregate DAX evidence. A coding agent receives a project-scoped read-only MCP configuration and a broad north-star brief, producing its own Markdown and JSON account. The two are retained independently rather than forced into consensus. That is already an evaluation-function move: consensus theatre is how you hide disagreement; dual retention is how you keep signal.

A modular PHP audit site communicates setup, method, findings, limitations and rebuild evidence to a Power BI professional. Communication is part of the product, not a blog afterthought.

Centre two — from audit repository to architecture reconciliation

The next brief changed the problem. The application would retain the observed Power BI estate, accept client spreadsheets as declarations of a target architecture, help determine how those declarations map to current knowledge, and stop at an evidence-backed scope and statement of work for the next engagement. It would not implement the target architecture.

That stop is load-bearing. Many "AI data" demos cannot stop. They rush into building because building is the only verb they know. FDE BI's commercial object is the first half of the engagement: determining what is true, what is wanted, what remains undecided, and what can safely be sold next.

observed estate
→ declared target (workbooks as specification)
→ interpreted comparison
→ human decisions
→ readiness position
→ scoped next engagement

Outside language for the same object: an evidence-backed consulting transaction compiler. Not "AI that builds Power BI reports." The general services layer around products that only exist because AI is inside them is AI-Constituted Services; here we stay with how this compiler is built.

Three substrates

The FastAPI/Jinja workbench uses three complementary substrates.

Keep the Bronze is the doctrine behind the first row: the raw archive is cold and immutable; silver and gold can be rebuilt cheaply over territory that still exists; deletion is the irreversible act.

Five evidence-bearing states

The core distinctions prevent an audit miss, a model inference or a synthetic fixture decision from silently becoming client truth:

1. Observed current — what the audit actually saw in this estate snapshot
2. Declared target — what workbooks or consultant statements claim as desired architecture
3. Interpreted target — what the model proposes the declaration means and how it maps
4. Agreed target — what a human consultant has disposed
5. Scoped transition — what may enter the next commercial unit

That is TOGAF ADM influence made executable rather than documentary. Ordinary architecture work produces decks describing baseline, target, gaps and transition. FDE BI turns those into distinct application states that cannot be flattened into one confident answer without leaving a receipt. Chapter 9 shows the decision surface this enables. Chapter 5 shows which prior doctrines forced which organs.

Deployment is real — production-ready is not

The live application is deployed under Supervisor and Cloudflare Tunnel at https://fde-bi.leverageai.com.au; its health endpoint is https://fde-bi.leverageai.com.au/healthz. Verified in the research pass for this book, the health endpoint returned an ok status against the runtime SQLite database. That is a real deployment receipt.

Deployment does not make the engagement client-production-ready. The retained runs are synthetic. Authenticated multi-user decisions, client data policy, adversarial-source testing and Windows service packaging remain explicit next increments. Chapter 13 develops those limits without burying them. Product of One would call burying them a failure of the evidence package.

Why the pivot is the product

Many teams would have stopped at centre one: a clever disposable Power BI lab. Useful. Fundable as a training toy. Not a consulting transaction compiler. The pivot to architecture reconciliation is where FDE BI becomes commercially legible. Observation alone is audit. Observation plus declared target plus governed comparison plus human disposition plus scoped next engagement is a readiness product.

Notice what the pivot refuses. It refuses to implement the target architecture inside the same breath as discovering it. That refusal is how fixed-price readiness becomes thinkable later. If discovery and build are the same unpaid fog, you are back to bespoke SOW theatre. The machine stops on purpose. Commercial protocol for what you sell after that stop lives in Buy Certainty First; the specimen contribution is that the stop is real in software.

How the factory actually earns the word "rebuildable"

The project record is specific about the host-side machinery, and the specifics matter because they are what make "disposable" more than a slogan. Host scripts create tuned ZFS datasets, manage VM lifecycle through Proxmox, build unattended configuration media, and pin external inputs in a versions lock file. Destructive commands resolve exact VM and dataset targets rather than accepting broad teardown requests. That last clause is systems administration taste made into safety policy: a factory that can destroy "whatever looks like the lab" is a liability; a factory that can destroy only the named guest and the named dataset is an instrument you can trust under pressure.

The verified 29 July path is worth unpacking as an integration probe, not as a feature catalogue. Microsoft's expired WinDev2407Eval appliance was used deliberately as a throwaway base — not as the long-term OS story. On that path the factory provisioned Power BI Desktop, Modeling MCP, Desktop Bridge, PBIR validation tools, SQL Server fixtures, Python and the coding CLIs. The MCP protocol exposed the required tools. A guest-side Python loop called the host LiteLLM endpoint without persisting the credential in the guest image, command line or repository. Live Desktop DAX returned the four expected finance totals. Desktop Bridge captured the report page. That sequence is the Delete Test applied to environment construction: if you cannot rebuild the probe, you do not own discovery — you own a snowflake laptop narrative.

A current evaluation or licensed Windows ISO remains the clean rebuild input. The expired appliance proved the path end to end; it does not pretend to be the production base. That distinction is itself receipt discipline: what was proven is the integration path, not a permanent Microsoft evaluation image strategy.

Two discovery tracks that refuse consensus theatre

Discovery deliberately runs on two tracks that are retained independently rather than forced into agreement. A deterministic harness produces repeatable inventory and aggregate DAX evidence. A coding agent receives a project-scoped read-only MCP configuration and a broad north-star brief, then writes its own Markdown and JSON account. Consensus would feel cleaner in a demo. Independent retention is more honest: disagreement is signal about what the estate actually is, not a defect to be smoothed before the consultant arrives.

A modular PHP audit site then communicates setup, method, findings, limitations and rebuild evidence to a Power BI professional. Communication is part of the instrument. An environment that only the builder can interpret is not a consulting product; it is a private lab.

The intermediate representation for consulting work

Once the workbench pivot lands, heterogeneity is the client's problem and stability is the compiler's job. Every client can begin with a different mess: Power BI models and reports, workbooks with different structures, undocumented sources, requirements in different language, unknown dependencies, inconsistent maturity. The system lowers that mess into a small set of objects:

source evidence
→ observed estate
→ declared requirement
→ proposed mapping
→ finding
→ human disposition
→ scoped work item

That is the real productisation move, stated sharply: you standardised the compilation pipeline, not the client's reality. Or even more sharply: you productised the path to understanding, not the conclusion. Under traditional consulting, each client is a new expedition. Under FDE BI, each client is a new source program passed through the same compiler. The answer remains completely client-specific; the path becomes stable enough to instrument.

The load-bearing application paths in the project record make the same claim in file names rather than slogans: evidence store, wiki agent and tools, workbook evidence extraction, blind comparison, consultant review, scope generation. Tests under the webapp suite preserve authority and anti-leakage boundaries. Architecture that cannot be named as paths and tests is still a slide.

Most project write-ups invent frameworks after the fact. They ship something that roughly works, then hunt for language that makes it sound intentional. FDE BI ran the other direction. Prior doctrines were already written, already linked, already sitting in a wiki the coding agent could inherit. The product organs that appeared are instances of those doctrines under load.

That is the claim this chapter instruments. Not "we used best practices." The frameworks generated the organs.

Your frameworks are no longer merely explanations you publish after doing the work. They are upstream source that generates the work.

The doctrine→instance table

This is the definitive placement of the mapping. Later chapters point here; they do not re-derive the table.

Walk the rows — generators, not stickers

Prompt Is Source → VM factory

Prompt Is Source says the durable asset is the retained package above generated code: intent, design, prompts, worldview context, acceptance tests, starting state, decisions regeneration must not re-guess. Generated code is compiled output relative to the agent.

The disposable Windows/Power BI factory is that doctrine made mechanical. Tear down. Rebuild. Pin versions. Improve the prompt when the agent fumbles. Keep going until the path does not need mid-run heroics. The guest image is not the source. The source is the package that can regenerate a working probe environment. That is why centre one is not "we installed Power BI once." It is a factory.

Wiki Is the Kernel → engagement brain

A wiki-graph as the stable semantic core agents boot from is prior architecture in this corpus. FDE BI applies it to a single engagement: the gold layer is where meaning lives and routes back to bronze. Chapter 6 is the correction that forced the wiki into that role after a first implementation treated it as a deterministic report. The doctrine was already clear; the first code violated it while still "working."

Keep the Bronze → evidence architecture

Content-addressed storage for exact workbooks, MCP reports, screenshots, transcripts and decision receipts is not pedantry. It is the refusal to let regenerable gold outrank evidence. When gold is wrong, you rebuild gold. When bronze is gone, you have lost the territory. Chapter 4 placed the three substrates; this row names the doctrine that made bronze non-negotiable.

Scout–Senior Split → knowledge authoring workflow

Junior models inspect with bounded tools and no write terminal; seniors alone emit the complete mutation. That is not organisational cosplay. It is an information and authority design: exploratory breadth without write privileges; synthetic judgment with a single atomic save path. Chapter 6 walks the implemented path and the retained 10/18/7/41 run. The published Scout and Senior framing is the parent pattern.

Hidden Gates → blind workbook evaluation

When a capable worker sees the exact rubric used to judge it, the measure becomes a target. Hidden Gates separates visible intent from held-out acceptance checks. Chapter 7 is this row made brutal: the first spreadsheet harness gave away the answer; the corrected path holds the oracle until after save. Green tests that prove a parser are worse than red tests that fail an intelligence claim honestly.

Deterministic–AI pendulum → responsibility boundary

Models own significance, synthesis and questions. Code owns evidence identity, access boundaries, validation, caching and mutation. That allocation appears in the project record as system architecture, not as a slide. It is the same pendulum visible across prior work — reuse allowed here without minting a new name. Wherever you see an LLM deciding whether scope may advance, the pendulum was abandoned.

Discussed Is Not Deployed → authority classes

A claim may occupy only the highest state supported by inspected evidence. Code is not commit; commit is not test; deploy is not production acceptance. In FDE BI the parallel is operational: observed is not declared; declared is not interpreted; interpreted is not agreed; agreed is not scoped. Chapter 9 shows the decision surface that makes the ladder visible to a consultant — "45 findings still need your call."

Proof-Carrying Transformation → evidence-to-scope spine

The valuable object is the unbroken chain from evidence through decision and scope, not polished recommendation text. FDE BI's reports preserve uncertainty instead of erasing it. Zero consultant decisions remain zero in the SOW language rather than being silently filled by model confidence. That is PCT as product behaviour.

Product of One → Marketplace vessel

The intended commercial rail is AWS Marketplace as a way to install a client-contained vessel — not generic multi-tenant SaaS. The software holds evidence and queues; the FDE investigates meaning and owns the engagement; the client receives inventory, decisions and scope; the firm retains compiler, extractors, prompts, orchestration and tests. Product of One already argued that moving from bespoke proposal to running client-shaped product raises both meta-credibility and proof burden. FDE BI is that move for the readiness transaction. AWS Marketplace is named as a platform; no consultancy sales narrative is smuggled in.³

Terminal Value Doctrine → why build this at all

The project did not ask only "how can discovery go faster?" It asked what a data consultancy becomes when analysis, coding, report construction and generic advice become cheap. Terminal Value Doctrine is the strategic parent: weak positions get crushed first when AI compresses labour models; Construct is building the AI-native delivery model before someone else compresses you from outside. FDE BI is part of that Construct answer in one narrow, instrumented form.

What the deck claimed — now inspectable

Several deck propositions from the FDE for Data story now have working implementation behind them:

That is the core commercial argument of the deck made inspectable rather than asserted. The commercial packaging of "buy certainty first" remains Buy Certainty First. This table is the specimen proof that the deck is no longer only slides.

How to use the table without turning it into stickers

There is a failure mode that looks like this chapter and is not this chapter: printing a framework name on every microservice and calling it alignment. The test for a real doctrine→instance row is causal. Remove the doctrine from the operator's working set — would the organ still have been designed this way, or would a neighbouring, weaker organ have appeared?

For Hidden Gates, the counterfactual is obvious: without held-out evaluation discipline, the answer-key harness would have survived. For Discussed Is Not Deployed, without evidence ceilings, model findings would print into scope. For Prompt Is Source, without rebuild discipline, the VM would have become a snowflake. Use the table as a set of counterfactuals, not as a logo wall. Chapters 6 and 7 are deep counterfactuals for two rows. The other rows earn their keep by binding architecture in Chapter 4 and receipts in Chapter 8.

The vessel layering is an instance of Product of One, not a listing slogan

When the AWS Marketplace rail appears in the doctrine table, it is easy to hear "go-to-market plan" and stop listening. The specimen's actual layering is more precise — and it is the organ Product of One predicted when it said the product is the proposal only if the vessel and evidence package travel together.

That split is why generic multi-tenant SaaS would be the wrong shape even if it shipped faster. The engagement happens in a client-contained vessel. The firm does not rent the client's truth as a hosted chat log. The client does not buy a vague "AI platform." They install a workbench that reads estate and spreadsheets, builds an evidence-linked current-versus-target map, routes unresolved findings to accountable reviewers, and produces a readiness verdict and scoped next engagement — without changing production.

What AI owns versus what code owns — the pendulum as instance, not slogan

The deterministic–AI pendulum row in the table is easy to treat as mood. The specimen implements it as two explicit work lists.

AI owns the semantic work: what a workbook appears to require; what current knowledge means; whether two concepts plausibly correspond; which gaps and questions are significant; how evidence should be synthesised into readable gold.

Deterministic software owns the binding work: identities and hashes; immutable evidence; visibility boundaries; queues and state transitions; valid citation coordinates; who may mutate what; atomic promotion; decision receipts; whether scope is allowed to advance.

That allocation is why Hidden Gates and Discussed Is Not Deployed can coexist with model fluency. The model is used precisely where enumerating every semantic rule would be futile. Code takes over wherever repeatability, authority, provenance or consequence demands it. If you reverse the lists — if code pretends to own significance, or models quietly own mutation — the doctrine→instance table collapses even if the UI still looks polished.

Naming hierarchy as commercial organ

Doctrine becomes commercial organ only when naming is explicit enough for a CFO, a consulting partner and a security reviewer to hold the same object. The specimen's hierarchy is:

• Practice / category: FDE for Data / BI
• Installed software: FDE Evidence Workbench
• Entry engagement: BI / Data Readiness Review
• Primary outputs: Readiness Decision Pack + Evidence-Backed Scope
• Follow-on engagement: Fixed-Price Build Pack
• Change allowance: Flex Reserve

Those names are not this book's commercial protocol — that protocol lives in Buy Certainty First. They are the naming surface the specimen already forces into existence when the deck becomes software. Without them, doctrine rows have nowhere commercial to land.

Not typing the code does not reduce authorship. In this build the strongest authorship evidence is where plausible, working implementations were overruled. This chapter is the first of those two corrections. Chapter 7 is the second. Together they are the signature of human evaluation over machine fluency.

Working software. Wrong problem.

Before — a deterministic report wearing a wiki costume

The first implementation deterministically rendered a wiki from SQLite and used the LLM only for optional proposals. Pages appeared. Navigation worked. A demo would have been easy. The software ran.

It also missed the thesis.

If the real semantic decisions are already made in SQL and relational state, the "wiki" is a report generator with nicer typography. Significance has already been flattened into whatever the deterministic pipeline decided to emit. The model is decorative — a writer of optional commentary after the engagement's brain has already been bypassed.

That is a common failure mode in "AI products." The team ships a system that produces artefacts that look like knowledge work, while the knowledge work itself never entered a place where judgment, edges, uncertainty and questions can live. Fluency arrives late and changes nothing important.

The restated intent

The intended design was restated without romance:

observation / audit data in
        → LLM read
        → ingest to wiki

The wiki was to be the engagement's brain and scribe — not a report written after the real decisions had already been made elsewhere. Models would own significance, synthesis and questions. Code would own evidence identity, access boundaries, validation, caching and authoritative mutation. That allocation is the deterministic–AI pendulum operating at system scale, not a prompt suggestion.

After — junior trail, senior mutation, deterministic gates

The implemented correction follows the same family of design as the maintained dev-wiki engine: bounded readers, phase separation, atomic promotion.

Junior phase. A junior model receives a bounded architecture map plus gold, silver and bronze readers. It has no write terminal. It must inspect evidence and finish by handing off a structured bundle through request_review. Its persuasive prose is removed at the phase boundary. Its tool trail remains. That stripping is not aesthetic. It prevents eloquence from smuggling uncited claims into the senior phase as if they were already decided.

Senior phase. A senior continues the same evidence trail, may inspect further material, and alone emits one complete save_review containing pages, claims, typed edges and review flags. One terminal mutation. Not a chat that slowly mutates production knowledge through side effects.

Deterministic gate. Ordinary code validates authority classes, evidence eligibility, edge endpoints, page structure and consultant-source use. It stages the generated files, applies relational state in a transaction, and atomically promotes the build. Requested aliases, actual returned models, junior and senior transcripts, the normalised mutation and the resulting build are retained as evidence.

The Scout–Senior pattern is the parent of this workflow. Wiki Is the Kernel is the parent of why gold must be a navigable brain rather than a dump of SQL. Neither parent is re-derived here; both are made concrete by the correction.

The retained run — exact numbers

A retained live run recorded in the implementation and test ledger produced:

The important output is not the page count. Ten pages could be vanity. The important output is the allocation of work the counts imply: a long junior tool trail before any authoritative save; typed edges and review flags as first-class objects; human-readable gold produced through model judgment under deterministic gates.

A hygiene failure that proves the discipline

Testing also exposed a knowledge-hygiene failure worth keeping. Source descriptions containing "fixture" and "smoke test" were initially promoted into business-facing semantic gold. The promoted pages were curated to remove that capture provenance while the original wording remained in immutable bronze, and the page-style prompt was changed to prevent recurrence.

That incident is not an embarrassment to hide. It is evidence that bronze and gold are doing different jobs. Capture provenance belongs in bronze. Business semantics belong in gold. Collapsing them is how synthetic test language becomes fake enterprise truth. The system preserves the distinction between the semantics discovered in a test estate and the provenance of how that estate was created.

Why overruling counts as authorship

The coding agent had produced functional software. The correction identified that it was solving the wrong problem despite appearing to work. That is the scarce job.

The agent wrote implementation. The human supplied:

• the intended world (wiki as brain, not report)
• the product boundary (engagement knowledge layer versus post-hoc narration)
• the division of responsibility (junior / senior / code)
• the tests of whether the idea was genuine (authority classes, evidence eligibility, atomic promote)
• the reason the plausible substitute was insufficient (SQL-rendered pages empty the thesis)

In Prompt Is Source terms, the source was not merely Python. It was intent, architecture, constraints, evidence rules, tests, decisions and corrections. The generated code was compiled output.

Chapter 7 repeats the shape on a different organ: the spreadsheet test that gave away the answer.

What "brain" means operationally

Calling the wiki a brain is not romance. Operationally it means: significance is judged there; relationships are typed there; questions are raised there; later work enters through navigable meaning rather than through ad hoc SQL dumps; regeneration is possible because bronze still holds the territory. A report generator can be pretty and still be dead as a cognitive substrate. A brain can be incomplete and still be alive as a substrate — flags, edges and open questions are features, not formatting errors.

That is why seven review flags in the retained run matter as much as ten pages. Flags are the system admitting unfinished judgment. Pages without flags are how consulting theatre hides uncertainty. The correction did not merely change a rendering path. It changed what kinds of objects the engagement is allowed to have.

What the gate actually validates

It is not enough to say "deterministic code validates the senior output." The project record lists the checks, and each check is a refusal of a known failure mode:

• Authority classes — so a page cannot claim a maturity or role it was not allowed to hold
• Evidence eligibility — so gold cannot cite material the model was not permitted to see
• Edge endpoints — so typed relationships cannot point into nowhere or into forbidden pages
• Page structure — so the build remains a wiki the system can re-enter, not free prose with a filename
• Consultant-source use — so steering that arrived as human input is not laundered into "observed estate"

Only after those checks does code stage the generated files, apply relational state in a transaction, and atomically promote the build. Partial promotion is how you create two truths — one in Markdown, one in SQLite — and then spend the engagement reconciling your own product. Atomic promotion is how you keep one truth.

The retained artefacts of a run are themselves part of the organ: requested aliases, actual returned models, junior and senior transcripts, the normalised mutation, and the resulting build. That is not logging for nostalgia. It is how you can later ask whether a gold page was a model invention or a gated synthesis over inspected evidence.

Load-bearing paths — the correction as code topology

The implemented correction is not a prompt tweak. It lives in named modules that follow the same family of design as the maintained dev-wiki engine: a wiki agent that runs the junior/senior phases, tools that expose bounded readers without a write terminal for the junior, and a wiki layer that can stage and promote. When the first implementation rendered gold from SQLite, those modules were either missing or inverted — the database was the author and the model was the optional copywriter. After the correction, the database is the binding substrate and the model is the significance author under gates.

That topology change is why "working software, wrong problem" is not a taste argument. The first system could generate pages. It could not implement the intended information flow:

observation / audit data in
        → LLM read
        → ingest to wiki
        → deterministic validate + atomic promote

If your "AI wiki" skips the middle two arrows and jumps from SQL to HTML, you have rebuilt the failure this correction killed.

Hygiene failure as positive evidence

The fixture-language incident deserves one more turn of the screw. Source descriptions containing words like "fixture" and "smoke test" were initially promoted into business-facing semantic gold. That is exactly the kind of silent laundering a deterministic renderer would also commit if it treated every stored string as meaning. The response was dual: curated gold so the engagement brain no longer spoke test-harness dialect, and immutable bronze so the original wording still existed as capture provenance. The page-style prompt was changed to prevent recurrence.

So the system now preserves two truths that consulting theatre usually collapses: the semantics discovered in a test estate, and the provenance of how that estate was created. Ten pages, eighteen edges, seven flags and forty-one junior tool calls are the numeric receipt of one live run. The hygiene correction is the qualitative receipt that gold and bronze are doing different jobs under pressure, not only in design docs.

The second major correction concerned client workbooks. It is the Hidden Gates doctrine under production load: when a capable system sees the answer key, the measure becomes a target, and you stop learning whether the intended work was done.

Before — the answer key in a lab coat

The original harness parsed a known spreadsheet contract and compared its derived target rows directly with SQLite. As a parser regression test, it was useful. As proof that an LLM could understand an unfamiliar physical workbook and reconcile it with discovered Power BI knowledge, it was a lie wearing a green badge.

Why? Because the hard work had already been done outside the model. The "target" was precomputed. The comparison was structural against a known shape. Fixture names and expected counts leaked the exam. You can pass that test while remaining incapable of reading a messy client workbook that was never designed as a schema document.

Many AI evaluations in the wild have this shape. They test whether the system can recover a secret that the harness already extracted. Then they publish accuracy. Then they ship. Then the first real workbook fails in ways the harness never allowed to exist.

After — physical bytes, safe packet, blind toolbelt, held-out oracle

The accepted path starts from the XLSX bytes and supplies no precomputed target breakdown.

XLSX.evidence v2 — manufacturing a world the model may inhabit

The extractor renders a structured evidence packet, not a dump of the workbook and not a pre-digested target model. Categories include:

• literal text coordinates and labels
• formulas
• sheet structure
• tables and defined names
• comments, notes and links
• validations and conditional formatting signals
• connection metadata and external links
• bounded indicators for Power Query, pivots, caches, slicers, charts
• embedded-model indicators
• package or security features such as VBA and signatures

Ordinary numeric, date and Boolean cell values stay out of the model packet. Secrets in supported connection metadata are masked. Opaque model, query, cache or VBA bodies are fingerprinted or reported as indicators rather than dumped. Every category reports whether it was found, absent, truncated, or merely detected without a full decoder.

That is not simple redaction. It is deciding what kind of world the model should inhabit — security, perception and compression in one boundary. The full privilege architecture around that move is Separation of Powers for Cognition. Here the specimen fact matters: design-time AI helped write complicated archaeology; runtime AI receives only the reviewed packet.

Blind comparison

The comparison toolbelt is deliberately isolated to current-gold pages. Target, mapping, decision and scope pages from earlier runs are invisible. Fixture names and expected counts are invisible. The model must identify requirements, cite workbook coordinates, and cite allowed current-gold pages in one terminal save_comparison. Deterministic code validates schema and evidence boundary. It does not decide whether a semantic mapping is direct, partial or missing.

Only after the result and transcript are saved does the evaluation harness reveal the fixture oracle.

That last sentence is the product claim. If the oracle is available during the run, you are not testing reconciliation. You are testing compliance with a secret answer sheet.

The retained live comparison — exact contract

The retained live comparison established the corrected contract. Numbers are exact. Provenance is the comparison documentation and implementation ledger in the project record.

An earlier historical run had classified two structurally present items as partial; it remains a useful receipt of why the comparison vocabulary was changed, not the final accepted result. Status vocabulary is product architecture. Calling a missing value-level detail "not implemented" invents scope. The corrected contract keeps validation questions from becoming false build mandates.

Spreadsheets as declarations, not oracles

This correction is also a career component wearing an engineering costume. On a multi-year spreadsheet-driven programme at a large insurer, spreadsheets functioned as a governance escape hatch: call it an application and it needs architecture, security, testing, ownership, funding and change control; call it a spreadsheet and someone can ship a small financial system before Friday's board meeting. Roughly two of three meetings were about reconciling those sheets to themselves or to the real world.

The organisation accumulates databases disguised as cell ranges, integration pipelines disguised as copy-and-paste, business rules disguised as formulas, master data disguised as lookup tabs, exceptions disguised as overwritten cells. The sheet is not simply rubbish. It is part application, part requirements document, part prototype, part historical receipt. The job is to interrogate it, recover useful specification, reconcile it with observed estate, and expose what remains ambiguous.

FDE BI therefore treats the workbook as a declaration, not an oracle. That is why blind comparison matters. If you pre-parse the "truth" out of the sheet, you have already decided the declaration is a schema. Sometimes it is a wish, a lie, a stale plan, or a shadow system that never matched production.

Downstream discipline

Consultant steering is passed separately from workbook evidence, with author, time and scope. Final dispositions are immutable receipts. Confirmed gaps and partials may enter scope; needs-evidence enters research; missing decisions keep the scope document blocked. Free-text consultant requirements use the same path through an explicitly virtual one-sheet workbook rather than pretending a physical XLSX existed.

Chapter 8 collects every retained number — including these — into one receipts chapter. Chapter 12 returns to why overruling this harness is authorship rather than fussiness.

Why "not found" is a first-class success

On the complete-miss workbook, eight not-found mappings are not an embarrassment. They are the system refusing to invent correspondences. A reconciler that always finds a home for every declared requirement is not smart. It is socially anxious. Consulting products inherit that social anxiety when commercial pressure rewards confident scope. Blind evaluation with a held-out oracle is how you train the opposite habit into the machine: missing is allowed; hallucination is not.

The partial workbook's ten direct and three not-found result is similarly load-bearing. Partial truth is the normal state of enterprise estates. Products that only have "match" and "fail" will launder partials into one or the other and create false build mandates. Status vocabulary is product architecture — Chapter 7 said it once; believe it twice.

From XLSX.text to XLSX.evidence v2 — the extractor had a before/after too

The spreadsheet correction is usually told as "blind compare versus parser regression." That is the evaluation story. There is also an extraction story. An earlier path rendered only sheet names and literal text cells as a compact text packet. Useful as a first sensor. Insufficient as a declaration of workbook intent. The accepted path uses the richer evidence packet: literal labels; formulas; sheet structure; tables and defined names; comments, notes and links; validation and conditional formatting; connections and external links; Power Query indicators; pivots, caches, slicers and charts; embedded-model indicators; package or security features such as VBA and signatures.

Every category reports whether it was found, absent, truncated, or merely detected without a full decoder. That status grammar is Hidden Gates thinking applied to perception itself. A silent absence is how systems pretend they looked. An explicit "detected without full decoder" is how systems admit the limit of the sensor while still giving the model something honest to reason over.

Ordinary numeric, date and Boolean values stay out of the model packet. Secrets in supported connection metadata are masked. Opaque model, query, cache or VBA bodies are fingerprinted or reported as indicators rather than dumped. The packet is not "the workbook with secrets blacked out." It is a manufactured world: secure enough, perceptual enough, compressed enough.

Design-time AI crystallised into a sensor

Here the specimen makes the "solidified AI" move concrete without reopening the full privilege book. Design-time AI investigated OOXML, discovered relevant structures, wrote extractors, wrote tests and revised them. Once accepted, that intelligence underwent a phase change:

probabilistic synthesis
→ inspected code
→ tested behaviour
→ versioned sensor
→ repeatable evidence

At runtime the Python extractor is not intelligent. It is prior intelligence crystallised into an executable mechanism. Existing software governance can review, test, hash, approve, deploy and roll it back. The organisation does not have to trust a live model with raw workbook access merely because AI helped author the program. That is why the first half of the project is not "chat with Excel." It is bring a messy, privacy-rich world into a safe text-native representation the runtime model is allowed to inhabit.

Blind toolbelt mechanics

The comparison path hands that packet to a model with an isolated current-gold toolbelt. Target, mapping, method, decision and scope pages from earlier runs are not visible. Fixture names and expected counts are not visible. The model must identify requirements, cite workbook coordinates, and cite allowed current-gold pages in one terminal result. Deterministic code checks schema and evidence boundary. It does not decide whether a semantic mapping is direct, partial or missing. Only after result and transcript are saved does the harness reveal the fixture oracle.

Consultant guidance is passed separately from workbook evidence — with author, time and workbook or sheet scope — so human steering cannot be smuggled in as if the sheet said it. Free-text consultant requirements use the same path through an explicitly virtual one-sheet workbook rather than pretending a physical XLSX existed. That is anti-laundering architecture: every declaration has a type, even when the declaration arrived as prose.

Vocabulary change as product architecture

An earlier historical run had classified two structurally present items as partial. That run remains a useful receipt of why the comparison vocabulary was changed, not the final accepted result. Missing value-level detail is a validation question, not invented implementation scope. Confirmed gaps and partials may enter scope; needs-evidence enters research; missing decisions keep the scope document blocked. Status words are commercial commitments. Treating them as UI labels is how answer-key culture returns through the front door after you locked the back door with a held-out oracle.

The retained contract stays exact: matching workbook, fourteen of fourteen direct; partial workbook, ten direct and three not found; complete-miss workbook, eight not found and zero mapped. Those numbers are not a leaderboard. They are the acceptance criteria for a claim about intelligent reconciliation under isolation.

Product of One draws a hard line: the evidence package is part of the product. Ten minutes of receipts convert a great story into a demonstrable one. Without them you are selling vibes with a marketplace costume.

This chapter is that package for FDE BI. It is deliberately dense. A sceptical reader who distrusts the compile-time claim should be able to sit here and audit.

Deployment receipts

• Application: https://fde-bi.leverageai.com.au
• Health: https://fde-bi.leverageai.com.au/healthz
• Operating path: Supervisor on origin; Cloudflare Tunnel publish path per project deployment record
• Session verification: health endpoint returned ok status against the runtime SQLite database during the research pass for this book (2026-08-03)

Live is not the same as client-production-ready. The next section of non-claims is not a footnote; it is part of the receipt.

Wiki authoring receipt

Retained live junior/senior wiki authoring run, from the implementation and test ledger:

Interpretation discipline: do not sell "ten pages" as the miracle. Sell the allocation — long inspect trail, typed edges, flags, atomic senior save, deterministic validation. Chapter 6 owns the architecture story; this row is the numeric receipt.

Blind comparison receipt

Contract reminders that travel with the numbers: oracle revealed only after save; model cites workbook coordinates and allowed current-gold pages; code validates citations but does not decide semantic mapping. Chapter 7 owns the before/after; this table is the numeric acceptance contract.

Report honesty receipt

The Data Readiness Report, on the retained synthetic path, does not pretend matching names prove production correctness. It distinguishes:

• 24 found
• 6 partially supported
• 15 not found

while explicitly stating that all 45 scope-bearing findings remain unreviewed model positions.

The Scope/SOW carries that uncertainty forward rather than concealing it:

• 0 consultant decisions
• 45 model findings used as the working position
• 21 proposed work items
• 2 weak-signal assumptions
• explicit client responsibilities
• explicit exclusions
• acceptance criteria that can actually fail

Most consulting scopes erase the uncertainty that produced them. This one preserves it and tells the buyer exactly what remains conditional. That is Proof-Carrying Transformation as document behaviour.

The 46-versus-45 seam

The dashboard can show 46 findings while 45 require a call and the reports describe 45 scope-bearing instances. The honest presentation is:

46 total findings · 45 scope-bearing · 1 context-only

Unexplained count differences are exactly the kind of thing that damages confidence in an evidence product. Receipts discipline includes labelling seams, not only celebrating matches.

Organising line of the UI

The central message of the deployed surface is not "AI found 45 things." It is:

45 findings still need your call.

Chapter 9 develops that decision surface. As a receipt, note only this: the product's primary object is human disposition, and the retained report path still shows zero consultant decisions. That combination is honesty, not failure — on a synthetic run, zero decisions is the correct state until a consultant acts.

What these receipts refuse to claim

• Real client estate and workbook completed under client data policy
• Named consultant decisions, including rejections, on a live engagement
• Accepted scope ready for commercial issue after human disposition
• A legitimate "do not build" outcome on a real buyer
• Engagement-two proof that another operator can run the vessel with far less dependence on the original expert
• Authenticated multi-user decision workflow as finished production
• Adversarial and prompt-injection evaluation as complete
• Windows service packaging inside the disposable guest as the delivery form

Chapter 13 turns those non-claims into a next-proof protocol. Here they protect the numbers you just read from being laundered into a portfolio story.

How to read a receipt without lying to yourself

Receipts can be misused as easily as they can be ignored. Three misuse patterns to refuse while you hold the tables above:

1. Vanity counts. Ten pages and fourteen mappings sound like a scoreboard. They are not. They are contract outputs under a specified harness. Change the harness and the number means something else.
2. Portfolio laundering. A live URL plus synthetic success is not three client logos. Do not let your marketing brain perform silent multiplication.
3. Precision theatre. Exact numbers are required when the ledger has them. When the ledger does not, write the shape in words. Inventing a third decimal place is not more scientific — it is fraud with better formatting.

Microsoft's own governance tooling around Fabric metadata scanning is a useful external rhyme: inventory and lineage can be first-class without treating ordinary row-level business data as the primary product.⁴ FDE BI is not that product; the rhyme is methodological. Measure structure and meaning carefully; do not confuse structure with completed business truth.

How reports themselves carry provenance

Receipts are not only harness numbers. The reporting path is designed so a sendable client document is a fingerprint of admissible evidence, not a chat souvenir. The project record describes a bundle builder that assembles the facts a report is allowed to use and fingerprints the evidence rather than the assembly time. The report service stores the actual bundle and prompt, retains requested and actual model information, and appends a deterministic provenance footer that the model does not write. Documents convert generated Markdown into browser HTML or a Word file. Tests make a report stale when its evidence changes and verify the provenance route.

That is Product of One applied to the artefact clients actually receive. If the report can be regenerated with different evidence and the same confident prose, you do not have a receipt — you have a brochure. Staleness when evidence changes is how the product refuses brochure physics.

The draft-scope seam as a receipt, not a scandal

One seam in the retained package is easy to misread as contradiction. The project account says scope remains blocked until every material finding is decided. A SOW was nevertheless generated with zero consultant decisions under a working rule that silence can carry the model position into scope preparation. Those can coexist only if states stay unmistakable:

• model-generated draft scope
• consultant-reviewed scope
• client-agreed scope
• scope ready for commercial issue

The dashboard's "0 scope ready" is good. Keeping that distinction equally prominent on every generated report is part of receipts discipline. A draft that looks final is how evidence products lose trust. A draft that looks like a draft — zero decisions, forty-five model findings as working position, twenty-one proposed work items, two weak-signal assumptions, explicit exclusions and fail-able acceptance criteria — is how uncertainty survives contact with a Word document.

Vessel receipts versus Marketplace mythology

The intended commercial rail is AWS Marketplace as installation and procurement of a client-contained vessel. The receipt that matters today is not "listed." It is the layering the specimen already implements: software holds evidence and queues; the human FDE owns ambiguity and rulings; the client receives inventory, decisions and scope; the firm retains compiler, extractors, prompts, tests and kernel. Listing without that layering would be packaging cosplay. Layering without operated client dispositions is still n=1 engineering proof — which this book states plainly.

What the full retained package therefore claims, no more and no less:

• Live deploy and health path under Supervisor and Cloudflare Tunnel
• Wiki authoring run: 10 pages, 18 edges, 7 flags, 41 junior tool calls
• Blind comparison: 14/14; 10 direct + 3 not found; 8 not found
• Report honesty: 24 found, 6 partial, 15 not found; 45 scope-bearing unreviewed; 0 consultant decisions; 21 work items; 2 weak-signal assumptions
• Presentation seam labelled: 46 total · 45 scope-bearing · 1 context-only
• Organising UI object: findings still need a human call
• Explicit non-claims: synthetic runs; multi-user auth; client data policy; adversarial evaluation; Windows service packaging; engagement-two operator proof

That list is the evidence package. Everything else is narrative around it. If a later marketing sentence cannot point at a line on this list, it is not allowed to borrow the specimen's credibility.

If you only remember one line from the deployed surface, remember this:

45 findings still need your call.

Not "AI found forty-five things." Not "forty-five insights ready to implement." The sentence puts the human decision in the centre of the product. Everything else — gold pages, comparison results, draft scope language — is upstream or downstream of that surface.

Epistemic status made operational

The impressive part of FDE BI is not model accuracy on fixtures. It is that epistemic status became application architecture.

Separate states exist for:

• what the audit observed
• what the workbook declared
• what the model interpreted
• what a consultant accepted, changed, rejected or escalated
• what may become scope

The model can investigate, synthesise and nominate. It cannot quietly make a consultant decision or mutate authoritative state. The junior–senior split, citation validation, isolated toolbelt and atomic terminal mutation are not decorative governance. They are the application.

That is Discussed Is Not Deployed in executable form: a claim may not occupy a higher maturity rung than its evidence supports. In project-intelligence language the rungs are discussed through accepted. In FDE BI the parallel rungs are observed through scoped. Collapsing them is how consulting theatre happens — a deck that sounds decided while nothing has been disposed.

Scope is a privilege, not a print button

Scope remains blocked until every material finding has been decided. That is the binding rule. A draft scope can still be generated for inspection under an explicit working-position rule — model findings carried forward with zero consultant decisions — but that draft is not consultant-reviewed scope, not client-agreed scope, and not scope ready for commercial issue.

Those states must be impossible to confuse:

1. Model-generated draft scope — working position, uncertainty preserved
2. Consultant-reviewed scope — material findings disposed
3. Client-agreed scope — buyer has accepted the readiness position
4. Scope ready for commercial issue — procurement can proceed without reopening the epistemology

The dashboard's "0 scope ready" is good. Keep that distinction equally prominent on every generated report. If silence can carry model position into draft preparation, the product must shout that the draft is still a model position. Otherwise you have rebuilt the oracle deck with better CSS.

Uncertainty preserved into the commercial document

Chapter 8 retained the report numbers: twenty-four found, six partially supported, fifteen not found; forty-five scope-bearing findings unreviewed; zero consultant decisions; twenty-one proposed work items; two weak-signal assumptions. The point for this chapter is behavioural: the SOW language does not pretend those zeros are ones.

Most consulting scopes erase the uncertainty that produced them. They translate ambiguity into confident work packages because confidence is what gets signed. FDE BI's reports do the opposite. They carry conditional structure — client responsibilities, exclusions, acceptance criteria that can fail — so the next engagement is a continuation of an evidence chain rather than a new fiction.

That is Proof-Carrying Transformation as document discipline: the valuable object is the unbroken chain from evidence through decision and scope, not polished recommendation text.

Unit of human work

Under traditional consulting, senior effort scales with sources × requirements × undocumented dependencies × interpretation cycles. The consultant holds the estate mentally. Under FDE BI, machine effort absorbs extraction, bounded search and item-level judgment; senior human effort concentrates on material findings, genuine exceptions and consequential decisions.

The better claim is not that complexity becomes constant. A thousand spreadsheets still cost more machine work than ten. The better claim is:

FDE BI changes the unit of human work from understanding the whole estate to disposing bounded findings.

That is why "45 findings still need your call" is not a UI flourish. It is the economic object of the product. Breadth becomes cheap, parallel machine work. Depth becomes selective wiki walking and drill-down. Human attention is reserved for the small set of places where interpretation, authority or consequence remains material.

The commercial packaging of a fixed-price readiness product that buys this kind of certainty before implementation is owned by Buy Certainty First. This chapter only needs the specimen fact: the decision surface exists, and scope is not allowed to pretend it does not.

What the consultant is for

Once findings are bounded, the consultant is not primarily a research intern for the estate. The consultant is a disposition authority with commercial and relational accountability. That is a different job description than "person who reads all the spreadsheets." It is closer to a control-room operator than to a lone archaeologist.

This is also where AI-constituted service economics peek through without taking over the chapter. A fixed-price readiness product that requires a senior to re-hold the whole many-to-many graph will not stay fixed-price for long. A readiness product that requires a senior to dispose material findings — with the graph held by the system — can at least be designed as a product. The general layer is AI-Constituted Services. The specimen contribution is the decision surface that makes the economics thinkable.

If your AI consulting tool has no place where a human can reject a finding with a receipt, you have not built a decision product. You have built a content generator pointed at a SOW template.

A Power BI expert might have built an audit utility. An AI developer might have built an impressive workbook demo. A TOGAF architect might have produced a current-to-target deck. A salesperson might have described a "two-week readiness assessment." A software firm might have built a generic SaaS scanner.

FDE BI joined those perspectives into a client-contained engagement vessel that observes an estate, understands spreadsheet intent, creates a governed decision surface, and compiles the result into the next commercial transaction. That shape required multiple backgrounds at once — not as a CV collage, but as compiled components an agent could inherit.

The career→component table

This is the definitive placement of the mapping from earlier capability to product organ. It is the human side of the doctrine→instance table in Chapter 5.

Walk the load-bearing rows

Accounting — the product is reconciliation, not chrome

An accounting education trains a person to care about definitions, cut-offs, approvals and whether two numbers that look related are actually the same claim. Inside FDE BI that becomes product instinct: measures and mappings matter more than dashboard decoration; "found" is not "production correct"; partial support is a first-class state. Without that instinct you ship pretty tiles that cannot survive a CFO's second question.

Spreadsheet programme — the governance escape hatch

On a multi-year spreadsheet-driven programme at a large insurer, the pattern was obvious and expensive. Call it an application and the enterprise demands rigor. Call it a spreadsheet and the same organisation tolerates a shadow database that still drives board-facing analysis. Meetings become reconciliation theatre. Systems update; sheets lag; someone pastes; someone overwrites; someone swears the VLOOKUP is the master.

That experience is why FDE BI treats workbooks as declarations and why Chapter 7's blind comparison exists. A pure software engineer might see Excel as a file format. A pure BI developer might see it as a bad report. The compiled view sees a shadow system that contains demand, semantics, exceptions and tuition — and still refuses to treat it as oracle.

TOGAF ADM — stages that cannot collapse

Ordinary architecture exercises produce documents. FDE BI produces states. Observed is not declared. Declared is not interpreted. Interpreted is not agreed. Agreed is not scoped. The ADM sequence becomes a machine that refuses silent promotion. That is enterprise architecture influence without enterprise architecture cosplay.

Legacy thinking — the estate is tuition

Legacy systems are not only debt. They contain requirements, behaviour, exceptions and institutional learning. The same principle applies to workbooks and Power BI estates: the job is to recover what the organisation has already paid to learn, then expose what remains ambiguous. AI Legacy Takeover develops that doctrine for codebases; here it is applied to BI and spreadsheet reality without re-minting the full framework.

Systems administration — disposable environments

Knowing how to build, destroy and rebuild a Windows guest with pinned inputs is not glamorous. It is what makes unfamiliar platform discovery safe. The agent outside the VM builds the VM; mistakes get folded back into prompts; the factory improves. Without that background, "learn Power BI in a day" becomes a snowflake laptop story.

Consulting ownership — the SOW bottleneck

When I ran my own consultancy, statements of work were so costly and error-prone I wrote them myself. Sales staff and senior technical staff could not reliably produce them fast enough or correctly enough. That bottleneck limits how much work you can even bother to write up. As a services firm grows without products, the problem scales.

FDE BI's stop at evidence-backed scope is a direct response to that pain. The commercial protocol that productises certainty before implementation is Buy Certainty First. The specimen contributes the machine that makes the SOW a receipt of decisions rather than a speculative essay.

Wiki and frameworks — north star during construction

The IP and dev wiki did not arrive after architecture drift for a retrospective write-up. They were available during the build. That is why inherited orientation works — Chapter 11 — and why doctrine could generate organs — Chapter 5. A career that is only biological recall cannot do this. A career that is only a document graveyard cannot either. The career has to be compiled.

Counterfactuals

Remove accounting and finance instinct: you get scanners that do not know what a reconciliation argument is.

Remove spreadsheet programme scar tissue: you treat Excel as junk or as oracle — both wrong.

Remove ADM discipline: states collapse into one confident answer.

Remove sysadmin factory skill: environments become unreproducible demos.

Remove consultancy ownership pain: you optimise the wrong bottleneck and ship another unpaid proposal tool.

Remove AI governance research: you get fluency without receipts.

Remove terminal-value pressure: you build a faster version of a dying labour model and call it innovation.

The joins are the rare part.

Forty-five years as a compression ratio

Roughly forty-five years — from childhood computers through accounting, systems work, architecture, consultancy ownership, sales, and recent AI research — is not a brand story. It is a compression ratio claim. The claim is that those years were not merely lived; they were eventually compiled so they could condition a day of construction. Uncompiled, the same years are a CV. Compiled, they are starting altitude.

Other people have long careers. The differentiator is not longevity. It is whether the career became addressable during live work. Most organisations still pay the setup tax on every project: retell the approach, re-find the documents, re-argue the non-negotiables. FDE BI is what it looks like when that tax has already been paid into a kernel and the remaining bill is mostly assembly plus evaluation.

When the coding agent was building FDE BI, it had access to the IP wiki and to prior source code. I did not have to repeat all the little things I had learned over time. They were self-evident to the agent.

That sentence is easy to misread as "big context window." It is not. It is Orientation Capital under production load.

Prepaid understanding

Orientation Capital is the durable, reusable compilation of judgment, history, capabilities, relationships and current state that lets new work begin oriented rather than cold. Cold prompts re-pay setup every time. Compiled worlds turn prompts into addresses.

The prompt has stopped being the specification. The prompt is becoming a pointer into a compiled self.

Fewer words are the least interesting part of the experience. The important change is the starting altitude of the work that returns. FDE BI did not save a few hours of background paragraphs. It began with doctrines, rejected approaches, commercial instincts and prior code already co-present enough that Power BI could be the final vocabulary rather than the entire education.

Not better memory

Memory answers: what did we store? Retrieval answers: what is similar to this query? Orientation answers: what world must be co-present so this act of work can begin without re-deriving identity?

Three failures of the memory framing:

1. Storage without integration is retention, not learning. A fact in an append-only log is retained. A fact related to prior beliefs, exceptions and transferable principles has been learned into orientation.
2. Similarity is not stance. Retrieving a nearby paragraph does not load the doctrines that change which options the system will propose or refuse.
3. Cold packs of documents are not attention-resident judgment. Dumping the intranet into a window is capacity theatre.

Compounded Execution Capital makes the same conversion for market value: a career becomes portable execution capacity only when judgment, history, code, rejected approaches and evidence are compiled into a callable substrate. FDE BI is that conversion caught in the act of construction, not described after the fact.

Historical rhyme — 2009

There is a smaller version of this pattern in the work archive from 2009. Prior code was reused to produce a WORM, CRC-checked, deduplicating Java attachment archiver in about four hours, intended for real use. At the time the note was:

If you are focussed you can pull off a lot of coding fast.

Earlier systems that turned accounting and consulting operations into requirements, object design, Java, databases, reporting and attempted productisation are precursors too. So is the recurring requirements → estimate → fixed-price or T&M → completion cycle that FDE BI now tries to instrument and improve.

The ability to make large interdisciplinary leaps quickly is not new. What is new is that:

• the reusable knowledge is now compiled
• frontier cognition is available on demand
• implementation has become cheap
• agents can inherit prior work directly
• feedback from each project can return to the kernel

The old version was an unusually productive person working from memory and prior code. The new version is that person plus a compiled self plus a software factory.

Why it feels like sudden convergence

Compounding often looks linear while it accumulates and discontinuous when it crosses a threshold. For decades the capabilities were separate: accounting, architecture, application development, infrastructure, consulting operations, sales, product strategy, governance, writing and framework formation. The IP wiki changed their topology. They stopped being separate entries on a CV and became simultaneously callable components of one operating system. Then coding agents made production cheap enough for the combined thought to become a working application almost immediately.

So yes, the timing is extraordinary. It is not merely luck. The technology arrived at the moment the machinery capable of using an entire background at once had finally been built.

Everything's coming up Scott — carefully

Milhouse, in The Simpsons, has a line about everything coming up Milhouse. For a stretch it felt like everything's coming up Scott: roughly forty-five years of capability landing on one pin-point. The line is fun. It is also dangerous if it becomes pure swagger. The mechanism underneath is orientation capital plus compounded execution capital plus cheap assembly. Without the mechanism, the cultural reference is just a victory lap. With the mechanism, it is a human way of naming threshold effects.

What the agent inherited in practice

Inherited orientation is not a mystical bond with a model. In this build it meant concrete co-presence: prior framework pages the agent could walk; prior code patterns for evidence stores and wiki tools; north-star prompts that already encoded non-negotiables; tests that already expressed what "done" means for authority boundaries. The operator still had to steer. The operator did not have to rebuild the worldview from a blank chat every morning.

That is why six months of intensive AI research and years of earlier writing show up as project speed rather than as a bibliography. The bibliography became a runtime. Executable Worldview names the closed composition; this chapter names the felt experience when the composition works: less re-explaining, higher ambition, returned work that cites organisational specifics you did not retype.

A lazy culture war runs in both directions. One side says: if you did not type the code, you are not the author. The other side says: if the AI wrote it, the human is a spectator. Both are wrong about this specimen.

Prompt Is Source already relocated source upstream of source code: the durable package is intent, design, prompts, context, tests, starting state and decisions that cannot be safely inferred. Generated code is honestly intermediate representation only when that package can regenerate equivalent behaviour.

FDE BI makes that abstract claim visceral. The coding agent wrote implementation. The human supplied the intended world, the product boundary, the division of responsibility, the tests of whether the idea was genuine, and the reasons plausible substitutes were insufficient.

The signature is the override

Chapters 6 and 7 already walked the two corrections. Here is the authorship reading of the same events.

Correction one. Functional wiki-from-SQL software existed. It was killed because a report is not a brain. The evaluation function recognised missing significance allocation.

Correction two. Functional spreadsheet harness existed. It was killed because a parser regression is not blind reconciliation. The evaluation function recognised an answer key corrupting the measure.

In both cases the agent had produced software that ran. In both cases the human identified that it solved the wrong problem. That is not "guidance." That is the product decision that no amount of fluent generation can replace.

That is the scarce job.

Two physical states of AI — without re-minting 203

There is a further authorship subtlety. Design-time AI wrote complicated deterministic extractors — spreadsheet archaeology, structure detection, masking, fingerprints. Once accepted, that intelligence underwent a phase change: probabilistic synthesis became inspected code, tested behaviour, versioned sensor, repeatable evidence. Runtime AI then interprets only inside the safe world those sensors manufacture.

So AI appears twice: live and solidified. Humans appear once where it counts: disposition authority. Deterministic compilers bind approved transitions. That separation is the privilege architecture developed fully in Separation of Powers for Cognition. The specimen authorship claim is narrower: using AI to write the sensors does not make the sensors "the AI" at runtime, and using AI to propose mappings does not make the model the consultant.

Contrast: receiptless authority

The Tesla Service AI case study is useful here as contrast, not as car diagnosis. When AI is given operational authority without membership, evidence and accountability, it can become an invisible foreman — locally efficient, globally trust-destroying.

FDE BI is the opposite shape on the authority question. Model output is provisional. Findings need a call. Scope stays blocked. Working implementations get overruled. Receipts are retained. The human is not cleaning up after an invisible foreman; the human is the disposition authority the system was built around. That is why "45 findings still need your call" is not a weakness of the demo. It is the design working.

What would count as non-authorship

If the human only accepted every first green path; if no test distinguished answer-key evaluation from blind evaluation; if gold were whatever SQL emitted; if scope printed from model confidence; if limits were hidden — then yes, calling that "authored product strategy" would be fraudulent. Authorship is not a vibe attached to a repo. It is a trail of evaluation moves that changed the system when fluency was insufficient.

FDE BI can answer those. That is the operational meaning of authorship without typing.

Delete Test, applied loosely but honestly

Prompt Is Source proposes a Delete Test: if deleting the generated implementation loses judgment that exists nowhere upstream, the code is still partly source; if equivalent behaviour regenerates from the package, the code has become disposable IR. Applied to FDE BI without theatre: many extractors and factory scripts could likely be regenerated from prompts, tests and design docs; the two corrections could not be inferred from green tests alone, because the first greens were the problem. The non-inferable residue — the evaluation moves — is exactly where authorship concentrates when typing is cheap.

Keep the source maps. Transcripts, prompts, correction notes and ledgers are not chat debris. They are the symbols later regeneration and reverse engineering need. A firm that discards them and keeps only the repo has thrown away the compiler inputs and kept the object files.

What the human must still sign

Even with perfect extractors and brilliant mappings, someone must still sign the readiness position. Signing is not a UI click. It is acceptance of commercial and relational consequences: what the client will fund next, what will be excluded, what uncertainty remains, what happens if acceptance criteria fail. AI can draft the language of that position. AI cannot carry the blame in the room when the position is wrong. Architecture that forgets this will eventually hide the signature until something breaks publicly.

FDE BI's "findings still need your call" is a reminder of that signature. Authorship without typing does not mean authorship without responsibility. It means responsibility concentrates on evaluation and disposition while typing is delegated. That is a more adult division of labour than either "human types everything" or "model owns the outcome."

If this book tapered here into vague "future work," it would betray its own receipts doctrine. Limits are not the embarrassing appendix. They are how an evidence product remains an evidence product.

What is true now — and what is not

True: a deployed workbench exists; synthetic harnesses exercise wiki authoring and blind comparison; reports can preserve zero consultant decisions; architecture enforces authority classes; health endpoints answer; the doctrine→instance join is real in code.

Not true: this is a finished multi-client production engagement platform with completed data policy, multi-user authentication, adversarial evaluation and Windows-service packaging as the standard delivery form. The project record is explicit. So is this chapter.

Limitation inventory

• Retained runs are synthetic — fixture estates and workbooks, not a named client production cutover
• Authenticated multi-user decision operations remain a next increment
• Client data policy, retention, redaction and access-control packaging remain explicit work
• Adversarial-source and prompt-injection evaluation are not claimed complete
• Invalid-review repair and frozen junior-trail replay against alternate seniors remain engineering backlog
• Automated source staleness and revalidation remain future apparatus
• Windows service packaging inside the disposable guest remains later
• Marketplace listing as operated commercial rail is strategy, not a completed proof package in this book
• Engagement-two operator independence is not yet demonstrated

Product of One would treat hiding any of the above as a failure of the offer's chain of custody.

Four next-proof increments

The synthetic harness is excellent engineering proof. The next proof package should contain the following. These are not slogans; they are acceptance criteria a reader could run.

1. Real estate and workbook

One real Power BI estate and one real set of client workbooks — under appropriate permission and data policy — exercised through the same bronze → gold → compare → dispose path. Synthetic fixtures test contracts. Real mess tests whether the contracts survive institutional entropy.

2. Named consultant decisions, including rejection

Material findings disposed by a named human with immutable receipts. At least one model finding rejected or materially modified. A rejection strengthens the product more than another perfect fixture run because it demonstrates that the consultant surface is real rather than ceremonial. If every finding is always accepted, you have an automation costume, not a decision product.

3. Final accepted scope with full trace

A source-to-finding-to-decision-to-SOW trace that a third party can walk without narrative glue. Bronze pointers resolve. Dispositions resolve. Scope items retain identity and provenance. Acceptance criteria can fail. This is Proof-Carrying Transformation as external audit, not internal confidence.

4. A legitimate "not ready" or "do not build" outcome

The product must be allowed to conclude that implementation should not proceed. If the only allowed ending is a build package, the system is a sales funnel with evidence cosplay. A readiness product that cannot say no is not a readiness product.

Engagement two — the operator test

The first live engagement can still be original-expert heroics. The stronger test is whether another competent data consultant can use the vessel on the next client with much less dependence on the person who compiled the career. That is a Practice OS style test: shared infrastructure improved the operator, rather than merely helping the original expert work harder. We do not re-mint Practice OS here; we borrow the falsifier. If engagement two still requires the same heroic compiler-of-self, the vessel is not yet a productised practice asset.

What would falsify the compile-time claim

• Showing that the same day-scale result is routine for operators without compiled orientation, doctrines or prior code — then "compile time" was just "AI is fast"
• Showing that the two corrections were unnecessary and the first green paths were the real product thesis
• Showing that held-out evaluation does not change outcomes versus answer-key harnesses
• Showing that authority classes are UI labels without binding effect on scope

This book stakes the opposite: without compiled source and evaluation overrides, you get demos; with them, you get a consulting vessel worth instrumenting further.

Sibling handoffs

If the next question is "what class of service is this economically?", go to AI-Constituted Services — and notice that piece pointed at FDE BI as summary while this book owned the biography.

If the next question is "how do sensors, safe worlds and privilege separate?", go to Separation of Powers for Cognition.

If the next question is "how do we sell fixed-price certainty without unpaid SOW theatre?", go to Buy Certainty First.

Marketplace without mythology

AWS Marketplace is a real procurement rail, not a metaphor.³ Positioning FDE BI as an installable vessel on that rail is coherent with Product of One and with client-contained engagement design. It is not, by itself, proof that the readiness transaction has been operated end to end with a buyer. Do not let "we will list it" become a substitute for the four next-proof increments above. Listing is packaging. Proof is operated evidence under disposition authority.

Similarly, calling the entry product a Data Readiness Review is naming, not completion. Names help commercial legibility. Names do not replace named decisions, rejected findings, or a do-not-build outcome. Chapter 8's receipts are the floor. This chapter's next proofs are the staircase. The roof is a practice that can run engagement two without heroics from the original compiler of the career.

How to run the next proof without moving the goalposts

Goalpost-moving is the enemy of receipts. If a real engagement is run but rejections are quietly discouraged; if a do-not-build outcome is relabelled as "phase zero education"; if traces exist only in chat logs; if engagement two still depends on the original expert but is marketed as productisation — then the next proof package has been faked even if the software ran.

Pin the acceptance criteria before the engagement starts. Publish them internally the way Chapter 8 publishes synthetic numbers. Then let the engagement write the ledger. The point of n=1 honesty now is to earn the right to a harder n later — not to make n=1 a permanent lifestyle.

Return to the reader question this book promised to answer:

How does one person ship a governed, deployed consulting product in a day — and what did the AI actually contribute versus the human?

AI contributed Power BI's nouns and the cheap assembly of implementation under north-star prompts, including design-time extractor writing and runtime synthesis over safe evidence. The human contributed the evaluation function: product thesis, state machine, authority allocation, the two corrections, which tests count, and a career's worth of joins that made those judgments possible in the first place.

The day was compile time. The source was roughly forty-five years of capability finally made executable at the moment execution became cheap.

Five physics changes

1. Starting altitude

The first serious token of work already sits inside a world — frameworks, rejected approaches, commercial instincts, prior code — not in a vacuum. Cold start is a different physical regime from oriented start. Chapter 11 named this prepaid orientation.

2. Prompt as pointer

You stop restating your worldview. You address it. "Self-evident to the coding agent" is what pointer semantics feel like from the operator's chair.

3. Doctrine as generator

Frameworks are not essays published after shipping. They emit organs. Chapter 5's doctrine→instance table is the instrument. If your frameworks only decorate retrospectives, you do not have this physics. You have literature.

4. Corrections as the scarce surface

When assembly is cheap, the job that remains is recognising working software that solves the wrong problem. Chapters 6 and 7 are the exhibits. Chapter 12 is the authorship reading. Fluency is abundant. Evaluation is scarce.

5. Receipts as product

Speed without an evidence package is a LinkedIn story. Speed with ledgers, health endpoints, held-out tests and stated limits is a consulting product. Chapter 8 is the ledger. Chapter 13 is the refusal to launder it.

What you can do with this without minting a new religion

This book mints no new framework. It is production evidence. Still, a principal can steal the operating moves:

1. Write down which doctrines you claim generate which product organs — or admit you are labelling after the fact
2. Force dual discovery tracks where consensus would hide disagreement
3. Build held-out evaluations for any claim that sounds like intelligence rather than parsing
4. Make authority classes binding on scope, not decorative on slides
5. Retain exact numbers with provenance; describe shape in words when you lack a number
6. Kill working software that solves the wrong problem — and keep the kill as a first-class receipt of authorship
7. State n=1 as n=1; specify the next proof package before you sell a portfolio story

The line to keep

That is not just a story about a successful project. It is evidence that a personal IP system can do what it claimed: turn accumulated experience into compounded execution capital at the exact moment the world made execution cheap.

The deck explained the engagement shape. The workbench now performs the first commercially decisive part of that engagement: determining what is true, what is wanted, what remains undecided, and what can safely be sold next.

The deck became software. The software still stops where a human must call the findings. That is not a bug in the demo. That is the product.

Closing the loop without opening a new framework

It is tempting, at the end of a case study, to mint a new named doctrine so the specimen feels "complete." Resist that. Completeness here is the opposite: the specimen is complete when it has been told with organs, corrections, receipts, career joins, limits and consequence — and when sibling books still own their layers. Rung-two evidence that tries to become rung-one IP mid-epilogue usually dilutes both.

If you take only one operational habit from FDE BI into your own shop, take this: when the agent hands you working software, ask whether it solved the problem you meant, or a neighbouring problem that was easier to green. Then keep the answer as a receipt. That habit is how a compiled career stays compiled — each override returns to the kernel instead of evaporating into oral history.