Seven papers, one argument:
where the value is, how to get it, who builds it, how to write it down — and how to govern the workforce that runs it.
Enterprise AI adoption is nearly universal; enterprise AI impact is rare. These papers set out why, what to do instead, what it takes to deliver it inside a timeline that survives contact with an organisation, how a company of 50 to 500 people should write the strategy down — generally, and inside a professional practice — how to buy the result rather than the effort, and what an autonomous workforce must be able to answer once it runs.
Establishes the problem and where value actually concentrates: not in better models, but at level five of the maturity ladder, where the workflow itself is re-engineered around governed intelligence.
Read paper No. 1 →Every legacy process is a fossil of constraints that governed intelligence removes. This paper sets out how to re-derive a process from its outcome rather than renovating it on top of the old limitations.
Read paper No. 2 →Method without a machine dies of its own timeline. This paper answers the question the first two leave open: execution — and why the constraint that kills level five is the time between the design and the cutover.
Read paper No. 3 →It should be a list of operations.
How a 50-to-500-person company writes an AI strategy that changes how it runs: the unit is an operation, not a use case; the first act is a constraint inventory, not a vendor evaluation; and governance is a property of the build, not a policy document.
Read paper No. 4 →cannot buy back time.
The method applied to the accounting and advisory practice: what to re-derive first, why a language model must never be the last word on a figure a client relies on, and what happens to the billable hour when the close takes five days instead of fifteen.
Read paper No. 5 →You paid for the effort.
Why outcome-based pricing usually fails: most vendors change only the invoice, so they carry a risk they cannot control and hedge it. The delivery model that makes an operational outcome contractable, the commercial model that follows from it, and the four questions that expose the difference.
Read paper No. 6 →Where is the decision?
Sovereign compute is necessary and not sufficient. What an autonomous workforce still has to answer once the data centre is certified — where each number came from, which rule applied, who signed, and how much autonomy that decision has earned — and six questions for any vendor that claims one.
Read paper No. 7 →Every paper’s argument is readable in full on this site. Papers one, four, five, six and seven download as a formatted PDF straight away; papers two and three are sent by email.
How they fit together
Paper one is diagnostic: three independent research programmes agree that the constraint is not model quality but the failure to change how work is done, and value concentrates only at level five of the maturity ladder. Paper two is the method — deliberately public, because any capable team can run it: inventory the fossil constraints, re-derive the process from the outcome, place every decision, and stage autonomy by reversibility. Paper three is what the method cannot supply on its own: speed. A redesign that takes eighteen months re-creates every failure the method exists to avoid, so the third paper describes the delivery machine — the Two Minds runtime, the Software Factory and the OS series. Papers four and five bring it back to the reader’s own desk: the fourth is how a company of 50 to 500 people writes the strategy down — an ordered list of operations, each with a baseline and an owner — and the fifth runs that method through a single sector, the accounting and advisory practice, where the product is the hour and the risk is the wrong number. Paper six separates the commercial model from the delivery model that makes an outcome contractable. Paper seven describes the workforce that does the routine work once the strategy is written — and why, once the compute is sovereign, the decision still has to be.