bience — EARS Specification & Flows

A derived product specification for a voice-first eldercare platform, written in EARS (Easy Approach to Requirements Syntax), and the companion flow document it traces to. Every requirement carries its provenance; every diagram names the requirements it implements. Where the two disagree, the specification wins.

spec.ears.md v0.7 498 requirements flows.md v0.2 25 diagrams spec source flows source
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#

PhaseContents
V1Surface 1 (elder phone line) + Surface 2 (carer app). Surfaces 3 and 4 stubbed. Single-language (English). Safeguarding by one trained reviewer.
V2Surface 4 (family web admin) hardened, multi-carer households, tier expansion, richer eval coverage.
V3Surface 3 (Vee, adult neurodivergent users). Multi-language.
V4Under-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#

ActorDescription
Elder userThe aging parent. Primary user of the phone line. May have hearing aids, dementia-affected speech, fluctuating capacity. Does not necessarily own a smartphone.
CarerThe buyer and primary operator. Adult child, spouse, or paid carer. Uses the carer app.
Younger userNeurodivergent young adult (V3) or child (V4). Uses Vee.
ObserverA family member with read-only or partial scope. Sibling, distant relative.
Paid carerProfessional carer with time-bounded, scope-limited access.
LPA holderHolder of a registered Lasting Power of Attorney (Health & Welfare, or Property & Financial Affairs). Legally distinct from "carer".
Safeguarding reviewerDBS-checked, trained internal reviewer. Handles flagged events.
Clinical leadNamed accountable clinician or safeguarding lead.
Support agentInternal staff handling account and billing issues.
EngineerInternal staff with break-glass-only production access.
Founder / execExplicitly holds no conversational data access.

2.2 AI personas#

PersonaSurfaceAudience
OmiPhone lineElder user
JoolCarer appCarer
VeeYounger-user appNeurodivergent young adult / child

2.3 Systems and subsystems (requirement subjects)#

SystemResponsibility
Voice gatewayPSTN/SIP termination, streaming STT/TTS transport, turn-taking, barge-in, latency budget.
Lide orchestratorPersona routing, context assembly, config resolution, guardrail enforcement, tool/escalation dispatch.
Safety classifierParallel-path real-time classification: suicide ideation, abuse, financial scam, capacity-loss signals.
Knowledge serviceRAG over authoritative sources with citation-required output.
Family graph servicePeople, roles, permissions, scopes, consent state.
Identity serviceSpeaker identification, confirmation flows, authenticated app sessions.
Consent serviceCapacity-aware consent capture, renewal, withdrawal.
Safeguarding serviceFlag intake, triage, severity routing, on-call handoff, regulator reporting.
Audit serviceAppend-only, cryptographically chained access log.
Configuration serviceTyped per-user config, schema validation, versioning.
Billing serviceStripe integration, tier entitlement, feature gating.
Usage telemetry servicePer-family minute/token/storage/event accounting; caps and anomaly detection.
Degradation controllerHealth detection, fallback selection, pre-written response playback.
Eval harnessRegression suite, release gating, drift monitoring.
Summarisation serviceGeneration of carer digests from transcript, with source attribution.
Onboarding serviceSignup, number verification, relationship declaration, activation gating.
Input defence layerScreening of conversational input for instruction injection and abuse.
Backup and recovery serviceBackup scheduling, restore, RPO/RTO, backup retention.
Secrets serviceInfisical. Machine identities, per-environment isolation, rotation, secret scanning.
Safety budget serviceBudget definition, consumption tracking, release blocking on exhaustion.
PlatformCross-cutting; used where no single subsystem owns the behaviour.

3. Requirement conventions#

3.1 EARS patterns used#

PatternForm
UbiquitousTHE <system> SHALL <response>
Event-drivenWHEN <trigger> THE <system> SHALL <response>
State-drivenWHILE <state> THE <system> SHALL <response>
Unwanted behaviourIF <condition> THEN THE <system> SHALL <response>
Optional featureWHERE <feature is included> THE <system> SHALL <response>
ComplexCombinations of the above

