ByramADVISORY GROUP Book a Teardown

The Sprint — rung one. Build it yourself.

The controls under the AI. Tested. On your own servers. Yours for good.

You get the source code of the controls we use. It is tested. It runs on your own servers. Your own coding workspace builds from the plan. Buy the Bootcamp later and the full $2,000 comes off the seat.

45 minutes on your real close. No access. No install. Five a month.

Owen ran the close in private equity.He wrote the first system for it. This package has tested forms of those controls. Read the case study →
1,965 tests. Run them for a reviewer.227 files, plus the release manifest. Hundreds of the tests check that a control refuses.
A seed and a build map.A live link, a real model answer and use on real work are each proved later. None of it is assumed.
01What you get

Code you own. A plan your own workspace builds from.

The Sprint is tested Python source code. Your firm owns it under a licence that does not end. You give your own coding workspace the plan. It builds the platform you chose: the suite, add-ons, screens and AI features. It tests its own work. You do not say yes to each step. Nothing touches your books, your data or a paid AI account without your say.

What shipsA seed and a build map. A live link to your books, a real model answer, and use on real work are each proved later. None of it is assumed.

You have the source.

Python source. Read it, change it, fork it, or throw it away. Not an API. Not a licence key. Not a workflow inside someone else’s product.

One payment. One firm. All the seats.

No per-user price. No renewal. No seat count to true up at year end. Nothing stops when you stop paying, since there is nothing to stop paying.

You choose where it runs.

The local base runs on your laptop. A hosted or model-linked setup uses your own hosting account, keys, spend limit, logs and data path, once you build those adapters and sign them off. Nothing routes through us. Nothing phones home by default.

You can change your mind.

You are not tied to a Byram service. A new model vendor or a new ledger needs a new adapter, tests and sign-off. A new approval limit needs review. You control that work. You do not file a vendor ticket.

Why we can hand it over. For most vendors 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 makes. It is worth more to us in your hands than locked behind a subscription. So ask every other option on your list one thing. Not whether their AI is good. What are you left holding when you stop paying them?

02The price

$2,000. One payment. One firm. Yours for good.

It is not a subscription. There is no Byram server, broker or sign-in. Stripe takes you straight to the zip, the start guide and the build order. There is no email wait. The same link is in your receipt.

It comes off a Bootcamp seatBuy The Sprint now. Take a Bootcamp seat later and the full $2,000 comes off it. The credit does not expire.

Build the platform yourself. Use your own workspace.

The Sprint

$2,000one payment

One firm. No seat limits. A licence that does not end.

  • You keep the code under a licence that does not end.
  • It is not a subscription.
  • Your workspace builds the platform you chose.
  • It builds the suite, the add-ons, the screens and the AI features.
  • It tests and commits its own work.
  • You use your own ChatGPT Work or Claude Cowork session. Neither is part of the price.
  • Your plan, settings and access set what you can use.
  • 227 files, plus the release manifest.
  • 1,965 tests. Run them for a reviewer.
  • Python 3.12 or newer, git, and three pinned packages.
  • It does not run on our servers. There is no broker.
  • It does not touch your books, your data or a paid AI account. Not until you say so.
  • If we publish a fix, each buyer gets it.
Get The Sprint — $2,000

Fifteen minutes first — is this the right rung? →

Bring your own workspace access. It is not bundled. Terms of sale →

Build the first workflow with us in the room. Then build the rest yourself.

The Bootcamp

$5,000per firm

Four live weeks. The Sprint is included in full.

  • The same code. A seat includes every file here.
  • Six chapters on why it is built this way.
  • A live session each week. Every control is made to fire against your own systems.
  • One office hour a week, on your own book.
  • A room of other firm owners.
  • It adds no files.
See the Bootcamp

Buy The Sprint alone and it credits in full against a seat. Starting here costs you nothing if you want the room later.

03Four controls, one door

Every change goes through one door. Four controls stand at it.

Each control stops one kind of failure. Each one has tests that prove it refuses. A test that shows the happy path works tells you nothing about a control.

