Coverage is not the same as assurance
A financial-services firm may handle millions of calls, chats and complaints while reviewing only a small manual sample. Speech-to-text, classifiers and language models can examine a much larger population. That wider coverage can expose patterns that random sampling misses. It can also create false confidence if transcription error, weak labels or a persuasive summary becomes an “outcome score.”
Customer outcome is not directly observable in a transcript. The record may show disclosure, explanation, empathy, delay, vulnerability cues and action taken. A reviewer still needs policy, product, customer and case context to judge whether the interaction delivered the required outcome.
Define the outcome question before selecting models
The control design begins with a test point: what behaviour or outcome is being examined, which population is in scope, what evidence is required and who decides. “Quality” is too broad. A mortgage explanation, fraud warning, complaint response and investment-support conversation have different obligations and evidence.
| Test point | Observable evidence | Additional context | Decision owner |
|---|---|---|---|
| Required disclosure | Phrase, timing, acknowledgement | Applicable script or policy version | Quality or compliance reviewer |
| Customer understanding | Questions, corrections, confirmations | Product complexity and customer needs | Authorised reviewer |
| Vulnerability response | Cue, offered adjustment, channel treatment | Known needs and permitted handling | Customer-outcome specialist |
| Complaint recognition | Dissatisfaction, harm or requested remedy | Complaint definition and prior contacts | Complaints function |
| Advice boundary | Recommendation-like language and action | User role, product and regulated service | Compliance or advice supervisor |
| Resolution | Promised and completed action | Case state and postcondition evidence | Operations owner |
The test contract records inclusion, exclusion, sampling or coverage mode, labels, tolerances, evidence and escalation. It also defines legitimate unknown outcomes. A missing recording, incomplete transcript or unavailable case state should not receive a passing score.
The FCA Consumer Duty is outcomes focused and requires firms to assess whether they deliver good outcomes. It does not prescribe one interaction classifier. The FCA's July 2026 Mills Review anticipates AI-driven transformation in retail finance while emphasising accountability, consumer outcomes and risk-tiered automation. Those sources should shape control questions, not become generic prompt text.
Build a multi-record interaction case
A conversation rarely stands alone. The customer may have contacted the firm repeatedly. An agent may promise an action that completes later. A warm handover may split one journey across chat and voice. Outcome testing should therefore build an interaction case with stable identifiers and bounded time.
The case separates actor, customer, channel, contact reason, product, relevant vulnerability handling, actions, promises and completion. It also carries consent and privacy treatment. Recordings and transcripts are sensitive; test data should be minimised and access purpose-bound.
| Evidence object | Authority | Limitation |
|---|---|---|
| Audio recording | Captures the audible interaction | May omit screen actions or off-call work |
| Transcript | Searchable representation of audio | Contains recognition and diarisation error |
| Chat log | Exact recorded messages for that channel | May not show upstream bot or system state |
| CRM note | Staff member's recorded summary | Observation, not a verbatim source |
| Policy or script | Defines expected treatment for scope and date | Does not prove delivery or understanding |
| Action receipt | Shows system state changed | Does not prove the change met customer need |
The transcript is a derived artefact. Material findings should retain audio time offsets or exact message IDs so a reviewer can inspect the source.
Treat speech processing as its own evaluated system
Speech-to-text quality varies by accent, noise, code switching, channel compression, names and specialist vocabulary. Aggregate word error rate can hide failure on the phrases that matter, such as a monetary amount, negation or vulnerability cue.
Evaluation should include material phrase accuracy, speaker attribution, amount and date accuracy, negation, overlap and omitted audio. Low-quality regions route to playback or exclusion. The downstream model sees the quality map and must not state that a phrase was absent when the relevant audio was unintelligible.
The architecture also needs tamper and completeness checks. A recording start or stop failure, unexpected silence or missing segment becomes an exception. It cannot be treated as a clean interaction.
Combine deterministic tests, classifiers and language models
Not every test point needs a generative model. Required phrases, sequence, duration and completed system actions may be checked deterministically. Domain classifiers can identify topics, complaint cues or likely vulnerability signals. A language model can assemble cited evidence and compare it with a test contract.
| Method | Suitable work | Important limit |
|---|---|---|
| Rules | Required phrase, order, timing, action receipt | Synonyms and contextual meaning |
| Speech or text classifier | Known cue or topic detection at scale | Label drift and segment dependence |
| Anomaly detection | Unusual pattern or team shift | Anomaly is not poor outcome |
| Language model | Evidence synthesis and nuanced comparison | Unsupported judgement and sensitivity to context |
| Human review | Material contextual and conduct judgement | Capacity, consistency and anchoring |
The certainty gradient should determine routing. High-confidence, low-consequence passes can reduce manual review if validation supports it. Suspected failures, vulnerable-customer cases, severe outcomes and uncertain evidence receive human review. Some findings always require review regardless of score.
The model's confidence is not the customer's outcome. Calibration can help route work; it cannot confer authority.
Use risk-based sampling on top of broad screening
Population screening can rank or stratify interactions, but assurance also needs unbiased coverage. If reviewers see only model-selected cases, false negatives remain invisible and the model's blind spots define the control.
The sample design should retain strata by product, channel, journey, customer group, team, language, outcome severity and model confidence. Random samples estimate population performance. Targeted samples improve defect discovery. Disagreement samples identify label or boundary weakness. The proportions and analysis should be explicit.
| Sample stream | Purpose | What it estimates |
|---|---|---|
| Random | Detect false negatives and population trend | Unbiased outcome rate within design limits |
| High risk | Find likely material cases quickly | Case discovery, not prevalence |
| Uncertain | Improve boundaries and reviewer guidance | Ambiguity profile |
| Novelty | Detect new language, products or journeys | Emerging risk signals |
| Known controls | Verify stable positive and negative behaviour | Regression and pipeline health |
Reviewers should not see the model's final label before making an independent judgement on calibration samples. This reduces anchoring and allows honest agreement estimates.
Make findings evidence-linked and contestable
A finding candidate states the test point, observed evidence, source offsets, model or rule version, counterevidence, uncertainty and proposed severity. The reviewer can accept, amend, reject or request evidence. Rejected candidates remain useful for monitoring false positives.
The reviewer interface should lead with the relevant segment and policy requirement, not a long summary. It should show what the system did not consider. For a broken promise, the evidence includes both the spoken commitment and the downstream action record. For an advice-boundary concern, it includes the precise language and the staff member's authorised role.
Outcome and breach states remain separate. A poor outcome may require remediation without establishing a regulatory breach. A control failure may not have harmed a customer in the sampled case. The data model should not collapse them.
Evaluate models, trajectories and review operations
The evaluation set needs hard negatives, indirect language, multiple speakers, interrupted journeys, policy changes, vulnerability cues, sarcasm, code switching, ASR errors and delayed postconditions. It should include cases where the right answer is insufficient evidence.
| Layer | Measure | Material failure |
|---|---|---|
| Speech | Material phrase and speaker accuracy | Negation or amount reversed |
| Detection | Recall and precision by test point and segment | Vulnerability cue missed in one channel |
| Evidence | Citation accuracy and counterevidence coverage | Finding points to wrong part of call |
| Routing | Correct severity, abstention and reviewer path | Severe case auto-passed |
| Review | Inter-reviewer agreement and override quality | Anchored acceptance without evidence inspection |
| Population | Weighted estimates with sample design | Targeted sample reported as population prevalence |
The April 2026 US interagency model risk guidance explicitly excludes generative and agentic AI from its model scope while stating that other governance should determine appropriate controls. A population-testing system therefore needs an integrated governance pack across speech, classifiers, language models, rules, workflow and human decision, not a single model card.
Production monitoring tracks transcription quality, missing recordings, finding rate by segment, reviewer disagreement, false-negative samples, policy version, routing drift, queue ageing and remediation recurrence. A change in call mix can invalidate historical thresholds.
Connect findings to improvement without creating surveillance
The purpose of outcome testing is to improve customer treatment and control effectiveness. Findings should aggregate into themes with sufficient evidence and uncertainty. Individual staff use must follow clear policy, notice, access and fairness controls. A system designed for customer assurance should not quietly become an opaque performance-ranking tool.
Access to recordings, transcripts and findings should be purpose-bound. Retention follows the relevant record policy. Evaluation datasets require minimisation, lawful use and separation from general model training. Reviewer corrections do not automatically become training labels without quality and privacy controls.
The NIST AI RMF provides a useful govern, map, measure and manage structure. It should be instantiated in the operating process: named owners, data and system maps, disaggregated measures, incident response and documented risk treatment.
A measured path to production
Start with one outcome question and one channel where policy, evidence and reviewer ownership are clear. Run beside the existing sample process. Reconcile every disagreement. Prove that source links, postconditions and unknown outcomes work before expanding population coverage.
Then add test points and channels in controlled releases. Use independent random sampling to estimate blind spots. Adjust reviewer capacity before widening automated screening. Release thresholds should be set by consequence and evidence, not by a universal model score.
The value case measures reviewed coverage, time to material finding, false-negative discovery, evidence-preparation effort, repeated harm, remediation closure and customer-outcome improvement. It should not claim success from transcripts processed or alerts generated.
Work one outcome case across channels
Consider whether a customer in financial difficulty received appropriate support across a call, two secure messages, a payment arrangement and a later complaint. No individual record proves the outcome. The call contains uncertainty about income. The message offers several options. The payment system records an arrangement. The complaint later says the customer did not understand a consequence.
The case builder first resolves the interaction boundary using customer, product, journey and time. It records source availability before interpretation. If one recording is missing, the case is incomplete rather than clean. Speech processing produces time-aligned words, speakers and confidence. Policy retrieval selects the relevant test points by product, customer state and interaction time.
Deterministic checks identify whether required disclosures and actions occurred. A classifier locates likely vulnerability and comprehension cues. A language model assembles cited evidence for and against each test point. It may state that the customer expressed uncertainty and that the staff member offered options. It cannot infer comprehension merely from the absence of an objection.
The reviewer sees the original audio interval, transcript, messages, payment record, policy point and contradictory evidence. The finding separates process adherence, likely customer understanding, downstream outcome and remaining uncertainty. An interaction outcome is a reasoned case conclusion, not a sentiment score attached to a call.
Test fairness across segments, channels and evidence quality
Aggregate precision can hide harmful differences. Evaluation should be disaggregated by channel, language variety, accent, recording quality, product, vulnerability indicator, interaction length and journey type where lawful and statistically defensible. The purpose is to find performance and treatment gaps, not to create unsupported personal classifications.
| Slice | Question | Guardrail |
|---|---|---|
| Audio quality | Does material-cue recall fall on poor recordings? | Report uncertainty; do not infer absence |
| Language or accent | Are transcription and speaker errors uneven? | Expert review and targeted improvement |
| Channel | Does message-only evidence receive different treatment? | Channel-specific test design |
| Product | Are policy points and thresholds correctly selected? | Versioned applicability rules |
| Vulnerability context | Are support cues found without over-labelling? | Evidence-linked proposition and human review |
| Interaction length | Does context truncation omit late disclosures? | Coverage checks and chunk lineage |
| Reviewer group | Does disposition vary after controlling for case mix? | Calibration and independent adjudication |
Small groups require confidence intervals and suppression rules. A raw percentage from a few cases should not become a fairness conclusion. Where protected attributes are unavailable or inappropriate, the programme can still test operational proxies such as channel, transcription quality and service route while documenting the limitation.
Thresholds may differ by test point because consequence and base rate differ. They should not vary in a way that reduces protection for a customer group. Any threshold change needs replay on stable cases, impact analysis and owner approval. Fairness assurance belongs in the release gate and production monitoring, not in an annual appendix.
Verify postconditions beyond the interaction
Many outcome questions depend on what happened after the conversation. A promised refund, forbearance action, complaint referral or accessibility adjustment must be verified in the relevant system. The language model cannot establish completion from a staff member's statement alone.
The postcondition contract names system, identifier, state, time limit and safe retry. It distinguishes proposed, submitted, completed, reversed and unknown. An action recorded in notes is not equivalent to an executed servicing state. A payment arrangement that was created and immediately cancelled may require a different outcome conclusion from one that remained active.
Cross-system matching needs its own quality controls. Customer and case identifiers, timestamps and product scope should reconcile deterministically where possible. Probabilistic matching creates a review item rather than silently attaching another customer's event. Evidence manifests preserve the queried interval and source version.
This approach also improves remediation. If outcome testing finds that a promised action was not completed, the workflow can create a proposed correction under human approval and verify the result. It does not let the testing agent edit a customer account directly. Detection authority and remediation authority remain separate.
Calibrate reviewers and measure decision quality
Human review is not a perfect reference by default. Reviewers can interpret policy differently, overlook counterevidence or anchor on the model's suggested finding. Calibration should therefore use blind independent review, structured disagreement and adjudication by authorised domain experts.
Review forms separate evidence sufficiency, test-point disposition, severity and required action. Free text explains reasoning but does not replace typed fields. The interface shows supporting and contrary spans before any suggested conclusion. Reviewers can ask for missing evidence and record why a source is unreliable.
Measures include agreement by test point, direction of overrides, evidence-opening behaviour, time to decision and recurrence after feedback. A high agreement rate after exposing a strong model recommendation may indicate anchoring. Periodic blind cases help detect it. Quality review samples both passes and findings because false negatives are the central risk in broad screening.
Reviewer feedback routes to the responsible component. Transcript correction goes to speech operations. Wrong policy selection goes to applicability. Unsupported drafting goes to the evidence composer. Disagreement about the expected customer outcome goes to the policy owner. A single override count cannot tell the programme what to improve.
Run a closed remediation and learning loop
A confirmed finding becomes a governed case with owner, severity, customer impact, required action and due date. Similar findings may share a systemic cause, but item-level lineage remains. The platform can cluster themes and suggest a causal hypothesis; accountable owners accept the remediation plan.
| Stage | Evidence required | Closure condition |
|---|---|---|
| Finding accepted | Reviewed interaction and test-point rationale | Named owner and impact assessment |
| Immediate protection | Required customer or service action | Verified postcondition |
| Root cause | Process, policy, training, system or data evidence | Challenge by control owner |
| Remediation | Defined change and affected population | Implementation receipt |
| Lookback | Search logic, population and sample design | Reviewed affected cases |
| Effectiveness | Independent outcome measure after change | Sustained improvement within range |
The lookback query is versioned and reviewed. It should not assume that the detection model defines the full affected population. Independent sampling estimates cases the query missed. Closure evidence remains separate from the team that implemented the fix where assurance requires independence.
Architecture review should ask whether missing records can be mistaken for clean cases, whether speech uncertainty is carried into findings, whether postconditions are checked in authoritative systems, whether segment performance is visible, whether reviewers are protected from anchoring. Whether remediation closure proves an improved customer outcome.
Anchor the service in conduct and data governance
The operating design should start from the outcome, policy and lawful purpose that justify examining interactions. The FCA Consumer Duty provides an outcome-centred supervisory frame for UK retail financial services. The FCA's guidance on vulnerable customers is relevant when designing evidence, support and review. These sources do not prescribe one model or monitoring architecture; they shape the questions accountable firms must answer.
Data governance should define which interactions are in scope, who can access them, how long derived artefacts remain, and whether outputs may be used for coaching, control testing, complaint handling or employment decisions. These purposes are not interchangeable. A model trained or evaluated for one purpose should not be repurposed through a dashboard setting.
The ICO guidance on AI and data protection provides a useful basis for purpose, transparency, data minimisation and individual rights. Governance must cover recordings, transcripts, embeddings, case state, prompts, model traces, reviewer notes and evaluation samples. Removing the source audio while retaining a searchable derived representation is not deletion.
Role separation limits internal surveillance risk. Conduct assurance reviewers see what they need for the case. Line managers receive approved thematic or coaching outputs under policy. Model developers use curated and minimised evaluation data. Operations staff diagnose through metadata unless deeper access is authorised. Exports and downstream joins are logged and restricted.
Design production economics around reviewed outcomes
Population-scale processing can be expensive. The service should route work according to evidence need and consequence. Deterministic metadata checks run broadly. Speech and classifiers screen the eligible population. More expensive language-model analysis is invoked for uncertain or material cases. Human review remains focused but includes independent random samples.
Cost per reviewed and accepted outcome is more useful than cost per transcript. The model should record transcription, retrieval, analysis, evidence storage and review effort by test point and channel. Quality and cost are examined together. A cheap route that loses material cues creates false economy; an expensive route applied to every interaction can make the service unsustainable.
| Economic measure | What it reveals |
|---|---|
| Cost per eligible interaction | Base population burden |
| Cost per material reviewed case | Routing efficiency |
| Reviewer minutes by test point | Evidence and interface quality |
| False-negative discovery cost | Price of blind spots |
| Remediation value and recurrence | Whether findings improve outcomes |
| Storage and replay cost | Sustainability of evidence retention |
Capacity tests should use peak call volumes, long interactions, poor recordings and correlated events such as product incidents. Queue limits and degradation policies are decided in advance. The service may defer low-consequence enrichment, but it should not silently reduce population coverage or evidence quality.
The business case should reward better detection, faster protection and sustained improvement, not the amount of content processed. That keeps investment connected to customer and control outcomes.
Make release decisions test-point specific
A service should not receive one broad approval for “conduct AI.” Each outcome test point has its own policy basis, source needs, error consequences, threshold, review route and remediation. A model may be reliable for disclosure presence and weak for comprehension. The first capability can proceed while the second remains under supervised study.
The release pack states eligible population, exclusions, source coverage, segment results, false-negative sampling, reviewer capacity, access policy and rollback triggers. It names what the system may do: screen, assemble evidence, recommend review priority or create a proposed finding. It also names what remains prohibited, such as automatic adverse action, staff ranking or customer-account change.
Change impact is equally specific. A speech model update may affect amount and negation recognition across several test points. A policy version may affect only one product. A reviewer-interface change may alter anchoring. The platform maps components to test points and replays the affected evaluation sets before release.
Rollback preserves case and evidence records. New screening can pause while accepted findings and remediation continue. Previously reviewed cases are not silently rescored. If a defect could have hidden material outcomes, the owner defines a lookback population and independent review.
Granular release authority makes the system easier to expand because every capability has a visible basis and reversal path. It also prevents a good result in one test from being used to justify unrelated automation.
The operating committee should review quality, customer impact, privacy, reviewer capacity, source coverage and cost in one view. Separate dashboards can make a technically improving model appear successful while queues age or remediation repeats. Decisions to widen a channel or test point should name the evidence and residual limits.
Front-line feedback is useful when it points to policy ambiguity, missing journey context or an impractical remediation route. It should not permit a team to suppress inconvenient findings. Feedback objects retain type, evidence and disposition. Material challenges go to an independent owner where the operating model requires it.
Customer corrections and complaints can reveal missed outcomes, but they are not a complete ground truth because many harms are never reported. The evaluation programme keeps independent sampling and targeted expert review. It also compares themes before and after policy, training or system changes so that closure reflects sustained behaviour.
This creates a disciplined path from broad visibility to specific action. The service remains valuable when it finds uncertainty, missing records and operating weakness, not only when it confirms compliance.
Population-scale outcome testing is credible when it expands visibility without hiding uncertainty or human responsibility. The platform's best contribution is not a single score. It is a reliable chain from interaction evidence to a reasoned, contestable and owned conclusion.