Axiom three in our thesis says trust scales with verification, not with intelligence. This paper is the engineering consequence. One loop, four steps, implemented in every velofy product no matter what the agent is doing: proposing journal entries, scoring Mains answers, or editing source files. The steps are cheap to state and unforgiving to implement, which is precisely why almost nobody ships all four.
propose → the agent renders exactly what it intends to do,
in a form a human or machine can inspect
confirm → an accountable party approves THIS proposal,
not a category of proposals
read back → the system re-fetches what actually landed
and diffs it against the promise
audit → all four moments land in a tamper-evident recordPropose: the payload is the interface
In Numera, our accounting console, nothing reaches a ledger without first rendering as a readable proposal — the full entry, debits and credits by account, the period it touches, and the effect on balances shown before and after. Journal entries are balance-checked before they can even be proposed: a lopsided draft never becomes anyone's problem. The same discipline appears in Kestrel as a dry-run diff preview with atomic per-file rollback, and in heyIAS as a scored rubric with per-dimension marks exposed, not a naked grade.
The design rule: the proposal must be checkable by something weaker than the agent that wrote it. If verifying the proposal requires the verifier to redo the agent's reasoning, you have built a chatbot with extra steps.
Confirm: accountability is a person or a gate, chosen deliberately
Confirmation takes a different shape per product because the point of trust differs. Accounting keeps a human: every confirmed write records who confirmed it, maker and checker are segregated, and filings carry a chartered accountant's signature. Coding automates the gate: Kestrel's exit code is zero only when the test suite ran green — the CI pipeline is the accountable party. Evaluation splits the difference: dual-pass scoring at temperature zero, low-confidence answers routed to a human queue, and a sampled slice re-checked by experts weekly to calibrate the engine itself.
Auto-approve toggles deserve suspicion everywhere. Numera's defaults off, and even then per-session only. Convenience that erases the confirmation step erases the accountability that makes the product sellable.
Read back: catch the wrong-account post
The step most teams skip, and the one that earns its cost. After a confirmed write lands, Numera re-fetches the posted record from the platform and diffs it against the proposal line by line — per account, per currency, per amount. Totals tying is not success: a post to the wrong account with correct totals passes every naive check and silently ruins the books. Our read-back catches it, and when a platform's API returns no account codes, the verdict says exactly that — "checked totals + line count" — so a verified stamp never overclaims what it could not see.
Two production details make this trustworthy. Writes are idempotent — a deterministic control id means a retried confirmation returns already-applied instead of double-posting. And posting into a closed or locked period is refused before the proposal ever renders, because no amount of after-the-fact auditing unpublishes a filed return. Unwinding is a documented operation — reversing entries that swap every debit and credit and cite the original — never an edit to history.
Audit: a ledger for the ledger
Every executed action lands in an append-only record chained with HMACs — each row signs the previous — so edits, insertions, renumberings and deletions are detectable, and a one-click packet exports a period's writes with their confirmations, read-back verdicts and row hashes for an auditor. We disclose the residual openly in-product: an attacker who deletes tail rows and their seals in lockstep defeats an on-box chain, which is why the roadmap puts the anchor off-box. Honesty about the last 2% is what makes the first 98% believable.
The same loop, three products
| Propose | Confirm | Read back | Audit | |
|---|---|---|---|---|
| Numera | Balanced-entry draft, balance-checked pre-render | Named human, maker ≠ checker | Line-level re-fetch diff per account/currency | HMAC-chained ledger + exportable packet |
| heyIAS | Rubric scores with per-dimension marks | Confidence threshold → human queue; weekly expert sample | Agreement rate vs expert re-checks, published | Score provenance kept per answer |
| Kestrel | Dry-run diff, atomic rollback | Test/build gate decides | Verification command output is the read-back | Run logs + failure reports, reproducible |
Rules in code, not prompts
Underneath the loop sits one more rule: anything that must hold is versioned code, never a prompt instruction. Debits equal credits is a validator. GST box arithmetic is a validator. Summit's expression interpreter enforcing a CSP-safe allowlist is a validator wearing a different coat. Prompts shape proposals; code shapes reality. An agent can be clever inside the walls and nothing it does crosses a wall unchecked.
Verdict
The loop is not free: read-back plumbing per platform, idempotency keys, chained audit storage, sampled human review. It is also the entire moat. Anyone can rent a model; almost nobody will do the unglamorous work of proving the model right. We intend to be defined by that work.
See also: three markets, one thesis for why this loop exists, and taste as a constraint for the same discipline applied to interfaces.