Run it before you change a thingThe worked example is in the box. It uses a throwaway database and a fake ledger. It is safe anywhere.

  1. 1

    Approval queue

    Anything that would change the books makes a proposal. It does not run. A named person says yes, or nothing happens. A service account cannot say yes.

  2. 2

    Fingerprint binding

    The yes is tied to the exact bytes it was given for. Say yes to a small entry, then try to post a big one. It refuses.

  3. 3

    Idempotency ledger

    Each action runs at most once, ever. A post that timed out after the ledger took it does not post twice on the retry.

  4. 4

    Spend monitor

    It sets money aside before the call. It records the real cost after. You set the ceiling, not your card company. And you can state the number per engagement.

What it looks like when it refuses

One script. Five things happen, in this order.

A proposal is not a run.
It proposes an entry. Then it tries to run it with no yes. Refused: no standing approval.
It cannot say yes to its own work.
A service account tries to approve it. Refused: the approver is not a named person.
A named person says yes. It posts.
The entry posts once. It gets an id and a period.
The retry does not post it twice.
The same call comes back with the first result. Posts so far: still one.
Say yes to a small entry. Try to post a big one.
Refused: the payload does not match what was proposed. Posts so far: still one.
The end of the run.
Four times it said no. Nothing posted twice.

Why the second one matters. One line in the code says the software may not grade its own work against rules it wrote. Turning that line on does not turn the behaviour on. It makes every approval fail out loud. So when a peer reviewer, a client’s counsel or an examiner asks whether a person approves the work, you show them one line. Circular 230 §10.22 asks for due care by the practitioner. §10.37 says what written advice may rest on. Software that grades its own output meets neither.

04What is in the box

Every part, and what it is for.

227 files, plus the release manifest. Here is each part in plain words. The names are the real folder and file names, so you can find them after you unzip.

Two files pin down what you gotPROVENANCE.md says where each part came from and how far along it is. PACKAGE-MANIFEST.json lists the exact files, their hashes, the source commit and the release.

PartWhat it is
controlplane/The four runtime controls, the one door every change goes through, and a command line for the queue. Standard library plus SQLite. The state is one file. You can copy it, hash it and file it with the workpapers.
checks/Five checks run before each commit, as a git pre-commit gate. The same five run at write time. They catch credentials. They catch client ids typed into the code. They catch writes that go around the approval path. They catch stored fields no one wrote down. And one came out of a real incident: your firm’s name typed into a memo that would post to a client’s ledger and stay there.
project-files/AGENTS.md, PROJECT.md, SCHEMA.md and KEY-REGISTER.md. The four files that go in every project. Your workspace starts from your rules, not from zero.
platform_app/The platform source. Each module signs itself in. Each link to a ledger is scoped to one book and fails closed. The accounting records are one standard shape. ASC 606 and ASC 842 engines do the sums. And the 157-slice catalog lives in the code, with a label on each slice that says how far along it is. Its 98 old assistant entries are set apart. They are a list to move over, not working chatbot features. The tenant helper and the standards search are not a signed-in app boundary, and not a service ready for real use.
tests/1,965 tests. Hundreds of them check that a thing says no. They include 25 golden numbers for revenue and 29 for leases, each checked by hand.
examples/Four worked examples, each about a hundred lines, each on 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, from a proposal to a single posting. They are teaching files, not an application. The tests run all four, so they cannot quietly rot.
0-START-HERE.htmlThe guided builder. It opens in your browser. Nothing installs. Nothing you type leaves your machine. Quick Start asks three questions. The work type. The first accounting product. The first useful result. The Customize path has seven stages and records more detail. In the first hour there are five setup checkpoints. Then it makes one four-file handoff for your one lasting Sprint Workspace.
BUILD.mdThe builder’s guide, as a document. The three-question Quick Start. The seven-stage Customize path. The first-hour setup lane. The order to build in. And the go-live stops that must hold before anything touches a real ledger.
README.mdThe plain path from download to a private repo, and on to the workspace handoff. You need no code skills. GitHub Desktop handles who you are, the first commit and private publishing, with buttons. You never set up Git in a Terminal.
docs/LEDGER-SETUP.mdHow to get keys out of QuickBooks Online, Xero, NetSuite or Sage Intacct. How to keep them safe. What each key may do. Sandbox first. And the expiry dates that come with no warning. We checked it against each vendor’s own docs. That includes the Intuit token rule change of November 2025, and the NetSuite deadline in 2027.
docs/HOSTING.mdRunning it somewhere other than a laptop, and the one thing that breaks in the move. The .env file does not travel. So the split between your dev keys and your client keys has to be rebuilt on the host. Plus the ten-line checklist before you point it at a real client.
docs/CUSTOMIZE.mdThe guide to shaping the Core, and the add-ons that still need building. It knows how far along each part is. It covers the planner choices in detail. The placeholders for your setup. How to carry on in one workspace. The provider First Proof. And the go-live checks.
docs/MODULE-MAP.mdThe 157-slice catalog, module by module. Each slice is marked as one of three: implemented, scaffolded or planned. It shows which slices need a link to a ledger. And it says why a catalog entry does not mean a thing is ready.
docs/PROVENANCE.mdWhere each part came from, and how far along it is. There are five kinds. Tested bases that fit any vendor. The packaging and planning code we wrote. Engines and controls we adapted. Old parts kept apart for fit. And work that is scaffolded or planned. PACKAGE-MANIFEST.json lists the exact files, their hashes, the source commit and the release.
05What is built, and what is planned

