Ixana · Finance operations
Finance orchestrator
One book of accounts under payroll, supplier bills, cards, the web store, the patent programme and the Ops Desk, with watchers that point at problems they can prove and draft the fix, while every approval stays a named person and every figure says where it came from.
Prototype- Live demo: $61,900.00 of patent counsel and $35,140 of Ops requests carried to the cent, checked by a test
- Eleven rules, one test each; five watchers, the books proven unchanged after every run
- Ask the books refuses any question about one person's pay, and shows no rows
A warning the watcher cannot prove is thrown away before anyone sees it; a change the watcher proposes waits for a named person.
Problem. Money at a hundred-person chip company had two honest surfaces: the patent ledger, where every lawyer's dollar names its matter, and the Ops Desk, where every request has an owner and a spending limit. Nothing read them together. Payroll, supplier bills, cards, the web store and a research grant sat in five exports, so a bill paid twice was found by whoever happened to look.
What I did. The company asked for it and I built it in full inside the Wiki: made-up books with deliberate mistakes and fraud patterns hidden in them, nine screens that work out every number from the rows, and five watchers under one contract that may point and draft but never act.
Result. It never went to users: priorities shifted before the read-only trial on real exports was scheduled. Every figure here is a score on the made-up books, each with its sample size, and none is adoption, time saved or fraud caught.
01Why this, and why now
The obvious answer was a supplier-bills automation product. I argued for proving the way of working on data we own: the two surfaces that already worked here won because every figure names its row and every change names its person. What was missing was the book between them, and the rule that a watcher may find and draft but never act.
02The problem as people experienced it
I read the two surfaces that existed the way an auditor would: 25 patent invoices and their 70 lines, the Ops Desk's 28 requests and 15 shipments, asking for each dollar who owned it, what it was for and where it sat in the books. Both answered the first two on every row; neither the third.
The five other flows had no surface at all.
| Flow | Where a dollar lost its owner | Counts from the rows |
|---|---|---|
| Patent counsel (Patents ledger) | Two charges the firm could not name a matter for; held rather than defaulted into one | 2 of 25 invoices carry an unallocated line, $3,360 of $61,900 |
| Purchases and shipments (Ops Desk) | Refused at the ceiling, or shipped with no account to post to | 4 of 28 requests refused at $5,000; 15 shipments with no freight or duties account until now |
| Supplier bills, cards, payroll, web store, award | No ledger; five exports; a bank-detail change was an email | 0 of 5 flows with a row-level trail; 4 vendor bank changes, 3 never verified by call-back |
The finance lead wanted to know where any number came from, and that nothing had paid itself.
03My role and approach
I owned the watchers' contract, the made-up data and its answer key, and the integrity rules; most of the work was writing rules a finance lead can argue with.
Key decisions
- Finance reads the two existing surfaces and never rewrites them. One test per source fails if a cent moves.
- A watcher returns warnings and drafts, or nothing. A warning with no proof row is dropped before it is shown.
- The answer key lives apart from the data. A test reads the watchers' code to prove they never open it.
- Every number is worked out on the spot, with its source. Nothing on a tile is stored, so it cannot drift.
04What was built
A Finance section inside the Wiki: one generator builds the books, two readers copy Patents and Ops in unchanged, nine screens work out what they show on each visit, five watchers return warnings and drafts, and the question box answers from rows it can point to, or refuses.
- 1Three warnings on one bill, because one row can be three things. The $61,000 rush bill copies the genuine April packaging bill, arrives a day after an unverified bank change, and is a round amount with no purchase order. The first scorecard run counted it as three false alarms; the answer key was wrong, not the rules.
- 2The reasons are weights a finance lead can argue with. Unverified change 50 %, days to the bill 20 %, requested by email 15 %, rush 15 %: shares of one confidence score, adding to 100, each with the value that earned it.
- 3Proof links open the rows; a warning with none is never shown. The contract drops it before it is returned and counts the drop; the count is zero and on the screen.
- 4Release payment is refused here, whoever asks. The bank change is unverified, so the check refuses the release with the reason and the phone call to make; the associate who keyed the bill is refused the approval as well.
A recreation on the made-up books. The bill, the supplier and the bank are invented; the rule, the weights and the refusal are the ones that run.Open the bill, then try to release the payment ↗
| Finance idea in the demo | The standard nonprofit fund-accounting term (ASC 958) | What holds it |
|---|---|---|
| Operating fund: money the company may spend on anything in the plan | Net assets without donor restrictions | Every line carries a fund; the operating fund has no rules |
| Award R-01: grant money with strings attached (allowed dates, a budget per category, rules) | Net assets with donor restrictions; a project with a budget, a period and allowability rules | Five rules judge every grant line each time it is read; a line that breaks them drafts a move to operating for the grant manager and the finance lead to approve |
| Overhead at 20 % on direct costs, never on equipment | Indirect cost rate on a modified base | Worked out from the allowed direct lines; a test holds the base |
| Month-end checklist, business days 1 to 5 after month end, proof per task | Period close with task ownership and a lock | Status is worked out from the rows; closing the month is a person's action |
| Tamper-proof audit log | Audit trail with tamper evidence | Verify recomputes every fingerprint; an edited entry breaks the chain from its number on |
Every image is the state its own link opens. All six are recreations on the made-up books; the people are invented and the refusals are the ones that run.
05What we learned
The build ran to the end; the rollout never started. The made-up books show the contract holds: 47 hidden problems, 179 look-alikes, 371 bank lines, every figure a count against its total. They cannot show what a real month holds, and no real month was ever read.
No outcome figure appears on this page; nothing was measured with users.
The stops were agreed before build with the finance lead who would have run the trial: any action taken by a watcher, any warning shown without a proof row, any write reaching the Ops Desk or the Patents ledger, any screen revealing one person's pay. None was ever tested against a real month.
The lesson is about sequence: proving the way of working on our own data produced a convincing demo and no user. The read-only trial should have been the first milestone, not the next one.
How we counted. A hidden problem counts as found when a warning of its type names its row; a look-alike counts as wrongly flagged when any warning of that type names it. Precision is the share of warnings that were real; recall is the share of real problems found.
Build configuration — a Finance section inside the Wiki (Next.js 16, React 19, Tailwind 4), nine routes and a mock API · one deterministic seed (mulberry32, seed 20260925, clock 21 Aug 2026), fingerprint pinned by test · two read-only adapters over the Patents ledger and the Ops Desk export (SHA recorded) · eleven rule functions, a three-pass matcher, five watchers under one contract, ask the books as deterministic retrieval · FNV-1a hash-chained audit log · vitest, 50 tests · no model, no network call, no database, no writes
06What I'd do differently
I wrote the answer key as one problem per row and paid with a first scorecard of 0.34 precision; most of the false alarms were real.
I would have asked for the trial’s slot before writing the first rule; a build with no scheduled user is the first thing a priority shift removes.