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, and no rule in it 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. It also says 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.
Stage gates that could refuse the work
Work could not proceed past a stage until an independent internal auditor had re-run every claim live. The first gate was refused, and that refusal is published.
A guard must catch a real defect first
A check must be shown to catch a known defect before its clean result is trusted.
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, and the company says so wherever the audits are mentioned. The audit history page lists the complete history and every finding. See 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. An independent internal auditor signed them off one at a time, and work could not continue until a gate was signed.
194,432 / 0
requests served / errors in the ten-minute load test
Ten minutes of sustained traffic with zero errors, and the books reconciled clean afterwards. The run was not measured on reference hardware, and 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.
How each figure is counted, for engineers
- 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 there were no partial writes, no double-applied entries, and the books were 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 it fails closed. A request that arrives with no valid boundary is refused.
Keys do one job
A partner key cannot move money, and a posting key cannot create tenants. Revocation takes effect immediately, and the ledger enforces expiry itself.
An outage is a 503, never a 403
If the authorisation service is unreachable, the ledger says so and does not pretend a valid key is invalid.
Limits at the edge
Request floods are refused before they reach the service. An oversized request is refused in the same error format the API uses for everything else.
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.com, which holds 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 is dated and shows 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.