Bottom line up front: Tax-ready books are books that can answer, for any number on the return, four questions: who recorded it, from what document, under which rule, and what it said on any prior date. Paper 11 argued that an append-only ledger with policy-as-code is a sufficient trust architecture for AI-operated finance. Paper #12 in the Thought-OS™ reading order.

Don Lovett, Fractional CFO & Managing Principal · ProjectBits Consulting · October 2026

Abstract

Tax-ready books are books that can answer, for any number on the return, four questions: who recorded it, from what document, under which rule, and what it said on any prior date. Paper 11 argued that an append-only ledger with policy-as-code is a sufficient trust architecture for AI-operated finance. This paper shows that two things are required, and that neither works without the other: a provable record and an executable rulebook. A record must be immutable, bitemporal, and rule-versioned. But "rule-versioned" is empty unless the rule itself is something that can be read, tested, and run — which means the rules, the firm’s policies, and the access controls must exist as code with versions, tests, and decision logs, not as descriptions in a workpaper.

Substantiation, book-to-tax reconciliation, shareholder basis, and state nexus all share one structure: cumulative, multi-year, rule-dependent facts. Each is a record problem and a rule problem at once. The paper proposes a provenance ledger built as a layer around the general ledger rather than in place of it, with a policy engine between the people who approve and the record that remembers. The owner keeps a locked book of record. AI proposes, rules evaluate and log their reasoning, evidence accumulates, humans approve, and only approved entries post.

The economics follow from an asymmetry: a provenance trail is cheap to keep and expensive to recover, and the owner is already doing the work it records. An implementation path on commodity infrastructure is given in twelve steps, with the rulebook built before the record that depends on it.

Part I — The Question in the Conference Room

Maria Sandoval runs a twelve-person managed services firm in Northern Virginia. Eighteen months ago she moved her books to an AI system that categorizes every transaction, drafts the invoices, and closes the month without a bookkeeper. Her financials are current to the hour. She is proud of this, and she should be: she built a company that runs itself.

Maria Sandoval and Tom Reyes are illustrative composites. The firm, the loan and the conversation are constructed to show a pattern; they are not drawn from a real client.

She is in a bank conference room because the firm is buying a competitor and needs a $1.4 million term loan. Across the table is Tom Reyes, a commercial lender who has approved loans for twenty years. He has her last three years of financials on his screen.

"Your meals and entertainment line dropped by half in 2025," Tom says. "What changed?"

Maria asks the system. It answers at once: the 2025 figure reflects a reclassification of staff-event meals to a separately tracked category. Tom nods. "Good. When was that reclassification made?"

The system shows the current value. It does not show when the value became current.

"Here’s why I ask," Tom says. "You sent us a P&L in April for the pre-approval. That P&L had the old number. I need to know whether the books I underwrote in April are the books you’re showing me now, or whether something moved. Not because I think you did anything wrong. Because my credit committee will ask me, and I need to answer."

Maria asks the system for the April version. It has no April version. It has the books as they are.

Tom tries a different angle. "The reclassification — what rule drove it? Fifty percent, a hundred percent, which year’s version? And I don’t mean the label on the account. I mean the rule itself. Can I see it?"

The system explains the current treatment clearly and confidently. It cannot show the rule, because it has no rule to show. It stores the result of applying something it learned, not the thing it applied, and it cannot say whether that something changed between April and now.

"Last question," Tom says. "Who approved the change?"

The system made the change. There is no one else in the record.

Tom closes the laptop. "I believe your numbers. I can’t prove them, and proving them is my job. Get me a trail — what each number was, as of when, under what rule, signed off by whom — and we’ll move fast."

Maria drives back to the office with a question she had not asked before. Her system is accurate. Why isn’t that enough?

The answer is that accuracy is a property of a number, and trust is a property of a record. Tom was not asking whether the number was right. He was asking whether the record could stand on its own, in a room she wasn’t in, answering questions she hadn’t anticipated — and whether the rules behind it were things a person could read. That is a different requirement, and it is the subject of this paper.

Part II — A Ledger Is Not a Database

Maria’s system replaced a ledger with a table, and the two are not the same thing. A general ledger is a database with four properties layered on top, and those properties are what make its outputs credible to anyone who was not in the room when the entries were made.

