Specification before code
The requirements register and the database definition were written and proven against a real database before the application existed. The schema is treated as law: no rule is ever weakened.
Assurance
Verified, not declared
Every claim on this site has a named source in the ledger repository, a date, and a check that keeps it true. This page says how the ledger was built, how it is verified, and how it is secured — and what has not been done.
How it was built
Specification, gates and an auditor who refused the first one
Money moves only through two functions
Application code cannot reach the journal directly. Every posting and every settlement goes through one of two database functions that check, lock and write in a single step.
Gates, not milestones
Work could not proceed past a stage until an independent internal auditor had re-run every claim live. The first gate was refused. That refusal is published.
Every guard tested in both directions
A check must be shown to catch a known defect before its clean result is trusted. A check that cannot go red cannot go green.
The audits were conducted by an independent internal audit function at RODMENA that did not write or merge the application code. No external body has reviewed the ledger; the company says so wherever the audits are mentioned. The complete history, with every finding, is on the audit history page.
Continuous verification
The numbers, and how they are produced
Re-counted from the repository before each release of this site; a figure older than 120 days fails the build.
112
automated tests
Run over real PostgreSQL and real HTTP against a running service, never a mock.
101
database certification probes
Schema-level probes that must all pass before a migration is accepted.
54
live probes against the running service
Each proves a known-positive before it asserts an absence, and tests every guard in both directions.
4
internal audit gates
Gate A schema fidelity, Gate B money path, Gate C workers and reads, Gate D readiness — each signed off by an independent internal auditor before work could continue.
194,432 / 0
requests served / errors in the ten-minute load test
Ten minutes of sustained traffic; zero errors; the books reconciled clean afterwards. Not measured on reference hardware, so no latency figure is published.
Figures re-counted from the ledger repository on 2026-09-05; every audit was internal, by an independent internal auditor. How the numbers are produced.
For engineers: how each figure is counted
- Automated tests
cd ~/develop/ledger && .venv/bin/python -m pytest --collect-only -q tests/ | tail -1- Database probes
grep EXPECTED_PROBES= audit/evaluations/schema-probes.sh- Live probes
grep -oE 'probe_[a-z0-9_]+' audit/evaluations/run_all.sh | sort -u | wc -l- Load test
- ledger SPECS/build-plan.md, ticket #9 verification record
Testing doctrine
Six rules the verification lives by
- 1A check that cannot go green cannot go red.
- 2Every guard is tested in both directions.
- 3Exact numbers, not ranges: the storm yields exactly ten commits, exactly zero deadlocks. “About ten” is a bug report.
- 4Crash tests are real: the process is killed at the named point, not a mocked exception.
- 5Report what you did not run.
- 6We never declare a readiness we have not exercised; what was not run is reported alongside what was.
Load and failure testing
Sustained traffic, a killed process, and clean books afterwards
194,432 requests, 0 errors
10 minutes of sustained traffic at a target of 500 requests a second. No request failed, and the reconciler reported clean books afterwards.
The process killed outright under load
With hundreds of transactions in flight the service process was killed without warning. Afterwards: no partial writes, no double-applied entries, books consistent.
A graceful stop that lost nothing
Told to stop mid-storm, the service finished every request in flight, refused none, and left the reconciler clean.
These runs were on a shared machine, not reference hardware. That is why no response-time figure appears anywhere on this site: it would be a number about the wrong computer.
Security model
What protects the books, in plain terms
The ledger cannot mint its own credentials
Keys are issued by the company authorisation service. The ledger holds no secret capable of producing a credential it would accept, and a probe asserts that continuously.
Isolation the application cannot bypass
Row-level isolation is enforced inside the database and fails closed: a request with no valid boundary is refused rather than answered.
Keys do one job
A partner key cannot move money; a posting key cannot create tenants. Revocation is immediate; expiry is enforced by the ledger itself.
An outage is a 503, never a 403
If the authorisation service is unreachable, the ledger says so rather than pretending a valid key is invalid.
Limits at the edge
Request floods are refused before they reach the service; oversized requests are refused with the same clear error format the API uses everywhere.
Every number here has a named source
The figures on this site are re-counted from the repository and dated. A stale figure fails the site build.
Company-level assurance lives on rodmena.co.uk: the Trust Centre, the security whitepaper, service and support, exit and portability and data processing. RODMENA holds no ISO 27001 or SOC 2 certification today and publishes its certification roadmap there.
Due diligence
Two pages for a procurement or risk review
Audit history
Every round, dated, with the number of findings and what happened to them.
Readiness for service
The GOV.UK Gate 4 review areas, mapped honestly to what a buyer can verify today.
Ask us the hard questions.
Send your due-diligence questionnaire or your own test plan; we answer with evidence, and we say plainly when the answer is no.