Product Compliance Process v1.
A repeatable, phase-gated process every Legalhelp product runs through before it touches a paying user. Designed so the 30th product passes the same gates as the 5th, and so any one of Ed, Rob, Rachel or Pablo can open the system and see exactly where any product sits.
v1 draft
For Ed approval
Parking Notices is the pilot
Rob's reputation and the venture's regulatory position both depend on every product being demonstrably tested for compliance, not just signed off in a memo. This document sets out the operating process that turns the compliance design already in the wiki into a running supply chain of evidence, sign-offs, monitoring, and audit trail. Two readers. Ed — to approve the shape and own the substantive sign-offs. Pablo — to use as the build spec for the rails that enforce the process. Same document, two uses.
APrinciple — separation of duty
Three roles, never confused. Every gate in the process is signed by a named human in one of these roles. The rails enforce that the signature exists; they never decide what counts as compliant.
| Role | Held by | Decides |
|---|---|---|
| Legal substance | Ed (qualified solicitor) + senior practitioner per product family + external counsel at named triggers only | Is this lawful? Does the output meet a professional bar? Does any claim cross the regulatory threshold? |
| Editorial & brand risk | Rob (with Castle Place) | Will I put my name on this? Does it match how I would say it? Does it carry a reputational risk? |
| Operating rails | Pablo (builds the system) + Rachel (runs it day-to-day) | Is the evidence captured? Are the gates enforced? Has the signed person actually signed in the system? |
Default posture
In-house. Ed signs substantive legal; Rob signs editorial; senior practitioner per family adds the per-product professional review; Rachel runs the day-to-day; Pablo builds the rails. External counsel is built into the process at four named triggers but is not part of normal running. See Section H.
BThe five phases at a glance
Phase 0Scoping
→
Phase 1Alpha
→
Phase 2Beta
→
Phase 3Pre-Live
→
Phase 4Live
Gate 0
Gate 1
Gate 2
Gate 3
Monitored
A product cannot skip a phase. A product can be sent back a phase if a later gate fails. Each phase has a purpose, entry criteria, activities (numbered, with owner), a gate (named signers, named artefacts), and a Pablo build note (the rails added in this phase).
CPhase 0 — Scoping
Purpose. Before any code is written, decide whether the product belongs in the portfolio at all, and what shape it must take to stay below the regulatory threshold.
Entry criteria. The product appears on the candidate list and has cleared the four-axis score in product-process step 2 (TAM, channel fit, build difficulty, defensibility).
Activities
| # | Activity | Owner | Output artefact |
|---|---|---|---|
| 0.1 | Legal scoping — primary legislation, secondary legislation, case law, procedural rules, limitation periods | Ed | Per-product reference set, written |
| 0.2 | Reserved-activity test — does the product touch any of the six s.12 LSA 2007 activities? | Ed | Reserved-activity memo (one page) |
| 0.3 | Hard-stop scope — which of the 11 hard stops this product will trigger; which onward referrals are needed | Ed | Hand-off list for the product |
| 0.4 | Editorial scope — Rob-credit, neutral-platform, or both? | Rob | Editorial-scope decision |
| 0.5 | Output specification — what document, what questions, what choices | Jemima | Output spec document |
| 0.6 | Risk band — ACT vs Sorted; regulatory-exposure score per the 19 May framing | Ed + Rob | Score sheet entry |
Gate 0 — into Alpha
Signed by: Ed (legal substance fits) + Rob (editorial scope decision made). Artefact: the Product Scoping Memo — combines 0.1–0.6 into a single one-page record.
Pablo build note
The
product_scoping record schema — memos captured as structured records, not Word files in Dropbox.
DPhase 1 — Alpha (Internal only)
Purpose. Build the product and prove its quality against an authoritative reference before any external party ever sees it.
Entry criteria. Gate 0 signed. Scoping memo on file.
Activities
| # | Activity | Owner | Output artefact |
|---|---|---|---|
| 1.1 | Prompt + tool construction (system prompt, product tool prompt, reference loading) | Pablo + engineering | Live prompts in dev |
| 1.2 | Gold-standard letter set — 10–20 "ideal" outputs written by a qualified hand | Ed drafts; Jemima curates | Gold-standard document library |
| 1.3 | ARC framework wired to the gold standard, scoring every prompt deploy | Pablo | ARC scores live in admin tab |
| 1.4 | Internal dogfooding — every team member runs the product on real personal scenarios | All team | Dogfood log; friction notes; regression catches |
| 1.5 | Hard-stop adversarial test set — scenario library covering each of the 11 hard stops for this product | Jemima drafts; Ed validates | Per-hard-stop scenario library |
| 1.6 | Hard-stop test harness — adversarial scenarios run automatically against every prompt deploy | Pablo | Pass/fail report in admin tab |
| 1.7 | Disclaimer + framing audit — verify the regulatory disclaimer is present on every screen, every output, session end | Ed signs; Pablo automates | Disclaimer audit pass report |
| 1.8 | Hand-off logic verified — when the product refuses to proceed (DV, criminal, family, etc.), where does the user go? Live-tested. | Ed + Jemima | Tested hand-off flows per hard stop |
Gate 1 — into Beta
Signed by: Ed (substantive review of prompts + sample outputs is acceptable to take to senior practitioner) + Pablo (ARC, hard-stop harness, disclaimer auditor all green). Artefacts: the Alpha Quality Report and the Internal Legal Sign-Off Memo.
Pablo build note
This phase is where most of the rails get built — ARC plumbing, hard-stop harness, disclaimer auditor, prompt-version retention, and the
product_compliance_evidence table that every later phase writes to.
EPhase 2 — Beta (Controlled external)
Purpose. Take the product to the people whose opinion counts — senior practitioner for the family and a small invited group of real users — before spending money on launch. Optionally invoke external counsel here, per Section H Trigger T3.
Entry criteria. Gate 1 signed. ARC has been green for 4 consecutive weeks.
Activities
| # | Activity | Owner | Output artefact |
|---|---|---|---|
| 2.1 | Senior-practitioner T2 review — would a competent practitioner stand behind this output in court / ombudsman / complaint? | Senior practitioner (per family) | Signed T2 memo; annotated sample outputs |
| 2.2 | T3 user-completion research — can a real consumer, given the product cold, finish it without help? | Jemima + research vendor | T3 completion report; friction map |
| 2.3 | Editorial Beta review — Rob walks through the product and signs that he'd put his name on it | Rob (Castle Place workflow) | Editorial sign-off; change requests |
| 2.4 | Closed-beta with 50–200 invited real users; conversion + accuracy instrumented | Rachel runs; Pablo instruments | Conversion + accuracy data; complaints log |
| 2.5 | Vulnerable-user pathway audit — every triggered hand-off in the beta cohort reviewed weekly | Ed + Rachel | Weekly pathway audit log |
| 2.6 | Regulatory-drift watch live — is the underlying law still as it was at scoping? | Ed (legal-news agent assists) | Drift log; trigger-to-review if anything changes |
| 2.7 | (Optional) External counsel review — invoked only at Trigger T3 (see Section H) | External counsel | Counsel sign-off memo |
Gate 2 — into Pre-Live
Signed by: Ed (changes from Beta absorbed) + Senior practitioner (substance acceptable) + Rob (editorial OK). External counsel signature added if and only if Trigger T3 has been invoked for this product. Artefacts: three or four signed memos plus the Beta data pack.
Pablo build note
The counsel / practitioner sign-off workflow — reviewers log in, see the dossier, sign the memo, the gate flips green automatically. The T3 evidence intake (research reports as evidence rows). The closed-beta invitation + telemetry.
FPhase 3 — Pre-Live (Public-readiness hardening)
Purpose. Everything that must be true on the public surface before the first paying user — the catch-net that protects users, Rob and the company if something goes wrong.
Entry criteria. Gate 2 signed with all required memos in place.
Activities
| # | Activity | Owner | Output artefact |
|---|---|---|---|
| 3.1 | DMCC substantiation registry populated for every public claim about this product | Rachel drives; Ed signs | Registry entries with evidence rows for every objective claim |
| 3.2 | Marketing copy + landing page reviewed against the 8 non-negotiables | Rachel + Ed | Marketing-surface sign-off |
| 3.3 | Rob-credit assets — additional editorial sign-off + DMCC-registry referenceability check | Rob + Rachel | Per-asset editorial sign-off |
| 3.4 | Public policy pages — privacy, T&Cs, cookies, complaints — live; reviewed against this product | Ed drafts; (optional) Trigger T2 brings external sweep | Published pages |
| 3.5 | Marketing-compliance approach — once-only review of DMCC / ASA / CMA fake-review house style | (optional) Trigger T1 external counsel sweep | Approved house-style document, re-used across products |
| 3.6 | PI + cyber insurance bound, with this product type within scope | John Miller | Bound policy |
| 3.7 | Refund / complaints process operational; complaints@ routes; 14-day SLA clock tracked | Rachel | Process documented; complaints register live |
| 3.8 | Hand-off referral list operational — real partners contacted; terms drafted; commercial disclosures ready | Ed | Signed referral list; disclosures on file |
| 3.9 | Live monitoring dashboard configured — five signals with alert thresholds | Pablo + Rachel | Monitoring live; alert routing tested |
| 3.10 | Incident-response playbook dry-run on a simulated incident for this product | Rachel runs; all participate | Dry-run log; gaps closed |
Gate 3 — into Live
Signed by: Ed (Operational Lead — every line of compliance-posture-memorandum §11 is green for this product) + Rob (Editorial Lead — happy for first paying user) + John (insurance bound). Artefact: the Pre-Launch Readiness Pack.
Pablo build note
The DMCC registry as a structured table wired into the Approvals UI; the monitoring dashboard with alert routing; the incident-response runbook UI (named on-call, paging path, rollback button).
GPhase 4 — Live & monitored
Purpose. Run the product, watch the signals, kill it or fix it if it stops working.
Entry criteria. Gate 3 signed. First paying user permitted.
Activities
| # | Activity | Owner | Cadence |
|---|---|---|---|
| 4.1 | Five-signal monitoring — conversion, ARPU, satisfaction, accuracy, regulatory drift | Pablo (rails) + Rachel (eyes) | Continuous; weekly review log |
| 4.2 | Complaints handling within the 14-day SLA | Rachel | Continuous |
| 4.3 | Hand-off audit — sample of triggered hand-offs verified | Rachel + Ed | Weekly |
| 4.4 | Editorial review of Rob-credit surface | Rob + Rachel | Monthly |
| 4.5 | C1–C12 controls re-attestation per product | Ed | Quarterly |
| 4.6 | External counsel re-look (Trigger T3 refresh, optional) | External counsel | Annual (only if previously invoked) |
| 4.7 | Kill-criteria active per product-readiness-testing | Ed | Continuous; retirement decision logged if triggered |
Stay-live gate — continuous
If any kill criterion fires (viral hallucination, regulatory finding, conversion below threshold for 4 consecutive weeks, T2 review fails on annual refresh), the product is sent back to Beta or retired.
Pablo build note
The quarterly re-attestation flow (C1–C12 grid auto-prompts each owner every 90 days); the kill-criteria automation (signal breaches threshold → auto-flag for review).
HExternal counsel — built in, deferred, never essential
External counsel is not part of normal running. It is invoked at four named triggers, each a one-off deliverable that benefits every subsequent product, not a continuous reviewer relationship.
| Trigger | When it fires | Why we'd pay | Cost (one-off) |
|---|---|---|---|
| T1 — Marketing-compliance approach review | Once, before first Rob-credit asset goes public | DMCC / ASA / CMA fake-review is specialist work; one fixed-fee look establishes a defensible house style | ~£2–4k |
| T2 — Public policy pages review | Once, before first paying user | T&Cs / privacy / cookies / complaints — Ed drafts v1; specialist sweep is cheap protection on public surfaces | ~£2–5k |
| T3 — Compliance Posture Memorandum sign-off | Before SEIS investor diligence opens, or before Rob's name fronts a product at scale — whichever first | Diligence audiences and Rob's brand both need an independent regulatory lawyer concurring; Ed signing his own memo doesn't carry the same weight externally | ~£5–15k |
| T4 — Incident or challenge response | Reactive — regulator, ombudsman, or significant complainant raises a point | Crisis-response standby relationship; cheap to set up; cost only if used | Near-zero base |
Per-product legal cost
Separate from external counsel: senior-practitioner T2 memo per product family, ~£1.5–3k per product, refreshed annually. This is the actual operating backbone of the per-product process.
Total external legal envelope at launch
Roughly £10–25k one-off, with T4 standby thereafter — vs £30–60k+/yr for a continuous retainer that we explicitly do not want. Castle Place free-look channel: worth Ed asking Lizzie directly whether any of T1/T2/T3 can be covered through Castle Place's existing legal capacity before commissioning externally.
IThe Compliance Stack v1 — what Pablo builds
Pablo's pilot delivers one thing: the rails any product plugs into. Every artefact is either a reusable rail (used by every future product) or a parking-specific instance sitting on the rail.
| Rail | What it does | First used in |
|---|---|---|
product_scoping record schema | Captures Phase 0 memos as structured records | Phase 0 |
product_compliance_evidence table + admin UI | Stores every evidence row keyed to (product × gate × evidence-type × version) | All phases |
| Gate-pass workflow | A product cannot advance until the named signer signs the named artefact in the system | All gates |
| ARC plumbing + prompt-version retention | Every prompt version auto-archived with ARC score and hash | Phase 1 |
| Hard-stop adversarial test harness | Per-product scenario set runs against every prompt deploy | Phase 1 |
| Disclaimer auditor | Verifies disclaimer presence on every screen and output | Phase 1 |
| Counsel / practitioner sign-off workflow | Reviewers log in, see the dossier, sign the memo, gate flips green | Phase 2 |
| DMCC substantiation registry | Structured table of claims × evidence rows; wired into Approvals UI | Phase 3 |
| Monitoring dashboard + alert routing | Five signals × thresholds × on-call | Phase 3 / 4 |
| Incident-response runbook UI | Paging path, rollback button, post-incident review template | Phase 4 |
| Quarterly re-attestation flow | C1–C12 owners auto-prompted to sign every 90 days | Phase 4 |
| Kill-criteria automation | Signal breaches threshold → auto-flag for review | Phase 4 |
Principle
None of these rails decides what is compliant. Each rail enforces that the named human has actually signed the named artefact.
JParking Notices today against this process
| Phase | Status | Detail |
|---|---|---|
| Phase 0 — Scoping | Substantially complete | Legal scoping done as part of v3 plan; reserved-activity test embedded in compliance-posture-memorandum §1. Needs to be re-captured as a product_scoping record once the schema exists. |
| Phase 1 — Alpha | In progress | ARC live; team dogfooding done; hard-stop logic in prompts but not adversarially tested; disclaimer audit not formally run. To pass Gate 1 we need: hard-stop test harness (Pablo) + disclaimer auditor (Pablo) + Ed's Internal Legal Sign-Off Memo. |
| Phase 2 — Beta | Not started | Senior practitioner for the parking family not engaged; no T3 vendor; no closed-beta of invited users on the rails. |
| Phase 3 — Pre-Live | Not started | DMCC registry doesn't exist; no PI/cyber; hand-off referral list "drafting"; public policy pages drafted but not signed. |
| Phase 4 — Live | Premature | Private-beta users on legalhelp.me.uk today are technically pre-Gate-2. Acceptable as a pre-launch test; not OK to take payment until Gate 3 has fired. |
The pilot is: take parking from where it is (mid-Alpha) cleanly through Gate 1, Gate 2, and Gate 3, building the rails alongside, and producing this document as the codified output applied to every subsequent product.
KOwnership map at a glance
| Stream | Scope | Lead | Pablo's role |
|---|---|---|---|
| A | Substantive legal review (per-phase legal sign-offs) | Ed | None — consumes outputs as inputs to evidence rows |
| B | Evidence & audit rails (the Compliance Stack itself) | Pablo | All of it |
| C | Marketing-claims supply chain (DMCC registry, editorial workflow) | Rachel | Wires the registry into the Approvals UI |
| D | Live monitoring & incident response | Pablo + Rachel | Pablo: dashboards + alerts. Rachel: incident playbook + complaints register |
| E | People & policies (panel, insurance, public policies, hand-offs) | Rachel drives; Ed + John deliver | None |
LDecisions to confirm
Five things to land before Pablo starts the build:
- Phase shape approved. Five phases, four gates, sign-offs by named human roles.
- Pilot scope confirmed. Parking only. CCD and others run on the rails afterwards, not in parallel with the pilot.
- External counsel posture approved. Trigger-based, deferred, never essential to normal running.
- Compliance Operations Lead named. Proposal: Rachel as day-to-day owner of the running process; Ed retains accountable Operational Lead.
- Castle Place free-look channel explored before commissioning any external work — Ed asks Lizzie directly whether T1/T2/T3 can be covered through Castle Place.
MGlossary of artefacts
A shared vocabulary so Ed, Rob, Rachel and Pablo all mean the same thing.
| Term | Means |
|---|---|
| Product Scoping Memo | Phase 0 output. One page. Combines legal scoping, reserved-activity test, hard-stop scope, editorial scope, output spec, risk band. Signed by Ed + Rob. |
| Gold-standard letter set | Phase 1 input. 10–20 "ideal" outputs per product written by a qualified hand. ARC scores live outputs against this set. |
| Alpha Quality Report | Phase 1 output. Pablo's automated summary: ARC, hard-stop harness, disclaimer auditor — all green. |
| Internal Legal Sign-Off Memo | Phase 1 output. Ed's qualified review of prompts + sample outputs. |
| T2 Memo | Phase 2 output. Senior practitioner per product family signs that they would stand behind the output. |
| T3 Completion Report | Phase 2 output. User-research vendor's report on whether real consumers reach a usable output without help. |
| Editorial Beta Sign-Off | Phase 2 output. Rob (via Castle Place workflow) signs that he'd put his name on the product. |
| DMCC Registry Entry | Phase 3 output. One row per public claim, with evidence row attached. |
| Pre-Launch Readiness Pack | Phase 3 output. The combined Gate-3 deliverable. Signed by Ed + Rob + John. |
| Hard-stop Scenario Library | Per-product adversarial test set. Run automatically against every prompt deploy. |
| Compliance Evidence Row | The atomic unit of audit trail. (Product × gate × evidence-type × version × pointer to artefact × signer × date.) |
| C1–C12 Controls | The twelve controls from compliance-posture-memorandum §2. Re-attested quarterly. |
| Trigger T1 / T2 / T3 / T4 | The four named external-counsel triggers in Section H. |
Next steps after Ed approves
Proposed into the wiki as
compliance-process-v1 under the regulatory & compliance section, sitting next to product-process and product-readiness-testing. The pilot's job: take Parking Notices through this process, build the rails as Pablo encounters each gate, and update this document with the lessons learned along the way.