In 2025, I built a highly functional prototype using Google AI Studio.
It was fast, direct, and surprisingly capable. I described what I wanted, watched the application take shape in the browser, refined the interface, and produced something that demonstrated how AI could support a different model of project and governance work.
I did not surround that prototype with extensive GitHub controls, independent model reviews, deterministic validation, evidence-release boundaries, or a formal distinction between proposed and accepted state. It was an experiment in whether the product experience could work.
It did.
By the time I returned to the idea in 2026, I was no longer trying to answer the same question. The book had changed how I understood the problem. I was not simply asking whether AI could help someone navigate project information. I was asking whether a system could preserve the chain from funded intent through delivery evidence, changing project state, executive interpretation, and authorized decision.
That was a much harder problem.
The new prototype needed to distinguish evidence from interpretation, proposed changes from accepted state, operational facts from reconstructed history, and AI-generated analysis from human authority. It needed to preserve uncertainty rather than improve the appearance of completeness. It needed to remember what the organization knew at a particular point without allowing later evidence to leak backward into the record.
In other words, the 2025 prototype asked whether the experience could be built.
The 2026 effort asked whether it could be governed.
What We Actually Built
The later work separated into two repositories.
What I casually called the “backend” was not a conventional application server or database. It was a Governed Investment Record maintained in GitHub as a canonical state and control layer.
The repository began with the funded belief: the outcomes, benefits, costs, assumptions, scope, deliverables, success conditions, risks, dependencies, and approval context that appeared to justify the original investment. Operational evidence would then be reconciled against that remembered state as the project progressed.
AI could inspect evidence and propose changes. It could not silently convert those proposals into institutional truth. Material changes required traceable evidence, deterministic validation, review, and identifiable human acceptance.
To test that architecture without hindsight, we used a historical project as a controlled replay environment. The system could see only the evidence authorized for a particular point in time. Later status reports, later decisions, and known outcomes remained outside the boundary. Contradictions stayed unresolved unless the authorized evidence and responsible human authority resolved them.
That effort produced an accepted Kernel v2 containing seven machine-readable schemas, evidence and replay controls, persistent object identities, first-class contradiction records, state-event history, validation tools, test fixtures, and GitHub Actions checks.
We then built a proposed Day-0 Governed Investment Record from four bounded startup sources. It contained 51 individually addressable funded-intent objects, four evidence records, explicit unknowns, confidence classifications, proof conditions, and an unresolved schedule contradiction. The source documents remained outside GitHub while sanitized evidence metadata and lineage entered the governed record.
The frontend was deliberately separated from that system.
It was a read-only React and TypeScript application using a lightweight Vite build. It did not have a database, authentication system, AI functionality, write controls, or production infrastructure. It consumed a frozen, noncanonical presentation snapshot tied to an exact backend commit.
Its purpose was straightforward: allow someone to understand the investment record without reading JSON files in a repository.
The frontend eventually included an executive investment overview, a record explorer, and an object inspector. It preserved distinctions among proposed, accepted, unresolved, and unknown conditions. It showed evidence references and relationships without inventing scores, selecting among contradictory propositions, or implying that acceptance meant the project was healthy.
A further Evidence and Provenance view was built and prepared for review, but not merged.
That is where the cost picture became impossible for me to ignore.
The Prototype Was Minimal. Its Assurance System Was Not.
The frontend was modest in product terms. It was static, read-only, and intentionally narrow.
Its assurance system became much larger.
Claude was not merely creating pages and styling components. It was proving that the presentation layer had not changed the meaning of the governed record. It generated snapshot controls, canonical-fidelity checks, semantic-preservation tests, confidentiality scans, deterministic selectors, source-provenance controls, and regression tests for distinctions that could not be allowed to collapse.
By the time the next frontend increment was prepared, the test suite reported 245 passing tests.
That rigor was not meaningless. Many of those controls addressed real risks. A read-only interface can still misrepresent the source. A label, summary, color, calculated count, or inferred relationship can quietly convert uncertainty into apparent fact. The frontend needed protection against becoming a more persuasive but less trustworthy version of the record beneath it.
The problem was not that Claude did poor work. The problem was that the engineering and assurance machinery consumed approximately $300 worth of included Claude usage within hours.
At roughly the same time, the backend control-plane work was consuming ChatGPT usage limits. Every bounded change involved repository inspection, evidence review, exact commit control, independent challenge, finding adjudication, correction, validation, and human acceptance. A defect discovered during the first real Day-0 build triggered another carefully bounded schema correction and verification cycle.
Then GitHub began warning me that my storage or account usage was approaching a point where I would need to upgrade.
I had not yet determined exactly which GitHub meter was responsible. The two repositories themselves were tiny. Their reported repository sizes totaled less than half a megabyte, and their workflows were not uploading build artifacts. The warning may have involved Codespaces storage or another account-level allowance, but I did not understand the cost architecture well enough to say.
That uncertainty was itself the signal.
Claude usage, ChatGPT limits, GitHub storage, development environments, CI activity, and my own attention were becoming one compounding resource problem. Each service presented its usage differently. Each individual step appeared manageable. Together, they were moving faster than my understanding of what the prototype was consuming.
I had governed the evidence, the state, the model authority, the tests, and every merge.
I had not governed the cost of the agents doing the governing.
I Was Not Close Enough to the Work
There is another part of the story that matters.
I was directing the work, but I was not deeply involved in the implementation. The AI systems were doing much of the engineering while I operated through prompts, reviews, approvals, and control-plane decisions.
That distance was partly intentional. One purpose of the experiment was to see how far AI-assisted engineering could go when the architecture, authority boundaries, and acceptance controls were explicit.
But the distance also created a risk.
The systems could produce code, tests, documents, branches, and review findings faster than I could build a practical understanding of what had been created. The repository might contain a technically disciplined implementation while I still lacked a simple mental model of the product, its current state, and what another increment would cost.
This resembles a familiar enterprise condition. A sponsor can authorize a project, receive frequent reports, and approve each formal gate without truly understanding how delivery complexity and recurring commitments are accumulating underneath the approved plan.
Nothing has to be hidden. The information can exist everywhere and still fail to become decision-ready.
The AI systems were transparent about their immediate work. GitHub preserved the history. The tests were visible. The pull requests explained their boundaries. Yet I was still losing sight of the combined economic picture.
The issue was not a lack of data. It was a lack of integrated cost visibility at the point of decision.
Pulling the Emergency Brake
I would like to say that I had established a precise token ceiling, measured the marginal value of the next increment, compared that value with the cost of finishing the book, and executed a preplanned stop condition.
That is not what happened.
I saw the Claude consumption, the ChatGPT limits, and the GitHub warning begin to compound. I became concerned that the prototype could continue consuming resources simply because the agents were capable of continuing. I did not understand the complete cost structure well enough to authorize more work responsibly.
So I pulled back and said: wait a minute.
That was less elegant than a mature capital-governance process should be. It was still the correct decision.
A Capital Risk Trigger does not prove that an investment has failed. It identifies a condition requiring the funding thesis to be examined again. In this case, the trigger was not defective software or an invalid concept. It was the loss of confidence that I understood and controlled the cost of the next development increment.
Continuing would have meant funding activity before I could explain what additional question the spending would answer, which model should perform the work, why another assurance cycle was proportionate, or where the total commitment would stop.
Permission to continue was not enough.
The work needed a reason to continue and a cost boundary within which that reason remained valid.
Governance Can Become Its Own Workstream
This experiment also exposed an uncomfortable possibility: governance intended to control the work can become a substantial body of work itself.
The backend architecture was trying to solve a serious institutional problem. If AI is allowed to reconcile evidence and propose changes to project state, the enterprise must preserve provenance, persistent identity, uncertainty, contradiction, authority, and history. Those are not decorative requirements.
The mistake would be assuming that every prototype phase requires the complete control structure of a production system.
A prototype needs enough governance to keep its conclusions trustworthy. It does not automatically need every possible assurance mechanism, independent review cycle, regression fixture, deployment control, and semantic defense before the next product question is even settled.
The appropriate level of control depends on the decision being prepared.
If the question is whether executives can understand a connected investment record, a bounded visual proof may be sufficient. If the question is whether AI can safely propose canonical state changes using client evidence, a much stronger control environment is justified. If the system is approaching production use, the assurance burden changes again.
Applying the same control intensity to every phase can make the governance architecture indistinguishable from the product-development effort.
The answer is not to abandon governance. It is to make governance proportionate.
What Will Change When I Return
For now, I am returning my attention to finishing Forensic Capital Governance.
The prototype repositories remain preserved. The accepted backend kernel, proposed Day-0 record, merged frontend capabilities, open work, tests, architectural decisions, and unresolved questions are still available. Nothing needs to be reconstructed from memory when the work resumes.
But I will not resume by simply issuing the next frontend prompt or reopening the next backend phase.
The first step will be to compare the highly functional 2025 Google AI Studio prototype with what the governed repositories taught me in 2026. The earlier version demonstrated speed, experience, and functionality. The later work demonstrated evidence discipline, state integrity, and authority boundaries. The next architecture should retain the strongest parts of both without assuming that maximum engineering ceremony is the only responsible path.
Each phase will need an explicit product question, a defined output, and a hard spending boundary. Token and dollar consumption must be visible across models rather than treated as separate allowances. One system should own the build, while independent review should be reserved for material architecture and acceptance gates. Validation should run locally where practical, with GitHub Actions used deliberately rather than as background machinery. Development environments, caches, storage, and inactive resources must be included in the cost model.
Most importantly, another increment will not begin merely because the current repositories make it possible.
It will begin when I can state what uncertainty the increment will reduce, what decision the resulting evidence will support, and what I am willing to spend to obtain that answer.
What the Experiment Actually Proved
The 2025 prototype proved that the product idea could become a highly functional application.
The 2026 experiment proved that its evidence, state, uncertainty, history, and decision authority could be governed far more rigorously.
It also proved that rigorous AI-assisted engineering can consume resources at a speed that overwhelms an owner who has not established integrated cost controls in advance.
All three findings matter.
The prototype did not fail. Claude did not fail. ChatGPT did not fail. GitHub did not fail. The systems performed the work they were permitted and encouraged to perform.
The governance gap was mine.
I had defined how evidence could enter the system, how AI could propose change, how humans would authorize state, and how every accepted result would remain traceable. I had not defined how quickly the engineering agents could consume resources, how much assurance was proportionate at each stage, or what cumulative signal would stop the work before concern became surprise.
That is the lesson I will carry forward when the book is complete.
A prototype succeeds when it changes what we know. Governance succeeds when that knowledge changes not only what we build next, but how much we are willing to spend to build it.