1. Double entry. Every change touches two accounts and the books balance by construction. An error shows up as an imbalance, not as a quiet drift.

2. Immutability. A posted entry is never edited. It is reversed or adjusted by another entry, and both remain visible.

3. Period lock. Once a period closes, its totals do not move. The May financials in December are the May financials from June.

4. Reproducibility. The same report, run next year, returns the same numbers.

None of these requires sophisticated software. A locked spreadsheet with discipline has most of them. What matters is that they are enforced by the system rather than by good intentions. A lender, an examiner, or a buyer accepts ledger outputs because of those four properties, not because of the interface, and not because the people keeping the books are honest.

An agent writing rows into a database with update privileges has none of the four unless someone builds them. In most AI-first bookkeeping designs, no one does, because the design goal is effort — no bookkeeper, no software subscription, no close process — and the four properties are invisible until the day they are needed.

Three things are lost in the trade.

Provenance of amounts. Who posted it, from which source document, applying which rule. A model that categorizes a transaction and stores the category has recorded a conclusion without its reasoning. That is unreviewable, which means it is also uncorrectable in any principled way.

Provenance of judgments. Business purpose, capitalize versus expense, related-party status, deductibility percentage. These are not categorizations; they are determinations with legal consequences. A field holding one current value records the determination and discards the chain of who asked, who answered, and who confirmed.

Temporal integrity. Restated numbers overwrite prior numbers. The question Tom Reyes asked — what did the books say on the day we underwrote this — becomes unanswerable, not because the answer was hidden but because it was never kept.

The owner who has outgrown a pure AI system is not the owner whose books are wrong. It is the owner whose books have become consequential: a loan, a multi-state footprint, a partner buyout, an exit. At that point the record has to stand in rooms the owner is not in, and the four properties stop being abstractions.

Part III — Three Properties, Not One

Paper 11 answered one question: can this record be trusted not to have been changed? Append-only storage answers it. Tax work asks two more, and append-only alone answers neither. Tom Reyes asked all three in order.

Immutable: has the record been altered?

Maria’s 2025 meals expense was recorded in March 2026 as $12,000, 50% deductible. In August, review found $3,000 of staff-event meals that are 100% deductible. An immutable ledger handles this cleanly: the March row is never edited; an August row supersedes it. Both remain. Nothing was tampered with, and anyone can see the correction and its date.

That is the property Paper 11 established, and it holds. It is also where most "audit trail" claims stop.

Bitemporal: what was true, as of when?

Tom’s second question was not "is the current number right" but "what did the books say on April 15." A single timestamp cannot answer it, because it conflates two different times: the period the fact is about (tax year 2025) and the moment the fact was recorded (March, then August).

A bitemporal record carries both clocks on every row — valid time and transaction time. "As of April 15" becomes a query rather than an archaeology project, and the answer is reproducible by anyone with access. Immutability guarantees that the history exists. Bitemporality makes the history navigable, which is what a lender, an examiner, or an acquirer means when they say the record is reliable.

Rule-versioned: why was it treated that way — and a version of what?

Take the same meals line in a different year. For 2021 and 2022, restaurant meals were temporarily 100% deductible; in 2023 the rule reverted to 50%. A row stating "meals, $12,000, deductible $6,000" can be immutable and bitemporal and still unexplainable, unless it records which version of the rule produced the $6,000.

Multiply this across depreciation conventions, state conformity to federal changes, nexus thresholds that legislatures amend, pass-through entity tax elections, and the firm’s own policies. "We applied the rule" is defensible only when the rule is a versioned, effective-dated object that the row points to.

But a version of what? If the "rule" is a sentence in a workpaper — "meals at 50% for 2025" — then versioning it means keeping old sentences. Nothing can be re-run, tested, or shown to have produced the number. The rule-versioned property only carries weight when the rule is executable: a piece of logic with inputs and an output, that can be evaluated again on the same facts and give the same answer. That turns rule versioning from a filing convention into a reproducibility guarantee, and it is the subject of Part IV.

Why all three

| Property | Question it answers | Fails without it |

|—|—|—|

| Immutable | Has this record been altered? | Any change is indistinguishable from the original |

| Bitemporal | What did we believe as of a given date? | Prior-period reports cannot be reproduced |

| Rule-versioned | Why was it treated this way? | A number without its justification |