3.2 Identifier scheme#

<DOMAIN>-<nnn>, with decimal sub-identifiers (<DOMAIN>-<nnn>.<n>) 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-<nn> (§4.3).

3.3 Provenance annotations#

Every requirement carries a second line marking where it came from and why it exists:

↳ *SOURCE* — rationale.

SourceMeaningCount
BRIEF/S1S4Stated in a surface description in the brief
BRIEF/Q1Q3From one of the three questions candidates asked
BRIEF/P1P10From one of the ten harder problems
BRIEF/U1U5From one of the five named unknowns
BRIEF/HCFrom the hard constraints table
BRIEF/ARCHFrom the reference architecture section
BRIEF total219 (43%)
LAW/…Required by statute, regulator or code, and not mentioned in the brief65 (13%)
REVIEWA gap found while deriving this specification. Not in the brief178 (35%)
USERRequested directly during drafting22 (4%)
DERIVEDFollows necessarily from another requirement here14 (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 <do X> only where <condition>, 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)#

4.2 Accessibility (ACS)#


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.

IDConstraintBindsRationale
DC-01The family graph SHALL be stored as explicit relationship rows in a relational store, and SHALL NOT be represented as nested documents.FGR-002Nested documents make "who can see this resource" an unbounded scan and make revocation non-atomic.
DC-02The feature gating layer SHALL be implemented as a module separate from application logic.BIL-003Entitlement checks scattered through application code cannot be proven not to gate a safety behaviour (BIL-004).
DC-03Conformance with CFG-010 SHALL be demonstrated by automated static analysis executed on every build.CFG-010Manual review does not scale and does not fail the pipeline.
DC-04The carer app SHALL be delivered on iOS and Android.SUR-201Named platforms; a web-only carer surface does not meet the notification requirements in SUR-205.
DC-05Carer authentication SHALL use platform biometric authentication with a passcode fallback.SUR-203Biometric-only excludes users who cannot enrol; passcode-only is weaker than the data warrants.
DC-06Degradation responses SHALL be cached at the edge or on the voice gateway.DEG-006A fallback that requires the orchestrator is not a fallback.

The requirements

Requirement

5. Surfaces#

5.1 Surface 1 — Elder phone line (SUR-1xx)#

5.2 Surface 2 — Carer app (SUR-2xx)#

5.3 Surface 3 — Vee (SUR-3xx)#

5.4 Surface 4 — Family web admin (SUR-4xx)#


6. Voice pipeline (VOI)#

6.1 Latency#

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.

6.2 Turn-taking and speech handling#

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.

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)#


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]


9. Configuration and customisation (CFG)#


10. Family graph, roles and permissions (FGR)#


11. Safety classification (SFC)#

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)#


13. Knowledge, grounding and hallucination control (KNW)#


14. Audit logging (AUD)#


15. Internal access control (ACC)#


16. Data governance (DAT)#


17. Billing, tiers and entitlement (BIL)#


18. Usage telemetry, cost and abuse (USG)#


19. Graceful degradation and resilience (DEG)#

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.


20. Evaluation and release gating (EVL)#


21. Observability and operations (OBS)#


22. Security and assurance (SEC)#

22.1 Secrets management#

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.


24. Account lifecycle and support (SUP)#


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.

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.


27. Onboarding and activation (ONB)#

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)#


29. Language and localisation (LNG)#

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]

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]


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)#


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.


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-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#

