AI-1 · layers 1.2 – 1.4
A perpetual licence to the source. One firm, unlimited seats.
The Sprint is an accounting platform you own outright — roughly nine thousand lines of Python, licensed to your firm permanently, running on your own infrastructure and your own model keys. It sits on top of the ledger you already run — QuickBooks Online, Xero, NetSuite, Sage Intacct, or another system you name. Nothing is ripped out and replaced. It reads from the books you already keep and runs the workflows your firm defines, to your firm’s standards and your firm’s review steps — the close, the reconciliations, the workpapers, the exception review — with an assistant built into the work rather than bolted beside it. And you own it outright: a perpetual licence to source you can read and change, not a subscription to ours.
You design it in about ten minutes, in business language. Open one file in your browser and answer eleven questions about how your firm actually works: which system holds the books, who may approve what, whether anything is permitted to reach a client ledger at all. The Sprint turns your answers into the build instructions for your own coding agent. No account, no install, and nothing you type leaves your machine.
Vibe coding gets you software nobody can account for. This ships with the
opposite. Every answer you gave becomes a written decision record. A validator in the box
checks your agent actually read it. And AGENTS.md sits at the root of the
project, instructing your agent not to touch your code until you have handed it that
plan — picked up automatically by agents that follow the convention, and pointed
at explicitly by the first message the builder writes for you. Even after a clean validation it stays unauthorised to edit: it explains the
smallest first step, and waits for you. Skip the questions and your own agent
stops you.
What arrives is the complete platform source — the tool registry
and its eight-invariant integrity gate, ninety-eight real tool schemas, the ASC 606
and ASC 842 engines, the row-level tenant isolation — plus the four runtime
controls, five commit-time checks, 1,903 tests and a guided builder that writes your
instructions. PROVENANCE.md names every file and what it is — including
the one engine that is not in the box, and why.
We have built production-grade systems like this before: an agentic accounting platform covering a whole month-end for a private equity portfolio — the close, the flux review, the 13-week cash forecast, covenants, AR and AP, board reporting, FP&A, and the technical accounting under ASC 842, 606, 326 and 205-40. The case study is the architecture, the five constraints that had to hold before any of it was useful, and what we deliberately did not build.
Two days gets you the foundation: every control installed, every test passing, four worked examples showing the seams connect. What it is not, on day two, is your finished workflow — the tools are declared, classified and gated, and the bodies are the build after that. They are also the part that makes it yours rather than everyone’s, and the part nobody could have written for you without knowing your firm. If you would rather build them alongside someone, that is the Bootcamp.
Ownership
What “yours” means, precisely.
The word gets used loosely enough in this market to be worthless, so here is the whole of it — four things, each one checkable before you buy and still checkable a year later.
You have the source
Not an API, not a licence key, not a workflow that lives inside somebody’s
product. Nine thousand lines of Python you can read, diff, fork, rewrite or throw
away. PROVENANCE.md names every file and where it came from,
including the one engine we did not ship.
One purchase, one firm
Unlimited seats inside it, permanently. No per-user pricing, no renewal, no seat count to true up at year end — and nothing here stops working because you stopped paying, since there is nothing to stop paying.
It runs where you put it
Your laptop, your server, your hosting account. Your model key, your spend ceiling, your logs, your data path. Nothing routes through us and nothing phones home — there is no us in the runtime to phone.
You can change your mind
A different model vendor, a different ledger, different approval limits: each of
those is an edit you make, not a ticket you file and wait on.
CUSTOMIZE.md lists every decision the code is currently making on
your behalf, marked blocks / decide /
leave it.
The reason this is unusual is not that it is clever. For most vendors in this market the code is the product, so handing it over ends the business. We sell the method and the teaching; the code is what the method produces, and it is worth more to us in your hands than locked behind a subscription. That is the whole trick, and it is worth knowing before you compare us to anybody — because the question to put to every other option on your list is not whether their AI is good. It is what you are left holding when you stop paying them.
Four controls, one door
Each one stops a specific failure. Each one has tests that prove it refuses — because a test that proves the happy path works tells you nothing about a control.
Approval queue
Anything that mutates state produces a proposal, never an execution. A named human approves it or nothing happens. A service account cannot be an approver.
Fingerprint binding
The approval is bound to the exact bytes approved, canonicalised and hashed. Approve a $400 reclass, present a $40,000 one, and it refuses.
Idempotency ledger
At most one execution per action, ever. The post that timed out after the ledger accepted it does not get posted twice by the retry.
Spend monitor
Reserve before the call, commit the actual after. A ceiling you set rather than one your card issuer sets — and a number you can state per engagement.
What it looks like when it refuses
This is the worked example, in the box, that you run before changing anything. Throwaway database, fake ledger, safe anywhere.
Why that second one matters. Circular 230 §10.22 requires due diligence by the practitioner and §10.37 governs what written advice may rely on. An engine that grades its own output against criteria it also produced satisfies neither.
When a peer reviewer, a client's counsel or an examiner asks whether a human
approves the work, the answer is a constant they can read rather than a paragraph
you have to defend. Setting it True does not enable the behaviour —
it makes every approval fail loudly.
From download to your first build
You are not writing code and you are not writing prompts. You make the business decisions; the builder turns them into instructions your coding agent can execute.
- Unzip, and open one file
0-START-HERE.htmlopens in your browser. Nothing installs, nothing connects, and nothing you type leaves your machine. - Answer business questions, not technical onesWhich accounting system you use. Who may approve what, and up to what amount. Whether anything is allowed to reach a client ledger at all. Every question explains why it matters before it asks.
- It writes the instructionsFour files come out: a machine-readable build
profile, an implementation brief, a written record of every decision you made, and
CODING-AGENT-START.md— the prompt you hand to your coding agent. - The agent builds it, and explains itself firstEach proposed step is explained before you approve it. The controls are already in place, so what it builds cannot reach a ledger without a named human approving the exact figures.
Change your mind later and you reopen the same file, change the answers, and generate a fresh handoff. The decisions are a document you own, not a conversation you have to remember.
The part nobody else ships
Your coding agent does not get to freelance.
Handing a repository to an AI and hoping is how firms end up with software nobody can account for. The orchestration in this package is built so that cannot happen to you — and you do not have to take our word for it or remember to enforce it, because it is enforced on the agent, in writing, by files sitting in the folder you just unzipped.
- It reads the rules before it reads your request
AGENTS.mdsits at the root of the project. Agents that follow theAGENTS.mdconvention pick it up on their own before doing anything; for the rest, the first message the builder writes for you sends them to it. Either way, the first thing yours learns is that this repository has an intake gate. - No plan, no editsThe gate instructs it not to change application code until you supply the builder package. Attaching the package and sending the first message are explicitly not approval to edit. That sentence is in the box, addressed to the agent, not buried in a manual addressed to you.
- It has to prove it read your planBefore implementing anything it runs
checks/validate-build-handoff.pyagainst your four files. The validator fingerprints your decisions and checks them against the builder’s own contract, so a stale, edited or mismatched plan fails rather than quietly proceeding. Missing, inconsistent or unsafe input is a hard stop. - A clean pass still is not permissionThis is the part that matters. Even
when validation succeeds, the gate holds
editing_authorized=false. The agent must explain the smallest sensible first step, in plain English, and wait for you to approve it by name. Nothing is written until you say so. - And it refuses secrets on the way inIf the handoff contains a credential, a token, a private key, an external company or realm identifier, or pasted client data, the gate stops without editing and tells you to regenerate the package and rotate what leaked — outside the chat.
It is the same discipline the software itself enforces on the people who use it —
nobody approves their own work — applied to the thing that builds it. You can read
every line of it: AGENTS.md and checks/validate-build-handoff.py
are plain files in the package, not a service we run.
What is in the box
| Directory | What it is |
|---|---|
| controlplane/ | The four runtime artifacts, the one execution door, and a CLI for the queue. Standard library plus SQLite — state is one file you can copy, hash and archive with the workpapers. |
| checks/ | Five commit-time checks as a git pre-commit gate, plus the same checks at write time: credentials, hardcoded client identifiers, mutation calls outside the approval path, undocumented stored fields, and — the one that came out of a real incident — your firm’s name hardcoded into a memo that would post to a client’s ledger and stay there. |
| project-files/ | AGENTS.md, PROJECT.md, SCHEMA.md, KEY-REGISTER.md — the four files that go in every project so the agent starts from your rules rather than from zero. |
| platform_app/ | The platform source. The tool registry, the eight-invariant gate that refuses to boot on a half-registered tool, the four-tier side-effect map, 98 real tool schemas, the ASC 606 revenue engine, the ASC 842 lease engine, the ASC standards corpus, and the row-level-security tenant pin. |
| tests/ | 1,903 tests, hundreds of them asserting a refusal, including 25 hand-computed golden numbers against the revenue engine and 29 against the lease engine. |
| examples/ | Four worked examples, each about a hundred lines, each one seam: the control plane end to end · writing a tool body and what it does not change · a real model offered your tools and the gate refusing on the arguments · the ASC 842 engine through a proposal to a single posting. Teaching artifacts, not an application — and the tests run all four, so they cannot quietly rot. |
| 0-START-HERE.html | The guided builder. Opens in your browser; nothing installs and nothing you type leaves your machine. Business decisions in, four files out — a machine-readable build profile, an implementation brief, a written record of every decision you made, and the prompt you hand to your coding agent. Reopen it later, change an answer, and generate a fresh handoff. |
| BUILD.md | The builder’s reference in document form — the same eleven questions with the reasoning behind each, the safe local workspace, the order to build in, and the go-live stops that must hold before anything touches a real ledger. |
| README.md | The nontechnical path from download to a private repository and coding-agent handoff. GitHub Desktop handles identity, the first commit and private publication with buttons; no Terminal-based Git configuration is required. |
| docs/LEDGER-SETUP.md | Getting credentials out of QuickBooks Online, Xero, NetSuite or Sage Intacct, and holding them safely — scopes, sandbox first, and the expiry dates that arrive without warning. Checked against each vendor’s own documentation, including Intuit’s November 2025 token-policy change and NetSuite’s 2027 deadline. |
| docs/HOSTING.md | Running it somewhere other than a laptop, and the one thing that breaks in the move: .env does not travel, so the development and client key separation has to be rebuilt in the host’s environment. Plus the ten-line checklist before you point it at a real client. |
| docs/CUSTOMIZE.md | Every decision the code is currently making on your behalf, in the order you need to make it, marked blocks / decide / leave it. checks/check-customization.py prints the same list from your own tree. |
| docs/MODULE-MAP.md | The whole platform, module by module — the close, cash, covenants, AR/AP, reporting, FP&A, reconciliation, the standards — each marked engine (complete and tested), declared (registered, classified and gated; the body is yours), or not here. Read it before you plan a build. |
| docs/PROVENANCE.md | Every file, when it was written, and whether it is platform source, extracted declarations, or written for this distribution. Including the one engine we did not ship from production, and why. |
Some of it is grown. Most of it is seed.
The platform this came out of covers a month of accounting rather than a slice of it. You are not getting all of it, and it would be dishonest to imply otherwise. You are getting the part that is hard, the part that is slow, and the part that is dangerous to get wrong — and for the rest, the shape it has to take.
| What you get | Which parts |
|---|---|
| Three standards engines, complete | ASC 842 leases (PV, ROU, both classifications, 29 golden tests) · ASC 606 revenue (SSP allocation, over-time recognition, modification catch-up, 25 golden tests) · ASC 205-40 going concern (the six indicators, the one-year look-forward, and an indeterminate verdict for every input it could not compute, 30 tests). Plus the schedules, the standards corpus, and the whole runtime. |
| Ninety-eight declared tools | The close and its task machine · reconciliation · the 13-week cash forecast · covenants · AR, AP and collections · financials and board reporting · FP&A, budget and drivers · KPIs · LBO. Each one registered, classified, tiered and reachable — the risk decisions already made and machine-checked. The handler bodies are yours. |
| Two modules, absent | Cap table, and the tax package / PBC binder. Named rather than hidden. They are the two most entangled with one firm’s specific process, and ours would cost you more to unpick than to build. |
A declared tool is not a stub with a shrug in it. It is
a decision already made — what the model may ask for, whether it can execute or only
draft, which role reaches it, whether it needs an idempotency key, which of the four
side-effect tiers it lands in. That decision is most of the work and all of the risk, and the
integrity gate will not let you get it wrong quietly. What is left is plumbing to
your ledger, which nobody could have written for you anyway. Write a read tool and
it is five lines. MODULE-MAP.md is the full map, module by module.
AI-1
And a method for deciding what to build next.
Code is half of what a firm needs. The other half is a way of deciding what to automate, in what order, and how you know a thing is safe to put in front of a client — the half that is still true in two years, when every model named on this page has been replaced twice. AI-1 is six layers, built in order, the way you would build anything you intended to stand on.
| Layer | The question it settles | Where it gets answered |
|---|---|---|
| 1.1 Foundation | May we do this at all — the written policy, §7216 and §6713 consent, §10.36 procedures | The AI Register |
| 1.2 Frame | What the agent may ask for, what it may never do, and who gets to decide that | In the box |
| 1.3 Systems | What it may read, what it may write, and what each call actually costs you | In the box |
| 1.4 Inspection | How you prove it refused — the controls, and the tests that fail when they stop refusing | In the box |
| 1.5 Occupancy | Who actually uses it, who approves, and what happens in the queue every morning | The Bootcamp |
| 1.6 Upkeep | Expiring credentials, changed models, drift, and the correction that has to reach every firm running it | Partly in the box |
The Platform is layers 1.2 to 1.4 — the three that are code, and the three that are dangerous to get wrong. Layer 1.1 is the AI Register, which is free and takes ninety seconds. Layers 1.5 and 1.6 are practice questions rather than build questions: who opens the queue, what you do the morning it says something you did not expect, and who is responsible when a token expires in October. Those are the ones a room helps with, which is most of what the four live weeks are for.
What this deliberately does not cover
Read this before you promise anything to a client.
| 1.1 Foundation | Your written AI use policy, §§6713/7216 and §10.36. Not code. Whether an API call to a model vendor is a “disclosure” under §7216 is publicly contested, and the answer determines your consent language. The AI Register produces it in ninety seconds, free. |
| 1.5 Occupancy | Not in this package. |
| Your ledger's permissions | This stops your agent. It does not stop a person with direct access, and it is not a substitute for the permissions inside QuickBooks, Xero or your practice management system. |
| Model quality | Nothing here makes the AI right. It makes the AI's output something a human has to look at before it becomes a fact about a client. Different problems, and only the second is solvable with code. |
| Support | This tier is files, not support. Corrections ship to everyone; your build is yours, and nobody is watching you make it. The extra $3,000 for a Bootcamp seat buys the six chapters of reasoning behind this code, four weekly sessions making it fire against your own systems, four 1:1s on your own book, and the room — not more files. A seat includes every file here. |
Two days from now, or four live weeks from now.
Same code either way — a Bootcamp seat includes this package in full. What four live weeks add is the six chapters of reasoning behind it, a weekly session in which every control is made to fire against your own systems, a 1:1 on your own book, and a room of other firm owners. Buy the Sprint alone and it credits in full against a seat, so starting here costs you nothing if you decide you want the room.