Immutable tells you the record is intact. Bitemporal tells you what it meant on any date. Rule-versioned tells you why — provided the rule is something that can be read and run. Substantiation requires all three, and a ledger that is merely tamper-proof but cannot answer the other two is a very secure pile of numbers.

Part IV — Rules as Code

A rule a person can read, a test can check, and an engine can run is different in kind from a rule written in a memo. The difference is what makes "rule-versioned" mean something, and it is where this paper extends Paper 11 most directly.

Three bundles, three owners

The logic behind a set of books is not one thing. It is three, with different owners and different rates of change, and they should be kept as three separate, versioned bundles:

| Bundle | Examples | Who changes it | How often |

|—|—|—|—|

| Rules | Meals deductibility, depreciation conventions, economic-nexus thresholds and lookbacks, basis adjustment ordering | Legislatures, taxing authorities, standard-setters | Yearly or by enactment; effective-dated |

| Policies | Approval limits, who may post, what requires client attestation, when an estimate is acceptable, retention periods | The firm | By decision; versioned by the firm |

| Controls | Which clients a user may read, what an agent may call, what may reach the ledger | The firm’s security owner | Rarely; deny by default |

Keeping them separate is not tidiness. A firm policy change must never alter a tax treatment, and a control change must never alter a policy. When all three live in one place, that is exactly what happens.

The registry is the bundle

The architecture in Part VI includes a rule registry: rule id, version, effective dates, jurisdiction. It is tempting to build that as a table of descriptions. It should be the bundle itself. Each registry entry holds the executable policy, its test suite, its effective dates, and a hash of the bundle. A fact stamped with that hash points at logic anyone can open, read, and re-run — not at a sentence about it.

Decision logs are the provenance of judgments

When a policy engine evaluates a fact, it can record the evaluation: the inputs it was given, the policy version it ran, the result, and the time. That log is the "who decided, under what rule, as of when" for every automated determination, produced by the engine rather than reconstructed by whoever wrote the row. The provenance stamp on a fact should carry the decision id, so a reviewer can pull the full evaluation and not just its outcome.

This is also the cleanest answer to the question professional standards now ask about tools: what did the tool do, and did a person review it? The human approval is the review. The decision log is what was reviewed.

Tests are evidence of care

A policy with a test suite shows that someone checked it against known cases before it touched a client’s books. The meals rule has a 2022 case and a 2023 case; the nexus rule has a case just under the threshold and one just over; the basis rule has a case where losses exceed basis and must be suspended. The tests run when the rule changes and before it is deployed. "Every rule we apply has tests, and the tests ran before the rule did" is a sentence a lender, an examiner, or a licensing board understands without any further explanation of the architecture.

What this does to the lender’s question

Tom asked to see the rule. In a rules-as-code system the answer is a specific, versioned policy with effective dates, a test that demonstrates it, and a decision log showing it ran on Maria’s meals line on a particular date with a particular result. In any other system the answer is a citation in a workpaper and the preparer’s memory. The first is evidence. The second is testimony.

Part V — One Problem, Four Faces, Four Rules

The three properties and the rulebook would be academic if only one line on the return needed them. They are not, because four of the most consequential areas of an owner-operated business’s tax life share a single structure: cumulative, multi-year, rule-dependent facts that no general ledger report produces. Each is a record problem and a rule problem at once, and each rule below is the kind of thing that belongs in the rules bundle, with tests.

Substantiation. The tax code does not ask whether an expense is real. It asks for amount, date, place, business purpose, and business relationship, with the document behind it. A general ledger holds the amount and date. A custom field can hold one current value for purpose. Neither records who supplied the purpose, from what source, when, or whether anyone reviewed it. *The *rule: given a purchase, a category, and a date, which substantiation elements are required and which deductibility percentage applies — with the meals rule’s effective dates as the test cases.

Book-to-tax. Books and tax diverge by design: depreciation methods, the meals disallowance, penalties, accrued compensation paid after the 2½-month window, officer life insurance, state modifications. The practical method is a book-to-tax adjustment ledger — a second double-entry layer on the same chart of accounts holding only the differences, each permanent or temporary, with temporary ones carrying a reversal schedule. Nothing tax-only ever posts to the book ledger. The rule: for each adjustment category, whether the difference is permanent or temporary and, if temporary, when it reverses — with the 2½-month accrued-compensation case as the test.

