Authorise the irreversible
RAPID's dividing line between "agents build" and "engineers govern" is not a feeling — it's an enumerated list. Agents investigate, build, verify and capture. A named human authorises anything that can't be cleanly undone, regardless of how confident the agent is.
Decision records (ADRs)
Decisions get silently reversed when nobody remembers why they were made. In a world where agents generate most of the code, that risk is worse: an agent will happily undo a deliberate choice it can't see the reason for. Architecture Decision Records (ADRs) are the memory that stops this. They are written for humans and read by agents.
Repo context & memory
An agent is only as good as the context it loads. This standard defines what lives where in every RAPID repo, so agents start each session with sharp, current context — and so the knowledge a loop earns is deposited, not lost. Knowledge silos are on the problem list RAPID exists to fix; don't rebuild them out of wikis and chat history.
Coding standards for agent-built code
Agents write most of the code, at volume. Standards therefore have to be machine-enforceable and agent-readable — shipped as linter config in the project scaffold, not as prose nobody runs. Humans never review anything a formatter can decide.
Code review for AI-generated code
Review has to assume volume: agents produce more code than a human wrote, so review attention is spent where machines can't help — intent, domain correctness, and test honesty — and never on what CI already checks.
CI/CD pipeline standard
One pipeline shape for all RAPID repos, shipped as shared templates in the project scaffold. Directly remediates the "partial automated deployment" problem on the legacy estate: every product reaches production the same automated way.
Branching, repo & commit conventions
One page, enforced by tooling. The theme: at agent speed, divergence is the enemy — keep changes small, integrated continuously, and attributable.
Docs with build
What makes "working software with docs and tests" real rather than aspirational: docs are produced or updated in the same PR as the code, reviewed in that PR, and a stale-docs check fails the merge gate if they drift.
Engineering Definition of Done
One page, embedded in every agent task brief and enforced (the automatable parts) by the merge gate. A change is done when all of these are true:
Agent guardrail & permission standard
The sandbox every coding agent runs inside. This is what makes "agents build" safe: an agent has exactly the access its task needs and no more, and it physically cannot reach the things reserved for human authorisation.
Acceptance criteria standard
The contract between Definition and the test gate. Every acceptance criterion (AC) must be concrete enough that a test agent generates an executable test from it without interpretation. Ambiguity here becomes defects downstream, at agent speed.
Test pyramid & coverage
Coverage numbers are necessary but not sufficient — they say the tests ran, not that they assert. This standard sets the shape of the suite and makes mutation testing the arbiter of quality.
AI-generated-test review
The biggest risk with agent-written tests is that they're written to pass, not to verify. This standard is the checklist for telling an honest test from a decorative one.
Secure by default
The security posture every AI-built service inherits automatically — shipped as machine-readable rules and linter config in the project scaffold, so agents build to it rather than being audited afterwards. An OWASP ASVS L2 baseline made concrete for the chosen stack.
Security gates
Security is checks built into the flow, not a final review meeting. Each check is named, placed in the pipeline, given a pass/fail threshold, and assigned override rights — so "secure" is verified continuously, not hoped for at the end.
Lifecycle RACI & decision rights
Who is Responsible, Accountable, Consulted and Informed across the phases and gates — and, critically, who may and may not waive a gate. This kills the failure mode agent speed amplifies most: "everyone assumed someone else reviewed it."
Metrics framework
The measurement standard. One framework, feeding one platform with many views (not eleven dashboards). Baselined during StudyBuddy so "velocity compounds" is measured, not asserted.
Reference architecture pack
C4-modelled architectures for the two or three shapes RAPID products actually take. A product maps onto one before build starts, so agents build within a known structure with the UK-insurance non-negotiables already in place.
Prioritisation framework
One currency of value across everything that competes for a squad's time — remediation, new build, and feedback-driven change. Without a single framework, "sales asked for it" and "it's on fire" and "it's strategic" can't be compared.
Model selection & routing
Match the model to the task so the economical choice is the default choice — encoded into the agent config defaults, not left to per-session discretion.
Token budgeting & cost-tagging
Agent execution has a unit cost, funded from STOP savings. This standard makes that cost visible, attributed and bounded — so "cost per shipped change" is a number we manage, not a surprise on the invoice.
Remediation backlog standard
STOP produces findings from four directions — debt, security, coverage, cost. They all land in one prioritised backlog, scored one way, so they compete on the same terms rather than four teams each claiming urgency.
Secrets management
The steady state the STOP secrets sweep leaves behind, and the standard every RAPID build inherits. Especially load-bearing here: you cannot safely point agents at a codebase whose secrets live in the code.
Domain glossary standard
One canonical, versioned ubiquitous-language glossary per product, stored in-repo and injected into every prompt — so agents never invent plausible-but-wrong domain terms.
NFR & compliance catalogue
A reusable menu of non-functional and compliance requirements, selected per product at Definition and verified at Refinement. Turns domain constraints from tribal knowledge into testable requirements.
Accessibility standard
WCAG 2.2 AA as concrete per-component and per-screen acceptance criteria, not a policy essay. Design owns the bar; Test enforces it in the gates. For EU-market clients, EN 301 549 / the European Accessibility Act apply on top.
Content & microcopy standard
Agents write most first-draft copy, so the tone and rules have to be encoded, not held in a content designer's head. Packaged into the design context pack and loaded into UI-producing agent sessions.
Data-model governance
Stops each squad's agents inventing incompatible vocabularies and unsafe data handling across the portfolio. The rules every data model follows.
Insurance UX heuristics
Nielsen's heuristics adapted to financially-consequential insurance journeys, so machine and human design review score against the same list. Used by the design-crit skill and the Design Review gate.
Supply-chain & dependency standard
Agents pull dependencies confidently — sometimes ones that don't exist (hallucinated) or are malicious look-alikes (typosquats). This standard is the defence.
Monitoring & observability
The instrumentation baseline every build ships with — so "operable" is checked at the Production Readiness gate, not hoped for. Observability starts in Build, not after an incident.
AI provenance & audit trail
Answers "who built this and how was it checked?" as a by-product of the pipeline, not extra work. Essential when the code was agent-generated and the client is a regulated insurer.
Release communication
Once releases ship weekly rather than quarterly, release comms have to be generated and consistent — not hand-written each time. Produced and approved at the Production Readiness gate.
Rapid-fix loop SLAs
The operational definition of the promised rapid-fix loop — severity levels, response/resolution SLAs, and the fast path from a support ticket to a same-day release through the existing gates.
Test data management
Realistic-but-fake insurance data is hard to get right — so solve it once, properly. The rule underneath everything: no production PII in lower environments (UK GDPR).
Test environment strategy
Environment contention would throttle agent-speed builds across two geographies — so environments are ephemeral, parity-controlled, and self-seeding.
Flaky test policy
Flaky suites are the fastest way to destroy trust in the gates — and once a team stops trusting the gate, the gate is worthless. At agent speed, that trust is load-bearing.
Defect taxonomy & triage
Shared severity/priority with SLAs, and — the RAPID-specific part — root-cause categories that tell you which part of the engine to fix. Classification turns defects into process feedback.
Regression strategy
The regression pack is deposited capital — every loop and every escaped defect adds to it, so the product gets harder to break over time.
LLM application security
For product features that themselves use LLMs (not the tools that build them). Mapped one-to-one to the OWASP LLM Top 10 so coverage is checkable at the gate.
AI decision auditability
Distinct from the build audit trail: this governs what a shipped product decides when it embeds AI in an insurance decision (e.g. ClaimPilot). Regulators and clients will ask how an automated decision was made — this is the answer.
Penetration test & external assurance
Independent human validation on top of the automated security gates — because automation and self-assessment have blind spots that an external tester doesn't.
Toolkit governance
One governance loop for the shared toolkit — not three competing bodies. A small cross-UK/India Toolkit Guild with clear decision rights, so the toolkit evolves fast without fragmenting.
Async communication & documentation
Writing-first norms so the UK, India and agents all work from the same written truth. The bridge between "two geographies" and "one team" — and between "humans" and "agents", who can only load what's written.
Client transparency & due-diligence
RAPID's STOP/GO communications will immediately prompt the question: "AI builds your software — how do we know it's safe?" This standard is the answer, ready before the first client conversation. One clear story on how we build, plus an annex for procurement and vendor-risk teams.
Product telemetry & analytics
Distinct from ops observability: this is about how the product is used, so the loop's "live feedback returns as input" has a quantitative half — not just opinions.
Demo script & demo environment
Every RAPID-built product is demonstrable on demand — because at RAPID pace, sales conversations happen continuously, not at quarterly milestones.