Review framework: seven dimensions

This page is the contract for the engagement. We are asking EY to assess the Olly documentation set against seven dimensions, file findings with a consistent severity rubric, and deliver the result in the format specified at the bottom of this page.

Severity rubric

Every finding should carry exactly one severity. The same rubric applies across all seven dimensions below.

• Critical - The issue blocks regulatory approval, blocks production launch, or creates an unmanaged risk of patient harm, financial loss, or data breach. Must be resolved before next phase.
• Major - The issue would materially weaken a regulatory or architectural defense if challenged. Resolvable within the current phase but needs an owner and a date.
• Minor - The issue is a clear improvement opportunity that does not block anything. Should be tracked in the backlog.
• Informational - An observation, a contextual question, or a "consider this pattern" suggestion. No action required, but useful to the team.

When in doubt between two levels, choose the higher and explain the trade-off in the finding text.

1. API design

This dimension covers the public and inter-service API surface: REST contracts, OpenAPI specs, event payloads, naming, versioning, error semantics, idempotency, pagination, and the consistency of those patterns across capabilities.

Questions to answer:

• Are API contracts consistent and discoverable across the claims, eligibility, enrollment, billing, provider, policy-admin, care, consent, and triage services?
• Is versioning explicit and forward-compatible? What happens to clients on a breaking change?
• Are error envelopes, idempotency keys, and pagination uniform, or does each service reinvent them?
• Are events first-class (named, versioned, schema-registered) or are they an afterthought to REST?
• Is there a clear distinction between public (member/employer/broker app) and private (service-to-service) APIs, with the right hardening on each?

2. Engineering patterns

This dimension covers the recurring patterns in the codebase as reflected in the docs: how services are structured, how cross-cutting concerns (auth, telemetry, retries, secrets, feature flags) are handled, and whether the patterns are applied consistently.

Questions to answer:

• Is there a documented "shape of a service" and do the documented services follow it?
• How are cross-cutting concerns - authn/authz, observability, retries, secrets, feature flags - factored, and is the factoring uniform?
• Are concurrency, transactional, and eventual-consistency boundaries explicit?
• Is there a clear pattern for handling PII, PHI, and Article 9 health data end-to-end?
• Where the docs reference internal patterns (PII walls, OPA partial eval, OpenBao Transit), is the rationale documented to a level a new senior engineer could pick up?

3. Layering

This dimension covers the separation between domain, application, integration, and infrastructure layers; whether the C4 levels are honest reflections of the running system; and whether responsibilities leak across layers.

Questions to answer:

• Do the C4 L1-L3 views reflect the same system, or do they drift apart?
• Is the domain layer (ontology, glossary, invariants) cleanly separated from transport and storage concerns?
• Are integrations (NHS, Stripe, Novu, Mirth, Keycloak) bounded behind anti-corruption layers, or do their concepts leak into core domain code?
• Is there a clear ownership boundary between the platform services and the apps (member, employer, admin, triage chat)?
• Where the docs describe a layer, can a reader tell which code lives in it without reading the code?

4. Integration completeness

This dimension covers the inbound and outbound integrations the platform depends on - identity, payments, EDI/HL7, NHS data, notifications, document storage, observability - and whether the integration story is complete enough to support a live operation.

Questions to answer:

• Is every external dependency named, with its purpose, contract, fallback behavior, and SLA documented?
• For each integration, is there a documented failure mode and a documented recovery procedure?
• Are the test environments and the production environments described with the same fidelity, including which integrations are mocked vs. live?
• Are the data flows that cross a trust boundary (e.g. clinical data into triage, payment data into billing) documented with the controls applied at the boundary?
• Are integration contracts (OpenAPI, AsyncAPI, HL7 mappings, EDI mappings) versioned and discoverable?

5. Use-case completeness

This dimension covers whether the documented architecture actually supports the business model the company has committed to. The process coverage map is the primary artefact here.

Questions to answer:

• Does the InFORM-aligned coverage map honestly reflect what is implemented, partially implemented, and out of scope?
• For the core insurance value chain (quote, bind, endorse, renew, claim, pay), is each step traceable from a business process to a service to an API?
• Are the cross-capability flows (triage-to-care, claim-to-payment, eligibility-to-prior-auth) documented end-to-end, or only per-service?
• For the regulated workflows (consent capture, prior authorization, claims adjudication, complaints), is the audit trail described?
• Are there documented use cases that the architecture does not support, with a documented reason?

6. Documentation maturity

This dimension covers the docs themselves as a deliverable: structure, navigability, freshness, consistency of tone, presence of decision records, and whether a new joiner could reach competence using only the docs.

Questions to answer:

• Is there a clear information architecture, and does the navigation match it?
• Are decisions captured as design records (or ADRs) with context, options, decision, and consequences?
• Is the language consistent? (Olly's glossary lives under domain - is it actually applied across the docs?)
• Are the docs versioned with the system, or do they drift?
• Could a new senior engineer or a regulator reach a working understanding using only what is in this build?

7. Regulatory posture

This dimension covers whether the documented architecture is defensible against the UK regulatory regime Olly operates under. Specifically:

• FCA - conduct of business, SYSC, SUP, ICOBS for insurance distribution.
• PRA - prudential rules where Olly is or becomes an authorised insurer.
• GDPR including Article 9 - lawful basis for processing health data, DPIAs, data subject rights, cross-border transfers.
• NHS DSPT - the Data Security and Protection Toolkit standards for organisations handling NHS data.
• IDD - the Insurance Distribution Directive's product oversight, demands-and-needs, and conflicts-of-interest requirements.
• Consumer Duty - the FCA's four outcomes (products and services, price and value, consumer understanding, consumer support).
• Solvency II - prudential, governance (Pillar 2), and reporting (Pillar 3) where Olly takes underwriting risk.

Questions to answer:

• For each regime, is the relevant control surface in the architecture identifiable, and is the control documented?
• Is the Article 9 health-data path (triage, clinical records, claims with diagnosis codes) walled, logged, and minimised end-to-end?
• Are Consumer Duty outcomes traceable to specific architectural decisions (e.g. how price-and-value is captured, how consumer understanding is evidenced in journeys)?
• Where Olly relies on a partner's regulatory permission (broker, underwriter, claims handler), is the dependency named and the responsibility split documented?
• For NHS DSPT, is the integration with NHS-controlled data sources (NHS 111, NHS Login, NHS spine if applicable) described with the assurance level it needs?

Deliverable specification

The output of the review is one finding register plus an executive summary.

The finding register is a table with one row per finding and the following columns:

Column	Content
dimension	One of the seven dimensions above.
severity	Critical / Major / Minor / Informational.
page_url	The page in this build the finding originates from (use the deployed URL, not the file path).
finding	The issue, written so an Olly engineer can act on it without rereading the page.
suggested_action	One sentence of what good would look like.
references	Regulations, standards, public design references, or comparator products that support the finding.

Format: deliver the register as both a PDF (for the executive read) and a spreadsheet (CSV or XLSX, for tracking). The executive summary sits on top of the PDF: one page per dimension, with the top three findings and the overall posture for that dimension.

Cadence: two-week turnaround per pass. Pass 1 is the full review against this build. Pass 2 (optional, scheduled later) is a re-review against the next build, scored as resolved / partially resolved / not resolved per finding.

---

Next: scope, NDA, and watermarking.