Shareholder basis. For an S corporation, each shareholder’s stock and debt basis is a per-person, since-inception running total adjusted every year by income, separately stated items, distributions, nondeductible expenses, and losses, in a prescribed order, with losses suspended when basis runs out. The IRS requires Form 7203 whenever a shareholder claims a loss, takes a distribution, or disposes of stock. The general ledger has no shareholder dimension, no ownership history, and no memory of prior years. Preparers routinely inherit clients with no basis schedule, and reconstruction from inception is often impossible. The rule: the adjustment ordering and the suspension of losses when basis reaches zero — with a loss-exceeds-basis year as the test.

State nexus. Economic nexus is a threshold over time, measured per state over the current or prior year, under rules that legislatures amend. Income-tax apportionment needs sales, payroll, and property by state. A single remote employee often trips physical-presence nexus before any sales threshold does. The general ledger has a location dimension meant for business segments, not jurisdictions. The rule: per state, the threshold, the measure, the lookback period, and the sourcing method, effective-dated — with a just-under and a just-over case as the tests, and a new version whenever a state amends its statute.

| Fact family | Cumulative | Multi-year | Rule-dependent | Per-person or per-jurisdiction |

|—|—|—|—|—|

| Substantiation | No | Yes (retention) | Yes | No |

| Book-to-tax | Yes (reversals) | Yes | Yes | By jurisdiction |

| Shareholder basis | Yes | Since inception | Yes | By shareholder |

| State nexus | Yes (thresholds) | Lookback | Yes | By jurisdiction |

The table is the argument. Four different compliance problems, one data shape and one rule shape. A single provenance design and a single rules bundle serve all four, and building them for one makes the other three schema and policy rather than design.

Part VI — The Architecture: AI Around the Ledger, Rules Between Them

The owner keeps a locked general ledger as the book of record. Around it sits a provenance spine — an analytical system of record that holds every fact with the three properties and every judgment with its chain of custody. Between the people who review and the spine that remembers sits the policy engine, running the three bundles. AI operates in the spine and through the engine, never directly in the ledger.

The provenance architecture: five layers, two directions

Data flows upward: postings, bank activity, and documents land in the spine as stamped facts. Control flows downward through two gates. The policy engine evaluates every proposal against the rules, policies, and controls, logs its decision, and sets the review state; a person then approves; only then does an entry post to the ledger. Three independent records result — the ledger’s audit log, the spine’s facts and lineage, and the engine’s decision log — each produced by a different component, each able to corroborate the others. That is the internal-control principle an examiner already recognizes, applied to an AI-operated process.

The spine and the engine standardize five things across every fact family.

1. A uniform provenance stamp. Every row carries source system and reference, who or what captured it (person, pipeline job, or model and prompt version), when, which rule and version applied, the engine’s decision id, review state, and reviewer. Breadcrumbs become a contract rather than a habit.

2. Append-only facts with two clocks. Valid time and transaction time on every row. Corrections are new rows that supersede old ones; nothing is updated in place. This is what answers "what did we believe on the day the covenant was signed."

3. A lineage graph. An edge table recording that this basis adjustment derived from that tax adjustment, which came from that ledger line, which came from that receipt — and from that decision log entry. A single source column cannot express a tax trial-balance line that depends on forty inputs; a graph can.

4. The rule registry as executable bundles. Rules, policies, and controls as three separately owned, versioned, tested bundles. The registry holds the policy source, its tests, its effective dates, and its hash; every fact the rule touched carries that hash.

5. Decision logs. Every evaluation the engine performs is recorded with its inputs, policy version, result, and time, and linked from the fact it decided. This is the provenance of judgments, produced by the component that made the judgment.

This is the Trust Stack from Paper 11 — append-only storage, policy-as-code, secrets management, an approval state machine, observability — given its first fully worked application, plus the three things accounting adds: bitemporality, rule versioning, and rules that are code rather than prose. Tamper-evidence can be strengthened at commodity cost by hash-chaining fact rows and anchoring a daily root with a managed signing key, and by placing source documents in object storage with retention locks. None of this requires a distributed ledger; all of it requires discipline the system enforces rather than people remember.

