# bience — Product Specification (EARS) **Document:** `spec.ears.md` **Version:** 0.7 (draft for co-founder discussion) **Source:** *"The problems, not the pitch" — Technical & Operational Brief v1.0, bience Ltd (DK)* **Status:** Derived specification. Every requirement below is a proposal, not an inheritance. Requirements marked **[OD-n]** depend on an open decision in §37. **Confidentiality:** Confidential — derived from a document shared after a substantive first call. --- ## 1. Purpose and scope ### 1.1 Purpose This document converts the bience technical brief into a testable requirements baseline using EARS (Easy Approach to Requirements Syntax). It exists to do three things: 1. Make the brief's implicit commitments **falsifiable** — a requirement that cannot fail a test is not a requirement. 2. Separate **safety-locked** behaviour from **configurable** behaviour at the specification layer, before either is implemented. 3. Expose the points where the brief is genuinely undecided, so that the CTO decision is recorded as a decision rather than absorbed as a default. ### 1.2 In scope V1 through V4 of the bience platform: the elder phone line (Omi), the carer application (Jool), the younger-user application (Vee), the family web admin, the Lide orchestrator, the safety and safeguarding subsystems, the family graph, audit, billing, and the eval harness. ### 1.3 Out of scope Commercial terms, pricing levels, fundraising, hiring, brand and tone-of-voice guidelines, and the content of the personas' scripted dialogue. Tier *boundaries* are out of scope; the *capability to enforce tiers* is in scope. ### 1.4 Release phases | Phase | Contents | |---|---| | **V1** | Surface 1 (elder phone line) + Surface 2 (carer app). Surfaces 3 and 4 stubbed. Single-language (English). Safeguarding by one trained reviewer. | | **V2** | Surface 4 (family web admin) hardened, multi-carer households, tier expansion, richer eval coverage. | | **V3** | Surface 3 (Vee, adult neurodivergent users). Multi-language. | | **V4** | Under-18 users. AADC compliance becomes load-bearing rather than latent. | Requirements are tagged with the earliest phase in which they must be **met**, not the phase in which they must be **designed for**. Several V1 requirements exist specifically because retrofitting them later is impossible (audit chaining, family graph shape, safeguarding taxonomy). --- ## 2. Actors, personas and systems ### 2.1 Human actors | Actor | Description | |---|---| | **Elder user** | The aging parent. Primary user of the phone line. May have hearing aids, dementia-affected speech, fluctuating capacity. Does not necessarily own a smartphone. | | **Carer** | The buyer and primary operator. Adult child, spouse, or paid carer. Uses the carer app. | | **Younger user** | Neurodivergent young adult (V3) or child (V4). Uses Vee. | | **Observer** | A family member with read-only or partial scope. Sibling, distant relative. | | **Paid carer** | Professional carer with time-bounded, scope-limited access. | | **LPA holder** | Holder of a registered Lasting Power of Attorney (Health & Welfare, or Property & Financial Affairs). Legally distinct from "carer". | | **Safeguarding reviewer** | DBS-checked, trained internal reviewer. Handles flagged events. | | **Clinical lead** | Named accountable clinician or safeguarding lead. | | **Support agent** | Internal staff handling account and billing issues. | | **Engineer** | Internal staff with break-glass-only production access. | | **Founder / exec** | Explicitly holds *no* conversational data access. | ### 2.2 AI personas | Persona | Surface | Audience | |---|---|---| | **Omi** | Phone line | Elder user | | **Jool** | Carer app | Carer | | **Vee** | Younger-user app | Neurodivergent young adult / child | ### 2.3 Systems and subsystems (requirement subjects) | System | Responsibility | |---|---| | **Voice gateway** | PSTN/SIP termination, streaming STT/TTS transport, turn-taking, barge-in, latency budget. | | **Lide orchestrator** | Persona routing, context assembly, config resolution, guardrail enforcement, tool/escalation dispatch. | | **Safety classifier** | Parallel-path real-time classification: suicide ideation, abuse, financial scam, capacity-loss signals. | | **Knowledge service** | RAG over authoritative sources with citation-required output. | | **Family graph service** | People, roles, permissions, scopes, consent state. | | **Identity service** | Speaker identification, confirmation flows, authenticated app sessions. | | **Consent service** | Capacity-aware consent capture, renewal, withdrawal. | | **Safeguarding service** | Flag intake, triage, severity routing, on-call handoff, regulator reporting. | | **Audit service** | Append-only, cryptographically chained access log. | | **Configuration service** | Typed per-user config, schema validation, versioning. | | **Billing service** | Stripe integration, tier entitlement, feature gating. | | **Usage telemetry service** | Per-family minute/token/storage/event accounting; caps and anomaly detection. | | **Degradation controller** | Health detection, fallback selection, pre-written response playback. | | **Eval harness** | Regression suite, release gating, drift monitoring. | | **Summarisation service** | Generation of carer digests from transcript, with source attribution. | | **Onboarding service** | Signup, number verification, relationship declaration, activation gating. | | **Input defence layer** | Screening of conversational input for instruction injection and abuse. | | **Backup and recovery service** | Backup scheduling, restore, RPO/RTO, backup retention. | | **Secrets service** | Infisical. Machine identities, per-environment isolation, rotation, secret scanning. | | **Safety budget service** | Budget definition, consumption tracking, release blocking on exhaustion. | | **Platform** | Cross-cutting; used where no single subsystem owns the behaviour. | --- ## 3. Requirement conventions ### 3.1 EARS patterns used | Pattern | Form | |---|---| | Ubiquitous | THE `` SHALL `` | | Event-driven | WHEN `` THE `` SHALL `` | | State-driven | WHILE `` THE `` SHALL `` | | Unwanted behaviour | IF `` THEN THE `` SHALL `` | | Optional feature | WHERE `` THE `` SHALL `` | | Complex | Combinations of the above | ### 3.2 Identifier scheme `-`, with decimal sub-identifiers (`-.`) where a single trigger has more than one distinct response. Sub-identifiers were introduced at v0.2 to enforce atomicity without renumbering; parent numbers are never reused. Domains: GEN, SUR, VOI, IDN, CNS, CFG, FGR, SFC, SFG, KNW, AUD, ACC, DAT, BIL, USG, DEG, EVL, OBS, SEC, AAD, ACS, SUP, TRN, SUM, ONB, HND, LNG, CMR, PRV, BCK, AIS, SFB, ENT. Design constraints use `DC-` (§4.3). ### 3.3 Provenance annotations Every requirement carries a second line marking where it came from and why it exists: ` ↳ *SOURCE* — rationale.` | Source | Meaning | Count | |---|---|---| | `BRIEF/S1`–`S4` | Stated in a surface description in the brief | | | `BRIEF/Q1`–`Q3` | From one of the three questions candidates asked | | | `BRIEF/P1`–`P10` | From one of the ten harder problems | | | `BRIEF/U1`–`U5` | From one of the five named unknowns | | | `BRIEF/HC` | From the hard constraints table | | | `BRIEF/ARCH` | From the reference architecture section | | | **BRIEF total** | | **219 (43%)** | | `LAW/…` | Required by statute, regulator or code, and not mentioned in the brief | **65 (13%)** | | `REVIEW` | A gap found while deriving this specification. Not in the brief | **178 (35%)** | | `USER` | Requested directly during drafting | **22 (4%)** | | `DERIVED` | Follows necessarily from another requirement here | **14 (2%)** | Annotations tagged `REVIEW v0.5` or `REVIEW v0.6` were added during a later correctness pass and name the version, so the drift is visible. **What the split means.** The brief is a genuinely strong document — 43% of a 498-requirement specification traces directly to it, which is far more than most founder briefs would support. The 13% legal tranche is the predictable gap: statute does not appear in a technical brief and has to be imported. The 35% review tranche is the interesting number, and it is not a criticism of the brief. It is what a specification is *for* — the brief names ten hard problems honestly, and specifying them exposes roughly three more requirements for each one, most of which nobody could reasonably have listed in advance. ### 3.4 Annotations Each requirement carries `(Phase · Priority · Verification)`. - **Phase:** V1 / V2 / V3 / V4 - **Priority:** `M` must, `S` should, `C` could - **Verification:** `T` test, `D` demonstration, `A` analysis, `I` inspection, `R` audit/review ### 3.5 Reserved terms **SAFETY_LOCKED** — a behaviour that no user, carer, admin, support agent, or configuration value may alter. **USER_CONFIGURABLE** — a behaviour a permitted actor may alter within a validated schema. **Break-glass** — time-boxed, second-approved, post-hoc-disclosed emergency access. **Flagged event** — any conversation turn or pattern the safety classifier scores above a routing threshold. --- ### 3.6 Policy on negative requirements A requirement of the form `SHALL NOT` cannot be verified by test: absence cannot be demonstrated over an unbounded input space. Every prohibition in this specification is therefore expressed as a positive restriction — `SHALL only where `, `SHALL exclude`, `SHALL withhold`, `SHALL limit disclosure to` — which is verifiable against a finite, enumerated permitted set. Two requirements retain `SHALL NOT` form deliberately, because they reproduce the wording of the ICO Age Appropriate Design Code and altering that wording would weaken the mapping to the standard: - **AAD-004** (nudge techniques) - **AAD-005** (detrimental use of children's data) **AAD-003** and **CMR-009** likewise retain statutory terms — *proportionate certainty* in the Age Appropriate Design Code and *proportionate refund* in the Consumer Contracts Regulations 2013. Substituting a number for either would misstate the law; the operational thresholds sit in **OD-14** and the refund policy respectively. Both are verified by inspection and design review (`I`, `R`) rather than by test. ## 4. Cross-cutting requirements ### 4.1 General (GEN) - **GEN-001** — THE platform SHALL implement every requirement designated SAFETY_LOCKED such that no configuration value, feature flag, tier entitlement, or administrative action can alter its behaviour. *(V1 · M · A)* ↳ *DERIVED* — Enforcement clause for the split BRIEF/Q1 describes as safety behaviour being 'structurally not configurable'. - **GEN-002** — THE platform SHALL treat all conversational content involving an elder user, a vulnerable adult, or a user under 18 as special category personal data. *(V1 · M · I)* ↳ *LAW/UK GDPR Art 9* — Health, care and vulnerability data is special category; the brief never classifies it. - **GEN-003.1** — IF a subsystem cannot determine whether an action is permitted, THEN THE platform SHALL deny the action. *(V1 · M · T)* ↳ *REVIEW* — Fail-closed default. The brief does not say what happens when permission is indeterminate. - **GEN-003.2** — IF a subsystem denies an action for indeterminate permission, THEN THE platform SHALL record the denial in the audit log. *(V1 · M · T)* ↳ *REVIEW* — A denial nobody can see is indistinguishable from a bug. - **GEN-004** — THE platform SHALL be capable of operating with a single trained safeguarding reviewer at launch and with 24/7 multi-reviewer on-call operation without re-architecture. *(V1 · M · A)* ↳ *BRIEF/P7* — 'Designed for the scaled version from V1 even if the day-one team is one trained person.' - **GEN-005** — THE platform SHALL record the schema version, prompt version, model identifier, and configuration version in effect for every conversation. *(V1 · M · T)* ↳ *BRIEF/P8* — Version pinning is what makes an eval result mean anything later. - **GEN-006** — IF a subsystem receives a request referencing a person not present in the family graph, THEN THE platform SHALL reject the request. *(V1 · M · T)* ↳ *DERIVED* — FGR-001 makes the family graph the sole authority on who exists. - **GEN-007** — THE platform SHALL expose no user conversational content to any interface other than those explicitly enumerated in §4.7 (ACC). *(V1 · M · A)* ↳ *BRIEF/HC* — Founder zero-access is only provable if the interface list is closed and enumerable. ### 4.2 Accessibility (ACS) - **ACS-001** — THE platform SHALL meet WCAG 2.2 AA on all visual surfaces. *(V1 · M · T)* ↳ *REVIEW* — The brief names accessibility for surface 3 but sets no measurable standard anywhere. - **ACS-002** — THE carer app and web admin SHALL support operating-system text scaling to at least 200% without loss of function. *(V1 · M · T)* ↳ *REVIEW* — Elderly and presbyopic carers, not just the elder user. - **ACS-003** — WHERE Vee is included, THE Vee app SHALL provide a reduced-motion mode that disables all non-essential animation. *(V3 · M · T)* ↳ *BRIEF/S3* — 'Reduced motion' listed under sensory-aware UI options. - **ACS-004** — WHERE Vee is included, THE Vee app SHALL preserve layout position and ordering of primary controls between sessions. *(V3 · M · T)* ↳ *BRIEF/S3* — 'Predictable layout.' - **ACS-005** — WHERE Vee is included, THE Vee app SHALL emit audio only when the user has initiated the action or has explicitly enabled the alert type. *(V3 · M · T)* ↳ *BRIEF/S3* — 'No surprise sounds.' - **ACS-006** — THE elder phone line SHALL require no application, account, smartphone, or internet connection on the user's device. *(V1 · M · D)* ↳ *BRIEF/S1* — 'No requirement on the user's device. A landline must work.' - **ACS-007.1** — THE Omi persona SHALL support a user-configurable speech rate across the range recorded in the accessibility baseline. *(V1 · S · T)* ↳ *BRIEF/S1* — 'Slow speech' named as an underrated hard bit. - **ACS-007.2** — THE Omi persona SHALL default to the speech rate recorded in the accessibility baseline as validated with users aged over 70. *(V1 · S · T)* ↳ *BRIEF/S1* — A default nobody validated with the actual population is a guess. --- ### 4.3 Design constraints (DC) The following are design constraints, not requirements. They specify *how* a requirement is to be met and are recorded separately so that a reviewer challenges the architecture here rather than inside the behavioural baseline. Each is binding until formally superseded. | ID | Constraint | Binds | Rationale | |---|---|---|---| | **DC-01** | The family graph SHALL be stored as explicit relationship rows in a relational store, and SHALL NOT be represented as nested documents. | FGR-002 | Nested documents make "who can see this resource" an unbounded scan and make revocation non-atomic. | | **DC-02** | The feature gating layer SHALL be implemented as a module separate from application logic. | BIL-003 | Entitlement checks scattered through application code cannot be proven not to gate a safety behaviour (BIL-004). | | **DC-03** | Conformance with CFG-010 SHALL be demonstrated by automated static analysis executed on every build. | CFG-010 | Manual review does not scale and does not fail the pipeline. | | **DC-04** | The carer app SHALL be delivered on iOS and Android. | SUR-201 | Named platforms; a web-only carer surface does not meet the notification requirements in SUR-205. | | **DC-05** | Carer authentication SHALL use platform biometric authentication with a passcode fallback. | SUR-203 | Biometric-only excludes users who cannot enrol; passcode-only is weaker than the data warrants. | | **DC-06** | Degradation responses SHALL be cached at the edge or on the voice gateway. | DEG-006 | A fallback that requires the orchestrator is not a fallback. | ## 5. Surfaces ### 5.1 Surface 1 — Elder phone line (SUR-1xx) - **SUR-101** — THE voice gateway SHALL accept inbound calls from UK landline and UK mobile numbers. *(V1 · M · T)* ↳ *BRIEF/S1* — 'Full UK PSTN coverage including landlines.' - **SUR-102** — THE voice gateway SHALL place outbound calls to UK landline and UK mobile numbers. *(V1 · M · T)* ↳ *BRIEF/P9* — Proactive call scheduling is named as a cost and abuse vector, so outbound is in scope. - **SUR-103** — WHEN a call is connected, THE voice gateway SHALL establish a streaming session with the Lide orchestrator before the first spoken turn. *(V1 · M · T)* ↳ *DERIVED* — VOI-001 cannot be met if the session is established after the first turn. - **SUR-104** — THE elder phone line SHALL function on a device with no data connection and no software installed. *(V1 · M · D)* ↳ *BRIEF/S1* — 'A 2008 Nokia must work.' - **SUR-105.1** — WHEN an elder user does not answer a scheduled outbound call, THE Lide orchestrator SHALL apply the family's configured retry policy. *(V1 · M · T)* ↳ *BRIEF/P9* — 'A misconfigured proactive-call schedule can hit the company in days.' - **SUR-105.2** — THE Lide orchestrator SHALL place at most the configured maximum number of outbound call attempts to a given user per calendar day. *(V1 · M · T)* ↳ *BRIEF/P9* — Per-account caps named as a V1 requirement. - **SUR-106** — IF an outbound call connects and no human speech is detected within a configured window, THEN THE voice gateway SHALL terminate the call and record a non-contact event rather than remaining silent on the line. *(V1 · M · T)* ↳ *REVIEW* — A connected call with nobody speaking is an Ofcom silent-call exposure the brief does not mention. - **SUR-107** — THE voice gateway SHALL present a consistent, correctly formatted UK CLI on all outbound calls. *(V1 · M · T)* ↳ *LAW/Ofcom* — CLI presentation requirements for outbound calls. - **SUR-108.1** — THE voice gateway SHALL maintain an abandoned-call rate at or below the Ofcom persistent-misuse threshold, measured over a rolling 24-hour period. *(V1 · M · A)* **[OD-11]** ↳ *LAW/Ofcom* — Persistent misuse policy on abandoned calls; absent from the brief entirely. - **SUR-108.2** — WHEN a call is abandoned, THE voice gateway SHALL play the identifying information message within two seconds of connection. *(V1 · M · T)* **[OD-11]** ↳ *LAW/Ofcom* — The identifying message is the specific obligation attached to an abandoned call. - **SUR-109.1** — IF an elder user asks to stop receiving calls, THEN THE Lide orchestrator SHALL suspend all proactive outbound calling to that user before the call ends. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — The elder's right to stop the calls is nowhere in the brief. It should be the first thing they can do. - **SUR-109.2** — WHEN proactive outbound calling is suspended at an elder user's request, THE Lide orchestrator SHALL notify the carer within one hour. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — The carer paid; they are entitled to know the service stopped, not why. - **SUR-110** — THE Omi persona SHALL identify itself as an AI assistant at the start of every first call with a person and on request at any time. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — Nothing in the brief requires Omi to say she is an AI. It should not be optional. - **SUR-111.1** — IF a caller requests emergency assistance, THEN THE Lide orchestrator SHALL state that it cannot contact emergency services. *(V1 · M · T)* — SAFETY_LOCKED **[OD-12]** ↳ *REVIEW* — The brief never says what happens when someone asks Omi for emergency help. It will happen in week one. - **SUR-111.2** — IF a caller requests emergency assistance, THEN THE Lide orchestrator SHALL instruct the caller to dial 999. *(V1 · M · T)* — SAFETY_LOCKED **[OD-12]** ↳ *REVIEW* — Stating the limitation without giving the alternative is worse than useless. - **SUR-111.3** — IF a caller requests emergency assistance, THEN THE Lide orchestrator SHALL raise an immediate-severity safeguarding flag. *(V1 · M · T)* — SAFETY_LOCKED **[OD-12]** ↳ *REVIEW* — An emergency request is a safeguarding event whether or not it was literal. ### 5.2 Surface 2 — Carer app (SUR-2xx) - **SUR-201** — THE carer app SHALL provide the complete carer feature set on every platform named in DC-04. *(V1 · M · T)* ↳ *BRIEF/S2* — 'iOS + Android.' - **SUR-202** — THE carer app SHALL provide a tap-based equivalent for every voice-initiated action. *(V1 · M · T)* ↳ *BRIEF/S2* — 'Voice-first but tap-fallback.' - **SUR-203** — THE carer app SHALL authenticate the carer, by the mechanism specified in DC-05, before displaying any personal data. *(V1 · M · T)* ↳ *BRIEF/S2* — 'Biometric auth.' - **SUR-204.1** — WHILE the carer app has no network connection, THE carer app SHALL display the most recently synchronised summaries. *(V1 · M · T)* ↳ *BRIEF/S2* — 'Offline-tolerant for transit.' - **SUR-204.2** — WHILE the carer app has no network connection, THE carer app SHALL queue outbound actions for delivery on reconnection. *(V1 · M · T)* ↳ *BRIEF/S2* — Offline tolerance is not read-only tolerance; carers act on trains. - **SUR-205** — WHEN the safeguarding service assigns an urgency level to an event, THE carer app SHALL route the notification through the channel mapped to that urgency level. *(V1 · M · T)* ↳ *BRIEF/S2* — 'Push notifications that route the right urgency level.' - **SUR-206** — THE carer app SHALL support deep links from SMS and email digests that resolve to the referenced item after authentication. *(V1 · M · T)* ↳ *BRIEF/S2* — 'Deep-linking from SMS/email digests.' - **SUR-207** — IF a deep link is opened by an unauthenticated session, THEN THE carer app SHALL require full authentication before revealing any content. *(V1 · M · T)* ↳ *DERIVED* — A deep link that renders content before auth is a disclosure channel. - **SUR-208.1** — WHEN a carer begins onboarding an elder user who is not present, THE carer app SHALL present the absent-user consent pathway defined in §7 (CNS). *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/S2* — 'The carer onboards mum without mum present' — named as the underrated hard bit. - **SUR-208.2** — THE carer app SHALL record consent for an elder user only where that consent was captured from the elder user or from a verified LPA holder. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/P4* — 'The carer cannot consent on the elder's behalf.' - **SUR-209** — THE carer app SHALL display, for each elder user, the current consent state and the date it was last confirmed. *(V1 · M · T)* ↳ *REVIEW* — The buyer needs to see consent state, or they cannot tell a quiet service from a stopped one. ### 5.3 Surface 3 — Vee (SUR-3xx) - **SUR-301** — WHERE Vee is included, THE Vee app SHALL satisfy every requirement of the carer app other than those scoped to the carer role in §10 (FGR). *(V3 · M · A)* ↳ *BRIEF/S3* — 'All of surface 2, plus.' - **SUR-302** — WHERE Vee is included, THE Vee app SHALL display to the user, before any conversation, what categories of information are shared with which named people. *(V3 · M · T)* ↳ *BRIEF/S3* — 'Explicit transparency about what is shared with the carer.' - **SUR-303** — WHERE Vee is included, WHILE the user is under 18, THE Vee app SHALL operate parent-shadow mode as defined in §14 (AAD). *(V4 · M · T)* ↳ *BRIEF/S3* — 'Parent-shadow mode for under-18s.' - **SUR-304** — WHERE Vee is included, THE Vee app SHALL allow the user to see a log of what has been shared with the carer in the last 30 days. *(V3 · M · T)* ↳ *DERIVED* — SUR-302 is meaningless without a record the user can actually inspect. - **SUR-305** — WHERE Vee is included, WHILE the user is 18 or over, THE Lide orchestrator SHALL share conversational content with a carer only under a sharing rule the user has explicitly approved or under a safeguarding escalation. *(V3 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — An adult Vee user's conversations are theirs. The brief does not say so. ### 5.4 Surface 4 — Family web admin (SUR-4xx) - **SUR-401** — THE web admin SHALL support at least eight distinct people per household with independent roles. *(V2 · M · T)* ↳ *BRIEF/S4* — '4–8 humans per family with distinct roles.' - **SUR-402** — THE web admin SHALL allow a permitted actor to view the audit log entries for the family within their permission scope. *(V2 · M · T)* ↳ *BRIEF/S4* — 'Audit-log access.' - **SUR-403** — THE web admin SHALL provide billing administration to the account holder only. *(V2 · M · T)* ↳ *BRIEF/S4* — 'Billing administration.' - **SUR-404** — THE web admin SHALL provide an account closure flow that triggers the deletion process defined in §11 (DAT). *(V2 · M · T)* ↳ *BRIEF/S4* — 'Account closure flows.' - **SUR-405.1** — WHEN an account closure is requested, THE web admin SHALL require confirmation from the account holder. *(V2 · M · T)* ↳ *REVIEW* — Closure is destructive and the brief treats it as a flow rather than an event with victims. - **SUR-405.2** — WHEN an account closure is confirmed, THE web admin SHALL notify every person in the family graph before data deletion begins. *(V2 · M · T)* ↳ *REVIEW* — Closure ends a service other people in the household depend on. - **SUR-406** — IF a household contains a person whose consent is active and who has not been notified of closure, THEN THE platform SHALL delay deletion until the notification period has elapsed. *(V2 · M · T)* ↳ *REVIEW* — A consenting elder should not lose the service without notice because the payer left. --- ## 6. Voice pipeline (VOI) ### 6.1 Latency - **VOI-001** — THE voice gateway SHALL achieve response latency, measured from end-of-turn detection to start-of-persona-audio, of no more than 800 ms at the 50th percentile. *(V1 · M · T)* ↳ *BRIEF/P1* — 'Sub-800ms end-to-end voice latency.' Re-based to end-of-turn detection at v0.5 — DK's figure did not name its clock. - **VOI-002** — THE voice gateway SHALL achieve response latency, measured from end-of-turn detection to start-of-persona-audio, of no more than 1,200 ms at the 95th percentile. *(V1 · M · T)* ↳ *BRIEF/P1* — p95 derived; the brief gives one number, and one number is not a latency requirement. - **VOI-003** — IF response latency exceeds 2,000 ms, THEN THE Lide orchestrator SHALL emit a pre-recorded holding utterance rather than allowing unexplained silence. *(V1 · M · T)* ↳ *REVIEW* — Unexplained silence reads as a dropped call to an elderly user, who will hang up. - **VOI-020** — THE voice gateway SHALL measure and report perceived gap, defined as the interval from end-of-user-speech to start-of-persona-audio and therefore inclusive of end-of-turn detection. *(V1 · M · T)* ↳ *REVIEW v0.5* — Added after the VOI-001/VOI-011 contradiction was found. This is the clock the elder actually experiences. - **VOI-021** — THE voice gateway SHALL achieve a perceived gap of no more than 2,200 ms at the 50th percentile on the elder phone line. *(V1 · S · T)* ↳ *REVIEW v0.5* — An honest target for the honest clock. > **Latency has two clocks, and conflating them produces an unmeetable requirement.** *Response latency* (VOI-001, VOI-002) starts when the gateway decides the user has stopped speaking. *Perceived gap* (VOI-020, VOI-021) starts when the user actually stopped, and therefore includes the end-of-turn silence threshold of VOI-011. With a 1,200 ms threshold, an 800 ms response latency is a perceived gap of roughly 2,000 ms. Both numbers are honest; only one of them is what the elder experiences. Any target expressed as "sub-800 ms end to end" without naming the clock is ambiguous, and the ambiguity always resolves in the flattering direction. - **VOI-004** — THE platform SHALL record a per-stage latency breakdown (transport, STT, orchestration, LLM first token, TTS first byte) for every turn. *(V1 · M · T)* ↳ *BRIEF/P1+P8* — Without per-stage attribution a latency regression is unassignable. - **VOI-005.1** — THE safety classifier SHALL execute on a path parallel to response generation. *(V1 · M · A)* — SAFETY_LOCKED ↳ *BRIEF/P1* — 'Classifier in parallel, not in series' — DK's own decision, adopted. - **VOI-005.2** — WHILE the safety classifier is running, THE voice gateway SHALL meet the latency targets in VOI-001 and VOI-002. *(V1 · M · T)* — SAFETY_LOCKED ↳ *DERIVED* — Parallelism is a claim until the budget is met with the classifier actually running. - **VOI-006.1** — IF the safety classifier has not returned a verdict within its bounded time window, THEN THE Lide orchestrator SHALL continue the conversation. *(V1 · M · T)* ↳ *BRIEF/P1* — 'Bounded-time escalation taps.' - **VOI-006.2** — WHEN a late safety classifier verdict is received, THE Lide orchestrator SHALL apply it as an out-of-band escalation. *(V1 · M · T)* ↳ *BRIEF/P1* — A late verdict still matters; it just cannot interrupt a turn that has ended. - **VOI-007** — IF the safety classifier returns a verdict at or above the immediate-severity threshold mid-turn, THEN THE Lide orchestrator SHALL interrupt the current response and switch to the corresponding safety script. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/P1* — The interrupt is the whole point of a parallel classifier. ### 6.2 Turn-taking and speech handling - **VOI-010.1** — WHEN a user begins speaking during persona audio playback, THE voice gateway SHALL stop persona audio within 200 ms. *(V1 · M · T)* ↳ *BRIEF/S1* — 'Robust turn-taking with barge-in.' - **VOI-010.2** — WHEN a user begins speaking during persona audio playback, THE voice gateway SHALL treat that speech as the active turn. *(V1 · M · T)* ↳ *BRIEF/S1* — Stopping the audio is half of barge-in; yielding the turn is the other half. - **VOI-011** — THE voice gateway SHALL use a configurable end-of-turn silence threshold with a default no lower than 1,200 ms on the elder phone line. *(V1 · M · T)* ↳ *BRIEF/S1* — 'Graceful handling of long silences and slow speech.' - **VOI-012** — WHILE a user's inter-word pauses are shorter than the end-of-turn threshold, THE voice gateway SHALL hold the user's turn open. *(V1 · M · T)* ↳ *DERIVED* — The positive form of the barge-in threshold: pauses are not endings. - **VOI-013** — IF no user speech is detected for the configured long-silence period, THEN THE Omi persona SHALL issue one re-engagement prompt before evaluating call termination. *(V1 · M · T)* ↳ *BRIEF/S1* — 'Graceful handling of long silences.' - **VOI-014.1** — THE STT service SHALL be evaluated against a held-out corpus covering at least six UK regional accent groups. *(V1 · M · T)* **[OD-06]** ↳ *BRIEF/S1* — 'Regional UK accents' named as an underrated hard bit. - **VOI-014.2** — THE STT service SHALL meet the word error rate target recorded in the eval baseline for each accent group. *(V1 · M · T)* **[OD-06]** ↳ *REVIEW* — The brief names the problem but sets no threshold, so it cannot fail. - **VOI-015** — THE STT service SHALL be evaluated against a corpus containing dysarthric and dementia-affected speech samples. *(V2 · M · T)* **[OD-06]** ↳ *BRIEF/S1* — 'Dementia-affected speech.' - **VOI-022** — THE STT evaluation corpus SHALL be encoded at the sample rate and codec carried on the production telephony path. *(V1 · M · T)* ↳ *REVIEW v0.6* — Wideband test audio flatters the recogniser. The test channel must match the production channel. - **VOI-023** — THE platform SHALL treat VOI-014.2 as satisfied only by word error rates measured on audio encoded under VOI-022. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW v0.6* — Without this, the accent target can be passed honestly and still fail on a real line. - **VOI-024** — THE platform SHALL measure and record, per accent group, the word error rate difference between wideband and narrowband encoding of the same corpus. *(V1 · S · T)* ↳ *REVIEW v0.6* — The delta is the input to the post-2027 wideband codec decision. See OD-30. > **Why VOI-022 and VOI-023 exist.** Telephony carries 8 kHz narrowband audio, typically G.711. Browser and WebRTC testing carries wideband Opus at 16 kHz or above. Word error rates measured on wideband audio are systematically better than the same recogniser achieves on a real call, and the gap widens precisely where accuracy is already marginal — regional accents, dysarthric speech, hearing-aid feedback. Without VOI-023 it is possible to pass the accent evaluation honestly, ship, and discover the recogniser fails on the population the product exists to serve. The test condition must match the production channel or the test measures nothing. > > **Why VOI-024 exists, and why it is an opportunity rather than a cost.** Recording the wideband-to-narrowband delta tells you what the channel is costing you, which is the input to a decision that becomes available in 2027. Once the UK PSTN is retired on 31 January 2027 every domestic "landline" is a VoIP service, and wideband codecs such as G.722 or Opus become technically possible end to end where the carrier and customer premises equipment support them. If the delta in VOI-024 is large, negotiating a wideband path is one of the few available levers that improves accuracy for the hardest population without changing recogniser. If the delta is small, that lever is not worth pulling. Either way, you only know because you measured it. - **VOI-016** — IF transcription confidence for a turn falls below the configured threshold, THEN THE Lide orchestrator SHALL request clarification rather than acting on the low-confidence transcript. *(V1 · M · T)* ↳ *REVIEW* — Acting on a low-confidence transcript is how a misheard word becomes a wrong action. - **VOI-017.1** — IF transcription confidence falls below threshold for three consecutive turns, THEN THE Lide orchestrator SHALL offer to end the call and call back later. *(V1 · S · T)* ↳ *REVIEW* — Three bad turns is a bad line, not a bad user. Ending kindly beats persisting. - **VOI-017.2** — IF transcription confidence falls below threshold for three consecutive turns, THEN THE Lide orchestrator SHALL record a call-quality event. *(V1 · S · T)* ↳ *REVIEW* — Call quality is a product metric nobody collects until a customer complains. - **VOI-018** — THE voice gateway SHALL apply acoustic echo cancellation and noise suppression tuned for hearing-aid feedback conditions. *(V1 · S · T)* ↳ *BRIEF/S1* — 'Background noise, hearing-aid feedback.' - **VOI-019** — THE Lide orchestrator SHALL gate a behaviour on a confidence signal only where that signal has a calibration curve recorded under EVL-013. *(V1 · M · A)* ↳ *REVIEW* — Model self-reported confidence is systematically miscalibrated; a gate built on it never fires. > **Note.** VOI-019 exists because self-reported confidence from an LLM is systematically miscalibrated. Any escalation gated on a model saying "I am 0.98 confident" will never fire. Confidence gates must be built on measured, calibrated signals with a held-out reliability curve. --- ## 7. Identity and speaker recognition (IDN) - **IDN-001** — THE identity service SHALL require a confirmation exchange in addition to any voice-characteristic match before treating a person's identity as established. *(V1 · M · A)* — SAFETY_LOCKED ↳ *BRIEF/P3* — 'Never-assume-identity-from-voice safety default' — DK's own stance, adopted verbatim in intent. - **IDN-002** — WHEN a call begins on a shared line, THE Omi persona SHALL establish who it is speaking to before disclosing any personal information. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/P3* — 'Mum and Dad share a landline. Visiting grandson picks it up.' - **IDN-003** — WHERE voiceprint identification is included, THE identity service SHALL treat a voiceprint match as a hypothesis requiring conversational confirmation. *(V1 · M · T)* ↳ *BRIEF/Q3* — 'Voiceprint speaker ID at the phone line is non-trivial.' A match is evidence, not proof. - **IDN-004** — IF the identity of the speaker is not confirmed, THEN THE Lide orchestrator SHALL restrict the conversation to content classified as non-personal. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/P3* — 'Must never disclose private information to the wrong person.' - **IDN-005.1** — IF the speaker is not a person registered in the family graph, THEN THE Omi persona SHALL limit its disclosure to the general statement of purpose held in the unregistered-speaker script. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — The brief covers wrong-family-member. It does not cover a complete stranger answering. - **IDN-005.2** — IF the speaker is not a person registered in the family graph, THEN THE Omi persona SHALL end the call within two conversational turns. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — Lingering with an unidentified caller is how a social-engineering attempt gets its second question in. - **IDN-006** — THE identity confirmation exchange SHALL complete within two conversational turns in the expected case. *(V1 · S · T)* ↳ *BRIEF/P3* — 'The UX challenge is making confirmation not feel like an interrogation.' - **IDN-007.1** — IF a registered user's voice characteristics have changed beyond the match threshold, THEN THE identity service SHALL fall back to conversational confirmation. *(V1 · M · T)* ↳ *BRIEF/P3* — 'Voice-shift due to cold/medication/dementia.' - **IDN-007.2** — WHEN conversational confirmation succeeds for a registered user, THE identity service SHALL grant that person's normal permission scope. *(V1 · M · T)* ↳ *BRIEF/P3* — Degraded voice must not become denial of service to the person it happens to. - **IDN-008.1** — WHERE voiceprint identification is included, THE identity service SHALL require explicit consent before voiceprint enrolment. *(V1 · M · T)* ↳ *LAW/UK GDPR Art 9* — A voiceprint is biometric data processed for identification. - **IDN-008.2** — WHEN a person withdraws voiceprint consent, THE identity service SHALL delete that person's voiceprint template within 24 hours. *(V1 · M · T)* ↳ *LAW/UK GDPR Art 17* — Withdrawal without deletion is not withdrawal. - **IDN-009** — THE identity service SHALL store voiceprint templates in a form that cannot be used to reconstruct audio. *(V1 · M · A)* ↳ *REVIEW* — A template that can reconstruct audio is a recording under another name. - **IDN-010** — WHEN a person is identified mid-call as different from the person identified at call start, THE Lide orchestrator SHALL re-apply the permission scope for the newly identified person before the next response. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — The handset changes hands mid-call. The brief implies this and never states the re-scoping rule. - **IDN-011** — THE carer app, Vee app, and web admin SHALL establish identity solely through authenticated sessions. *(V1 · M · T)* ↳ *BRIEF/Q3* — 'Authenticated sessions on the app side are easier.' --- ## 8. Consent and capacity (CNS) > Legal frame: UK GDPR Articles 6, 7 and 9; Mental Capacity Act 2005 (England & Wales); Adults with Incapacity (Scotland) Act 2000; Mental Capacity Act (Northern Ireland) 2016; PECR regulation 19 for automated calling. **[OD-01, OD-11]** - **CNS-001** — THE consent service SHALL record consent per person, per processing purpose, per data domain, with timestamp, method of capture, and the wording presented. *(V1 · M · T)* ↳ *LAW/UK GDPR Art 7* — Demonstrable consent means per purpose, with the wording that was actually presented. - **CNS-002** — THE consent service SHALL accept a consent record for an elder user only where that record was created by that elder user or by a verified LPA holder acting within the scope of their authority. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/P4* — 'The carer cannot consent on the elder's behalf... only an LPA holder can, and only for certain things.' - **CNS-003** — WHEN a carer completes onboarding for an absent elder user, THE Lide orchestrator SHALL treat the elder's consent as not yet obtained. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/P4* — 'The carer onboards mum's phone line without mum present.' - **CNS-004.1** — WHILE an elder user's consent has not been obtained, THE Lide orchestrator SHALL restrict Omi to the consent-capture script. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/P4* — 'Mum's first conversation must include a capacity-aware consent flow led by Omi.' - **CNS-004.2** — WHILE an elder user's consent has not been obtained, THE Lide orchestrator SHALL withhold all family-provided personal information from the conversation. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — Until consent exists, family-supplied information about the elder cannot be spoken back to them. - **CNS-005** — WHEN Omi conducts a first conversation with an elder user whose consent is not recorded, THE Lide orchestrator SHALL run the capacity-aware consent script covering: who is calling, who arranged it, what is recorded, what is retained, who can see it, and how to stop it. *(V1 · M · T)* ↳ *BRIEF/P4* — 'MCA-2005-compliant consent flow.' The six disclosure elements are derived from Art 13. - **CNS-006.1** — IF the elder user does not consent, THEN THE Lide orchestrator SHALL end the call using the consent-declined closing script. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/P4* — 'With a clean exit path.' - **CNS-006.2** — IF the elder user does not consent, THEN THE Lide orchestrator SHALL suspend all further calls to that user. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — Refusal that does not stop the calls is not refusal. - **CNS-006.3** — IF the elder user does not consent, THEN THE platform SHALL delete all audio captured in that call within one hour. *(V1 · M · T)* — SAFETY_LOCKED ↳ *LAW/UK GDPR Art 6* — Audio captured before refusal has no lawful basis to persist. - **CNS-006.4** — IF the elder user does not consent, THEN THE platform SHALL notify the carer that consent was not given, disclosing no conversational content. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — The commercially hardest requirement here: the payer learns the outcome, never the content. - **CNS-007.1** — IF the consent conversation produces indicators that the elder user may lack capacity to consent, THEN THE Lide orchestrator SHALL exit the consent flow. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/P4* — 'A clean exit path if capacity is unclear.' - **CNS-007.2** — IF the consent conversation produces capacity indicators, THEN THE consent service SHALL leave that user's consent state as not obtained. *(V1 · M · T)* — SAFETY_LOCKED ↳ *LAW/MCA 2005* — Capacity doubt means consent is not validly given, so the state must not advance. - **CNS-007.3** — IF the consent conversation produces capacity indicators, THEN THE Lide orchestrator SHALL raise a capacity-review flag to the safeguarding service. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — Suspected incapacity is a safeguarding signal, not merely a data-protection one. - **CNS-008.1** — THE consent service SHALL support recording a verified LPA holder and the scope of that authority. *(V1 · M · T)* **[OD-02]** ↳ *BRIEF/P4* — 'Only an LPA holder can.' - **CNS-008.2** — THE consent service SHALL treat a recorded LPA authority as effective only after documentary verification is complete. *(V1 · M · T)* **[OD-02]** ↳ *REVIEW* — An unverified claim of attorney status is exactly the vector an abuser would use. - **CNS-009** — THE consent service SHALL treat authority granted by an LPA for Property & Financial Affairs as applying only to the finance data domain. *(V1 · M · T)* ↳ *LAW/MCA 2005* — The two LPA types confer different authority. See OD-02 — this remains legally unsettled. - **CNS-010.1** — WHEN any person withdraws consent, THE platform SHALL cease the corresponding processing within 24 hours. *(V1 · M · T)* ↳ *LAW/UK GDPR Art 7(3)* — Withdrawal must be as easy as giving, and must actually stop processing. - **CNS-010.2** — WHEN any person withdraws consent, THE platform SHALL confirm the withdrawal to that person within 24 hours. *(V1 · M · T)* ↳ *REVIEW* — Silent compliance leaves the person unsure whether it worked. - **CNS-011.1** — WHILE a user's capacity is recorded as fluctuating, THE consent service SHALL re-confirm consent at the configured interval. *(V2 · M · T)* **[OD-03]** ↳ *BRIEF/U3* — 'Dementia-affected elders who revoke consent inconsistently.' - **CNS-011.2** — IF a scheduled re-confirmation does not complete, THEN THE consent service SHALL raise a human review task. *(V2 · M · T)* **[OD-03]** ↳ *REVIEW* — A missed reconfirmation is a question for a human, not a trigger for a machine. - **CNS-011.3** — IF a scheduled re-confirmation does not complete, THEN THE consent service SHALL leave the existing consent state unchanged. *(V2 · M · T)* **[OD-03]** ↳ *REVIEW* — Auto-withdrawing on silence would cut a vulnerable person off for having a bad week. - **CNS-012.1** — THE consent service SHALL present spoken consent wording at a reading age no higher than 11. *(V1 · M · I)* ↳ *LAW/UK GDPR Art 12* — Information must be concise and in plain language. - **CNS-012.2** — THE consent service SHALL make the consent wording available to the carer in written form. *(V1 · M · I)* ↳ *REVIEW* — The carer needs the wording in a form they can re-read and challenge. - **CNS-013.1** — THE Lide orchestrator SHALL inform every participant on a call that the call is being processed, before any content is retained. *(V1 · M · T)* — SAFETY_LOCKED ↳ *LAW/UK GDPR Art 13* — Processing must be disclosed at the point of collection. - **CNS-013.2** — WHILE call recording is enabled, THE Lide orchestrator SHALL state at the start of the call that the call is being recorded. *(V1 · M · T)* — SAFETY_LOCKED ↳ *LAW/PECR* — Recording notification is separate from processing notification. - **CNS-014** — WHERE proactive outbound calling is included, THE platform SHALL obtain and record prior consent for automated calling from the person called. *(V1 · M · T)* **[OD-11]** ↳ *LAW/PECR reg 19* — Applicability is genuinely uncertain — see OD-11. Specified conservatively. - **CNS-015.1** — THE platform SHALL complete a Data Protection Impact Assessment before processing any production personal data. *(V1 · M · R)* ↳ *LAW/UK GDPR Art 35* — Large-scale special category processing of vulnerable adults is a textbook mandatory DPIA. - **CNS-015.2** — WHEN a material change to processing is proposed, THE platform SHALL re-run the Data Protection Impact Assessment before that change takes effect. *(V1 · M · R)* ↳ *LAW/UK GDPR Art 35(11)* — A DPIA is a live document, not a launch artefact. --- ## 9. Configuration and customisation (CFG) - **CFG-001** — THE configuration service SHALL store configuration per person, not per family. *(V1 · M · I)* ↳ *BRIEF/Q1* — 'A typed configuration layer per user (not per family).' DK's own emphasis. - **CFG-002.1** — THE configuration service SHALL validate every configuration write against a versioned typed schema. *(V1 · M · T)* ↳ *BRIEF/Q1* — 'Schema-validated, version-controlled, audit-trailed.' - **CFG-002.2** — IF a configuration write fails schema validation, THEN THE configuration service SHALL reject the write. *(V1 · M · T)* ↳ *DERIVED* — Validation that does not reject is logging. - **CFG-003** — THE configuration schema SHALL partition every field into exactly one of `SAFETY_LOCKED` or `USER_CONFIGURABLE`. *(V1 · M · I)* ↳ *BRIEF/Q1* — 'A config schema with explicit SAFETY_LOCKED and USER_CONFIGURABLE sections.' - **CFG-004** — THE configuration service SHALL reject any write to a `SAFETY_LOCKED` field originating from a user, carer, admin, or support interface. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/Q1* — 'No path for a user-configurable field to influence a safety-locked behaviour.' - **CFG-005.1** — THE Lide orchestrator SHALL resolve the effective configuration for the identified person at conversation start. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/Q1* — 'The LLM pipeline reads at conversation start.' - **CFG-005.2** — WHILE a conversation is in progress, THE Lide orchestrator SHALL apply the safety configuration resolved at conversation start without modification. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — Mid-conversation safety reconfiguration is the obvious social-engineering route. - **CFG-006** — THE configuration service SHALL support user-configurable fields for persona selection, voice preference, speech rate, topic preferences, call schedule, call frequency, language, and notification routing. *(V1 · M · T)* ↳ *BRIEF/Q1* — 'Personality, voice preferences, topic preferences, escalation rules, and language.' - **CFG-007** — THE configuration service SHALL classify escalation thresholds, safeguarding routing, consent behaviour, identity confirmation, citation requirements, and degradation scripts as `SAFETY_LOCKED`. *(V1 · M · I)* ↳ *BRIEF/Q1* — DK's own example: 'don't escalate to my daughter when I mention pain' is not configurable. - **CFG-008** — IF a proposed schema change would place a `USER_CONFIGURABLE` field on a code path that determines a `SAFETY_LOCKED` behaviour, THEN THE configuration service SHALL reject that schema change. *(V1 · M · A)* — SAFETY_LOCKED ↳ *BRIEF/Q1* — 'The architectural decision is where the line sits and how we enforce it.' Enforced at schema-change time. - **CFG-009.1** — THE configuration service SHALL assign a version to every configuration change. *(V1 · M · T)* ↳ *BRIEF/Q1* — 'Version-controlled.' - **CFG-009.2** — THE configuration service SHALL retain, for every configuration change, the actor, timestamp, previous value, and new value. *(V1 · M · T)* ↳ *BRIEF/Q1* — 'Audit-trailed.' - **CFG-010** — THE platform SHALL demonstrate, for every release, that no `USER_CONFIGURABLE` field is read on a code path that determines a `SAFETY_LOCKED` behaviour, by the means specified in DC-03. *(V1 · M · A)* ↳ *BRIEF/Q1* — The proof obligation behind CFG-004. Design constraint DC-03 says how. - **CFG-011.1** — WHEN a user asks Omi to change a `SAFETY_LOCKED` behaviour, THE Omi persona SHALL state that it cannot make that change, using language at a reading age no higher than 11. *(V1 · M · T)* ↳ *REVIEW* — Refusing without explaining sounds like malfunction to an elderly user. - **CFG-011.2** — WHEN a user asks Omi to change a `SAFETY_LOCKED` behaviour, THE Omi persona SHALL give the reason held in the locked-behaviour explanation script. *(V1 · M · T)* ↳ *REVIEW* — A stated reason is what makes a refusal feel like care rather than obstruction. - **CFG-011.3** — WHEN a user asks Omi to change a `SAFETY_LOCKED` behaviour, THE Omi persona SHALL offer the human route for raising the request. *(V1 · M · T)* ↳ *REVIEW* — Every locked refusal needs a human route, or it is a dead end. - **CFG-012** — THE configuration service SHALL support per-persona model selection as a platform-level, not user-level, configuration. *(V1 · S · I)* ↳ *BRIEF/ARCH* — 'Omi may use a smaller, lower-latency model than Jool.' Platform-level, not user-level. --- ## 10. Family graph, roles and permissions (FGR) - **FGR-001** — THE family graph service SHALL model a household as containing many people, each person holding many roles, each role granting many permissions, each permission scoped to a data domain. *(V1 · M · I)* ↳ *BRIEF/Q3* — 'A household has many people; each person has many roles; roles have many permissions; permissions are scoped per data domain.' - **FGR-002** — THE family graph service SHALL represent every relationship as an individually addressable record that can be queried, granted, and revoked independently of any other relationship, as constrained by DC-01. *(V1 · M · I)* ↳ *BRIEF/Q3* — 'Postgres with explicit relationship rows (not nested JSON).' Recast as behaviour; DC-01 holds the storage decision. - **FGR-003** — THE family graph service SHALL support the roles: carer, elder, dependent, observer, paid carer, LPA holder, and account holder. *(V1 · M · T)* ↳ *BRIEF/Q3* — 'Carer / elder / dependent / observer', extended with paid carer, LPA holder and account holder. - **FGR-004** — THE family graph service SHALL support the permission verbs: read, propose, approve, and configure. *(V1 · M · T)* ↳ *BRIEF/Q3* — 'Read / propose / approve / configure.' - **FGR-005** — THE family graph service SHALL support the data domains: medication, finance, appointments, messages, health notes, location, and safeguarding. *(V1 · M · T)* ↳ *BRIEF/Q3* — 'Medication / finance / appointments / messages', extended with health notes, location, safeguarding. - **FGR-006** — THE family graph service SHALL evaluate every data access as a triple of (person, verb, domain-scoped resource). *(V1 · M · T)* ↳ *DERIVED* — The evaluation primitive implied by FGR-001 through FGR-005. - **FGR-007** — THE family graph service SHALL default every permission to denied. *(V1 · M · T)* ↳ *REVIEW* — Deny-by-default is not stated in the brief and is the only safe starting position. - **FGR-008** — THE family graph service SHALL support time-bounded permission grants that expire without manual revocation. *(V1 · M · T)* ↳ *BRIEF/U3* — 'Paid carers with limited scope.' Expiry as data, not as a cron job. - **FGR-009** — THE family graph service SHALL support a person being present in more than one household with independent roles in each. *(V2 · S · T)* ↳ *BRIEF/U3* — 'Ex-spouses, estranged siblings' — people belong to more than one household. - **FGR-010** — THE family graph service SHALL support explicit exclusion relationships that block a named person from a named person's data regardless of household role. *(V1 · M · T)* ↳ *BRIEF/U3* — 'Real families are messier than RBAC handles.' Exclusion as a first-class object is the specific answer. - **FGR-011** — WHEN a subject of data requests that a specific person's access be removed, THE family graph service SHALL apply the removal without requiring the account holder's approval. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — The subject must outrank the payer over their own data. Not in the brief. - **FGR-012.1** — IF the account holder attempts to grant themselves access to a data domain the subject has restricted, THEN THE family graph service SHALL deny the change. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — The account holder is the most likely person to attempt this, and the least likely to be challenged. - **FGR-012.2** — WHEN such a change is denied, THE family graph service SHALL notify the subject within one hour. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — A blocked attempt the subject never hears about is a warning wasted. - **FGR-013** — THE family graph service SHALL record every permission change with actor, timestamp, before state, and after state, in the audit log. *(V1 · M · T)* ↳ *BRIEF/P6* — 'Every access to user data... logged.' Permission changes are access changes. - **FGR-014** — THE family graph service SHALL support migration of the graph schema without loss of historical permission state. *(V1 · M · A)* ↳ *BRIEF/Q3* — 'So we can audit, query, and migrate it.' - **FGR-015.1** — WHEN a paid carer's engagement ends, THE family graph service SHALL revoke all of that person's permissions. *(V1 · M · T)* ↳ *BRIEF/U3* — 'Paid carers with limited scope.' - **FGR-015.2** — WHEN a paid carer's permissions are revoked, THE family graph service SHALL retain the historical record of that person's prior access. *(V1 · M · T)* ↳ *BRIEF/P6* — Revocation must not erase the history of what was accessible. - **FGR-016** — THE family graph service SHALL be queryable to answer, for any resource, the complete list of people currently able to access it. *(V1 · M · T)* ↳ *BRIEF/Q3* — 'So we can audit, query.' This is the query that makes the audit meaningful. - **FGR-017** — THE family graph service SHALL be queryable to answer, for any person, the complete list of resources they can currently access. *(V1 · M · T)* ↳ *LAW/UK GDPR Art 15* — The subject access answer depends on this query existing. --- ## 11. Safety classification (SFC) - **SFC-001** — THE safety classifier SHALL classify every user turn on the phone line for: suicide and self-harm ideation, physical abuse indicators, emotional and coercive control indicators, neglect indicators, financial abuse and scam indicators, and capacity-loss signals. *(V1 · M · T)* ↳ *BRIEF/P1* — 'Suicide ideation, abuse indicators, financial scam detection', extended with capacity-loss signals from BRIEF/ARCH. - **SFC-002** — THE safety classifier SHALL run in parallel with response generation. *(V1 · M · A)* ↳ *BRIEF/P1* — 'Classifier in parallel, not in series.' - **SFC-003** — THE safety classifier SHALL assign a severity level from a fixed taxonomy to every positive classification. *(V1 · M · T)* ↳ *BRIEF/P7* — 'Flag taxonomy, severity routing.' - **SFC-004.1** — WHEN the safety classifier assigns immediate severity, THE Lide orchestrator SHALL execute the immediate-severity script. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/P7* — Severity routing is only real if the highest severity changes the conversation immediately. - **SFC-004.2** — WHEN the safety classifier assigns immediate severity, THE safeguarding service SHALL notify the on-call reviewer within the immediate-severity notification target. *(V1 · M · T)* — SAFETY_LOCKED **[OD-08]** ↳ *BRIEF/P7* — 'On-call handoff.' - **SFC-005** — IF the safety classifier returns an ambiguous verdict, THEN THE Lide orchestrator SHALL flag the turn at the review severity. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/P10* — 'When the safety classifier returns ambiguous' is named as an open question. This is the answer. - **SFC-006.1** — THE safety classifier SHALL be evaluated for recall against a labelled corpus before every release. *(V1 · M · T)* **[OD-07]** ↳ *BRIEF/P8* — 'Safety classification recall' listed as a required eval dimension. - **SFC-006.2** — THE safety classifier SHALL meet the recall floor recorded in the eval baseline before a release is promoted. *(V1 · M · T)* **[OD-07]** ↳ *REVIEW* — A measured recall that does not gate a release is a metric, not a control. - **SFC-007.1** — THE platform SHALL measure and report safety classifier precision alongside recall for every release. *(V1 · M · A)* ↳ *REVIEW* — The brief asks for recall and never mentions precision. Recall alone is trivially gamed. - **SFC-007.2** — WHEN a change increases safety classifier recall, THE platform SHALL record the measured precision cost of that change. *(V1 · M · A)* ↳ *REVIEW* — Every recall improvement has a false-positive cost paid by a human reviewer. - **SFC-008** — IF the safety classifier is unavailable, THEN THE Lide orchestrator SHALL restrict all conversations to the degraded-mode script defined in §15 (DEG). *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/P10* — Extends the degradation story to the classifier, which the brief lists but does not resolve. - **SFC-009** — THE safety classifier SHALL run on every user turn on the phone line irrespective of configuration value, feature flag, or billing tier. *(V1 · M · A)* — SAFETY_LOCKED ↳ *BRIEF/Q1* — The classifier is the canonical SAFETY_LOCKED behaviour. - **SFC-010.1** — IF no specialised classifier is available for a risk category, THEN THE platform SHALL record that gap in the risk register. *(V1 · M · R)* ↳ *BRIEF/U4* — 'Off-the-shelf classifiers don't cover financial abuse of elders or capacity-loss signals.' - **SFC-010.2** — IF no specialised classifier is available for a risk category, THEN THE platform SHALL route that category to human review by default. *(V1 · M · R)* ↳ *BRIEF/U4* — 'Partnership-first, build-second' means humans cover the gap in the meantime. - **SFC-011.1** — THE safety classifier SHALL be version-pinned per release. *(V1 · M · T)* ↳ *BRIEF/P8* — 'Every model upgrade has to run through a regression suite.' - **SFC-011.2** — THE safety classifier SHALL record its version against every classification it produces. *(V1 · M · T)* ↳ *BRIEF/P8* — A classification without a version cannot be re-evaluated after a model change. - **SFC-012** — THE platform SHALL measure safety classifier recall against transcripts produced from audio encoded under VOI-022. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW v0.6* — Transcription error propagates into classifier recall. Audio quality is a safeguarding parameter here. > **Why SFC-012 exists.** The classifier reads transcripts, not audio, so every transcription error propagates into it. The chain is short and it ends badly: narrowband encoding degrades the transcript, a degraded transcript degrades classifier recall, and degraded recall means a missed disclosure of abuse or suicidal ideation. Measuring classifier recall on clean wideband transcripts and reporting it as the recall floor for SFC-006.2 would overstate the safety of the system in the exact channel it actually operates in. Audio quality is a safeguarding parameter here, not an audio-quality parameter. --- ## 12. Safeguarding operations (SFG) - **SFG-001** — THE safeguarding service SHALL maintain a versioned flag taxonomy mapping every classification category and severity to a response pathway recorded in that taxonomy. *(V1 · M · I)* ↳ *BRIEF/P7* — 'Flag taxonomy, severity routing.' - **SFG-002** — THE safeguarding service SHALL route every flagged event to a DBS-checked trained reviewer. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/HC* — 'Trained DBS-checked reviewer in loop for every flagged event.' - **SFG-003** — THE safeguarding service SHALL enforce, for each severity level, the maximum time from flag creation to reviewer acknowledgement recorded in the safeguarding SLA table. *(V1 · M · T)* **[OD-08]** ↳ *BRIEF/P7* — '24/7 operation' implies a stated acknowledgement time. The brief gives none — see OD-08. - **SFG-004.1** — IF a flag is not acknowledged within its severity target, THEN THE safeguarding service SHALL escalate to the next on-call tier. *(V1 · M · T)* ↳ *BRIEF/P7* — 'On-call handoff.' - **SFG-004.2** — IF a flag is not acknowledged within its severity target, THEN THE safeguarding service SHALL record the breach. *(V1 · M · T)* ↳ *REVIEW* — An unrecorded SLA breach is an SLA that does not exist. - **SFG-005** — THE safeguarding service SHALL support on-call rota definition, handoff, and coverage gap detection. *(V1 · M · T)* ↳ *BRIEF/P7* — 'On-call handoff' at 'hundreds of flags a day'. - **SFG-006** — THE safeguarding service SHALL record, for every flagged event, the classification, the reviewer decision, the rationale, the action taken, and the outcome. *(V1 · M · T)* ↳ *BRIEF/P7* — 'Regulator-ready reporting' requires the decision and its rationale, not just the outcome. - **SFG-007** — THE safeguarding service SHALL produce, for any specified period, a report containing every flagged event with its classification, reviewer decision, action taken, and outcome. *(V1 · M · T)* ↳ *BRIEF/P7* — 'Regulator-ready reporting.' - **SFG-008** — WHERE a local authority safeguarding referral is made, THE safeguarding service SHALL record the referral reference and the responsible officer. *(V1 · M · T)* ↳ *LAW/Care Act 2014 s.42* — Local authority enquiries need a reference to be traceable afterwards. - **SFG-009.1** — THE safeguarding service SHALL surface to a reviewer only the conversation turns within the flagged window defined by the flag taxonomy. *(V1 · M · T)* ↳ *REVIEW* — Data minimisation applied to the reviewer. The brief puts a human in the loop without bounding what they see. - **SFG-009.2** — THE safeguarding service SHALL record every reviewer access to conversational content in the audit log. *(V1 · M · T)* ↳ *BRIEF/P6* — 'Every access to user data — by us, by... safeguarding — logged.' - **SFG-010** — IF a carer is recorded as a subject of a safeguarding concern, THEN THE safeguarding service SHALL exclude that carer from all notifications relating to that concern. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — The carer may be the abuser. The brief's notification model assumes they are not. - **SFG-011** — WHEN the flag taxonomy changes, THE platform SHALL re-run the safeguarding regression suite before the change takes effect. *(V1 · M · T)* ↳ *BRIEF/P8* — Taxonomy changes are behaviour changes and belong behind the same gate. - **SFG-012** — THE platform SHALL hold documented referral pathways with named external partners before processing production data. *(V1 · M · R)* ↳ *BRIEF/HC* — 'Hourglass, Samaritans, NSPCC partnerships before launch.' - **SFG-013** — THE safeguarding service SHALL support caseload volumes at least two orders of magnitude above launch volume without change to its data model. *(V1 · M · A)* ↳ *BRIEF/P7* — 'Day one: 50 families... Year three: 50,000 families.' - **SFG-014** — WHEN a reviewer confirms financial abuse or scam indicators, THE safeguarding service SHALL follow the documented outward referral pathway for that concern type. *(V1 · M · T)* ↳ *REVIEW* — The brief detects financial abuse and never says what happens next. - **SFG-015** — THE platform SHALL maintain documented referral pathways to Action Fraud and to the vulnerable customer route of the relevant bank. *(V1 · M · R)* **[OD-24]** ↳ *REVIEW* — Detection without a referral route is surveillance, not safeguarding. - **SFG-016** — THE safeguarding service SHALL record the outcome of every outward referral. *(V1 · M · T)* ↳ *REVIEW* — An outward referral with no recorded outcome cannot be learned from or defended. --- ## 13. Knowledge, grounding and hallucination control (KNW) - **KNW-001** — THE Lide orchestrator SHALL classify content domains as `AUTHORITATIVE_ONLY` or `CONVERSATIONAL`. *(V1 · M · I)* ↳ *BRIEF/P2* — 'Zero is the only acceptable bar for benefits-rule statements, drug-interaction claims, and any clinical guidance.' - **KNW-002** — THE domains benefits and welfare entitlement, medication and drug interaction, clinical guidance, and legal rights SHALL be classified `AUTHORITATIVE_ONLY`. *(V1 · M · I)* — SAFETY_LOCKED ↳ *BRIEF/P2* — The four domains named in the brief. - **KNW-003** — WHILE responding within an `AUTHORITATIVE_ONLY` domain, THE Lide orchestrator SHALL emit only statements supported by a retrieved passage from an approved source, with a recorded citation. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/P2* — 'RAG against authoritative sources with citation-required outputs.' - **KNW-004.1** — IF no supporting passage is retrieved for an `AUTHORITATIVE_ONLY` question, THEN THE persona SHALL state that it does not know the answer. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/P2* — 'It says "I'd want to check that with the GP".' - **KNW-004.2** — IF no supporting passage is retrieved for an `AUTHORITATIVE_ONLY` question, THEN THE Lide orchestrator SHALL withhold any answer not supported by a retrieved passage. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/P2* — 'The model never speaks unsourced facts in these domains.' - **KNW-004.3** — IF no supporting passage is retrieved for an `AUTHORITATIVE_ONLY` question, THEN THE Lide orchestrator SHALL route the question to the referral destination mapped to that domain. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/P2* — 'And routes appropriately.' - **KNW-005** — THE knowledge service SHALL maintain approved source sets with named provenance, retrieval date, and version. *(V1 · M · T)* ↳ *BRIEF/P2* — 'DWP guidance, BNF, NHS England.' - **KNW-006** — THE knowledge service SHALL record the source version used for every cited statement. *(V1 · M · T)* ↳ *REVIEW* — Benefits rules and drug data change. A citation without a version is a citation to something that no longer exists. - **KNW-007** — WHEN an approved source is updated, THE platform SHALL re-run the grounding regression suite before the updated index is promoted. *(V1 · M · T)* ↳ *BRIEF/P8* — 'Every retrieval index rebuild has to run through a regression suite.' - **KNW-008.1** — THE Lide orchestrator SHALL treat diagnosis, treatment recommendation, dosage instruction, and triage decision as prohibited output classes. *(V1 · M · T)* — SAFETY_LOCKED **[OD-04]** ↳ *REVIEW* — The brief implies clinical restraint; this states it as a bounded output class. See OD-04 on medical device classification. - **KNW-008.2** — WHEN a request falls within a prohibited output class, THE Lide orchestrator SHALL route the request to the referral destination mapped to that domain. *(V1 · M · T)* — SAFETY_LOCKED **[OD-04]** ↳ *BRIEF/P2* — 'Routes appropriately.' - **KNW-009** — WHEN a submission to a third party is drafted on a user's behalf, THE platform SHALL require human approval before that submission is sent. *(V2 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/P2* — 'Human-in-the-loop on draft submissions.' - **KNW-010** — THE platform SHALL assess whether any planned feature constitutes a medical device under the UK MDR before that feature is released. *(V1 · M · R)* **[OD-04]** ↳ *REVIEW* — MHRA software-as-a-medical-device classification is absent from the brief and is a company-ending surprise. - **KNW-011.1** — THE eval harness SHALL measure the unsupported-claim rate in `AUTHORITATIVE_ONLY` domains for every release. *(V1 · M · T)* ↳ *BRIEF/P8* — 'Factual accuracy' as an eval dimension. - **KNW-011.2** — IF the measured unsupported-claim rate is greater than zero, THEN THE pipeline SHALL block the release. *(V1 · M · T)* ↳ *BRIEF/P2* — 'Zero is the only acceptable bar.' A zero-tolerance bar has to be a hard gate. --- ## 14. Audit logging (AUD) - **AUD-001** — THE audit service SHALL record every access to user data by any person, automated system, support process, or safeguarding process. *(V1 · M · T)* ↳ *BRIEF/P6* — 'Every access to user data — by us, by automated systems, by support, by safeguarding.' - **AUD-002** — THE audit service SHALL record, for each entry: actor identity, actor role, subject, resource, data domain, verb, timestamp, justification, and outcome. *(V1 · M · T)* ↳ *REVIEW* — The brief says log everything and does not say what an entry contains. - **AUD-003** — THE audit store SHALL be append-only. *(V1 · M · A)* — SAFETY_LOCKED ↳ *BRIEF/P6* — 'Append-only.' - **AUD-004** — THE audit service SHALL cryptographically chain entries such that removal or modification of any entry is detectable. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/P6* — 'Cryptographically chained.' - **AUD-005** — THE platform SHALL grant no engineer, administrator, or founder the ability to modify or delete audit entries. *(V1 · M · A)* — SAFETY_LOCKED ↳ *BRIEF/P6+HC* — 'Engineers cannot modify' plus 'including me' from the founder access constraint. - **AUD-006.1** — THE platform SHALL verify audit chain integrity at least once every 24 hours. *(V1 · M · T)* ↳ *REVIEW* — A chain nobody walks is a chain nobody knows is broken. - **AUD-006.2** — IF audit chain verification fails, THEN THE platform SHALL raise an alert to the on-call engineer within five minutes. *(V1 · M · T)* ↳ *REVIEW* — Detection without alerting is forensics, not control. - **AUD-007** — WHEN a user requests their access log, THE platform SHALL provide a human-readable record of every access to their data within the retention period. *(V1 · M · T)* ↳ *BRIEF/P6* — 'Users can request their own access log.' - **AUD-008** — THE audit service SHALL remain available and writable as a precondition of any access to user data. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — The hard consequence of P6: if audit is a precondition, audit availability gates the product. - **AUD-011** — IF the audit service is unavailable, THEN THE platform SHALL deny all access to user data. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — Split from AUD-008 at v0.5 for atomicity. Fail closed. - **AUD-009** — THE audit log SHALL retain entries for at least the statutory retention period applicable to safeguarding records. *(V1 · M · I)* **[OD-05]** ↳ *REVIEW* — Safeguarding retention norms exceed ordinary data retention. See OD-05. - **AUD-010** — THE audit service SHALL store in each entry only the fields enumerated in AUD-002. *(V1 · S · A)* ↳ *BRIEF/P6* — 'Audit logging that you'd be willing to publish' — only possible if entries hold no conversational content. --- ## 15. Internal access control (ACC) - **ACC-001** — THE platform SHALL expose to founder and executive roles only aggregate metrics containing no conversational content. *(V1 · M · A)* — SAFETY_LOCKED ↳ *BRIEF/HC* — 'Zero access to user conversations. Dashboards only. Including me.' - **ACC-002** — THE platform SHALL enforce the absence of founder conversational access architecturally rather than by policy. *(V1 · M · A)* — SAFETY_LOCKED ↳ *BRIEF/HC* — 'Architecturally prevented.' Policy is not architecture. - **ACC-003** — THE platform SHALL provide engineers with no standing access to production user data. *(V1 · M · A)* — SAFETY_LOCKED ↳ *BRIEF/HC* — 'Break-glass only.' - **ACC-004** — WHEN an engineer requires production data access, THE platform SHALL require a recorded justification, a second approver, and a time-boxed grant. *(V1 · M · T)* ↳ *BRIEF/HC* — 'Justified, time-boxed, second-approver.' - **ACC-005** — WHEN a break-glass grant expires, THE platform SHALL revoke the access automatically. *(V1 · M · T)* ↳ *BRIEF/HC* — 'Time-boxed' means expiry happens without anyone remembering. - **ACC-006** — WHEN break-glass access to a person's data has occurred, THE platform SHALL disclose that access to that person within the disclosure period recorded in the internal access policy. *(V1 · M · T)* — SAFETY_LOCKED **[OD-09]** ↳ *BRIEF/HC* — 'User-disclosed post-hoc.' - **ACC-007** — THE platform SHALL provide a synthetic dataset that reproduces every entity type, relationship type, and permission edge case present in the production schema. *(V1 · M · D)* ↳ *BRIEF/HC* — 'Synthetic data for routine debugging.' - **ACC-008** — THE platform SHALL prohibit the copying of production user data into any non-production environment. *(V1 · M · A)* — SAFETY_LOCKED ↳ *DERIVED* — Synthetic-for-debugging is void if production data can be copied down. - **ACC-009** — THE platform SHALL expose to support agent roles only account, billing, and device metadata. *(V1 · M · T)* ↳ *BRIEF/P6* — 'By support' is listed as an access category; the brief does not bound it. - **ACC-010** — THE platform SHALL log every break-glass request, approval, denial, and use to the audit service. *(V1 · M · T)* ↳ *BRIEF/P6* — Break-glass is the highest-privilege access and needs the fullest record. --- ## 16. Data governance (DAT) - **DAT-001** — THE platform SHALL process production personal data only in the United Kingdom or in a jurisdiction covered by UK adequacy. *(V1 · M · A)* — SAFETY_LOCKED ↳ *BRIEF/HC* — 'Production data processed only in UK or EU-adequate jurisdictions.' - **DAT-002** — THE platform SHALL maintain a register of every sub-processor with data residency, retention terms, training-data terms, and DPA status. *(V1 · M · R)* ↳ *BRIEF/P5* — 'Vendor-by-vendor due diligence on data residency, training-data use, and DPA terms.' - **DAT-003** — THE platform SHALL engage a model, STT, or TTS vendor only under contractual terms prohibiting training on user data. *(V1 · M · R)* — SAFETY_LOCKED ↳ *BRIEF/HC* — 'No training on user data.' - **DAT-004** — THE platform SHALL default training-on-user-data to off for every user. *(V1 · M · I)* — SAFETY_LOCKED ↳ *BRIEF/HC* — 'Default off.' - **DAT-005** — THE platform SHALL exclude the data of users under 18 and of vulnerable adults from every model training set, irrespective of any consent given. *(V1 · M · A)* — SAFETY_LOCKED ↳ *BRIEF/HC* — 'Children's and vulnerable adult data: never, regardless of consent.' - **DAT-006.1** — WHERE adult opt-in to training is offered, THE consent service SHALL require capacity-assessed consent before opt-in takes effect. *(V2 · C · T)* ↳ *BRIEF/HC* — 'Adult opt-in only with capacity-assessed consent.' - **DAT-006.2** — WHERE adult opt-in to training is offered, THE consent service SHALL allow the user to reverse that opt-in at any time. *(V2 · C · T)* ↳ *LAW/UK GDPR Art 7(3)* — Opt-in that cannot be reversed is not consent. - **DAT-007.1** — THE platform SHALL synthesise persona speech only from licensed voice models listed in the sub-processor register. *(V1 · M · A)* — SAFETY_LOCKED ↳ *BRIEF/HC* — 'Synthetic voices only, from licensed providers.' - **DAT-007.2** — THE platform SHALL exclude all user audio from every voice model training, adaptation, and enrolment process. *(V1 · M · A)* — SAFETY_LOCKED ↳ *BRIEF/HC* — 'No-clone-from-user-audio terms.' - **DAT-008** — THE platform SHALL use only synthetic persona voices licensed under terms prohibiting cloning from user audio. *(V1 · M · R)* — SAFETY_LOCKED ↳ *BRIEF/HC* — 'Of users, of deceased users, of public figures, ever.' - **DAT-009.1** — THE platform SHALL retain call audio for no longer than the short-retention period recorded in the retention schedule. *(V1 · M · T)* **[OD-05]** ↳ *BRIEF/ARCH* — 'Audio (short retain).' - **DAT-009.2** — WHEN the short-retention period elapses, THE platform SHALL delete the call audio without manual intervention. *(V1 · M · T)* **[OD-05]** ↳ *REVIEW* — Retention enforced by infrastructure, not by a job somebody has to remember to run. - **DAT-010.1** — THE platform SHALL retain transcripts for no longer than the long-retention period recorded in the retention schedule. *(V1 · M · T)* **[OD-05]** ↳ *BRIEF/ARCH* — 'Transcripts (long retain).' - **DAT-010.2** — WHEN the long-retention period elapses, THE platform SHALL delete the transcript without manual intervention. *(V1 · M · T)* **[OD-05]** ↳ *REVIEW* — Same reasoning as DAT-009.2. - **DAT-011** — THE platform SHALL encrypt all personal data at rest and in transit. *(V1 · M · T)* ↳ *BRIEF/ARCH* — 'UK-resident, encrypted, audited.' - **DAT-012.1** — WHEN a data subject requests erasure, THE platform SHALL delete their personal data within one calendar month, other than records retained under a legal obligation. *(V1 · M · T)* ↳ *LAW/UK GDPR Art 17* — Erasure within one month. - **DAT-012.2** — WHEN a record is retained after an erasure request, THE platform SHALL record the legal obligation relied upon. *(V1 · M · T)* ↳ *LAW/UK GDPR Art 17(3)* — Anything retained needs a recorded exemption, not an assumption. - **DAT-013** — WHEN a data subject requests access, THE platform SHALL provide their data in a portable format within one calendar month. *(V1 · M · T)* ↳ *LAW/UK GDPR Art 15+20* — Access and portability. - **DAT-014.1** — IF a personal data breach occurs, THEN THE platform SHALL produce the ICO notification record within 72 hours of detection. *(V1 · M · R)* ↳ *LAW/UK GDPR Art 33* — 72 hours from awareness. - **DAT-014.2** — THE platform SHALL retain, for every processing operation, the evidence items enumerated in the breach evidence schedule. *(V1 · M · R)* ↳ *REVIEW* — The 72-hour clock is unmeetable if the evidence has to be assembled from scratch. - **DAT-015** — THE platform SHALL record a lawful basis under UK GDPR Article 6 and a condition under Article 9 for every processing purpose. *(V1 · M · R)* **[OD-01]** ↳ *LAW/UK GDPR Art 6+9* — The brief never states a lawful basis. See OD-01. - **DAT-016** — THE platform SHALL provide the account holder a machine-readable export of household data within their permission scope. *(V2 · S · T)* ↳ *REVIEW* — Household export is distinct from a statutory subject access request. - **DAT-017** — THE platform SHALL provide each data subject an export of their own data independently of the account holder. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — The subject's export must not route through the account holder, who may be the problem. - **DAT-018.1** — WHEN a legal hold is applied, THE platform SHALL suspend automatic deletion for the identified records. *(V1 · M · T)* ↳ *REVIEW* — Litigation hold is absent from the brief and conflicts directly with automatic deletion. - **DAT-018.2** — WHEN a legal hold is applied, THE platform SHALL record the hold, its scope, and the person who applied it. *(V1 · M · T)* ↳ *REVIEW* — An unrecorded hold is indistinguishable from a retention failure. - **DAT-019** — WHILE a legal hold is in force, THE platform SHALL record every access to the held records in the audit log. *(V1 · M · T)* ↳ *REVIEW* — Held records are the ones most likely to be looked at improperly. --- ## 17. Billing, tiers and entitlement (BIL) - **BIL-001** — THE billing service SHALL support a 14-day trial followed by a recurring monthly subscription billed to the carer. *(V1 · M · T)* ↳ *BRIEF/Q2* — '14-day trial, then tiered monthly subscription billed to the carer.' - **BIL-002** — THE billing service SHALL support at least four distinct tiers in its data model regardless of how many are offered commercially. *(V1 · M · I)* ↳ *BRIEF/Q2* — 'Support up to 4 tiers from V1 even if we ship with 2.' - **BIL-003** — THE feature gating layer SHALL resolve entitlements at request time, as constrained by DC-02. *(V1 · M · I)* ↳ *BRIEF/Q2* — 'A billing-aware feature gating layer separate from the application logic.' - **BIL-004** — THE platform SHALL apply every safety, safeguarding, consent, and audit behaviour identically across all billing tiers. *(V1 · M · A)* — SAFETY_LOCKED ↳ *REVIEW* — The brief does not say safety is never tier-gated. It has to be said out loud. - **BIL-005** — WHEN a subscription lapses, THE platform SHALL continue to honour safeguarding obligations for any open flagged event. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — An open safeguarding case does not close because a card expired. - **BIL-006** — WHEN a trial ends without conversion, THE platform SHALL notify all affected household members before service to the elder user changes. *(V1 · M · T)* ↳ *REVIEW* — Trial expiry silently ending calls to an elder is a safeguarding event, not a billing event. - **BIL-007** — THE billing service SHALL support tier change mid-cycle with proration. *(V2 · S · T)* ↳ *BRIEF/Q2* — Tier movement is implied by a tiered model. - **BIL-008** — THE billing service SHALL record every entitlement decision for reconciliation against usage. *(V1 · S · T)* ↳ *BRIEF/Q2* — 'Unit-economics visibility' requires reconciling entitlement against usage. --- ## 18. Usage telemetry, cost and abuse (USG) - **USG-001** — THE usage telemetry service SHALL record, per family and per person, call minutes, LLM token spend, STT and TTS usage, storage volume, and safeguarding event count. *(V1 · M · T)* ↳ *BRIEF/Q2* — 'Call minutes, token spend, storage size, safeguarding events.' - **USG-002** — THE usage telemetry service SHALL compute per-family unit economics on a daily basis. *(V1 · M · T)* ↳ *BRIEF/Q2* — 'Unit-economics visibility.' - **USG-003** — THE platform SHALL enforce a per-account cap on call minutes per day and per month. *(V1 · M · T)* ↳ *BRIEF/P9* — 'Per-account caps.' - **USG-004** — WHEN an account approaches its cap, THE platform SHALL notify the carer before the cap is reached. *(V1 · M · T)* ↳ *REVIEW* — A cap that arrives without warning looks like a fault to the carer. - **USG-005.1** — IF an account exceeds its cap, THEN THE platform SHALL suspend proactive outbound calling for that account. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/P9* — 'A user gaming the line.' - **USG-005.2** — WHILE an account is over its cap, THE platform SHALL continue to accept inbound calls from the elder user. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — Cost control must never stop an elder reaching the service. Cf. SFB-013. - **USG-006.1** — THE platform SHALL detect anomalous call duration, call frequency, and destination patterns. *(V1 · M · T)* ↳ *BRIEF/P9* — 'Anomaly detection on call duration.' - **USG-006.2** — WHEN an anomalous pattern is detected, THE platform SHALL raise an alert within one hour. *(V1 · M · T)* ↳ *BRIEF/P9* — 'Can hit the company in days' — so detection has to be same-day. - **USG-007** — THE platform SHALL provide a kill-switch that halts all outbound calling platform-wide within 60 seconds of activation. *(V1 · M · D)* ↳ *BRIEF/P9* — 'A hard kill-switch.' - **USG-008** — THE platform SHALL provide a kill-switch scoped to a single account. *(V1 · M · T)* ↳ *REVIEW* — A platform-wide switch is too blunt for a single runaway account. - **USG-009.1** — IF telephony spend exceeds the configured daily threshold, THEN THE platform SHALL alert the on-call engineer. *(V1 · M · T)* ↳ *BRIEF/P9* — '~£15/month in telephony alone' per heavy user makes spend the leading indicator. - **USG-009.2** — IF telephony spend exceeds the configured daily threshold, THEN THE platform SHALL apply automatic rate limiting to outbound calling. *(V1 · M · T)* ↳ *BRIEF/P9* — Alerting without throttling still lets the damage complete. - **USG-010** — THE platform SHALL validate every outbound destination number against an allow-list of permitted number ranges. *(V1 · M · T)* ↳ *REVIEW* — Destination allow-listing is the cheapest control against toll fraud, absent from the brief. - **USG-011** — THE platform SHALL place calls to premium-rate and international destinations only where that destination class is explicitly enabled for the account. *(V1 · M · T)* ↳ *REVIEW* — Premium-rate and international are where telephony abuse monetises. --- ## 19. Graceful degradation and resilience (DEG) - **DEG-001** — THE degradation controller SHALL monitor the health of the telephony provider, STT service, LLM provider, TTS service, safety classifier, knowledge service, and family graph service. *(V1 · M · T)* ↳ *BRIEF/P10* — 'When the LLM provider has an outage? When STT is down?' - **DEG-002** — IF the primary LLM provider is unavailable, THEN THE Lide orchestrator SHALL fail over to the secondary provider on a different vendor. *(V1 · M · T)* ↳ *BRIEF/ARCH* — 'Secondary on a different vendor for failover.' - **DEG-003.1** — IF no LLM provider is available, THEN THE degradation controller SHALL play the pre-written apology and callback offer. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/P10* — 'Omi politely says she's not at her best today, can she call back?' - **DEG-003.2** — WHEN the pre-written apology has played, THE degradation controller SHALL end the call. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/P10* — Graceful ending is part of the graceful failure. - **DEG-004** — THE degradation controller SHALL use only pre-written, human-authored, human-reviewed responses in any failure path. *(V1 · M · I)* — SAFETY_LOCKED ↳ *BRIEF/HC* — 'Every degraded path has a pre-written, non-AI fallback.' - **DEG-005** — WHILE the platform is in a degraded state, THE degradation controller SHALL emit only pre-written responses. *(V1 · M · A)* — SAFETY_LOCKED ↳ *BRIEF/HC* — 'Users never hear hallucinated AI in a failure state.' - **DEG-006** — THE degradation responses SHALL remain playable during a total outage of the Lide orchestrator, by the means specified in DC-06. *(V1 · M · T)* ↳ *BRIEF/P10* — 'Pre-written, on-device or edge-cached.' - **DEG-007** — IF the primary STT service is unavailable, THEN THE voice gateway SHALL fail over to the secondary STT provider. *(V1 · M · T)* ↳ *BRIEF/P10* — 'When STT is down.' - **DEG-013** — IF no STT service is available, THEN THE voice gateway SHALL enter degraded mode. *(V1 · M · T)* ↳ *REVIEW v0.5* — Split from DEG-007 for atomicity. - **DEG-014** — IF a scheduled call to a line recorded as power-dependent fails to connect, THEN THE platform SHALL include that dependency in the non-contact notification to the carer. *(V1 · M · T)* ↳ *REVIEW v0.6* — Distinguishes 'did not answer' from 'could not be reached' — different messages, different carer actions. - **DEG-015** — THE platform SHALL record premises power dependency as a known availability limitation outside its control in the service description. *(V1 · M · I)* ↳ *REVIEW v0.6* — Post-2027 every landline is VoIP and depends on mains power at the premises. > **Why DEG-014 exists.** "Your mother did not answer" and "your mother's line was unreachable, and her line stops working in a power cut" are different messages that produce different actions. The first invites worry and then inaction, because the carer has no information to act on. The second tells a carer in a storm-affected area to check on a relative, or tells a carer in an unaffected area to relax. Withholding the distinction is not neutral — a non-contact event is the moment a carer most needs to know which kind of silence they are looking at. - **DEG-008** — THE platform SHALL maintain two independent telephony providers with the ability to shift traffic between them. *(V1 · M · T)* ↳ *BRIEF/ARCH* — 'Aim for two providers from day one — telephony is the single biggest reliability risk.' - **DEG-009** — WHEN a call ends in a degraded state, THE platform SHALL notify the carer that the scheduled contact did not complete normally. *(V1 · M · T)* ↳ *REVIEW* — A missed call the carer never hears about defeats the purpose of the service. - **DEG-010** — WHEN the platform enters a degraded state affecting safeguarding coverage, THE platform SHALL alert the clinical lead. *(V1 · M · T)* ↳ *REVIEW* — Degradation that removes safeguarding coverage is a clinical event, not an ops one. - **DEG-011** — THE platform SHALL meet a monthly availability target for the elder phone line of at least 99.9%. *(V1 · S · A)* **[OD-13]** ↳ *REVIEW* — The brief sets no availability target. See OD-13. - **DEG-012** — THE platform SHALL exercise every degradation path in a scheduled failure drill at least quarterly. *(V1 · M · D)* ↳ *REVIEW* — 'Most AI startups skip this' — the brief's words. Untested fallbacks are the way it gets skipped anyway. --- ## 20. Evaluation and release gating (EVL) - **EVL-001** — THE eval harness SHALL execute as a gate in the continuous integration pipeline. *(V1 · M · I)* — SAFETY_LOCKED ↳ *BRIEF/P8* — 'Evals are part of CI, not a separate quarterly exercise.' - **EVL-002** — WHEN a prompt, model version, retrieval index, safety classifier, or persona configuration changes, THE platform SHALL run the full regression suite before the change reaches production. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/P8* — 'Every prompt change, every model upgrade, every retrieval index rebuild.' - **EVL-003** — THE regression suite SHALL cover factual accuracy, safety classification recall, safety classification precision, refusal calibration, tone consistency, persona separation, latency, and grounding citation compliance. *(V1 · M · T)* ↳ *BRIEF/P8* — 'Factual accuracy, safety classification recall, refusal calibration, tone consistency, and persona separation.' - **EVL-004** — IF any safety-category eval falls below its recorded baseline, THEN THE pipeline SHALL block the release. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/P8* — 'Eval-driven development is non-optional for vulnerable-user products.' - **EVL-005** — THE eval harness SHALL use a versioned, held-out dataset that is not used for prompt or model tuning. *(V1 · M · I)* ↳ *REVIEW* — An eval set used for tuning stops measuring anything. - **EVL-006** — THE eval harness SHALL support synthetic conversational corpora weighted toward known failure classes. *(V1 · M · T)* ↳ *REVIEW* — Uniform sampling under-tests the failures that matter. - **EVL-007.1** — THE platform SHALL maintain a documented failure taxonomy. *(V1 · M · I)* ↳ *REVIEW* — A taxonomy is what turns 'it went wrong' into a countable class. - **EVL-007.2** — THE eval harness SHALL map every eval case to a class in the failure taxonomy. *(V1 · M · I)* ↳ *REVIEW* — Unmapped eval cases cannot be reported as coverage. - **EVL-008** — THE eval harness SHALL detect persona leakage, defined as one persona producing content characteristic of another persona's audience. *(V1 · M · T)* ↳ *BRIEF/P8* — 'Persona separation.' - **EVL-009** — THE eval harness SHALL detect language reversion, defined as the persona reverting to a non-configured language after the opening turns. *(V2 · M · T)* ↳ *BRIEF/Q1* — Language is user-configurable, so reversion is a configuration failure. - **EVL-010** — THE eval harness SHALL detect non-terminating clarification loops. *(V1 · M · T)* ↳ *REVIEW* — A clarification loop is the specific failure mode that most frustrates elderly users. - **EVL-011.1** — THE platform SHALL retain LLM traces for every production conversation. *(V1 · M · T)* ↳ *BRIEF/ARCH* — 'LangFuse or Braintrust for LLM traces.' - **EVL-011.2** — THE platform SHALL make production traces available to the eval harness in de-identified form. *(V1 · M · T)* ↳ *BRIEF/HC* — De-identification is what makes traces usable without breaching the access constraints. - **EVL-012** — THE platform SHALL run a scheduled production sampling eval independent of the release gate. *(V1 · S · T)* ↳ *REVIEW* — A release gate only sees what it was asked about. Production sampling sees the rest. - **EVL-013** — THE eval harness SHALL record calibration curves for any confidence signal used to gate a behaviour. *(V1 · M · T)* ↳ *REVIEW* — Supports VOI-019 — a confidence gate without a calibration curve is decoration. - **EVL-014** — THE eval harness SHALL use production user conversations as eval cases only where a lawful basis is recorded and the content has been de-identified. *(V1 · M · R)* ↳ *LAW/UK GDPR Art 6* — Reusing real conversations as test data is a separate processing purpose. - **EVL-015** — THE eval harness SHALL measure digest omission rate against a labelled corpus of calls containing safety-relevant events. *(V1 · M · T)* ↳ *REVIEW* — Digest omission is the product's characteristic failure and nothing else measures it. - **EVL-016** — IF digest omission rate for safety-relevant events falls below the recorded floor, THEN THE pipeline SHALL block the release. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — Measuring omission without gating on it changes nothing. - **EVL-017** — THE eval harness SHALL measure the rate of digest assertions unsupported by a cited source turn. *(V1 · M · T)* ↳ *REVIEW* — Fabrication and omission are different failures needing different metrics. - **EVL-018** — THE eval harness SHALL include an adversarial input suite covering every attack class enumerated in §33 (AIS). *(V1 · M · T)* ↳ *REVIEW* — Prompt injection over voice is absent from the brief entirely. - **EVL-019** — THE eval harness SHALL run the full safety regression suite separately for each supported language. *(V3 · M · T)* ↳ *REVIEW* — Supports LNG-004 — a language is only supported once its safety layer is measured. --- ## 21. Observability and operations (OBS) - **OBS-001** — THE platform SHALL emit distributed traces spanning voice gateway, orchestrator, model calls, and data access for every conversation. *(V1 · M · T)* ↳ *BRIEF/ARCH* — 'Datadog or Grafana stack for ops.' - **OBS-002** — THE platform SHALL alert on breach of the latency budget at the 95th percentile over a rolling window. *(V1 · M · T)* ↳ *BRIEF/P1* — The latency requirement needs an alert or it is aspirational. - **OBS-003** — THE platform SHALL alert on safeguarding acknowledgement SLA breach. *(V1 · M · T)* ↳ *BRIEF/P7* — The safeguarding SLA needs an alert for the same reason. - **OBS-004** — THE platform SHALL alert on audit chain verification failure. *(V1 · M · T)* ↳ *BRIEF/P6* — Chain verification failure is the highest-severity signal in the system. - **OBS-005** — THE platform SHALL alert on anomalous spend. *(V1 · M · T)* ↳ *BRIEF/P9* — 'Can hit the company in days.' - **OBS-006** — THE observability stack SHALL store only the metadata fields enumerated in the telemetry schema. *(V1 · M · A)* — SAFETY_LOCKED ↳ *BRIEF/HC* — Traces are an access path. The zero-access constraint applies to them too. - **OBS-007** — THE platform SHALL maintain an on-call rota for engineering with the acknowledgement target recorded in the on-call policy. *(V1 · M · I)* ↳ *BRIEF/P7* — On-call is named for safeguarding; engineering needs the same. - **OBS-008** — THE platform SHALL record a post-incident review for every incident affecting a user conversation. *(V1 · M · R)* ↳ *REVIEW* — Post-incident review is how a taxonomy stays current. --- ## 22. Security and assurance (SEC) - **SEC-001** — THE platform SHALL be provisioned entirely through version-controlled infrastructure-as-code. *(V1 · M · I)* ↳ *BRIEF/ARCH* — 'Terraform from day one.' - **SEC-002** — THE platform SHALL host production data in a UK region only. *(V1 · M · A)* ↳ *BRIEF/ARCH* — 'AWS or GCP, UK region only for production data.' - **SEC-003** — THE platform SHALL achieve Cyber Essentials Plus certification before public launch. *(V1 · M · R)* ↳ *BRIEF/ARCH* — 'Cyber Essentials Plus by launch.' - **SEC-004** — THE platform SHALL target ISO 27001 certification by end of year two. *(V2 · S · R)* ↳ *BRIEF/ARCH* — 'ISO 27001 target year 2.' - **SEC-005** — THE platform SHALL enforce multi-factor authentication for all internal access to production systems. *(V1 · M · T)* ↳ *REVIEW* — Baseline control, absent from the brief. - **SEC-006** — THE platform SHALL scan dependencies for known vulnerabilities on every build. *(V1 · M · T)* ↳ *REVIEW* — Baseline control, absent from the brief. - **SEC-007** — THE platform SHALL commission an independent penetration test before public launch and annually thereafter. *(V1 · M · R)* ↳ *REVIEW* — Cyber Essentials Plus is not a penetration test and is often mistaken for one. - **SEC-008.1** — THE platform SHALL manage every application secret in Infisical. *(V1 · M · T)* ↳ *USER* — Infisical named by Dave. Replaces a generic managed secret store. - **SEC-008.2** — IF a secret is committed to source control, THEN THE build SHALL fail. *(V1 · M · T)* ↳ *USER* — Committed secrets are the most common real-world breach path. - **SEC-009** — THE platform SHALL define and test a documented incident response plan covering data breach and safeguarding incident. *(V1 · M · R)* ↳ *LAW/UK GDPR Art 33* — The 72-hour clock assumes a plan already exists. - **SEC-010** — WHERE an NHS data flow exists, THE platform SHALL complete the Data Security and Protection Toolkit. *(V2 · C · R)* **[OD-10]** ↳ *REVIEW* — Only bites if an NHS data flow appears. See OD-10. - **SEC-011** — THE platform SHALL maintain, for each critical vendor, a documented exit plan stating data return format and timescale. *(V1 · M · R)* ↳ *REVIEW* — Vendor exit is absent from the brief despite P5's sub-processor concern. - **SEC-012** — THE platform SHALL substitute the primary LLM, STT, or TTS vendor without change to the family graph, consent, or audit stores. *(V1 · M · A)* ↳ *BRIEF/P5* — Substitutability is what makes the PoC vendor swaps safe rather than throwaway. - **SEC-013** — WHEN a vendor contract ends, THE platform SHALL obtain written confirmation that the vendor has deleted all user data. *(V1 · M · R)* ↳ *BRIEF/P5* — 'Vendor-by-vendor due diligence' has to extend past contract end. ### 22.1 Secrets management - **SEC-014** — THE platform SHALL authenticate every service to Infisical using a machine identity scoped to a single environment. *(V1 · M · T)* ↳ *USER* — Machine identities scoped per environment — Infisical's model, adopted as requirement. - **SEC-015** — THE platform SHALL inject secrets into runtime memory only, excluding secrets from container images, source control, and CI logs. *(V1 · M · T)* — SAFETY_LOCKED ↳ *USER* — Runtime-only injection is the property that makes a secrets platform worth having. - **SEC-016** — THE platform SHALL isolate secrets per environment such that a non-production identity cannot read a production secret. *(V1 · M · T)* — SAFETY_LOCKED ↳ *USER* — Environment isolation prevents a dev credential reading production. - **SEC-017** — THE platform SHALL require break-glass approval under ACC-004 before granting a person access to a production secret. *(V1 · M · T)* — SAFETY_LOCKED ↳ *DERIVED* — Ties secret access to the same break-glass discipline as data access. - **SEC-018** — THE platform SHALL rotate every application secret at the interval recorded in the secrets policy. *(V1 · M · T)* **[OD-27]** ↳ *USER* — Rotation interval deferred to OD-27. - **SEC-019** — WHEN a person with production secret access leaves or changes role, THE platform SHALL revoke that access within 24 hours. *(V1 · M · T)* ↳ *USER* — Leaver revocation is the control most often skipped in small teams. - **SEC-020** — WHEN a person with production secret access leaves, THE platform SHALL rotate every secret that person was authorised to read within 7 days. *(V1 · M · T)* ↳ *USER* — Revocation without rotation leaves the leaver holding the secret. - **SEC-021** — THE platform SHALL run secret scanning on every commit and on every build. *(V1 · M · T)* ↳ *USER* — Scanning at commit and at build catches different mistakes. - **SEC-022** — IF a secret is exposed, THEN THE platform SHALL rotate that secret within 24 hours. *(V1 · M · T)* ↳ *USER* — Exposure without prompt rotation is an open door. - **SEC-023** — IF a secret is exposed, THEN THE platform SHALL record the exposure and the rotation in the audit log. *(V1 · M · T)* ↳ *BRIEF/P6* — Secret exposure is an access event and belongs in the audit record. - **SEC-024** — THE platform SHALL export the Infisical access log to the audit service. *(V1 · M · T)* ↳ *BRIEF/P6* — 'Every access to user data' — the secrets platform is an access path to all of it. - **SEC-025** — THE platform SHALL host the Infisical instance holding production secrets in the United Kingdom. *(V1 · M · A)* **[OD-27]** ↳ *BRIEF/HC* — Residency applies to secrets as much as to conversations. See OD-27. - **SEC-026** — THE platform SHALL maintain a documented recovery procedure for loss of the secrets service. *(V1 · M · R)* ↳ *REVIEW* — Loss of the secrets service is a total outage with no obvious recovery path. - **SEC-027** — IF the secrets service is unavailable at deploy time, THEN THE pipeline SHALL fail the deployment. *(V1 · M · T)* — SAFETY_LOCKED ↳ *USER* — Fail closed. The env-var fallback reintroduces exactly what SEC-015 removes. - **SEC-028** — THE platform SHALL exclude secrets from every trace, log, and metric. *(V1 · M · A)* — SAFETY_LOCKED ↳ *BRIEF/HC* — Same reasoning as OBS-006, applied to secrets. > **SEC-027 note.** Failing closed matters more than it looks. The tempting fallback — drop to environment variables when the secrets service is unreachable — reintroduces exactly the plaintext-at-rest problem SEC-015 exists to remove, and it does so at the moment nobody is watching. --- ## 23. Children's Code (AAD) > These requirements are dormant until a single under-18 user exists in the system, at which point they become load-bearing immediately. They are specified in V1 because the family graph and consent model must be able to express them. - **AAD-001** — WHILE any user under 18 is present in the system, THE platform SHALL apply the UK Age Appropriate Design Code to all services likely to be accessed by that user. *(V4 · M · R)* ↳ *BRIEF/S3* — 'AADC compliance from day one if a single under-18 user is in the system.' - **AAD-002** — THE platform SHALL apply the highest privacy settings by default to any account belonging to a user under 18. *(V4 · M · T)* ↳ *LAW/AADC std 1-2* — High privacy by default. - **AAD-003** — THE platform SHALL establish age with a level of certainty proportionate to the risks arising from the processing. *(V4 · M · T)* **[OD-14]** ↳ *LAW/AADC std 3* — Age assurance proportionate to risk. Threshold deferred to OD-14. - **AAD-004** — THE platform SHALL NOT use nudge techniques to encourage a user under 18 to weaken privacy settings or provide additional data. *(V4 · M · I)* — SAFETY_LOCKED ↳ *LAW/AADC std 13* — Nudge techniques. Retained in SHALL NOT form to preserve the mapping — see §3.6. - **AAD-005** — THE platform SHALL NOT use the personal data of a user under 18 in a manner detrimental to their wellbeing. *(V4 · M · R)* ↳ *LAW/AADC std 1* — Best interests of the child. Same reasoning as AAD-004. - **AAD-006** — WHILE parent-shadow mode is active, THE Vee app SHALL make visible to the young user what the shadowing adult can see. *(V4 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/S3* — 'Parent-shadow mode' plus AADC transparency: shadowing the child must be visible to the child. - **AAD-007** — THE platform SHALL complete a DPIA specific to child users before any under-18 account is created. *(V4 · M · R)* ↳ *BRIEF/HC* — 'DPIA mandatory.' - **AAD-008** — THE platform SHALL provide privacy information to users under 18 at the reading age recorded in the age-band table for that user's band. *(V4 · M · I)* ↳ *LAW/AADC std 4* — Transparency in age-appropriate language. - **AAD-009.1** — THE platform SHALL set geolocation to off by default for every user under 18. *(V4 · M · T)* ↳ *LAW/AADC std 10* — Geolocation off by default. - **AAD-009.2** — WHILE location sharing is active for a user under 18, THE Vee app SHALL display a persistent location-sharing indicator. *(V4 · M · T)* ↳ *LAW/AADC std 10* — Active location sharing must be obvious to the child. --- ## 24. Account lifecycle and support (SUP) - **SUP-001** — THE platform SHALL support transfer of the account holder role between people in the household with confirmation from both. *(V2 · S · T)* ↳ *REVIEW* — Account holders die, divorce and fall out. The brief has no transfer path. - **SUP-002.1** — WHEN an elder user is recorded as deceased, THE platform SHALL suspend all calling to that user immediately. *(V1 · M · T)* **[OD-15]** ↳ *REVIEW* — Calling a deceased person's line is the single worst failure this product can produce. - **SUP-002.2** — WHEN an elder user is recorded as deceased, THE platform SHALL retain that user's data under the bereavement retention policy. *(V1 · M · T)* **[OD-15]** ↳ *REVIEW* — Bereavement retention differs from ordinary closure. See OD-15. - **SUP-003** — IF a household is in dispute, THEN THE platform SHALL preserve the data subject's control over their own data ahead of the account holder's preferences. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/U3* — 'Ex-spouses, estranged siblings.' In a dispute, the subject outranks the payer. - **SUP-004** — THE platform SHALL provide a non-app route for an elder user to raise a complaint or request deletion. *(V1 · M · D)* ↳ *BRIEF/S1* — The elder has no app, so every route available to them must work by phone or post. - **SUP-005** — THE platform SHALL publish a plain-English summary of what the service does with data, at a reading age no higher than 11. *(V1 · M · I)* ↳ *LAW/UK GDPR Art 12* — Concise, transparent, plain language. --- ## 25. Transparency to the subject (TRN) > This section exists because v0.2 gave Vee users visibility of what was shared about them (SUR-302, SUR-304) and gave elder users nothing equivalent. The elder user is the person who did not buy the product, may not have been present when it was configured, and has the most to lose from an unseen sharing relationship. Parity is a floor, not a feature. - **TRN-001** — THE platform SHALL make available to every data subject the categories of information shared about them and the named people who receive it. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — The gap that started this section: surface 3 gets transparency, surface 1 got nothing. - **TRN-002** — WHEN an elder user asks what the family can see, THE Omi persona SHALL state the categories of information shared and the named people who receive them. *(V1 · M · T)* ↳ *REVIEW* — Parity with SUR-302, delivered by voice because the elder has no screen. - **TRN-003** — THE Omi persona SHALL provide, on request, a spoken equivalent of the 30-day sharing log available to Vee users under SUR-304. *(V1 · M · T)* ↳ *REVIEW* — Parity with SUR-304. - **TRN-004** — WHEN a person is granted access to an elder user's data, THE platform SHALL inform that elder user within 24 hours. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — A new person gaining access is the event most worth knowing about. - **TRN-005** — WHEN a permission scope over an elder user's data is widened, THE platform SHALL inform that elder user within 24 hours. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — Scope creep inside an existing relationship is quieter and just as consequential. - **TRN-006** — WHEN an elder user asks by voice that a named person's access be removed, THE Lide orchestrator SHALL route that request under FGR-011. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — Rights the elder cannot exercise by voice are rights they do not have. - **TRN-007** — WHEN an access removal requested by an elder user takes effect, THE Omi persona SHALL confirm the change to that user on the next call. *(V1 · M · T)* ↳ *REVIEW* — An unconfirmed change leaves the person unsure whether they were heard. - **TRN-008** — WHEN an elder user asks what was in the most recent carer summary, THE Omi persona SHALL state its contents. *(V1 · M · T)* ↳ *REVIEW* — The digest is written about them; they should be able to hear it. - **TRN-009** — THE platform SHALL apply TRN-001 to TRN-008 irrespective of who holds the account or who pays for the service. *(V1 · M · A)* — SAFETY_LOCKED ↳ *REVIEW* — The payer must not be able to buy away the subject's visibility. - **TRN-010** — THE platform SHALL present the transparency statement in the consent conversation under CNS-005, before consent is captured. *(V1 · M · T)* ↳ *REVIEW* — Consent given without knowing the sharing arrangement is not informed. - **TRN-011** — THE platform SHALL disclose to the carer, before activation, that the service cannot reach the elder user during a power or broadband outage affecting a digital voice line. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW v0.6* — A carer who believes contact is daily may visit less. That inference must be correctly informed. > **Why TRN-011 is SAFETY_LOCKED.** A carer who believes the service will reach their parent every day may reasonably decide they need to visit less often. That inference is the product working as intended, and it is also the mechanism by which an undisclosed availability gap turns into a person alone in a house with no working telephone. The disclosure has to be made before activation, because after activation the carer has already changed their behaviour. --- ## 26. Summarisation and derived output (SUM) > The carer digest is the thing the carer actually buys. v0.2 specified the safety layer that reads the call and said nothing about the artefact produced from it. A digest that reports "Mum sounded fine" after a call in which she mentioned a fall is simultaneously a product failure, a safety failure, and the most likely source of a complaint. - **SUM-001** — THE summarisation service SHALL derive each carer digest solely from transcript content of calls with the elder user it concerns. *(V1 · M · T)* ↳ *REVIEW* — The digest is the product the carer buys and the brief specifies none of it. - **SUM-002** — THE summarisation service SHALL record, for every statement in a digest, the call and turn range it derives from. *(V1 · M · T)* ↳ *REVIEW* — Attribution is what makes a summary checkable. - **SUM-003** — THE summarisation service SHALL limit digest content to observed statements and events, excluding clinical interpretation. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — 'Mum seems more confused' is a clinical claim the system is not entitled to make. - **SUM-004** — THE summarisation service SHALL describe a topic that was not raised as not discussed, rather than as an absence of concern. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — The characteristic failure: silence reported as reassurance. - **SUM-005** — IF a call contains a turn classified at or above the review severity, THEN THE summarisation service SHALL place that event at the head of the digest. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — A safety event buried at position nine has been hidden, not reported. - **SUM-006** — IF a scheduled call did not take place or ended in a degraded state, THEN THE summarisation service SHALL state that fact in the digest. *(V1 · M · T)* ↳ *REVIEW* — A missing call must not read as a normal quiet day. - **SUM-007** — WHEN a digest asserts a fact about the elder user's health or wellbeing, THE summarisation service SHALL cite the originating utterance. *(V1 · M · T)* ↳ *REVIEW* — Health assertions carry the most weight and need the most grounding. - **SUM-008** — THE summarisation service SHALL apply the recipient's permission scope to every digest it generates. *(V1 · M · T)* ↳ *DERIVED* — The digest is a disclosure and takes the same permission check as any other. - **SUM-009** — WHERE a digest is delivered to more than one person, THE summarisation service SHALL generate a separate digest per permission scope. *(V1 · M · T)* ↳ *DERIVED* — Different scopes cannot share one artefact without leaking. - **SUM-010** — THE summarisation service SHALL make the cited source turns available to the recipient within their permission scope. *(V1 · M · T)* ↳ *REVIEW* — A citation the recipient cannot follow is decoration. - **SUM-011** — THE summarisation service SHALL record the model, prompt version, and source transcript version used for every digest. *(V1 · M · T)* ↳ *BRIEF/P8* — A digest is model output and needs the same version pinning as any other. --- ## 27. Onboarding and activation (ONB) - **ONB-001** — THE onboarding service SHALL verify the carer's control of the contact number and email address before creating an elder record. *(V1 · M · T)* ↳ *REVIEW* — The brief starts at 'the carer onboards mum' and never verifies the carer. - **ONB-002** — WHEN a carer enters an elder telephone number, THE onboarding service SHALL require the carer to state their relationship to that person and the basis on which they are arranging the service. *(V1 · M · T)* ↳ *REVIEW* — A stated relationship is weak evidence, but it is evidence, and it creates accountability. - **ONB-003** — THE onboarding service SHALL record the declared relationship and basis in the family graph. *(V1 · M · T)* ↳ *REVIEW* — Recorded at onboarding, it becomes the audit trail for the consent decision. - **ONB-004** — THE onboarding service SHALL verify that the elder telephone number is reachable before the first scheduled call. *(V1 · M · T)* ↳ *REVIEW* — Calling an unverified number risks contacting a stranger. - **ONB-005.1** — IF an elder telephone number is already registered to another household, THEN THE onboarding service SHALL block activation. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — The estranged-relative control. Cheapest safeguarding control in the specification. - **ONB-005.2** — IF an elder telephone number is already registered to another household, THEN THE onboarding service SHALL raise a review task. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — A collision is a signal about a person, not a data-quality problem. - **ONB-006** — THE onboarding service SHALL provide the carer, before the first call is placed, a written statement of what the elder user will be told on that call. *(V1 · M · T)* ↳ *BRIEF/S2* — The carer must be able to predict what their parent will hear. - **ONB-007** — THE onboarding service SHALL complete activation only after the consent conversation under CNS-005 has succeeded. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/P4* — Activation before consent would make the consent decorative. - **ONB-008.1** — IF activation does not complete within the configured window, THEN THE onboarding service SHALL notify the carer. *(V1 · M · T)* ↳ *REVIEW* — A stalled activation leaves an elder record with no consent and no purpose. - **ONB-008.2** — WHEN the pending-record retention window elapses without activation, THE onboarding service SHALL delete the pending elder record. *(V1 · M · T)* ↳ *LAW/UK GDPR Art 5(1)(e)* — Storage limitation applies to records that never became accounts. - **ONB-009** — WHEN a carer enters an elder telephone number, THE onboarding service SHALL ask whether that line is a digital voice service and whether battery backup is present at the premises. *(V1 · M · T)* ↳ *REVIEW v0.6* — Post-2027 every landline is VoIP; power dependency is knowable only by asking. - **ONB-010** — THE onboarding service SHALL record the answers to ONB-009 against the elder user in the family graph. *(V1 · M · T)* ↳ *REVIEW v0.6* — Captured once, used by DEG-014 every time a call fails. > **Why ONB-009 and ONB-010 exist.** The old copper PSTN powered a handset from the telephone exchange, so a landline worked in a power cut. Digital voice runs through a router that needs mains power at the premises, so it does not. Over two-thirds of UK landlines have already migrated and all of them will have migrated by 31 January 2027. This means the assumption underneath surface 1 — that the phone always works — quietly stops being true for every user, at a date already fixed, without anything changing at bience's end. Capturing it at onboarding costs one question and is the only point at which the carer is reliably paying attention. > **ONB-005 note.** This is the estranged-relative control. Without it, any person holding a telephone number can register another adult for a service that calls them, records them, and reports on them. It is the cheapest safeguarding control in the specification. --- ## 28. Human handoff (HND) - **HND-001** — THE platform SHALL provide every user a route to reach a human that does not pass through an AI persona. *(V1 · M · D)* ↳ *REVIEW* — The brief has no human route anywhere. For vulnerable users that is a serious omission. - **HND-002** — WHEN a user asks to speak to a person, THE Lide orchestrator SHALL provide the human contact route without requiring a reason. *(V1 · M · T)* ↳ *REVIEW* — Requiring a justification to reach a human is a dark pattern. - **HND-003.1** — THE platform SHALL publish a response time target for the human route. *(V1 · M · R)* ↳ *REVIEW* — An unpublished target is not a commitment. - **HND-003.2** — THE platform SHALL report performance against the published human-route response target each month. *(V1 · M · R)* ↳ *REVIEW* — A published target nobody measures is marketing. - **HND-004** — THE platform SHALL provide the elder user a telephone route to a human, as required by SUP-004. *(V1 · M · D)* ↳ *BRIEF/S1* — The elder has no app; the human route must be reachable by phone. - **HND-005** — WHEN a handoff to a human occurs, THE platform SHALL record it in the audit log. *(V1 · M · T)* ↳ *BRIEF/P6* — A handoff is an access event. --- ## 29. Language and localisation (LNG) - **LNG-001** — THE Lide orchestrator SHALL conduct each conversation in the language recorded in that user's configuration. *(V3 · M · T)* ↳ *BRIEF/Q1* — 'Language' is listed among per-family customisation. - **LNG-002** — WHILE a conversation is in progress, THE Lide orchestrator SHALL maintain the configured language on every turn. *(V3 · M · T)* ↳ *REVIEW* — Reverting to English after a few turns is a known voice-agent failure mode. - **LNG-003** — IF a user speaks in a language other than the configured language, THEN THE Lide orchestrator SHALL confirm the change before switching. *(V3 · M · T)* ↳ *REVIEW* — Silent language switching confuses users who did not ask for it. - **LNG-004** — THE safety classifier SHALL meet its recall floor in every supported language. *(V3 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — Safety parity across languages is not implied by conversational parity. - **LNG-005** — THE platform SHALL offer a language as supported only where the safety classifier, the knowledge service, and the consent script have been evaluated in that language. *(V3 · M · A)* — SAFETY_LOCKED **[OD-26]** ↳ *REVIEW* — Shipping a language the safety layer cannot read is unmonitored operation, not degraded service. - **LNG-006** — THE consent script SHALL be available in every supported language at the reading age required by CNS-012.1. *(V3 · M · I)* ↳ *BRIEF/P4* — Consent in a language the person does not read is not informed consent. > **LNG-005 note.** The failure mode this prevents is shipping a language the conversational layer handles and the safety layer does not. That is not a degraded experience; it is an unmonitored one. --- ## 30. Consumer contract and subscription (CMR) > Legal frame: Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013; Consumer Rights Act 2015; CAP Code; Equality Act 2010; Payment Services Regulations 2017. The DMCC Act 2024 subscription contracts regime is **not yet in force** — commencement is expected spring 2027 and awaits secondary legislation — so V1 is built on the CCRs, with DMCC readiness as a V2 design target. **[OD-21]** - **CMR-001** — THE platform SHALL provide the statutory cancellation right and cooling-off period required by the Consumer Contracts Regulations 2013. *(V1 · M · R)* ↳ *LAW/CCRs 2013* — Statutory cancellation and cooling-off. Absent from the brief entirely. - **CMR-002** — THE platform SHALL make cancellation available through the same surface used to subscribe, in no more steps than subscription required. *(V1 · M · T)* ↳ *LAW/CCRs 2013* — Exit no harder than entry. - **CMR-003** — THE platform SHALL present total price, billing frequency, minimum term, and renewal date before the subscriber commits. *(V1 · M · I)* ↳ *LAW/CCRs 2013* — Pre-contract information. - **CMR-004** — WHEN a trial is due to convert to a paid subscription, THE platform SHALL notify the subscriber before the first charge is taken. *(V1 · M · T)* ↳ *REVIEW* — The brief's 14-day trial converts to a charge; the subscriber should see it coming. - **CMR-005** — WHEN a subscription is cancelled, THE platform SHALL confirm in writing the cancellation date and the date service ends. *(V1 · M · T)* ↳ *LAW/CCRs 2013* — Confirmation in a durable medium. - **CMR-006** — IF a payment fails, THEN THE billing service SHALL apply the dunning schedule. *(V1 · M · T)* ↳ *REVIEW* — The brief's recurring model implies dunning and never mentions it. - **CMR-007** — IF a payment fails, THEN THE platform SHALL notify the carer before any change to service takes effect. *(V1 · M · T)* ↳ *REVIEW* — Service change without notice reads as a fault. - **CMR-008.1** — WHILE an account is in dunning, THE platform SHALL continue to accept inbound calls from the elder user. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — A payment problem must never stop an elder reaching the service. - **CMR-008.2** — WHILE an account is in dunning, THE platform SHALL continue to meet every safeguarding obligation for that household. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — Safeguarding duties do not follow the payment status. - **CMR-009** — THE billing service SHALL support full refunds and refunds proportionate to the unused term, as required by the Consumer Contracts Regulations 2013. *(V1 · M · T)* ↳ *LAW/CCRs 2013* — Proportionate refund is the statutory term; see §3.6. - **CMR-010** — THE billing service SHALL apply Strong Customer Authentication to subscriber payments. *(V1 · M · T)* ↳ *LAW/PSRs 2017* — Strong Customer Authentication. - **CMR-011** — THE billing service SHALL issue a VAT invoice for every charge. *(V1 · M · T)* ↳ *LAW/VAT Act 1994* — Invoicing. - **CMR-012.1** — THE platform SHALL assign a version to every published terms of service. *(V1 · M · T)* ↳ *REVIEW* — Terms that cannot be versioned cannot be enforced or defended. - **CMR-012.2** — THE platform SHALL record acceptance of the terms of service per person per version. *(V1 · M · T)* ↳ *REVIEW* — Per person, because a household has several people bound by them. - **CMR-013.1** — WHEN terms change materially, THE platform SHALL notify every affected person. *(V1 · M · T)* ↳ *LAW/CRA 2015* — Material variation requires notice. - **CMR-013.2** — THE platform SHALL apply materially changed terms to a person only after that person has re-accepted them. *(V1 · M · T)* ↳ *LAW/CRA 2015* — And acceptance, not just notice. - **CMR-014** — THE platform SHALL operate a complaints procedure with a published response target and signposting to alternative dispute resolution. *(V1 · M · R)* ↳ *LAW/ADR Regs 2015* — Complaints and ADR signposting. - **CMR-015.1** — WHEN a person requests a reasonable adjustment under the Equality Act 2010, THE platform SHALL record the request. *(V1 · M · R)* ↳ *LAW/Equality Act 2010* — Reasonable adjustments as a service provider. - **CMR-015.2** — WHEN a reasonable adjustment is requested, THE platform SHALL respond within the published complaints target. *(V1 · M · R)* ↳ *LAW/Equality Act 2010* — An adjustment request with no timescale is a refusal in slow motion. - **CMR-016** — THE platform SHALL hold documented substantiation for every advertised capability claim before that claim is published. *(V1 · M · R)* ↳ *LAW/CAP Code* — Substantiation before publication. - **CMR-017.1** — THE platform SHALL describe the service in all marketing as an AI assistant. *(V1 · M · I)* — SAFETY_LOCKED ↳ *LAW/CAP Code* — AI capability claims to a vulnerable audience carry the highest substantiation burden. - **CMR-017.2** — THE platform SHALL limit marketing claims to capabilities substantiated under CMR-016, excluding any claim that the service monitors health or summons help. *(V1 · M · I)* — SAFETY_LOCKED ↳ *REVIEW* — 'Monitors health' and 'summons help' are the two claims most likely to be inferred and most dangerous if believed. - **CMR-018** — WHERE the DMCC subscription contracts regime is in force, THE platform SHALL meet its pre-contract information, reminder notice, cooling-off, and exit requirements. *(V2 · M · R)* **[OD-21]** ↳ *LAW/DMCC 2024* — Not in force — commencement expected spring 2027. Readiness only. See OD-21. - **CMR-019** — THE platform SHALL state in all marketing that the service is not an emergency alarm and does not operate during a power or broadband outage. *(V1 · M · I)* — SAFETY_LOCKED ↳ *REVIEW v0.6* — A daily-contact claim implies availability the service does not have during a power cut. > **Why CMR-019 sits alongside CMR-017.** CMR-017 already forbids claiming the service monitors health or summons help. CMR-019 closes the adjacent gap: a claim of *daily contact* implies availability the service does not have. The regulatory precedent is close at hand — Ofcom fined a provider for disconnecting customers with telecare devices during digital voice migration, and providers have committed not to migrate telecare users without a confirmed working equivalent. bience is not telecare, but a daily wellbeing call to a vulnerable adult sits near enough to it that the expectations are worth adopting voluntarily rather than being handed later. **[OD-29]** --- ## 31. Marketing, analytics and privacy consent (PRV) - **PRV-001** — THE platform SHALL obtain PECR-compliant consent before setting any non-essential cookie or device identifier. *(V1 · M · T)* ↳ *LAW/PECR reg 6* — Consent before non-essential storage or access on the device. - **PRV-002** — THE platform SHALL default all non-essential analytics to off. *(V1 · M · T)* ↳ *LAW/PECR reg 6* — Default off is the only defensible default. - **PRV-003** — THE platform SHALL address marketing communications only to the account holder and to carers who have opted in. *(V1 · M · T)* — SAFETY_LOCKED ↳ *LAW/PECR reg 22* — Direct marketing consent. - **PRV-004** — THE platform SHALL exclude elder users and dependent users from every marketing communication. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — Marketing to a vulnerable adult who did not buy the product is indefensible. - **PRV-005** — THE platform SHALL provide a one-step unsubscribe in every marketing message. *(V1 · M · T)* ↳ *LAW/PECR reg 23* — Unsubscribe in every message. - **PRV-006** — THE platform SHALL exclude conversational content from every marketing, analytics, and product telemetry dataset. *(V1 · M · A)* — SAFETY_LOCKED ↳ *BRIEF/HC* — Conversational content in an analytics dataset would breach the access constraints. - **PRV-007** — THE platform SHALL maintain the record of processing activities required by UK GDPR Article 30. *(V1 · M · R)* ↳ *LAW/UK GDPR Art 30* — Record of processing activities. - **PRV-008.1** — THE platform SHALL register with the ICO before processing production personal data. *(V1 · M · R)* ↳ *LAW/DPA 2018* — ICO registration. - **PRV-008.2** — THE platform SHALL pay the ICO data protection fee for each fee period. *(V1 · M · R)* ↳ *LAW/DPA 2018* — The fee is per period, not once. - **PRV-009.1** — THE platform SHALL appoint a Data Protection Officer. *(V1 · M · R)* **[OD-22]** ↳ *LAW/UK GDPR Art 37* — Large-scale special category processing is a strong indicator of the duty. See OD-22. - **PRV-009.2** — THE platform SHALL publish the Data Protection Officer's contact details. *(V1 · M · R)* **[OD-22]** ↳ *LAW/UK GDPR Art 37(7)* — Contact details must be published and given to the ICO. > **PRV-009 note.** Large-scale processing of special category data is a strong indicator of the Article 37 duty. Treat the appointment as required until legal advice says otherwise, not the reverse. --- ## 32. Backup, restore and continuity (BCK) - **BCK-001** — THE platform SHALL back up every persistent store at an interval that meets its recovery point objective. *(V1 · M · T)* ↳ *REVIEW* — The brief covers failover and never mentions data loss. - **BCK-002** — THE platform SHALL meet a recovery point objective of no more than 15 minutes for the family graph, consent, and audit stores. *(V1 · M · T)* **[OD-23]** ↳ *REVIEW* — Graph, consent and audit are the three stores whose loss cannot be reconstructed. See OD-23. - **BCK-003** — THE platform SHALL meet a recovery time objective of no more than 4 hours for the elder phone line. *(V1 · M · T)* **[OD-23]** ↳ *REVIEW* — The elder line is the safety-relevant surface, so it sets the recovery target. - **BCK-004.1** — THE platform SHALL encrypt every backup at rest and in transit. *(V1 · M · T)* ↳ *BRIEF/HC* — Encryption applies to backups as much as to live data. - **BCK-004.2** — THE platform SHALL hold every backup in the United Kingdom. *(V1 · M · T)* ↳ *BRIEF/HC* — Residency applies to backups too, and is the most commonly missed instance. - **BCK-005** — THE platform SHALL perform and record a restore test at least quarterly. *(V1 · M · D)* ↳ *REVIEW* — An untested backup is a belief, not a control. - **BCK-006** — THE platform SHALL apply the retention schedule to backups such that deleted data does not persist beyond one backup cycle past its deletion date. *(V1 · M · T)* ↳ *LAW/UK GDPR Art 17* — Erasure that leaves the data in backups is not erasure. - **BCK-007** — WHEN an erasure request is executed, THE platform SHALL confirm to the subject the date by which the data will be expunged from backups. *(V1 · M · T)* ↳ *REVIEW* — Telling the subject the expunge date is the honest version of a partial deletion. - **BCK-008** — WHEN a restore completes, THE platform SHALL verify audit chain integrity before returning the system to service. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/P6* — A restored system with an unverified chain has an unprovable audit history. - **BCK-009** — THE platform SHALL maintain a business continuity plan covering the loss of any single critical vendor. *(V1 · M · R)* ↳ *BRIEF/P5* — Sub-processor concentration is a continuity risk, not only a compliance one. --- ## 33. Adversarial input and abuse (AIS) > The attack this section defends against: a caller instructs Omi to disregard its configuration and read out what it knows about the family. A voice product with a permission model and no authorisation layer outside the model is one sentence away from a disclosure incident. - **AIS-001** — THE Lide orchestrator SHALL derive its instructions solely from the configuration resolved under CFG-005.1. *(V1 · M · A)* — SAFETY_LOCKED ↳ *REVIEW* — Prompt injection over voice is absent from the brief. The attack is one sentence long. - **AIS-002** — THE input defence layer SHALL screen every user turn for instruction-injection patterns. *(V1 · M · T)* ↳ *REVIEW* — Screening is the cheap layer, not the sufficient one. - **AIS-003** — IF conversational input attempts to alter persona behaviour, permission scope, or disclosure limits, THEN THE Lide orchestrator SHALL continue under the resolved configuration. *(V1 · M · T)* — SAFETY_LOCKED ↳ *REVIEW* — The resolved configuration must be immune to what the caller says about it. - **AIS-004** — IF an instruction-injection attempt is detected, THEN THE platform SHALL record a security event. *(V1 · M · T)* ↳ *BRIEF/P6* — An injection attempt is a security event worth counting. - **AIS-005** — THE family graph service SHALL authorise every disclosure independently of the language model. *(V1 · M · A)* — SAFETY_LOCKED ↳ *REVIEW* — The load-bearing control: authorisation outside the model, so a persuaded model still cannot disclose. - **AIS-006** — IF an injection attempt is detected and the speaker's identity is unconfirmed, THEN THE Lide orchestrator SHALL apply the unregistered-speaker script under IDN-005.1. *(V1 · M · T)* — SAFETY_LOCKED ↳ *DERIVED* — Injection plus unconfirmed identity is the highest-risk combination in the system. - **AIS-007** — THE knowledge service SHALL treat every retrieved passage as data rather than as instruction. *(V1 · M · A)* — SAFETY_LOCKED ↳ *REVIEW* — Retrieval poisoning is the same attack arriving through the knowledge base. - **AIS-008** — THE voice gateway SHALL rate-limit inbound calls per originating number. *(V1 · M · T)* ↳ *BRIEF/P9* — The brief bounds outbound cost and never bounds inbound volume. - **AIS-009.1** — IF inbound call volume from a single originating number exceeds the configured threshold, THEN THE voice gateway SHALL apply progressive delay to that number. *(V1 · M · T)* ↳ *REVIEW* — Progressive delay degrades an attacker's economics without blocking a legitimate caller. - **AIS-009.2** — IF inbound call volume from a single originating number exceeds the configured threshold, THEN THE platform SHALL raise an abuse event. *(V1 · M · T)* ↳ *REVIEW* — Abuse volume is a signal about a person, sometimes a distressed one. - **AIS-010** — THE platform SHALL apply the identity requirements of §7 (IDN) before any disclosure, irrespective of what the caller asserts about themselves. *(V1 · M · T)* — SAFETY_LOCKED ↳ *BRIEF/P3* — Identity discipline must not be talked out of by an assertion. --- ## 34. Safety budgets (SFB) > A safety budget is the safety-critical analogue of an SRE error budget: a stated, finite allowance of degradation per period, owned by the clinical lead rather than by engineering. Its purpose is to convert "we should look at that" into an automatic consequence. Budget exhaustion stops *change*; it never stops *protection*. - **SFB-001** — THE platform SHALL define a safety budget for each metric enumerated in SFB-002, stating the permitted degradation per rolling 30-day period. *(V1 · M · I)* **[OD-28]** ↳ *USER* — Safety budgets requested by Dave. Value deferred to OD-28. - **SFB-002** — THE safety budget set SHALL cover safety classifier recall shortfall, safety classifier precision floor, digest omission rate for safety-relevant events, unsupported-claim rate in `AUTHORITATIVE_ONLY` domains, turn latency p95 breaches, safeguarding acknowledgement SLA breaches, and undetected instruction-injection attempts. *(V1 · M · I)* ↳ *USER* — The metric set spans every safety-relevant measure already in the specification. - **SFB-003** — THE platform SHALL record the clinical lead as the approver of every safety budget value. *(V1 · M · I)* — SAFETY_LOCKED ↳ *USER* — Clinical ownership is what stops the budget becoming an engineering convenience. - **SFB-004** — THE platform SHALL display current consumption of every safety budget on the operations dashboard. *(V1 · M · T)* ↳ *USER* — A budget nobody can see is not consumed, it is ignored. - **SFB-005** — WHEN a safety budget reaches 75% consumption, THE platform SHALL alert the clinical lead and the on-call engineer. *(V1 · M · T)* ↳ *USER* — 75% is the point at which behaviour can still change. - **SFB-006** — IF a safety budget is exhausted, THEN THE pipeline SHALL block every release to the affected subsystem other than a remediation change. *(V1 · M · T)* — SAFETY_LOCKED ↳ *USER* — The consequence that makes the budget real. - **SFB-007** — IF a safety budget is exhausted, THEN THE platform SHALL notify the clinical lead within one hour. *(V1 · M · T)* — SAFETY_LOCKED ↳ *USER* — Clinical lead notification, because exhaustion is a clinical signal. - **SFB-008** — THE platform SHALL reset each safety budget at the start of its rolling period without carrying forward unconsumed allowance. *(V1 · M · T)* ↳ *USER* — Carry-over would let a quiet month fund a reckless one. - **SFB-009** — THE platform SHALL treat unconsumed safety budget as non-transferable between metrics. *(V1 · M · A)* ↳ *USER* — Transfer between metrics would let good latency pay for poor recall. - **SFB-010** — THE platform SHALL record every safety budget change with actor, timestamp, previous value, new value, and rationale. *(V1 · M · T)* ↳ *BRIEF/P6* — Budget changes are safety-behaviour changes and belong in the audit record. - **SFB-011** — WHILE a safety budget is exhausted, THE platform SHALL continue to meet every `SAFETY_LOCKED` requirement. *(V1 · M · A)* — SAFETY_LOCKED ↳ *USER* — Exhaustion stops change, never protection. The distinction is the whole design. - **SFB-012** — THE platform SHALL enforce an infrastructure spend budget per environment with alerting at the thresholds recorded in the spend policy. *(V1 · M · T)* ↳ *BRIEF/P9* — Spend budgets extend the brief's cost-control concern to infrastructure. - **SFB-013** — IF a proposed cost control would reduce safety classifier coverage, safeguarding capacity, or audit availability, THEN THE platform SHALL reject that control. *(V1 · M · A)* — SAFETY_LOCKED ↳ *REVIEW* — The requirement that has to survive the first cash-flow squeeze. - **SFB-014** — THE platform SHALL report safety budget consumption at the monthly operational review. *(V1 · M · R)* ↳ *USER* — Consumption reported where decisions get made. > **SFB-013 note.** This is the requirement that survives the first cash-flow squeeze. Every safety system in this specification has a cost, and the cheapest way to make the numbers work will always be to trim one of them. Writing the prohibition down before the pressure exists is the only time it is easy to write. --- ## 35. Non-functional budget summary | Attribute | Target | Requirement | |---|---|---| | Response latency p50, from end-of-turn detection | ≤ 800 ms | VOI-001 | | Perceived gap p50, from end of user speech | ≤ 2,200 ms | VOI-021 | | Response latency p95 | ≤ 1,200 ms | VOI-002 | | Barge-in stop | ≤ 200 ms | VOI-010 | | Elder line availability | ≥ 99.9% monthly | DEG-011 | | Safeguarding ack (immediate) | To be set | SFG-003 **[OD-08]** | | Unsupported claim rate (authoritative domains) | 0 | KNW-011 | | Safety classifier recall | Baseline floor, release-gating | SFC-006 | | Audio retention | Short, automatic | DAT-009 | | Transcript retention | Long, automatic | DAT-010 | | DSAR / erasure turnaround | ≤ 1 calendar month | DAT-012, DAT-013 | | Telephony providers | 2 independent | DEG-008 | | RPO (graph, consent, audit) | ≤ 15 min | BCK-002 | | RTO (elder phone line) | ≤ 4 h | BCK-003 | | Restore test cadence | Quarterly | BCK-005 | | Digest omission rate (safety events) | Baseline floor, release-gating | EVL-015, EVL-016 | | Digest unsupported-assertion rate | Measured every release | EVL-017 | | Transparency notice to elder user | ≤ 24 h | TRN-004, TRN-005 | | Cancellation effort | ≤ signup effort | CMR-002 | | Safety budget alert threshold | 75% consumption | SFB-005 | | Safety budget period | Rolling 30 days, no carry-over | SFB-001, SFB-008 | | Secret rotation on leaver | ≤ 7 days | SEC-020 | | STT and classifier evaluation channel | Production narrowband encoding | VOI-022, VOI-023, SFC-012 | | Power-dependency disclosure | Before activation | TRN-011 | | Access revocation on leaver | ≤ 24 h | SEC-019 | | Exposed secret rotation | ≤ 24 h | SEC-022 | --- ## 36. Traceability ### 26.1 Brief problems P1–P10 → requirements | Brief item | Requirements | |---|---| | P1 Latency with guardrails in path | VOI-001…VOI-007 | | P2 Hallucination tolerance | KNW-001…KNW-011, EVL-003 | | P3 Speaker identification | IDN-001…IDN-011 | | P4 Consent for absent users | CNS-001…CNS-015, SUR-208 | | P5 Residency and sub-processors | DAT-001…DAT-008, SEC-002 | | P6 Publishable audit logging | AUD-001…AUD-011, ACC-001…ACC-010 | | P7 Safeguarding triage at scale | SFG-001…SFG-013, GEN-004 | | P8 Evals as discipline | EVL-001…EVL-014 | | P9 Telephony cost and abuse | USG-001…USG-011 | | P10 Graceful degradation | DEG-001…DEG-013 | ### 26.2 Brief questions Q1–Q3 → requirements | Brief item | Requirements | |---|---| | Q1 Customisation limits | CFG-001…CFG-012 | | Q2 Subscription model | BIL-001…BIL-008, USG-001…USG-002 | | Q3 Multiple family members | FGR-001…FGR-017, IDN-001…IDN-011 | ### 36.4 Commercial and operational coverage added at v0.3 | Concern | Requirements | |---|---| | Subject transparency parity | TRN-001…TRN-010 | | The carer digest as a product | SUM-001…SUM-011, EVL-015…EVL-017 | | Signup to first call | ONB-001…ONB-008 | | Reaching a human | HND-001…HND-005 | | Multi-language safety parity | LNG-001…LNG-006, EVL-019 | | Consumer contract and subscription law | CMR-001…CMR-018 | | Marketing, analytics, ICO registration | PRV-001…PRV-009 | | Backup, restore, continuity | BCK-001…BCK-009 | | Prompt injection and inbound abuse | AIS-001…AIS-010, EVL-018 | | Data export and legal hold | DAT-016…DAT-019 | | Outward safeguarding referral | SFG-014…SFG-016 | | Vendor exit and portability | SEC-011…SEC-013 | | Enterprise channel | ENT-001…ENT-011 (Appendix A) | ### 36.5 Added at v0.4 | Concern | Requirements | |---|---| | Safety budgets and change freeze | SFB-001…SFB-014 | | Secrets management (Infisical) | SEC-008.1, SEC-014…SEC-028 | | Cost control must not erode safety | SFB-012, SFB-013 | ### 36.6 Added at v0.6 | Concern | Requirements | |---|---| | Evaluation channel must match production | VOI-022, VOI-023, VOI-024, SFC-012 | | Digital voice power dependency | ONB-009, ONB-010, DEG-014, DEG-015, TRN-011, CMR-019 | ### 26.3 Brief unknowns → open decisions | Brief unknown | Open decision | |---|---| | U1 Build-vs-buy voice gateway | OD-16 | | U2 Persona engineering approach | OD-17 | | U3 Family graph schema | OD-18 | | U4 Safeguarding classifier build-vs-buy | OD-19 | | U5 Eval harness investment | OD-20 | --- ## 37. Open decisions register | ID | Decision | Blocks | |---|---|---| | OD-01 | Lawful basis and Article 9 condition per purpose | CNS, DAT-015 | | OD-02 | LPA verification method and evidence standard; whether an attorney can lawfully give UK GDPR consent on a donor's behalf at all, and the fact that a Health & Welfare LPA operates only on incapacity while Property & Financial Affairs may operate with capacity | CNS-008, CNS-009 | | OD-03 | Fluctuating-capacity re-consent interval | CNS-011 | | OD-04 | Clinical scope boundary and medical device classification | KNW-008, KNW-010 | | OD-05 | Retention periods for audio, transcripts, audit | DAT-009, DAT-010, AUD-009 | | OD-06 | Accent and atypical speech corpus sourcing | VOI-014, VOI-015 | | OD-07 | Safety classifier recall floor and precision ceiling | SFC-006 | | OD-08 | Safeguarding acknowledgement SLA per severity | SFG-003 | | OD-09 | Break-glass disclosure window | ACC-006 | | OD-10 | NHS / DSPT applicability | SEC-010 | | OD-11 | Whether PECR reg 19 bites at all — it addresses automated systems transmitting *pre-recorded* messages, and synthesised conversational speech is arguably outside it. Untested. Also the Ofcom silent-call position on proactive calling | SUR-108, CNS-014 | | OD-12 | Emergency call posture | SUR-111 | | OD-13 | Availability target and its cost | DEG-011 | | OD-14 | Age assurance method | AAD-003 | | OD-15 | Bereavement data policy | SUP-002 | | OD-16 | Voice gateway build vs buy | Architecture | | OD-17 | Persona engineering: prompts vs fine-tunes | CFG-012 | | OD-18 | Family graph schema shape beyond RBAC | FGR | | OD-19 | Safeguarding classifier build vs partner | SFC-010 | | OD-20 | Eval harness V1 investment level | EVL | | OD-21 | DMCC subscription regime readiness ahead of spring 2027 commencement | CMR-003, CMR-018 | | OD-22 | DPO appointment: internal, fractional, or external | PRV-009 | | OD-23 | RPO and RTO targets and their infrastructure cost | BCK-002, BCK-003 | | OD-24 | Bank and Action Fraud referral routes | SFG-015 | | OD-25 | Whether the enterprise channel is pursued at all | Appendix A | | OD-26 | Supported language list and the order languages are added | LNG-005 | | OD-27 | Infisical self-hosted versus Infisical Cloud, and rotation intervals | SEC-018, SEC-025 | | OD-28 | Numeric value of each safety budget | SFB-001 | | OD-29 | Whether the service falls within telecare or technology-enabled care scope, and which standards and vulnerable-customer commitments would follow | CMR-019, TRN-011 | | OD-30 | Whether to pursue a wideband codec path on the post-switchover VoIP leg, decided from the VOI-024 delta | VOI-024 | --- ## 38. Verification strategy | Group | Primary method | Notes | |---|---|---| | VOI | Automated load and latency harness against synthetic call corpus | Per-stage breakdown required for attribution | | IDN, CNS | Scripted conversational tests plus legal review | Legal review is a gate, not a comment | | CFG, FGR | Property-based tests over permission triples plus static analysis | Static analysis proves CFG-010 | | SFC, SFG | Labelled corpus evaluation plus tabletop exercise | Tabletop covers the human pathway | | KNW | Grounding regression with zero-tolerance gate | | | AUD, ACC | Architecture review plus tamper-detection test | Independent reviewer preferred | | DAT, SEC | Documentary audit plus penetration test | | | DEG | Scheduled failure injection | Quarterly minimum | | EVL | Meta-evaluation: does the harness catch seeded regressions | Seeded-defect test | | TRN, SUM | Scripted conversational tests plus labelled digest corpus | Omission is the failure mode, not fabrication | | ONB, HND | Journey walkthrough plus duplicate-number test | ONB-005 needs a deliberate collision test | | CMR, PRV | Documentary audit plus consumer journey review | Legal sign-off is a gate | | BCK | Quarterly restore drill with audit chain verification | Untested backups are not backups | | AIS | Red-team suite against the live voice path | Must be run over the phone line, not the API | | SFB | Dashboard inspection plus a deliberate budget-exhaustion drill | The drill is the test — an untriggered freeze is unproven | | SEC (secrets) | Scanning in CI, leaver drill, deploy-time failure injection | SEC-027 needs the secrets service taken down on purpose | --- ## 39. Assumptions 1. UK-only market at V1; no cross-border data flows beyond UK-adequate jurisdictions. 2. The elder phone line is not a replacement for emergency services and is not marketed as one. 3. No feature in V1 through V3 constitutes a medical device. **[OD-04]** 4. Safeguarding partnerships are in place before production data exists, not after. 5. Household size at V1 does not exceed eight people. 6. The carer is the payer in all V1 households. 7. The DMCC subscription contracts regime is not in force at V1 launch; the CCRs 2013 govern. **[OD-21]** 8. The product is sold direct to consumers at V1; Appendix A is not implemented. **[OD-25]** 9. English is the only supported language until V3. **[OD-26]** 10. The elder's telephone line is reachable over the public network and is not power-independent after the PSTN retirement of 31 January 2027. **[OD-29]** 11. bience is not a telecare or technology-enabled care service. This assumption is load-bearing and untested. **[OD-29]** --- ## 40. Change log | Version | Date | Change | |---|---|---| | 0.1 | 2026-07-25 | Initial derivation from *"The problems, not the pitch"* v1.0. | | 0.2 | 2026-07-25 | EARS conformance pass. Keyword semantics corrected (9). Compound requirements split into decimal sub-identifiers (61). Negative requirements recast into positive restriction form (30 of 32). Vague terms replaced with named artefacts (13). Design statements relocated to §4.3 Design Constraints (6). Requirement count 266 → 331. | | 0.7 | 2026-07-26 | Provenance pass. Every one of the 498 requirements annotated with its source and rationale (§3.3). Split: 43% traceable to the brief, 13% statutory, 35% found in review, 4% requested during drafting, 2% derived. | | 0.6 | 2026-07-26 | Added the evaluation-channel requirements (VOI-022 to VOI-024, SFC-012): speech and classifier accuracy must be measured on production narrowband encoding, not wideband test audio. Added digital voice power-dependency capture and disclosure (ONB-009, ONB-010, DEG-014, DEG-015, TRN-011, CMR-019) ahead of the 31 January 2027 PSTN retirement. Two new open decisions. Requirement count 488 → 498. | | 0.5 | 2026-07-25 | Correctness pass. Resolved a contradiction between VOI-001 and VOI-011: response latency is now measured from end-of-turn detection, with perceived gap added as a separate, honestly larger measure (VOI-020, VOI-021). Requirement count 486 → 488. | | 0.4 | 2026-07-25 | Added §34 Safety budgets (SFB, 14 requirements) with clinical-lead ownership and release blocking on exhaustion. Added §22.1 Secrets management (SEC-014…SEC-028) naming Infisical, covering machine identities, per-environment isolation, rotation, leaver revocation, scanning, and fail-closed deployment. Two new open decisions. Requirement count 457 → 486. | | 0.3 | 2026-07-25 | Commercial completeness pass. Added TRN (subject transparency parity), SUM (carer digest), ONB (onboarding), HND (human handoff), LNG (language), CMR (consumer contract), PRV (marketing and ICO), BCK (backup and continuity), AIS (adversarial input). Extended EVL, DAT, SFG, SEC. Added Appendix A (enterprise channel). Six new open decisions. Requirement count 331 → 457. | --- ## Appendix A — Enterprise and public-sector channel (ENT) > **Conditional.** These requirements apply only if bience sells to organisations — local authorities, integrated care boards, care providers, insurers — rather than direct to families. They are recorded now because the decision changes the data model (processor mode, tenancy) and is expensive to retrofit. They are **not** implemented at V1. **[OD-25]** - **ENT-001** — WHERE the platform is supplied to an organisation, THE platform SHALL operate as a processor under a written agreement meeting UK GDPR Article 28. *(V2 · M · R)* ↳ *REVIEW* — Conditional on OD-25. Processor mode changes the data model and is expensive to retrofit. - **ENT-002** — WHERE the platform is supplied to an organisation, THE platform SHALL isolate that organisation's data from every other tenant. *(V2 · M · T)* ↳ *REVIEW* — Tenant isolation is the minimum an organisational buyer will diligence. - **ENT-003** — WHERE the platform is supplied to an organisation, THE platform SHALL provide a contractual service level with the remedies recorded in the service level agreement. *(V2 · M · R)* ↳ *REVIEW* — Consumer terms do not carry the remedies an organisation expects. - **ENT-004** — WHERE the platform is supplied to an organisation, THE platform SHALL publish a service status page covering the elder phone line and the carer app. *(V2 · S · D)* ↳ *REVIEW* — A status page is table stakes in any B2B sale. - **ENT-005.1** — WHEN an organisational contract ends, THE platform SHALL return that organisation's data in the agreed format. *(V2 · M · R)* ↳ *REVIEW* — Data return format agreed at contract, not negotiated at exit. - **ENT-005.2** — WHEN an organisational contract ends and data return is complete, THE platform SHALL confirm deletion in writing. *(V2 · M · R)* ↳ *LAW/UK GDPR Art 28(3)(g)* — Deletion confirmation at end of processing. - **ENT-006** — WHERE the platform is supplied to an organisation, THE platform SHALL evidence professional indemnity, cyber, and public liability insurance at the contracted level. *(V2 · M · R)* ↳ *REVIEW* — Insurance evidence is a standard procurement gate. - **ENT-007** — WHEN a sub-processor changes, THE platform SHALL notify each organisational customer before the change takes effect. *(V2 · M · T)* ↳ *LAW/UK GDPR Art 28(2)* — Sub-processor change notification. - **ENT-008** — WHERE the platform is supplied to an organisation, THE platform SHALL provide tenant-scoped audit export. *(V2 · M · T)* ↳ *BRIEF/P6* — Tenant-scoped export of the audit record the brief already requires. - **ENT-009** — WHERE the platform forms part of an NHS care pathway, THE platform SHALL apply clinical risk management under DCB0129 and DCB0160. *(V2 · M · R)* **[OD-10]** ↳ *LAW/DCB0129* — Clinical risk management if the service forms part of an NHS pathway. See OD-10. - **ENT-010** — WHERE DCB0129 applies, THE platform SHALL appoint a named Clinical Safety Officer. *(V2 · M · R)* ↳ *LAW/DCB0129* — A named Clinical Safety Officer is the standard's central requirement. - **ENT-011** — WHERE the platform is supplied to an organisation, THE platform SHALL preserve the individual data subject rights in §16 (DAT) and §25 (TRN) irrespective of the organisation's instructions. *(V2 · M · A)* — SAFETY_LOCKED ↳ *REVIEW* — The commercial buyer is not the data subject and must not be able to contract away their rights. > **ENT-011 note.** The commercial customer is not the data subject. An organisational buyer must not be able to contract away an elder user's transparency or erasure rights. This requirement is the reason the enterprise channel needs specifying before it is sold, not after.