Assurance
Readiness for service
The UK government’s Gate 4 review asks whether a service is ready to go live, meaning tested, supportable, recoverable and accountable. We mapped its review areas to the ledger and graded each one without rounding up.
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.
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, and its eight findings were fixed and re-audited. These reviews were internal to RODMENA. 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. The findings are published with their dates and their status. Evidence → |
| 5 | Load, soak and failure testing | Evidenced | Ten minutes of sustained traffic with zero errors, and clean books afterwards. The service process was killed outright under load and the books stayed consistent. A graceful drain lost nothing. The measurements were not taken on reference hardware. No speed figure is published. Evidence → |
| 6 | Known defects, incomplete work and the plan for them | Evidenced | The API reference carries a “what is not here yet” section. The state panel names what is not open. The changelog records what changed. 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. A certification roadmap is 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 | Every response in the guides was captured from a running instance. There is also 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 | An account statement can be exported through the paged API. The company exit policy describes formats and handover. Because the journal cannot be deleted, exit decommissions a tenant and leaves its rows in place. 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, and a migration may not weaken a rule. Every change is ticketed with a written requirement and a verification note. Evidence → |
| 17 | Accountability and handover | Evidenced | RODMENA LIMITED is the named operator. Its company number, registered office, contacts and security disclosure route are published. Evidence → |
| 18 | Lessons-learned mechanism | Evidenced | All of the audit rounds and all of the findings are 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 | No business case is published. The service is free today, and 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.