What the owner gets is a general ledger that remains dull and locked, a rulebook that can be read, and a second record that can explain any number on the return — who, from what, under which rule and version, as of when — to someone who was never in the room.

Part VII — Governance: Who Does What, and How Anyone Knows

Parts IV through VI describe controls as code and a record that cannot be altered. Neither works without people in named roles, kept apart where the law and common sense require, informed and trained, and checked. The COSO internal-control framework names five components, and the architecture so far addresses only two of them well. This part fills in the other three, organized the way an examiner, a lender, or a licensing board would ask about them.

Control environment: roles and separation of duties

The system implies roles; governance names them and keeps them apart.

| Role | May | May not |

|—|—|—|

| Proposer (the AI agent, or a bookkeeper) | Stage facts and proposed entries; answer client prompts; draft | Post to the ledger; approve; author rules |

| Approver (controller, firm reviewer) | Approve or reject proposals; post approved entries | Author rules or policies; hold payment authority |

| Rule steward (tax lead) | Write and test the rules bundle; publish versions with release notes | Approve the first use of a rule they wrote; change policies or controls |

| Policy owner (managing principal) | Set firm policies: thresholds, attestation requirements, retention, AI procedures | Alter tax treatments; author controls |

| Control owner (security or IT) | Own the controls bundle and access; manage keys and sub-processors | Post, approve, or author rules or policies |

| Independent reviewer | Sample decision logs against approvals; test that controls fire; report exceptions | Any operating role above |

The AI agent is a role, not a tool. It has its own identity, its own permissions in the controls bundle, and the same incompatibilities as a person: it may propose and may never approve or post. A firm with one principal cannot fill six roles. What collapses safely: steward and policy owner, with release notes as the check. What never collapses: proposer and approver, and operating roles with the independent reviewer — in a solo practice the reviewer is an outside preparer or a peer, engaged for a few hours a quarter.

Payment authority is a separation issue with personal consequences. Under IRC §6672 any person with authority over which creditors are paid can be held personally liable for withheld payroll taxes that are not remitted; Virginia has a parallel rule for sales and withholding taxes. A bookkeeping firm should never hold signing or payment authority it does not need, and when it does, the instruction under which it acts should be a versioned policy and every payment direction a stamped fact. The record decides who was responsible, in both directions.

Risk assessment: what gets protected first

Not every fact family carries the same exposure, and the build order should follow the risk. Rank by the cost of a gap at the three moments: payroll remittance and §6672 exposure first; substantiation (routine examination exposure) and basis (permanent loss if lost) next; book-to-tax and nexus after. High-exposure determinations — a basis adjustment, a nexus registration decision, any payment direction — require two approvals; routine substantiation requires one. The ranking is a policy in the policies bundle, with a date, so the firm can show it was made deliberately and revisited.

Information and communication: nothing works if people don’t know

Three audiences need to be told, and the telling is itself a control.

Staff. How to read a decision log, what an approval means and what it commits them to, when to escalate, how a rule change reaches them. SSTS §1.4 (reliance on tools) and Circular 230 §10.35 (competence) make professional care and competence with the tools a personal obligation of the practitioner, so training is not an onboarding nicety; it is the compliance. Record attendance and content as facts.

Clients. Why the firm asks for business purpose and attendees, how to answer a prompt and by when, what "approved" on their statement means, and that an unanswered prompt is recorded as unsubstantiated. The engagement letter carries the standing terms; a short onboarding walk-through carries the habit.

Rule and policy changes. Every bundle version ships with a release note: what changed, why, effective date, who approved. Material rule changes — a state nexus threshold, a deductibility percentage — go to affected clients as a notice. The release notes are the change log an examiner asks for.

What the engagement letter must say. The architecture triggers specific disclosures. As the engaged preparer, the firm is a tax return preparer under IRC §7216, so the letter must carry written consent, in the IRS-prescribed form, before tax return information is disclosed to a provider outside the United States, to any provider that makes substantive determinations affecting tax liability, or used for anything beyond preparing the return, such as training a model or a client-facing benchmark that falls outside the regulation’s statistical-compilation limits. A Social Security number cannot be disclosed to a recipient outside the United States even with consent. Providers in the United States that only process or host the information do not require consent, but the firm must still meet the regulation’s conditions, including written notice of §§6713 and 7216 to every individual at a software contractor who receives the information. A GLBA privacy notice for individual clients. The no-assurance terms of a preparation engagement under SSARS 21. The firm’s records policy and retention periods. And, best kept in a separate Data and AI Addendum that cites the policies bundle version in force: the categories of tools used, that AI proposes and a named person approves, that determinations are logged and the client may ask how one was made, the sub-processors and where data lives, the client’s own responsibilities in the substantiation model, consent to the communication channels used for prompts, and what the client receives on exit so the trail is portable. When a bundle changes materially, the addendum is reissued, and its version history joins the record.