Some is built. Most is a build map.

The Sprint mixes five kinds of work. Tested bases that fit any vendor. Planning and safety code we wrote. Sums and controls we adapted. Old parts kept apart for fit. And a catalog of work that is scaffolded or planned. It does not claim that every line came unchanged from a prior live system. It does not claim that a named slice is ready for client data.

157 slicesAcross 23 families, with the status in the code
16 builtBuilt and tested. They fit any system.
9 scaffoldedThe shape is there. The code is not yet.
132 plannedNamed, with what each one needs
Three bases, built and tested
ASC 842: the sums and the standard monthly journal are built. Judgment and posting are scaffolded. Contract import and ledger tie-out are planned. ASC 606: the sums are built. The judgment terms are scaffolded. Live imports, tie-outs and the monthly journal’s life cycle are planned. ASC 205-40: the indicator check is built. Sending a case up for review is scaffolded. Getting the signals in one standard form is planned.
Each slice says how far along it is
157 slices across 23 families. 16 implemented, 9 scaffolded and 132 planned. The 98 old assistant entries are a sorted list to move over, not working chatbot features. The status lives in the code. So the build cannot pass a planned slice off as ready.
Most workflows still need building
Most of the work is still to build. That means client accounting work. Document and PBC flows. Reading contracts. Live financials. Consolidation. Reports. Budgets. Advisory. Most of the assistant bindings. And many more slices. All of it is scaffolded or planned. Cap-table and tax-package work sit outside the ready Core too.

A catalog entry is a build boundary. It is not a claim that a thing is ready. It records what a slice needs, what it may do, and how far along it is. Built slices give the tested base, and it fits any system. Scaffolded and planned slices still need the code, the provider, the evidence and the firm workflow named in their status. MODULE-MAP.md is the full map, module by module.

06What it covers, and what it does not

Three of six layers are in the box. Here is the rest.

Code is half of what a firm needs. The other half is a way to decide what to automate, and in what order. And how you know a thing is safe to put in front of a client. That half 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 meant to stand on.

What The Sprint coversLayers 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. It is free and takes ninety seconds.

1.1 Foundation
May we do this at all? The written policy, §7216 and §6713 consent, and §10.36 procedures. Answered by The AI Register.
1.2 Frame
What the workspace 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 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 uses it. Who says yes. What happens in the queue each morning. The Bootcamp.
1.6 Upkeep
Keys that expire, models that change, drift, and the fix that has to reach every firm running it. Partly in the box.

Layers 1.5 and 1.6 are practice questions, not build questions. Who opens the queue. What you do the morning it says something you did not expect. Who is on the hook when a token expires in October. A room helps with those. That is most of what the four live weeks are for.

What this does not cover, on purpose

Read this first. Do not promise a client more.

1.1 Foundation
Your written AI use policy. §§6713/7216 and §10.36. Not code. Is an API call to a model vendor a “disclosure” under §7216? People argue about that in public. The answer sets your consent words. The free AI Register lists the providers that already touch client work. It shows what each one sees, whether anyone read the terms, and how the cost is booked. It does not write the policy.
1.5 Occupancy
Not in this package.
Who can write to your ledger
The controls in the box can stop the path they guard. They do not stop a person with direct access. They do not stop a path they were not given. They do not replace the permissions inside QuickBooks, Xero or your practice software.
Model quality
Nothing here makes the AI right. The package gives you the parts to require a person’s review before output becomes a client fact. A finished build still has to connect every path to them. Those are different problems. Only the second one can be fixed with code.
Support
Support is bounded. It covers the planner, the starter code, the Sprint Workspace handoff and the guides. You may send us a closed, sanitized diagnostic. We may say what the next safe step is, as a courtesy. We do not promise a response time. It does not include hands-on building, testing or refinement. A Bootcamp seat adds six chapters, four weekly sessions, a weekly office hour on your own book, and the room. It adds no files. A seat includes every file here.
07After you buy

