Skip to content
Menu
The Finance Hub case

Finance Hub · system map

Finance Hub, under the hood

Explore how an invoice becomes checked books in our own property finance system. Claude reads the documents; plain code checks everything it wrote. Play the tour, pick one of the 8 journeys, or select any part to see what it does.

Verified against the code, 12 October 2026

Journeys8 journeys through the system

PEOPLEthe owner and a guestINBOX AND CLAUDEdocuments in, rows outRECORDSthe books, in the repositoryAPP SEEDwhat the app is built fromCHECKSAPPin the browser · no AI callsHOSTINGserver functions and stateAPP BACKUPScopies of the stored stateBOOKS BACKUPSrepository and off-site copyOwnerGuest viewerRaw files inboxIntake triageClaude readsAIArchive stepLedger notesLedgersOriginalsDocument registerApp mirrorSeed builderCIValidator self-testBooks checkPre-commit guardDeploy gateLeak checkDashboard appSave engineConflict dialogBooks syncState functionState storeSign-inSave historyDaily backupPrivate repositoryOff-site copy

Overview

Every booking starts with a document the owner drops in the inbox. Follow it to the dashboard through 29 parts and 44 connections.

Mapped from the Finance Hub code and checked against it. Structure only: no amounts, people, suppliers or documents are shown.Verified against the code

By the numbers

checks the books must pass
52
self-test cases: a clean copy and 8 planted mistakes
9
source documents archived, each with a SHA-256
47
line items booked from them
207
app rows from 52 expenses
103
views in the app, plus an admin Settings page
7
deploy gate steps, all must pass
6
days each daily backup is kept
30

Checked against the code, with a passing books check, on 12 October 2026.

How each number was counted
52 checks the books must pass
The failure checks in the books validator, 12 October 2026.
9 self-test cases: a clean copy and 8 planted mistakes
The validator self-test, 12 October 2026.
47 source documents archived, each with a SHA-256
The archived originals, with a passing books check, 12 October 2026.
207 line items booked from them
The line-item ledger, with a passing books check, 12 October 2026.
103 app rows from 52 expenses
The app mirror, one row per asset an expense touches, with a passing books check, 12 October 2026.
7 views in the app, plus an admin Settings page
The dashboard app, 12 October 2026.
6 deploy gate steps, all must pass
Lint, the books check, its self-test, server tests, unit tests and the build, 12 October 2026.
30 days each daily backup is kept
The scheduled backup job, 12 October 2026.

The journeys, step by step

The same 8 journeys the map plays, written out. Each step names the parts it connects.

01An invoice, inbox to dashboardInbox and Claude · 11 steps
  1. 1The owner drops a PDF or a photo of an invoice into the inbox.Owner → Raw files inbox
  2. 2Intake hashes the file and checks the register. Identical content is a duplicate and is never booked twice.Raw files inbox → Intake triage
  3. 3A re-scan goes to the owner, who decides which copy replaces which.Intake triage → Owner
  4. 4A new file goes on to Claude.Intake triage → Claude reads
  5. 5Claude reads it and adds the expense, line-item and asset rows, following the written booking steps.Claude reads → Ledgers
  6. 6The original is copied into the archive and re-hashed to prove the copy matches, and its hash is registered.Claude reads → Archive step; Archive step → Originals; Archive step → Document register
  7. 7Each expense becomes one app row per asset it touches, and the seed is regenerated.Ledgers → App mirror; App mirror → Seed builder
  8. 8The books check cross-checks every layer: ledgers, mirror, seed, line items, file hashes and the ledger notes.Seed builder → Books check
  9. 9The batch goes in as one guarded commit.Books check → Pre-commit guard; Pre-commit guard → Private repository
  10. 10On push, CI and the deploy gate run every check again, and the public bundle is scanned before anything deploys.Private repository → CI; Private repository → Deploy gate; Deploy gate → Leak check
  11. 11Once it is deployed, the books rows go live and the dashboard shows the invoice.Deploy gate → State function; State function → Books sync; Books sync → Dashboard app
02Asking the ownerPeople · 3 steps
  1. 1An unclear split, payment method or date becomes a question for the owner, not a guess.Claude reads → Owner
  2. 2The question is logged under Open questions in the ledger notes.Claude reads → Ledger notes
  3. 3Once the owner answers, the settled decision is written into the booking steps.Owner → Claude reads
03The self-test plants mistakesChecks · 3 steps
  1. 1The self-test copies the books to a temporary folder.Validator self-test → Ledgers
  2. 2The clean copy must pass. Then 8 planted defects must each fail: a wrong flat, a shifted split, edited line items, a changed original, a stale seed, a wrong column, a locked owner decision broken and a typo in a fixed list.Validator self-test → Books check
  3. 3It runs in CI on every push, and again before every deploy.CI → Validator self-test; Deploy gate → Validator self-test
04A save with a conflictApp · 4 steps
  1. 1An edit in the app autosaves, with the revision it started from.Owner → Dashboard app; Dashboard app → Save engine
  2. 2If the copy has changed since, this tab gets a conflict reply instead of overwriting it.Save engine → State function
  3. 3The person chooses Merge, or Discard mine, with their edits downloaded first.State function → Conflict dialog
  4. 4The merged copy is saved only if nothing changed in the meantime.Conflict dialog → Save engine; Save engine → State function; State function → State store
05Nothing silently deletedHosting · 5 steps
  1. 1Deleting in the app only marks the record deleted, and logs it.Dashboard app → Save engine
  2. 2The server refuses any save that would make a stored record disappear. The audit log is append-only.Save engine → State function
  3. 3The previous state is copied before every overwrite.State function → Save history
  4. 4The Deleted items page restores a record, and logs the restore.Owner → Dashboard app
  5. 5On the books side, a missing original fails the check.Books check → Originals
06Build gate and leak checkChecks · 4 steps
  1. 1The deploy gate runs the books checks first: the books check and its self-test.Deploy gate → Books check; Deploy gate → Validator self-test
  2. 2The public bundle is scanned for 6 bookkeeping data patterns. A single match fails the build.Deploy gate → Leak check
  3. 3Line items reach the browser only after sign-in, which is rate-limited and uses signed sessions.Leak check → Dashboard app; Dashboard app → Sign-in
  4. 4A guest viewer gets a cut-down, read-only view, with no audit log, contacts or PINs.Guest viewer → Dashboard app
07BackupsBackups · 3 steps
  1. 1A scheduled job copies the stored state into a separate store every day, and keeps each copy for 30 days.State store → Daily backup
  2. 2Every save keeps a copy first: the latest 50, plus one a day for 90 days.State store → Save history
  3. 3After each batch, the books get an add-only off-site copy with a verified hash manifest.Private repository → Off-site copy
08Where AI is usedAI · 3 steps
  1. 1AI only reads documents, at booking time: Claude turns each new document into ledger rows.Raw files inbox → Claude reads; Claude reads → Ledgers
  2. 2Deterministic checks then verify everything Claude wrote.Ledgers → Books check
  3. 3The app makes no AI calls at runtime. It shows only books that have passed the checks.Dashboard app → State function

Want your documents booked like this, and checked like this?

Tell us about the paperwork and where it has to end up. We'll reply within two business days with a first view of what we'd build.

Start a project