Assurance
Readiness for service
The UK government’s Gate 4 review asks whether a service is ready to go live: tested, supportable, recoverable, accountable. We mapped its review areas to the ledger and graded each one honestly.
About this mapping
A public-sector lens, applied to a startup
Gate 4 “Readiness for Service” is a review framework for major public-sector programmes. RODMENA is a startup and the ledger has not been reviewed by any external body. What follows is our own mapping of the framework’s review areas to what a buyer can verify today: Evidenced means the linked material shows it; Partial means some of it exists and the gap is named; Planned means it is on the roadmap; Not applicable means the area belongs to the buyer, not the vendor.
The review areas
Twenty-one areas, graded
15 evidenced · 4 partial · 0 planned · 2 not applicable
| # | Review area | Status | What a buyer can verify |
|---|---|---|---|
| 1 | Requirements agreed before build | Evidenced | A written requirements register and a normative database definition existed before the first line of application code; the audit history shows the gates that checked the build against them. Evidence → |
| 2 | Testing complete against acceptance criteria | Evidenced | Automated tests over a real database and real HTTP, database certification probes on every migration, and live probes against the running service. Figures and how they are counted are on the assurance page. Evidence → |
| 3 | Independent review at stage gates | Evidenced | Four gates, each signed off by an independent internal auditor before work could continue. The first gate was refused on its first pass; the eight findings were fixed and re-audited. Internal. No external body has reviewed the ledger. Evidence → |
| 4 | Adversarial re-verification after certification | Evidenced | Repeated no-trust rounds that treated the previous sign-offs as claims to falsify. Every finding, its date and its status is published. Evidence → |
| 5 | Load, soak and failure testing | Evidenced | Ten minutes of sustained traffic with zero errors and clean books afterwards; the service process killed outright under load and the books still consistent; a graceful drain that lost nothing. Not on reference hardware; no speed figure is published. Evidence → |
| 6 | Known defects and incomplete work, with a plan | Evidenced | The API reference carries a “what is not here yet” section; the honest-state panel names what is not open; the changelog records every change. Evidence → |
| 7 | Rollback and continuity | Partial | A one-command application rollback that re-verifies through the public URL. Database backup and standby arrangements are described in operator runbooks that are not yet published. Publishing the database continuity summary is planned. Evidence → |
| 8 | Incident management | Partial | Operator runbooks exist for the failure modes the design anticipates; the company security whitepaper covers incident response and notification. No incident history is published yet. Evidence → |
| 9 | Monitoring and health | Evidenced | A health endpoint that checks the database before answering, a background reconciler that keeps proving the books balance, and an alert path that has been shown to fire. Evidence → |
| 10 | Information assurance and accreditation | Partial | The security model is published; the company holds no ISO 27001 or SOC 2 certification and says so, with a certification roadmap on the company site. Evidence → |
| 11 | Service and support model | Evidenced | Support model, severity definitions and maintenance windows are published. There is no uptime commitment on the free plan, and the pricing page says so. Evidence → |
| 12 | Training, documentation and onboarding | Evidenced | Guides with every response captured from a running instance, a runnable tour, an API explorer, the OpenAPI document and a contract written for software agents. Evidence → |
| 13 | Data retention and immutability | Evidenced | The journal is permanent by construction. Retention periods for operational data (request keys, delivery events) are documented in the API reference. Evidence → |
| 14 | Exit and portability | Partial | Every account statement can be exported through the paged API. The company exit policy describes formats and handover; because the journal cannot be deleted, exit means decommissioning a tenant, not deleting rows. Evidence → |
| 15 | Data protection | Evidenced | ICO registration, published data-processing terms, a data processing agreement and a sub-processor list. Evidence → |
| 16 | Change control | Evidenced | Database changes ship only as versioned migrations that never weaken a rule; every change is ticketed with a written requirement and a verification note. Evidence → |
| 17 | Accountability and handover | Evidenced | A named operator, RODMENA LIMITED, with company number, registered office, contacts and a security disclosure route published. Evidence → |
| 18 | Lessons-learned mechanism | Evidenced | Every audit round and every finding is published, including the ones that were embarrassing. Lessons are recorded against the tickets that taught them. Evidence → |
| 19 | Go/no-go and release verification | Evidenced | A deploy refuses a dirty or unpushed tree, verifies the served site after the switch, and rolls back on any failed check. Evidence → |
| 20 | Benefits evaluation and pilot success criteria | Not applicable | A vendor cannot evaluate a buyer’s benefits. A five-point pilot checklist is offered instead. Evidence → |
| 21 | Business, financial and commercial cases | Not applicable | Not published. The service is free today; the company’s terms are on the company site. Evidence → |
Use this as your due-diligence checklist.
Send us the areas you weight most; we answer each with the evidence behind it, and say plainly where the answer is partial or no.