Unzip. Answer three questions. Hand the plan to your workspace.

You make the business decisions once. The builder writes them down. One lasting Sprint Workspace carries the technical work forward from there.

What you bringYour own ChatGPT Work local project or Claude Cowork task. Neither is part of the price. Your plan, settings and access set what you can use.

  1. Unzip, and open one file

    Open 0-START-HERE.html in your browser. That is all. Nothing installs. Nothing connects. Nothing you type leaves your machine. It is a page, not an app.

    A page in your browser. Nothing on the network.

  2. Choose Quick Start or Customize

    Quick Start asks three questions. The work type. The accounting product to prove first. The first useful result. The optional seven-stage path records more detailed firm rules. Review the plain-language plan once.

    Your plan, in plain words.

  3. Set up the workspace first

    The Setup Cockpit walks you through it. It helps you lock down the private project. It runs the hosting probe that fits your case. It opens one lasting Sprint Workspace. The click-by-click steps are in README.md.

    One workspace that keeps your rules.

  4. Save one intact handoff to that workspace

    Four files come out inside BAG-build-handoff.zip. A machine-readable profile. A build brief. A written record of your decisions. And the workspace start message. Leave the handoff zipped. Attach it to the same Sprint Workspace.

    Four files. One zip. Leave it closed.

  5. Start with the outcome you want. Not with sign-offs.

    The workspace checks the handoff. Then it looks for your current request, or a yes you gave before, for the same outcome. Once that matches, it owns the routine work. Design, code, tests, review, fixes and commits. And any deployment you already said yes to. The runtime controls still need a named person to say yes to the exact figures before anything can reach a ledger.

    It builds. You keep the last yes.

Your choices carry forward in the same workspace. If the outcome or a big limit changes later, the workspace writes down one change. It does not make you answer the questions again. The decisions stay a document you own, not a chat you have to recall.

How your workspace keeps to the plan

Hand a repo to a blank workspace and you get software you cannot account for. The supported Sprint Workspace uses the handoff, the checker and the repo rules. They keep the workspace inside the outcome and the limits you approved. Those files cannot hold back a workspace or tool that ignores them.

It reads the rules before your request
AGENTS.md sits at the root of the project. Workspaces that follow the AGENTS.md convention read it first. For the rest, the start message points to it. Either way, your workspace learns that this repository has an intake gate.
No plan, no edits
The gate tells it not to change app code until you supply a valid builder package. Attaching or checking that package supplies the plan. It does not, by itself, give permission to build. That rule is in the box. It is addressed to the workspace, not buried in a manual addressed to you.
It has to prove it read your plan
Before it builds anything, it runs a checker against your four files. The checker fingerprints your decisions. It checks them against the builder’s own contract. A stale, edited or mismatched plan fails. It does not quietly go ahead. Missing, mixed-up or unsafe input is a hard stop.
It asks for a yes once
A clean check is still not permission. The workspace looks for a clear current request, or a yes you gave before, that covers the same outcome and its limits on cost, access, data and live use. If neither exists, it asks once, in plain words. If one matches, it carries the routine technical work through. No approval loop per file, diff, test, hash or phase.
It stops secrets at the door
If the handoff holds a secret, the gate stops. That means a password, a key, a token, an outside company or realm id, or pasted client data. It edits nothing. It tells you to make the package again, and to change what leaked, outside the chat.
Plain files, not a service
It is the same rule the software puts on the people who use it. Nobody approves their own work. Here it is applied to the thing that builds it. You can read every line. AGENTS.md and the checker, checks/validate-build-handoff.py, are plain files in the package, not a service we run.
08Where to start

Get the code. Or bring your close first.

The Sprint is $2,000, once, for one firm, for good. If you are not sure it is the right rung, start where it costs you nothing. The close teardown is free. 45 minutes on your own close. You leave with one written page.

Emailinfo@byram-advisory.com

Or just talk15 minutes with Owen →

More questionsThe answers we give most, on one page. Questions we get →