Monitoring: someone has to look

Logs are not monitoring; a person reading them is. Each quarter the independent reviewer samples decisions against approvals, reviews policy exceptions, confirms the append-only trigger still rejects updates and the controls bundle still denies by default, and reports in writing. A control failure has a named path: who is told, who fixes it, how clients are notified if their data or their numbers were affected. Monitoring results are facts in the spine like everything else, so the next reviewer can see what the last one found.

Privacy by design: four rules the schema must honor

Most owner-operator clients fall outside GDPR and California’s privacy law, and Virginia’s own statute exempts data already governed by the federal Safeguards Rule, which covers bookkeeping and tax data. The concepts still belong in the design, and one of them conflicts with immutability if it is not planned for.

1. Automated decisions are explained and humanly reviewed. Every automated determination is logged, explainable from the decision log, and approved by a named person. This is what GDPR Article 22 and California’s automated-decision-making rules ask for, and it is already what the professional standards require.

2. The record of processing writes itself. The activity table and rule registry, with purpose and retention fields added, generate the register of what personal data is processed, why, with whom it is shared, and for how long.

3. Erasure without breaking immutability. Tax and accounting records are exempt from deletion rights while legally required retention runs. Personal identifiers that are not required — attendee names after the retention period, an employee’s home address — live in a separate keyed store; deleting the key leaves the immutable fact intact with the identity unrecoverable. Retention periods are rules in the policies bundle with effective dates, so "why do you still have this" has a versioned answer. Design this before the first fact is written; retrofitting it onto an append-only schema is painful.

4. Collect only what the rule needs. Business purpose and attendees, not a narrative. An employee’s work state for nexus, not their address. Document pulls skip anything containing identification numbers or health information unless a rule requires it. Minimization is also what keeps the erasure problem small.

In relation to clients the firm is a processor acting on instruction, and the engagement letter’s data addendum is the contract that says so, names the sub-processors, and commits to notice when they change.

Part VIII — Implementation in Twelve Steps

The build runs on commodity infrastructure: a relational database, object storage, a policy engine, a workflow runner, and the ledger’s own API. The rulebook comes before the record, because the record’s stamps depend on it, and the governance terms come before the first client fact, because consent and roles cannot be retrofitted. Steps 1 through 7 are the design and contracting work and take roughly a month. Everything after is one pattern repeated.

1. Write the standard. One page: spine column names and types, the append-only rule, naming for fact families, what counts as a source, the review states, the three bundles with their owners, the six roles and who holds each (including which collapse in a small firm), and the risk ranking that orders the rest of the build. No schema or policy work begins before it exists.

2. Write the first rules as code. The three or four rules the firm applies most — the meals percentage with its effective dates, the capitalization floor, one state’s nexus threshold, the basis ordering — as executable policies, each with tests for the known cases. Separate bundles for rules, policies, and controls from day one; the policies bundle includes retention periods and the risk ranking.

3. Stand up the policy engine. Load the bundles, turn on decision logging, and confirm that a change to a bundle produces a new version, a hash, and a release note, and that the tests run before deployment. Nothing else may evaluate a rule.

4. Spine schema. A provenance mixin on every fact table, including the decision id; the rule registry pointing at bundle versions and hashes; a lineage edge table; an activity table with purpose and retention fields (job or session, actor type, actor id, model and prompt version, start and end). Valid-from, valid-to, recorded-at, and superseded-by on every fact. A separate keyed store for personal identifiers that are not required to be retained, so erasure never touches an immutable fact.

5. Enforce append-only and separation. Revoke update and delete on fact tables for every role but migrations. A trigger that rejects updates. A single function that writes the superseding row and stamps the old one in one transaction. Row-level security by client. The AI agent as its own identity in the controls bundle, permitted to propose and nothing else; no firm identity holds payment authority it does not need.