AttributeTargetRequirement
Response latency p50, from end-of-turn detection≤ 800 msVOI-001
Perceived gap p50, from end of user speech≤ 2,200 msVOI-021
Response latency p95≤ 1,200 msVOI-002
Barge-in stop≤ 200 msVOI-010
Elder line availability≥ 99.9% monthlyDEG-011
Safeguarding ack (immediate)To be setSFG-003 [OD-08]
Unsupported claim rate (authoritative domains)0KNW-011
Safety classifier recallBaseline floor, release-gatingSFC-006
Audio retentionShort, automaticDAT-009
Transcript retentionLong, automaticDAT-010
DSAR / erasure turnaround≤ 1 calendar monthDAT-012, DAT-013
Telephony providers2 independentDEG-008
RPO (graph, consent, audit)≤ 15 minBCK-002
RTO (elder phone line)≤ 4 hBCK-003
Restore test cadenceQuarterlyBCK-005
Digest omission rate (safety events)Baseline floor, release-gatingEVL-015, EVL-016
Digest unsupported-assertion rateMeasured every releaseEVL-017
Transparency notice to elder user≤ 24 hTRN-004, TRN-005
Cancellation effort≤ signup effortCMR-002
Safety budget alert threshold75% consumptionSFB-005
Safety budget periodRolling 30 days, no carry-overSFB-001, SFB-008
Secret rotation on leaver≤ 7 daysSEC-020
STT and classifier evaluation channelProduction narrowband encodingVOI-022, VOI-023, SFC-012
Power-dependency disclosureBefore activationTRN-011
Access revocation on leaver≤ 24 hSEC-019
Exposed secret rotation≤ 24 hSEC-022

36. Traceability#

26.1 Brief problems P1–P10 → requirements#

Brief itemRequirements
P1 Latency with guardrails in pathVOI-001…VOI-007
P2 Hallucination toleranceKNW-001…KNW-011, EVL-003
P3 Speaker identificationIDN-001…IDN-011
P4 Consent for absent usersCNS-001…CNS-015, SUR-208
P5 Residency and sub-processorsDAT-001…DAT-008, SEC-002
P6 Publishable audit loggingAUD-001…AUD-011, ACC-001…ACC-010
P7 Safeguarding triage at scaleSFG-001…SFG-013, GEN-004
P8 Evals as disciplineEVL-001…EVL-014
P9 Telephony cost and abuseUSG-001…USG-011
P10 Graceful degradationDEG-001…DEG-013

26.2 Brief questions Q1–Q3 → requirements#

Brief itemRequirements
Q1 Customisation limitsCFG-001…CFG-012
Q2 Subscription modelBIL-001…BIL-008, USG-001…USG-002
Q3 Multiple family membersFGR-001…FGR-017, IDN-001…IDN-011

36.4 Commercial and operational coverage added at v0.3#

ConcernRequirements
Subject transparency parityTRN-001…TRN-010
The carer digest as a productSUM-001…SUM-011, EVL-015…EVL-017
Signup to first callONB-001…ONB-008
Reaching a humanHND-001…HND-005
Multi-language safety parityLNG-001…LNG-006, EVL-019
Consumer contract and subscription lawCMR-001…CMR-018
Marketing, analytics, ICO registrationPRV-001…PRV-009
Backup, restore, continuityBCK-001…BCK-009
Prompt injection and inbound abuseAIS-001…AIS-010, EVL-018
Data export and legal holdDAT-016…DAT-019
Outward safeguarding referralSFG-014…SFG-016
Vendor exit and portabilitySEC-011…SEC-013
Enterprise channelENT-001…ENT-011 (Appendix A)

36.5 Added at v0.4#

ConcernRequirements
Safety budgets and change freezeSFB-001…SFB-014
Secrets management (Infisical)SEC-008.1, SEC-014…SEC-028
Cost control must not erode safetySFB-012, SFB-013

36.6 Added at v0.6#

ConcernRequirements
Evaluation channel must match productionVOI-022, VOI-023, VOI-024, SFC-012
Digital voice power dependencyONB-009, ONB-010, DEG-014, DEG-015, TRN-011, CMR-019

26.3 Brief unknowns → open decisions#

Brief unknownOpen decision
U1 Build-vs-buy voice gatewayOD-16
U2 Persona engineering approachOD-17
U3 Family graph schemaOD-18
U4 Safeguarding classifier build-vs-buyOD-19
U5 Eval harness investmentOD-20

