Skip to main content

​
The same Claude, wrapped in guarantees

The question this page answers is the one every technical reader arrives with:
Why not just use Claude Code?
It is a fair question, and the answer is not “our model is better”. It is the same model. The Clerk is Claude reading the document. The Typewriter is Claude drafting one. What changed is where the output lands.

​
The comparison

The last row is not a throwaway, and it is not false modesty.Conceding that raw Claude wins on setup speed and one-off flexibility is what makes the other seven rows believable.A comparison table with a clean sweep is a marketing artefact. This one has a row where the other column wins by a wide margin, and that row is true.

​
What each row actually means

Claude can produce a perfectly correct journal entry and write it into a spreadsheet, a database or a message.What it cannot do is make that entry unchangeable afterwards, or guarantee that the next one balances.GreatBook routes every posting through a single writer that refuses an unbalanced entry before the transaction opens, and stores each entry in a hash chain with database-level immutability triggers underneath.Correction is by reversal, never by edit.
A prompt can be told “do not approve your own work”.A control is the thing that makes it impossible, and that holds when someone tries.For a document-originated posting, two gates and three people mean the submitter, the intake approver and the posting checker must be three distinct real identities, enforced in the graph, in the service layer and by a database constraint - and the identity is derived from the verified session rather than accepted from the caller. An Accountant workpaper instead requires a named non-agent human who did not propose it.
Ask a model to do the same job twice and it does the job twice.A double-click on Approve, a retried request and a run resumed after a restart are all the same event arriving twice, and a book of record has to absorb all three as one.A GL idempotency key on a unique index makes the second one a no-op at the writer, and the Bookkeeper’s eval grades that the entry count stays at 1.
A conversation that dies mid-task is gone.The cognitive loop is checkpointed in Postgres, which is what makes the human gate durable rather than a UI convention: the graph survives a restart while it is paused, and resumes from the checkpoint rather than re-running the expensive pipeline.A run that dies anyway becomes an orphan, and the Auditor’s orphan family finds it.
This is the row where “varies per prompt” is doing real work.The same document, the same model, two differently worded prompts, two different document types. That is not a defect in the model - it is what a prompt is.GreatBook pins the prompt, pins the registry the answer must come from, grounds the procedure in an SOP store generated from the code that enforces it, and then measures the result on 68 recorded cases so drift shows up as a number rather than as a complaint.
Every posted entry carries lineage to its authoritative native source, approved document or workpaper, reversal, or system event. A document-originated entry also links to the exact bytes a human approved.An Auditor re-derives the hash chain, re-checks the GL invariants over already-posted entries, and scans for records stuck mid-pipeline - on a schedule, with read-only database sessions, and with its own read-only guarantee fingerprinted on every run.An assistant with no memory of what it posted last month cannot do this at all.
Two hundred supplier invoices a month do not want a conversation each.They want a lane: ingest, classify, extract, stage, approve, propose, approve, post - with the two approvals batched into a review queue and everything else automatic.The gates stay. What goes away is the typing.
Genuinely, and by a lot.“Reconcile these two CSVs and tell me what does not match” is a thirty-second job for a chat window and a bad reason to build a ledger.So is anything exploratory, anything one-off, and anything where the output is an answer rather than a record.The distinction that matters: does the output need to be true again next year? If not, use the chat window. If so, it needs a book of record, and a book of record needs the seven rows above.

​
The framing sentence

The difference is not better AI. It is the same Claude, wrapped in guarantees.
The judgment is Claude’s, and it is measured rather than assumed. What surrounds it is not intelligence at all:
  • the output lands in an immutable ledger through a single writer;
  • behind its source-specific control - two human gates for document intake, or the applicable canonical service control for another origin;
  • idempotently, so the same event twice is one entry;
  • with lineage from the entry back to its authoritative source and any bytes or workpaper somebody approved;
  • and with the judgment itself regression-gated, so a model change that degrades classification shows up as a red board rather than as a surprise in a close.
None of that makes the model smarter. All of it makes the model’s output accountable, which is a different and, for a book of record, more important property.

​
Where the comparison stops being useful

“Claude alone” is not a straw man, and it is also not a fixed target.A sufficiently determined engineer can build every row of that table around a chat window.At which point they have built this, and the interesting question stops being “why not just use Claude?” and becomes “who is going to attack your posting gate, and what happened when they did?”That question has an answer with receipts.