6. Wire the gate. The workflow runner sends each proposed fact to the engine; the engine returns allow or deny plus the rule ids and decision id; the writer records them on the row and sets the review state, with two approvals required for the high-exposure families the risk ranking names. Policies decide review state, not people typing it.

7. Contract and consent. Engagement letter updated for the preparation-engagement terms and records policy; §7216 consent in the prescribed form before any return information goes to a provider outside the United States or to one that makes substantive determinations, or is used beyond preparation, with the regulation’s conditions met for United States providers that only process or host it; GLBA privacy notice for individual clients; the Data and AI Addendum citing the policies bundle version; a client onboarding walk-through for prompts. None of the following steps touches a client’s data before this one is complete.

8. First fact family: substantiation. Nightly pull of purchases and attachments from the ledger into object storage, skipping documents the minimization rule excludes; OCR; substantiation rows with full stamps and decision ids. A message to the client for any missing purpose; the reply becomes a new row captured by the client; an unanswered prompt is recorded as unsubstantiated.

9. Snapshots and the book-to-tax ledger. A month-end job freezes each client’s book trial balance, hashed and stamped. Adjustment rows and a reversal schedule, seeded from last year’s tax workpapers for the firm’s own books and one pilot client, with the permanent/temporary rule in the bundle. Reconcile the tax trial balance to the filed Schedule M-1. A fixed-asset register with book and tax methods side by side as a feeder.

10. Basis and nexus. Derivations over steps 8 and 9 plus two feeders: ownership history and employee work locations (state only). New rules in the bundle, with tests; two-approval review by policy. Schema plus policy at this point, not design.

11. Tools, surfaces, and training. Trace a fact, read it as of a date, see who decided it and which decision log entry, list open items by client, and propose an adjustment — which writes to staging in the proposed state and nowhere else. Reporting over the tax trial balance; a weekly scorecard for substantiation gaps and approaching thresholds. Staff trained on reading decision logs, what an approval commits them to, and escalation, with attendance recorded as facts. No write tool reaches the ledger directly.

12. Monitor, pilot, productize. The independent reviewer’s first quarterly sample and control tests, reported in writing. A full year-end on the firm’s own books and one client before busy season. The deliverables — substantiation report, M-1 package, basis schedule with Form 7203 support, nexus assessment, the rulebook with its tests and release notes, and the reviewer’s report — become the service tier. Price on the artifacts, not the hours.

Three disciplines hold the whole thing together. Nothing tax-only ever posts to the book ledger. No fact exists in only one place: the hash in the database and the hash on the stored document are the handshake that lets either side verify the other. And no rule is applied except by the engine, so that every application has a version and a log.

Part IX — Five Questions Your Books Should Answer

An owner does not need to understand bitemporal schemas to know whether their books are provable. Pick any line on last year’s return and ask the system five questions.

1. Who recorded this, and was it a person or a program?

2. What document is behind it, and can I see it right now?

3. What rule decided its treatment, which version — and can I read the rule itself?

4. Has it changed since it was first recorded, and if so, when and by whom?

5. What did this line say on the date I signed the loan, the lease, or the purchase agreement?

Books that answer all five are ready for the three moments when evidence decides money: the examination letter, the financing, and the sale. Books that answer none of them are not wrong — they may be perfectly accurate — but they depend on the owner being in the room to vouch for them, and the owner will not always be in the room.

This is not an argument against AI in the books. It is an argument about where AI belongs. A system in which the AI proposes, evidence accumulates, a person approves, and a locked ledger records is one in which the AI’s speed and the ledger’s credibility reinforce each other. The owner gets both. That is the version of AI-operated finance worth building toward, and it is a stage an owner grows into rather than a product they switch to: a solo consultant with no debt, one state, and no exit plans does not need it yet. The owner buying a competitor does.

Part X — The Economics: Cheap to Keep, Expensive to Recover

The natural objection is cost. The answer is an asymmetry, not a sales argument: a provenance trail is inexpensive to keep and expensive — often impossible — to recover.

The asymmetry. A reviewer stamp costs seconds at the time the review happens. Reconstructing who decided what, three years later, costs hours per transaction and frequently fails, because the person has moved on or the document is gone. Basis is the extreme case: a schedule maintained annually is a routine deliverable, while one reconstructed from inception may not be possible at any price, and when it is not possible the loss is permanent — suspended losses disallowed, distributions taxed as gains.