37. Open decisions register#

IDDecisionBlocks
OD-01Lawful basis and Article 9 condition per purposeCNS, DAT-015
OD-02LPA 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 capacityCNS-008, CNS-009
OD-03Fluctuating-capacity re-consent intervalCNS-011
OD-04Clinical scope boundary and medical device classificationKNW-008, KNW-010
OD-05Retention periods for audio, transcripts, auditDAT-009, DAT-010, AUD-009
OD-06Accent and atypical speech corpus sourcingVOI-014, VOI-015
OD-07Safety classifier recall floor and precision ceilingSFC-006
OD-08Safeguarding acknowledgement SLA per severitySFG-003
OD-09Break-glass disclosure windowACC-006
OD-10NHS / DSPT applicabilitySEC-010
OD-11Whether 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 callingSUR-108, CNS-014
OD-12Emergency call postureSUR-111
OD-13Availability target and its costDEG-011
OD-14Age assurance methodAAD-003
OD-15Bereavement data policySUP-002
OD-16Voice gateway build vs buyArchitecture
OD-17Persona engineering: prompts vs fine-tunesCFG-012
OD-18Family graph schema shape beyond RBACFGR
OD-19Safeguarding classifier build vs partnerSFC-010
OD-20Eval harness V1 investment levelEVL
OD-21DMCC subscription regime readiness ahead of spring 2027 commencementCMR-003, CMR-018
OD-22DPO appointment: internal, fractional, or externalPRV-009
OD-23RPO and RTO targets and their infrastructure costBCK-002, BCK-003
OD-24Bank and Action Fraud referral routesSFG-015
OD-25Whether the enterprise channel is pursued at allAppendix A
OD-26Supported language list and the order languages are addedLNG-005
OD-27Infisical self-hosted versus Infisical Cloud, and rotation intervalsSEC-018, SEC-025
OD-28Numeric value of each safety budgetSFB-001
OD-29Whether the service falls within telecare or technology-enabled care scope, and which standards and vulnerable-customer commitments would followCMR-019, TRN-011
OD-30Whether to pursue a wideband codec path on the post-switchover VoIP leg, decided from the VOI-024 deltaVOI-024

38. Verification strategy#

GroupPrimary methodNotes
VOIAutomated load and latency harness against synthetic call corpusPer-stage breakdown required for attribution
IDN, CNSScripted conversational tests plus legal reviewLegal review is a gate, not a comment
CFG, FGRProperty-based tests over permission triples plus static analysisStatic analysis proves CFG-010
SFC, SFGLabelled corpus evaluation plus tabletop exerciseTabletop covers the human pathway
KNWGrounding regression with zero-tolerance gate
AUD, ACCArchitecture review plus tamper-detection testIndependent reviewer preferred
DAT, SECDocumentary audit plus penetration test
DEGScheduled failure injectionQuarterly minimum
EVLMeta-evaluation: does the harness catch seeded regressionsSeeded-defect test
TRN, SUMScripted conversational tests plus labelled digest corpusOmission is the failure mode, not fabrication
ONB, HNDJourney walkthrough plus duplicate-number testONB-005 needs a deliberate collision test
CMR, PRVDocumentary audit plus consumer journey reviewLegal sign-off is a gate
BCKQuarterly restore drill with audit chain verificationUntested backups are not backups
AISRed-team suite against the live voice pathMust be run over the phone line, not the API
SFBDashboard inspection plus a deliberate budget-exhaustion drillThe drill is the test — an untriggered freeze is unproven
SEC (secrets)Scanning in CI, leaver drill, deploy-time failure injectionSEC-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#

VersionDateChange
0.12026-07-25Initial derivation from "The problems, not the pitch" v1.0.
0.22026-07-25EARS 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.72026-07-26Provenance 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.62026-07-26Added 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.52026-07-25Correctness 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.42026-07-25Added §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.32026-07-25Commercial 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-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.