What it actually costs. The components are ordinary. Commodity infrastructure: a relational database, object storage, and a policy engine, none of which carries a license tier or a distributed ledger. A one-time build of the standard, the schema, and the first rules with their tests. And a recurring cost that is mostly already being paid: the bookkeeper’s categorization, the preparer’s workpapers, the client’s answer to "what was this for?" The spine does not add those steps. It records them. The incremental cost is discipline, not labor.

What it displaces. Year-end reconstruction. Preparer questions in April. The clean-up engagement before a loan or a sale. The basis study a buyer’s diligence team demands. The multi-state exposure review done under deadline. Each is a line item an owner already recognizes, and each shrinks or disappears when the trail exists.

The three moments, priced by mechanism. A disallowed deduction costs the tax on the full amount, plus penalties and interest, not the cost of the missing receipt. A stalled loan costs the deal’s opportunity and a second underwriting, not the cost of the missing snapshot. A diligence gap is priced as a holdback or a reduction in the multiple applied to the whole business, not to the gap. In every case the cost of the gap is a multiple of the cost of the trail. The reader can complete the arithmetic for their own business; the paper does not need to.

The staircase makes it affordable. This is a stage an owner grows into, so it scales. A solo consultant needs the one-page standard and a decision log. A firm with a line of credit needs the spine and substantiation. A firm with partners and employees in three states needs basis and nexus. Nobody buys the whole thing on day one, and the entry step costs less than one clean-up engagement.

The framing. Insurance pays after a loss. A provenance trail keeps the loss from being one. You’re already doing the work. A little structure up front keeps the receipts for it.

Closing — Back in the Conference Room

Six weeks later Maria is across the table from Tom Reyes again. Nothing about her AI system has been removed. It still categorizes, drafts, and closes. What changed is what sits around it: a locked ledger it can no longer write to directly, and a record beside the ledger that keeps every proposal, every piece of evidence, every rule version, and every approval, with two dates on each.

Tom asks about the meals line. Maria pulls the April version and the current version side by side, with the August reclassification between them, the staff-event receipts attached, the rule that made them fully deductible — the rule itself, with its effective dates and the test that proves it — the engine’s log showing it ran on that line on that date, and her controller’s approval with a timestamp.

"That’s the trail," Tom says. He does not ask another question about the books.

Maria’s system was never inaccurate. It was unaccountable, in the literal sense: it could not give an account of itself to someone who was not there. The difference between the two meetings is not better numbers. It is a record that can stand on its own.

Relationship to Paper 11

Paper 11, The Trust Stack, established that an append-only ledger with policy-as-code, managed secrets, an approval state machine, and observability is a sufficient trust architecture for AI-operated finance, and that a distributed ledger is not required. This paper does not revise that conclusion. It extends it in four ways. First, it shows that immutability — the property Paper 11 secured — must be joined by bitemporality and rule versioning before a record is useful for substantiation, book-to-tax, basis, or nexus. Second, it shows that rule versioning only carries weight when the rules are code: separately owned bundles with tests and decision logs, which Paper 11 named as a component and this paper puts at the center. Third, it adds the governance Paper 11 assumed: named roles with separation of duties, the AI agent as one of those roles, communication and training as controls, monitoring by a person, privacy by design, and the engagement terms — §7216 consent among them — that the architecture requires. Fourth, it gives the Trust Stack its first fully worked application, with a schema, a build order, an economic case, and a set of deliverables an owner can hold. Paper 13, The Owner’s DAO, takes the governance layer forward from here.

The short form, for the owner and the lender alike: immutable tells you the record is intact; bitemporal tells you what it meant on any date; rule-versioned tells you why — and only rules you can read, test, and run can tell you that. Tax-ready books require all three, and a rulebook that is code.

This paper is the twelfth in the ProjectBits reading order. Read the series in order at projectbits.com/method. It builds on Paper 11, The Trust Stack, and is followed by Paper 13, The Owner’s DAO.

ProjectBits Consulting · projectbits.com/method · Reston, VA. Thought-OS™ is a trademark of ProjectBits Consulting. This paper is published for practitioner and client education.