# UX design of AI behaviour-vs-speech (Say Do Gap) features in AI research assistants Market Research Report - Global

**Generated on:** 2026-10-19 11:04:45.094399  
**Industry:** UX design of AI behaviour-vs-speech (Say Do Gap) features in AI research assistants  
**Geography:** Global  
**Details:** # Deep research prompt: UX of Say Do Gap (AI Vision) in Compass

## Your role

You are a senior UX researcher specialising in human-AI interaction, research tooling and evidence presentation. Produce a rigorous, cited research report that a product designer can turn directly into design guidelines and a concept test plan. Use UK English.

## Context

Voxpopme is a video-based qualitative research platform. Respondents record video answers to study questions. Researchers (mostly enterprise insight teams at brands and agencies) analyse these responses.

Compass is Voxpopme's AI research assistant. Researchers chat with it to analyse a project. It produces findings, reports, counts and quotes, with video clips embedded as evidence.

Say Do Gap (also called AI Vision) is a new capability. An AI model watches each video and records what people actually do, then compares this with what they say. Examples: free-pouring cleaner while claiming to use one capful, how a can is opened, whether dough is damaged. Observations are stored as codes or tags per response, guided by the project's objectives and questions. They appear:
- On the single response view
- In a "said vs seen" view (a graph, observed-behaviour tags and a "What it means" tab)
- Inside Compass, so researchers can ask about behaviour across a project

Status: released behind a flag and tested with clients for around two months. Not yet released to all clients.

Product owner's position: no full UX review is needed because Vision is "additional data given to Compass, so the experience should seem similar, just smarter." Treat this as a hypothesis to test, not a given.

Release blockers already set:
1. Vision must run on every relevant response, including new ones.
2. Compass must accurately know which responses Vision has processed.
3. When Compass points to "the video where X happens", it must be right.

Problems found in client testing:
- The same behaviour was coded three different ways across responses because codes were created per response, not per project (since reduced in the backend).
- Compass showed the wrong videos as evidence, or appeared to.
- Some claims were overstated, especially with small samples.
- Compass analysed only a third of responses until asked again.
- Compass silently swapped in a different study when asked to compare two.
- Researchers cannot easily tell which findings rely on video observation rather than transcripts.
- Researchers want margins of error on counts.
- The level of detail (tags, booleans) may not suit all audiences.
- When Vision has not run, Compass says so but offers no "run analysis" action.

Customer requests: a project-level Vision report, a toggle for Vision analysis in Compass, Vision data in exports, a flag when observed behaviour contradicts screener or survey answers, and a collapsible Vision section on long response pages.

Wider Compass issue: Compass extracts quotes and inserts the matching video inline, mid-text. This breaks reading flow and can make the video look unrelated to the claim. The lead engineer has suggested returning to attributed quotes. Engineering prefers deterministic, non-LLM counts and code mapping to build trust. A UI for users to review or merge codes was floated but engineering is unconvinced.

Planned self-serve setup with two flows:
- Auto-detect: the system detects that a project would benefit and prompts the user to switch Vision on.
- Manual: users add behavioural observation through additional settings.

Known unknowns: whether designs exist for these flows; whether Vision works on screenshare or non-face-cam video; whether Compass must be enabled for Vision to run; how users currently discover the feature.

## Research sections

Answer every question. Where evidence is thin, say so and reason from the closest analogous domain.

### 1. Is "same experience, just smarter" valid?
- What does the evidence say about adding a new data modality or inference type to an existing AI assistant without changing the interface? Does user trust or mental model shift when an assistant starts making observational rather than textual claims?
- How do users calibrate trust differently for claims about what someone did (inferred from video) versus what someone said (transcribed)?
- What failures occur when new AI capabilities are introduced invisibly? Give documented examples.
- What is the minimum UX change needed to keep trust appropriately calibrated?

### 2. Showing observed behaviour next to self-report (said vs seen)
- What are proven patterns for juxtaposing two data sources that may contradict each other (for example, stated vs revealed preference in behavioural economics, survey vs analytics, diary vs observation in ethnography)?
- Which visualisations best communicate a gap between said and done at individual and project level (diverging bars, paired dot plots, matrices, Sankey, quadrants)? Which are misread most often?
- How should a contradiction be framed so it reads as an insight, not as an accusation that the respondent lied?
- How should a "What it means" interpretation layer be separated from the raw observation so researchers can audit the leap from data to meaning?
- How should contradictions with screener or survey answers be flagged without implying screener fraud?

### 3. Provenance: signalling the source of a finding
- What patterns exist for labelling the source of an AI claim (video observation, transcript, survey, combination)? Include badges, colour coding, icons, footnote markers and hover provenance.
- How do research repositories, BI tools and AI search products (for example Perplexity, Elicit, NotebookLM, Dovetail, Marvin) show provenance per sentence or per claim?
- When a finding draws on mixed sources, how should that be shown without clutter?
- What is the evidence that provenance labelling changes reliance behaviour, not just stated trust?

### 4. Confidence, sample size and margins of error
- How should qualitative-scale counts (for example 7 of 12) be presented to avoid overclaiming? Is a margin of error appropriate for qual samples, or misleading? What do statisticians and qual methodologists recommend?
- What does uncertainty visualisation research (for example frequency framing, icon arrays, intervals, hedged language) say about lay and expert interpretation?
- Should model confidence per observation be shown? What happens to trust and workload when it is?
- How should language generation itself be constrained (hedging rules, minimum n before generalising, "in this sample" framing)? Give example copy patterns.
- What is the evidence for deterministic counts versus LLM-generated counts in building trust?

### 5. Processing coverage and completeness
- How should an AI assistant communicate which part of a dataset it has actually analysed (for example "Based on 34 of 102 responses")?
- What patterns exist for coverage indicators in analytics, search and data pipeline tools?
- How should the assistant behave when coverage is partial: refuse, warn, proceed with caveat, or offer to complete?
- How should scope be confirmed when a user asks to compare multiple studies, to prevent silent substitution? What do confirmation and scope-echo patterns look like?

### 6. Video evidence alongside AI-generated text
- Compare inline video mid-text, attributed text quotes with expandable video, footnote-style citations, side panels, evidence drawers and end-of-section galleries. What does evidence say about reading flow, comprehension, perceived relevance and verification behaviour for each?
- How should a clip be cropped, timestamped and labelled so its relevance to the claim is obvious (for example highlighting the moment of behaviour, captioning what to look for)?
- For observed behaviour (not speech), what replaces a quote? Thumbnails, keyframes, short loops, timestamp plus description?
- How do readers verify a claim in practice? How many check sources, and what affects that?
- What are the accessibility implications of each pattern (screen readers, captions, motion, autoplay)?

### 7. Evidence accuracy and grounding
- What UX patterns help users detect a mismatched citation quickly?
- How should the system respond when a user reports a wrong clip? What feedback loops exist in comparable products?
- What design and system practices (for example claim-to-evidence linking, grounded generation, verification passes) reduce wrong-evidence errors, and which are visible to the user?

### 8. Empty, partial, loading and error states
- Best-practice patterns for "not analysed yet" states that offer a clear next action (for example "Run Vision analysis on 58 responses").
- How should long-running, costly AI processing be communicated: progress, estimated time, notification on completion, partial results as they arrive?
- How should states differ for: never run, running, partially complete, failed, not applicable (for example screenshare or no visible behaviour), and new responses arriving after a run?
- Example copy for each state, written in plain, US/UK neutral language.

### 9. Reviewing and correcting AI-generated codes
- How do qual analysis tools (for example ATLAS.ti, NVivo, MAXQDA, Dovetail, Marvin, Condens, Looppanel) handle AI-suggested codes, merging, renaming and codebook management?
- What does human-in-the-loop research say about when correction UIs increase trust versus add burden that users skip?
- Lightweight alternatives to a full review UI: spot-check sampling, accept or reject per code, project-level codebook preview before running, "these look the same, merge?" prompts.
- Should corrections propagate to Compass answers? How should that be communicated?

### 10. Opt-in and auto-detect for costly AI analysis
- Patterns for suggesting an AI capability when the system detects relevance (proactive suggestions) versus manual opt-in in settings. What makes proactive suggestions feel helpful rather than salesy or intrusive?
- How should cost (credits, money, time) be communicated before a user commits?
- How should a Compass-level toggle for Vision data behave, and what are the risks of users forgetting it is on or off?
- How should discoverability be handled for a feature behind a flag moving to general release?

### 11. Audience and level of detail
- How should the same observational data be layered for different audiences: hands-on researchers, insight managers, executive stakeholders?
- Patterns for progressive disclosure from narrative summary to tags to raw booleans to video.
- What should a project-level Vision report contain, and how should Vision data appear in exports (CSV, PPT, reports) without losing provenance?
- Collapsible sections on long response pages: default open or closed, and what evidence informs that?

### 12. Ethics, consent, privacy and regulation
- What respondent consent and disclosure is expected when AI analyses behaviour in video, beyond speech? Reference MRS Code of Conduct, ESOMAR guidance and Insights Association guidance.
- How does the EU AI Act treat behavioural observation versus emotion recognition and biometric categorisation? What must researchers be told? Consider UK GDPR and special category data.
- What UX signals help researchers stay compliant (for example consent status on responses, warnings when analysis touches faces or emotions)?
- Reputational risks of "said vs seen" framing for respondents and clients.

### 13. Competitive landscape
- How do Outset (visual intelligence), Conveo, Listen Labs, Discuss.io, Medallia LivingLens, Rival, Qualtrics video features and any other AI-moderated or video qual platforms present observed behaviour, provenance, confidence and video evidence?
- How do facial coding and behavioural analytics tools (for example Realeyes, Affectiva or Smart Eye, iMotions, Noldus) present observation data, confidence and caveats? What lessons transfer and what should be avoided?
- What do these tools do for empty states, opt-in and cost?
- Where is there a clear gap Voxpopme could own?
- Separate verified product behaviour (documentation, demos, reviews) from marketing claims.

### 14. Edge cases and failure modes
- Screenshare, non-face-cam, poor lighting, off-camera actions, multiple people in frame.
- Behaviour that is ambiguous or culturally variable.
- Very small samples (n under 10) and very large ones.
- New responses arriving after analysis, and studies being compared that were analysed with different codebooks.
- What researchers secretly distrust about AI observation that they will not say in an interview.

## Output instructions

1. Start with a one-page executive summary: the ten most important guidelines, ranked by impact on trust and correctness.
2. For each section, give: findings, evidence (cited, with links), evidence strength (peer-reviewed, industry research, vendor documentation, expert opinion), and specific design guidelines a designer can act on.
3. Prioritise evidence from research and analysis tools, AI analytics products and human-AI interaction literature (for example Microsoft's Guidelines for Human-AI Interaction, Google PAIR People + AI Guidebook, research on appropriate reliance, explainability and uncertainty visualisation). Flag where evidence comes from adjacent domains.
4. Clearly separate what UX can solve from what requires model or backend fixes. Do not propose UI that hides an accuracy problem.
5. Map recommendations to the three release blockers, then to post-release improvements. Use Must, Should, Could.
6. Flag trade-offs and anything surprising or counter-intuitive.
7. Provide a concept test plan for researchers: 6 to 8 testable hypotheses, the concepts or stimuli to compare (for example inline video vs attributed quotes vs side panel), tasks, success measures (including calibrated trust, verification behaviour, error detection rate and time to insight, not just preference), recommended sample and method.
8. Include example UI copy for key states and labels, in plain language that works in both US and UK English.
9. Do not invent sources. If you cannot verify a claim, say so.

---

# Designing Trustworthy Behavioural Evidence in Voxpopme Compass

## Executive Summary

**Recommendation: retain Compass's familiar chat interface, but change its evidence contract before general release.** "Same experience, just smarter" is a hypothesis, not a safe release assumption. Video observation introduces uncertainty about visibility, interpretation and coverage that transcript analysis does not make equally apparent. Human-AI interaction research supports calibrated reliance, not maximum trust; explanations and citations can increase confidence without making decisions more accurate. [15][1][45]

The following ten guidelines are ranked by their likely impact on correctness and appropriately calibrated trust. **Must, Should and Could are recommendations**, not descriptions of existing Compass functionality. Product-specific failures and release status come from the supplied brief; they have not been independently audited.

- **1. Must - Make Every Evidence Link Correct**: A historical generative-search audit found that only **74.5% of citations supported their associated statement**. A real source is not necessarily supporting evidence. -> Bind each claim to the correct response, asset and time span; treat wrong-clip errors as a backend release blocker, not a presentation defect. [7]
- **2. Must - Expose Processing And Answer Coverage**: Google Analytics makes data-quality limitations inspectable; Compass's reported partial analysis requires an equivalent, but AI-specific, contract. -> Show "34 of 102 eligible responses processed" and separately state how many processed responses the answer actually used. Never imply completeness from a partial retrieval. [22]
- **3. Must - Lock Study Scope**: Power BI's Copilot documentation recognises the importance of report/model context and clarification. -> Echo study names, filters and versions before comparisons; never silently substitute an unavailable study. [23]
- **4. Must - Separate Observation From Interpretation**: Facial movements are not reliably diagnostic of particular emotions across contexts. Physical-action detection also needs bounded claims, although it is a different task. -> Present "what was said", "what was visible" and "possible meaning" as separate, inspectable layers. [33]
- **5. Must - Count Deterministically And Name The Denominator**: AAPOR advises against conventional sampling margins of error for non-probability samples. -> Generate counts from canonical records, show participants or responses explicitly, and distinguish unprocessed, unobservable and absent behaviour. Do not attach population-style margins of error to ordinary qualitative recruitment. [6]
- **6. Must - Label The Source Of Each Material Claim**: Citations increase stated trust, but source checking is limited. -> Use compact, textual provenance labels such as "Video observation" and "Transcript", with claim-linked evidence available on demand. Do not mistake a badge for proof of calibrated reliance. [13]
- **7. Must - Make Missing Analysis Actionable**: ATLAS.ti demonstrates explicit selection, processing-time information and background analysis. -> Replace passive "Vision has not run" messages with an eligible-response count, cost preview, clear action and completion notification. [43]
- **8. Should - Keep Reading And Verification Connected**: Dovetail documents citation-to-clip navigation and source previews without leaving the conversation. -> Test attributed quotes or observation descriptions with an expandable evidence panel against mid-paragraph video; do not assume inline playback is best. [14]
- **9. Must - Preserve Consent And Correction Lineage**: MRS and Insights Association guidance require transparency about AI processing and human oversight. -> Show consent/permission status, maintain project-level code versions, and propagate corrections into counts and future answers while marking older outputs as out of date. [27][28]
- **10. Should - Test Correct Reliance, Not Preference Alone**: Cognitive-forcing interventions can reduce overreliance while being less liked. -> Measure acceptance of supported findings, rejection of wrong ones, evidence-checking effectiveness and time to a defensible insight; use satisfaction as a secondary measure. [1]

**Commercial implication:** the strongest positioning is not "AI sees what people really mean". It is **auditable behavioural evidence that enterprise researchers can challenge, correct and share**. The rest of this report turns that positioning into design and release decisions.

## 1. A New Modality Requires A New Evidence Contract

**Finding.** Keeping the same interaction shell is reasonable; keeping the same source, scope and uncertainty signals is not. Microsoft's human-AI interaction guidelines were evaluated with **49 design practitioners across 20 AI products**, while Google PAIR explicitly frames trust as knowing when to apply judgement rather than trusting probabilistic systems completely. Neither establishes that adding video observation to a qualitative assistant can safely be invisible. [11][15]

The important distinction is not "text is factual, video is uncertain". Transcription can mishear; quotes can lose context. However, a transcript claim often permits direct word-for-word checking, whereas an observational claim adds choices about the relevant person, object, action, duration, visibility and category. An interpretation such as "wasteful use" adds another inferential step. These are different warrants for belief, even when delivered in the same fluent voice.

**Case study - explanations that increase authority without sufficient scrutiny.** In Buçinca and colleagues' controlled nutrition task, explanations could function as competence signals rather than information people scrutinised. Cognitive-forcing designs reduced overreliance, but did not eliminate it and could be less preferred. This is adjacent-domain evidence, not an evaluation of enterprise researchers or video analysis. Its practical lesson is that making Compass sound more capable may worsen reliance unless evidence remains easy to inspect. [1]

**Documented failure analogues.** A historical audit of generative-search systems found that only **51.5% of generated sentences were fully supported** by their citations. The problem was not merely missing links: sources could support only part of a claim or contradict it. Power BI's documentation separately recognises context-selection and clarification needs. These demonstrate grounding and scope failure mechanisms, not proof that invisible capability changes caused them. The supplied Compass incidents - partial analysis, wrong clips and substituted studies - are the closer product-specific warning signs. [7][23]

**Evidence strength:** peer-reviewed HAI research and a research audit; vendor documentation for the BI analogy. **Direct evidence comparing "silent video upgrade" with an explicit modality change in qualitative assistants is thin.**

**Minimum design change - Must:** preserve chat, but add a persistent analysis-scope strip; claim-level source labels; processed/eligible coverage; inspectable timestamped evidence; and an actionable unavailable/error state. **Backend - Must:** supply these from actual processing and retrieval records, not from the language model's recollection of what it analysed.

**Decision:** commission a targeted UX review of the evidence contract, not necessarily a wholesale redesign of Compass.

## 2. Frame Said-Versus-Seen Differences As Questions, Not Accusations

**Finding.** A discrepancy is evidence of a difference between records, not evidence of dishonesty. A peer-reviewed study of exercise reporting found that direct survey answers could express identity and idealised self-understanding rather than deliberate deception. In one comparison, campus exercise reports averaged **1.74 days**, compared with **1.08 days** in admission records. The study also shows why measurement context matters: asking questions can itself affect behaviour. [20]

**Case study - the cleaner demonstration in the supplied brief.** "I use one capful" and a clip of direct pouring may differ because usual practice differs from this demonstration, the question referred to another occasion, the cap was used off-camera, or the amount cannot be established visually. A useful observation is "Pours directly from the bottle into the bucket". "Uses more than one capful" needs evidence of quantity; "lies about dosage" is an unjustified interpretation. Pair the exact question and answer with the relevant visible sequence before presenting a gap.

For individual responses, use aligned **Said / Observed / Interpretation** cards. Include question wording, time reference and the option "Cannot assess". At project level, choose a chart only after defining whether the records are paired, the units match and missingness is known.

| Visualisation | Best use | Main misreading risk | Recommendation |
|---|---|---|---|
| Paired dot plot | Comparing stated and observed measures on the same scale and population | Treating different measures or unpaired groups as a within-person gap | Should: use direct labels and a shared denominator |
| Concordance matrix | Paired categorical answers: agreement, difference and unknown | Reading unknown as disagreement or treating cells as moral judgements | Must: include unassessable/missing categories |
| Diverging bars | A clearly defined signed difference | Confusing direction, percentage-point differences and percentages | Could: show the underlying counts alongside the difference |
| Sankey | Genuine paired movement between categories | Inferring time, causation or precise magnitude from complex flows | Could: reserve for sufficiently clear transitions; provide a table |
| Quadrants | Exploratory prioritisation using two justified measures | Treating arbitrary cut-offs as natural categories | Could: disclose thresholds; avoid person-level "truthfulness" quadrants |

These are design assessments, not a verified head-to-head ranking of these charts for Say Do Gap. No strong evidence reviewed establishes which is most frequently misread in this exact task.

Separate the interpretation layer with a heading such as **"Possible interpretation"**, its supporting observations, alternative explanations and contradictory evidence. A "What it means" tab should not conceal the leap from observation to meaning. For screeners, use **"Difference from earlier answer - review context"**, displaying both questions and dates; never auto-label fraud or exclude a respondent on that basis alone.

**Evidence strength:** peer-reviewed measurement research, transferred from an adjacent domain; chart selection and wording are expert recommendations.

**Decision:** make the unit of comparison an auditable pair of records, not an AI verdict about a person.

## 3. Put Provenance At The Claim, Not Just At The Answer

**Finding.** Provenance has at least three jobs: identify the source modality, locate the supporting material and show how that material supports the claim. A generic "Sources" list performs only part of this job. Historical generative-search research distinguishes citation support coverage from citation correctness; a linked document can be genuine while failing to support the statement beside it. [7]

| Product pattern | Publicly documented behaviour | Transfer to Compass | Limitation |
|---|---|---|---|
| Dovetail | Individual citations jump to clips; source hover cards and peek overlays preserve conversation context | Claim-linked preview plus deliberate playback | Documentation establishes behaviour, not a measured comprehension gain |
| Elicit | Vendor describes sentence-level source citations for generated claims | Keep support close to each material claim | A vendor claim, not independent proof of citation accuracy |
| NotebookLM | Help describes using selected sources and citations to quotes, text and images | Make the active source set visible and inspectable | Does not establish observational-video grounding quality |
| Perplexity | Help describes numbered source links | Compact markers can reduce repeated source text | A numbered link does not identify which inference it supports |
| Marvin | Vendor describes tracing insights to original sources and producing clips/reels | Preserve a route from narrative back to source | Detailed observational provenance and confidence controls were not verified |

The useful convergence is **local evidence access with persistent context**, not any particular badge or icon. [14][21][49][60][56]

**Case study - citations and checking are different outcomes.** In Ding and colleagues' study, citations increased reported trust, but only **193 of 1,976 cited answers were manually checked, or 9.77%**. **83 of 197 participants** checked at least one. These are different denominators: it would be wrong to say that only 9.77% of people checked sources. Checking was associated with lower trust, but that association does not establish causality. [13]

A separate AI-search preprint found that invalid references were not reliably noticed. Taken together, the evidence argues against assuming that adding provenance automatically changes reliance appropriately. It does not establish a universal source-checking rate for professional researchers. [18]

**Design - Must:** use short text labels: **Transcript**, **Video observation**, **Survey**, **Combined**. Pair icons with words; never rely on colour alone. Expand "Combined" into the individual evidence contributions rather than suggesting that every source independently supports every clause. A hover preview must also work through focus, click and touch. Counts should open the contributing set, not one persuasive example.

**Backend - Must:** store claim-to-source relationships and source roles. **Should:** distinguish "AI-generated observation", "researcher reviewed" and "corrected"; avoid an ambiguous "verified" badge.

**Evidence strength:** vendor documentation; empirical citation/trust research, with general-question and search tasks rather than qualitative analysis.

**Decision:** provenance should let users challenge a specific claim with minimal effort, not merely make the whole answer look scholarly.

## 4. Show Counts Honestly Without Inventing Statistical Precision

**Finding.** A conventional margin of sampling error is generally inappropriate for purposive, convenience or opt-in qualitative samples. AAPOR distinguishes probability-sampling precision from model-based uncertainty, which requires explicit assumptions. A narrow interval cannot repair selection bias or turn qualitative recruitment into a representative sample. [6][10]

**Case study - the request for margins of error.** In the supplied brief, researchers ask for uncertainty around counts. The underlying need is legitimate, but "7 of 12 +/- X%" would collapse several different uncertainties into one misleading number. The better response is to expose what was processed, what was visible, how the code was applied and what can be inferred about this sample.

| Uncertainty | What it means | Appropriate presentation |
|---|---|---|
| Recruitment/inference | Whether these participants represent a wider population | "In this study"; recruitment and sample limitations |
| Processing coverage | Whether relevant responses were processed and included | Exact processed/eligible and used/processed counts |
| Observation/classification | Whether the action is visible and correctly coded | Assessable/unknown counts, review state and actionable limitations |
| Interpretation | Whether the observation supports the proposed explanation | Separate hypothesis, alternatives and counterexamples |

The first priority is not an error bar: it is ensuring that these four questions cannot be confused.

**Illustrative copy:** "The action is visible in 10 of 12 responses. Seven show direct pouring; two responses cannot be assessed." If each response represents a different participant, say so. If participants submit repeated entries, report both units and avoid treating entries as independent people. Do not turn "7 of 12 in this study" into "58% of consumers".

Uncertainty research does not support a simple rule that numbers destroy trust. Van der Bles and colleagues' five experiments, involving **5,780 participants**, found generally limited trust costs from numerical uncertainty; verbal uncertainty could have different effects. But that does not legitimise an interval whose statistical assumptions are inappropriate. Icon arrays are not automatically superior either: a controlled risky-choice study found no overall performance improvement and found that random icon layouts changed perceived probabilities. [37][44]

**Model confidence - Should:** default to actionable information such as **"Needs review: the action is partly off-camera"**, rather than an unvalidated percentage. A confidence experiment improved behavioural trust calibration without improving assisted decision accuracy; low-confidence cases could also be hard for people. Show numerical model confidence only after calibration and task-specific validation, and never label it a sampling margin of error. [45]

**Backend - Must:** calculate counts and membership deterministically from canonical codes, unit definitions and filters. Let the LLM explain those results, not recalculate them. There is no direct comparative study in the reviewed evidence proving that deterministic counts themselves increase researchers' trust; the recommendation rests on reproducibility and auditability.

**Language - Must:** use "in this sample", exact bases and bounded observations. No minimum sample size automatically permits population generalisation. **Evidence strength:** authoritative statistical methodology and peer-reviewed uncertainty studies; transfers to qualitative video remain partly inferential.

**Decision:** satisfy the request for uncertainty by showing its components, not by manufacturing a margin of error.

## 5. Treat Coverage And Study Scope As First-Class Data

**Finding.** "Analysed" is too ambiguous. It may mean a video job completed, a code was created, an observation entered the index, or a response contributed to this answer. Compass needs to distinguish these states. Google Analytics provides a useful adjacent-domain pattern: a clickable data-quality indicator reveals sampling and thresholding limitations. AI processing coverage is different from statistical sampling, but the principle of inspectable limitations transfers. [22]

**Case study - the missing two-thirds.** In the supplied client testing, Compass analysed only a third of responses until prompted again. A warning alone would not fix this: the assistant needs a processing ledger and an answer-level aggregation record. Otherwise a user cannot tell whether "34 responses" means all available evidence, a retrieval subset or a partially completed job.

**Proposed coverage strip, using illustrative numbers:**

> **Study A | Video + transcript | 34 of 102 eligible responses processed**  
> This answer summarises 34 of 34 processed responses. 68 are awaiting Vision analysis.  
> **Complete analysis** | **View response status**

Show total collected, eligibility criteria, failed/unsupported items, processing status, answer inclusion and the snapshot time on expansion. Failed processing must not disappear from the denominator. "Not visible" is a substantive observation outcome, not proof that processing did not run.

| User intent | Partial-coverage behaviour | Required action |
|---|---|---|
| Explore an example or preliminary theme | Proceed with a prominent limited-scope statement | Offer completion and access to omitted records |
| Report a project-wide count or prevalence | Do not imply a complete result | Complete processing, or explicitly issue a partial-snapshot result |
| Compare studies | Check both scopes, codebooks and processing states | Echo scope; ask if a requested study is unavailable |
| Export or share a report | Preserve the original coverage and snapshot | Include the limitation in the export, not only in chat |

The policy should depend on the claim being made, not on a blanket refusal to help whenever processing is incomplete.

For comparisons, use a **scope echo** before execution: "Compare Study A [ID], all responses, codebook v3, with Study B [ID], selected market filter, codebook v2. Their behavioural categories differ. Align categories or compare separately?" Power BI's documented context and clarification patterns provide a relevant enterprise analogy. They do not justify selecting a substitute without permission. [23]

**Backend - Must:** maintain per-response eligibility and job status; queue new eligible responses idempotently; bind answers to a dataset snapshot; expose retrieval/aggregation scope. **UX - Must:** make scope visible, explain partial results and provide a completion action. Agree permission and spending rules for automatically processing new arrivals.

**Evidence strength:** analytics/BI documentation plus direct product problems supplied in the brief; no controlled evidence establishes one ideal coverage widget.

**Decision:** release blocker 2 requires a machine-readable truth source, not more persuasive wording about completeness.

## 6. Keep Video Evidence Close Without Interrupting Every Paragraph

**Finding.** Direct head-to-head evidence comparing all six requested layouts in AI qualitative analysis is limited. Treat the following as testable interaction hypotheses, informed by documented repository patterns and source-verification research, not proven rankings.

| Layout | Likely advantage | Main risk | Best role in Compass |
|---|---|---|---|
| Inline video mid-text | Immediate visibility and emotional salience | Interrupts reading; neighbouring claim may be ambiguous | Could: deliberately selected presentations, not the default for every claim |
| Attributed quote with expandable video | Preserves a readable narrative and explicit speaker attribution | A quote cannot substantiate an unspoken action | Should: default for speech-based evidence |
| Footnote-style citation | Compact and familiar | Easy to ignore; citation scope may be unclear | Should: pair with informative preview, not a bare number alone |
| Side panel | Keeps claim and evidence visible together | Split attention; limited space on smaller displays | Should: test as the desktop verification default |
| Evidence drawer | Progressive disclosure with room for metadata | Can obscure text or lose navigation context | Should: retain the active claim and return focus on close |
| End-of-section gallery | Supports storytelling and multiple examples | Claim-to-clip distance; persuasive selection may replace checking | Could: a supplement, not the only evidence route |

The default should optimise **reading first, targeted verification second**, while making the connection between the two unmistakable.

**Case study - Dovetail's connected evidence.** Dovetail documents citation clicks that jump to individual clips, a highlight carousel and source previews/peek overlays. These provide concrete implementation analogues for maintaining context. They do not prove that a side panel outperforms inline video. The supplied Compass reading-flow problem makes an attributed-text alternative worth testing rather than accepting on engineering preference alone. [14]

For speech, show the attributed quote and question context. For an action, replace the quote with an explicit observation: **"Observed: pours directly from the bottle into the bucket"**. Add a still or keyframe, response identifier, question/task, source modality and exact start/end timestamps. The player should land at the relevant moment, with enough preceding and following context to inspect the interpretation. Mark the original span; do not crop away counterevidence or imply that a keyframe establishes a temporal action.

For verification behaviour, the citation study's **9.77% checked-answer rate** cautions against designing for universal checking. It is not a benchmark for professional research users. Measure whether people inspect the relevant span and detect errors, rather than counting source clicks alone. [13]

**Accessibility - Must:** provide keyboard-operable controls, speech captions, important sound information and a text description of the relevant visible action. Speech captions alone do not communicate silent pouring or dough damage. Use meaningful thumbnail alternatives, accessible source-button names, managed drawer focus, pause controls and no surprise autoplay. Optional loops need user control and a reduced-motion alternative. W3C media guidance supports captions, descriptions, transcripts and device-independent control; it is guidance, not by itself a complete conformance audit. [24]

**Evidence strength:** vendor documentation, empirical general-question verification research and accessibility guidance; layout effects remain hypotheses.

**Decision:** prototype attributed evidence plus a connected panel before changing the entire answer format.

## 7. Ground Claims In Evidence Relationships, Not Plausible Clips

**Finding.** A valid video link, an on-topic video and a video that supports a particular claim are three different things. The generative-search audit found citations that were only partially supporting or contradicted the associated statement. Its distinction between verifiability and factuality matters here: even a perfectly located clip does not establish that the AI's interpretation is correct. [7]

**Case study - the apparently wrong Compass clip.** The supplied brief leaves two possibilities: the system selected the wrong response, or the presentation failed to reveal why the correct clip was relevant. Investigate these separately. A source panel can fix the second by showing question, respondent, timestamp and observation. It cannot fix the first. Hiding a retrieval defect behind an explanatory caption would make the product more misleading.

**Backend - Must:** create a typed evidence record containing study ID, response ID, asset ID, question/task ID, temporal span, modality, canonical code ID, codebook version, observation text and review state. Bind answer claims to those records. Use deterministic joins for identities and counts, not fuzzy matching from generated quote text. If a quote is edited for readability, preserve the original transcript and span.

**Should:** run separate checks for valid identity, valid temporal bounds, source availability and support for the specific claim. A model-based support verifier may help, but is not a guarantee: independent validation and failure analysis remain necessary. For aggregate claims, retain the entire contributing set and contrary cases; one vivid example cannot establish a frequency claim.

**UX - Must:** put the same short claim/observation label on the answer and evidence card. Show the active span and respondent/source identifiers, with "View full response". Offer specific feedback choices: **Wrong response**, **Wrong moment**, **Action not visible**, **Interpretation not supported**, **Other**. Do not collapse all of these into a generic thumbs-down.

On a wrong-clip report, acknowledge the report immediately, preserve the evidence snapshot and mark the affected claim as **reported for review**. Do not call it corrected until a correction actually exists. If support is invalidated, remove the unsupported conclusion from regenerated answers, recalculate affected aggregates and show what changed. Feedback must not silently become permission to train an external model; research standards distinguish research processing from model-training use. [27][28]

Dovetail and Discuss provide useful source-navigation examples, but their documentation does not establish an identical wrong-clip correction workflow. That workflow is a recommendation for Compass, not a verified competitor feature. [14][59]

**Evidence strength:** empirical citation audit, product documentation and research standards; proposed grounding architecture is an engineering recommendation.

**Decision:** acceptance testing must evaluate claim-to-evidence support, not merely successful playback or a non-broken URL.

## 8. Make Every Processing State Distinct And Actionable

**Finding.** An empty observation list can mean "not run", "failed", "unsupported", "not visible" or "no matching behaviour". These must not share one empty state. ATLAS.ti documents selecting documents, showing approximate processing time and allowing background work; MAXQDA distinguishes completion without identified segments. These are useful examples of communicating process separately from result. [43][46]

The following is **proposed UI copy, with illustrative counts**. Actual cost, timing, eligibility and capability must come from the service.

| State | Example copy | Primary action and behaviour |
|---|---|---|
| Never run | "Vision has not analysed this project. 58 responses are ready." | **Review and run Vision**; show cost/time before confirmation |
| Running | "Vision is processing 58 responses. 21 are complete." | **View progress**; allow background work and completion notification |
| Partially complete | "Vision is complete for 34 of 102 eligible responses. Findings shown here use those 34 responses." | **Complete analysis**; explain pending/failed items |
| Failed | "Vision could not process 4 responses. Completed results are still available." | **Review failures** / **Retry 4 responses**; explain charges before retry |
| Unsupported format | "Vision cannot analyse this recording type." | **View supported recording types**; do not imply Compass supports screenshare until confirmed |
| Processed, action unobservable | "Analysis is complete, but the action is not visible clearly enough to assess." | **View video** / **Mark for review**; do not record absence as fact |
| Processed, no matching action found | "Analysis is complete. No matching action was identified using this codebook." | **Review evidence and codebook**; distinguish detection result from certainty of absence |
| New responses arrived | "12 new responses have arrived since the last Vision analysis." | **Review and process new responses**, or show the agreed automatic-processing policy |
| Codebook changed | "These findings use an earlier codebook. Counts may change when analysis is updated." | **Review changes** / **Update analysis** |

The important distinction is between **processing completion** and **observational certainty**. A completed job can legitimately produce "cannot assess".

**Case study - background processing without false completion.** ATLAS.ti's background workflow permits users to continue working while processing proceeds. Compass should similarly avoid trapping researchers behind a modal spinner. However, partial results should retain a visible snapshot label, and a notification must not imply the entire project is complete if new responses or failures remain. [43][22]

**UX - Must:** name the work, show meaningful completed/eligible counts and provide recovery. **Should:** allow notification on completion and provide an ETA only when measured estimates are reliable. If the service cannot estimate, say "You can keep working; we will notify you when this run finishes" rather than inventing a countdown. Cancellation should explain whether already completed work and charges remain.

**Backend - Must:** expose explicit job states, durable failures and retry semantics. Progress should reflect actual work rather than elapsed-time animation. **Could:** stream provisional findings as records arrive, provided each is clearly labelled preliminary and can be revised.

**Evidence strength:** qualitative-tool documentation, analytics analogy and HAI error-recovery guidance. No reviewed study identifies a universally optimal progress display for this workload. [15]

**Decision:** the first release needs a state model and action model, not just a loading component.

## 9. Review Codes Selectively, With Project-Level Consistency

**Finding.** Existing qualitative tools support different combinations of AI suggestions, source inspection and code management; they should not be treated as interchangeable evidence for a full correction workflow.

| Tool | Verified AI/source-review behaviour | Verified code management | Important limit |
|---|---|---|---|
| ATLAS.ti | Review generated categories and quotations before applying results | Merge selected codes into a target code | Does not prove that its workflow fits Compass's scale |
| MAXQDA | Review suggested segments/rationales; delete or adjust boundaries | Reassign segments; rename/recolour codes | Human review remains necessary |
| Dovetail | Channels document automated tagging and running counts | Create/edit/rename tags; shared boards support consistency | Specific AI merge workflow not verified here |
| Condens | Source reviewed documents tag management | Tag descriptions and merging semantically equivalent tags | Downstream AI-answer propagation not verified |
| NVivo | Public material describes AI coding suggestions and summaries | Detailed review/merge interaction not verified in accessible material | Do not infer the full workflow from the summary page |
| Marvin | Vendor describes source-linked insights and clips | Detailed AI codebook/merge controls not verified | Marketing does not establish correction mechanics |
| Looppanel | Help documents AI notes, transcript highlights and video clips | Detailed AI codebook/merge controls not verified | Clip creation is not equivalent to code governance |

The strongest transferable pattern is **source-grounded review with a manageable codebook**, not compulsory review of every machine output. [43][48][46][63][42][55][56][57]

**Case study - three names for one behaviour.** The supplied Compass beta created codes per response, producing three labels for the same behaviour. Reducing duplicates in the backend is a necessary improvement, but label similarity alone cannot establish semantic equivalence. "Pours without measuring", "pours directly" and "exceeds recommended amount" may overlap without meaning the same thing. A merge UI cannot compensate for an undefined observational construct.

**Backend - Must:** maintain canonical project-level code IDs, definitions, inclusion/exclusion examples, units and versions. Preserve original observations when mapping synonyms. Use this same mapping for counts, retrieval and exports. Comparing studies requires a visible codebook crosswalk or separate reporting, not a silent label merge.

**UX - Should:** begin with a lightweight codebook preview before running; a review queue for uncertain/high-impact cases; accept/reject at observation level; and suggested merges that show both definitions and affected records. **Could:** add a full code editor when testing demonstrates sufficient recurring demand. Include audit history and undo.

Human-in-the-loop review is not automatically useful simply because it exists. Cognitive-forcing research shows a trade-off between lower overreliance and greater friction; benefits also vary across users. Make review targeted and consequential, rather than a ritual checkbox that researchers learn to skip. [1]

Corrections **should propagate** to canonical records, deterministic counts, retrieval and newly generated answers. Mark affected saved answers as out of date and offer regeneration; do not silently rewrite already shared exports. State: **"Code updated. Counts and future answers now use this definition. Two saved reports need updating."** The number is illustrative.

**Evidence strength:** tool documentation plus adjacent-domain HAI research; the optimal review burden for Compass remains untested.

**Decision:** ship project-level code governance before deciding whether a comprehensive code-management interface is necessary.

## 10. Separate Buying Analysis From Using Its Results

**Finding.** Auto-detect and manual setup solve different discovery problems, but both need a clear commitment boundary. PAIR recommends progressive automation under user guidance and warns that confidence information is not always actionable. A recommendation should explain what it enables and what it costs, not merely assert that AI would improve the project. [15]

**Case study - Conveo's task-observation activation.** Conveo documents task observation as an invitation/private-beta capability, with a price uplift shown. It lets researchers select camera or screen observation per question and describes important capture limitations. This demonstrates a useful separation between capability, input suitability and purchase decision; it is not evidence that Compass has equivalent screenshare support. ATLAS.ti and MAXQDA offer complementary patterns: processing-time information and selected-document/quota visibility before commitment. [58][43][46]

**Proposed proactive suggestion:** "This project asks people to demonstrate product use. Vision could help compare visible actions with their answers. Review what it can analyse and the estimated cost." Provide **Review setup**, **Not now** and a durable dismissal. Avoid repeated prompts, urgency cues or unsupported claims such as "Unlock the truth". The relevance explanation should refer to study objectives/questions, not invasive inferences about participants.

Manual discovery should use the same setup screen through a clearly named project setting, not a hidden advanced switch. Show supported recording types, the chosen behavioural questions/codebook, eligible-response count, estimated credits or price, likely duration, permissions, and what happens when new responses arrive. If a price is only an estimate, state its basis and any spending cap.

| Control | Meaning | Required guardrail |
|---|---|---|
| **Run Vision analysis** | Starts processing and may incur cost | Explicit scope/cost confirmation and permissions |
| **Include Vision findings in Compass** | Changes which existing data an answer may use | Persistent scope indicator; repeat the setting on each answer |
| **Process new eligible responses automatically** | Authorises future jobs | Explain future spending, limits, notifications and how to pause |

These controls should not be combined into one ambiguous "Vision on/off" switch. Turning off inclusion must not silently delete observations, stop an already paid job or imply that earlier answers no longer used video.

**General-release discovery - Should:** use a contextual announcement, one concise example, accessible help and a visible project setting. Preserve the setting in exported answer metadata. Test whether users can identify the current mode after returning later; a remembered toggle position is not sufficient evidence of understanding.

**Backend - Must:** enforce permissions, quotas and consent eligibility independently of the display. The supplied unknowns - flow designs, screenshare support, Compass dependency and current discovery routes - remain unresolved product questions.

**Evidence strength:** HAI guidance and vendor documentation; proactive-prompt wording and persistence are design hypotheses.

**Decision:** make activation a deliberate commitment and data inclusion a visible analysis choice.

## 11. Layer Detail Without Losing The Evidence Trail

**Finding.** Different audiences need different entry points, not different truths. PAIR recommends explaining consequential aspects rather than everything at once, while Dovetail's documented source peeks show how detail can remain accessible without dominating the narrative. [15][14]

| Audience | Default entry point | On-demand detail | Information that must remain visible |
|---|---|---|---|
| Hands-on researcher | Observation groups and differences | Codes, definitions, status, contributing records and clips | Source, coverage, review state and uncertainty |
| Insight manager | Finding, size within the study and implications | Codebook, alternatives, segment comparisons and quality checks | Base size, scope and limitations |
| Executive stakeholder | Short bounded finding and business relevance | Selected examples plus a route to the complete evidence set | "In this study", source basis and material caveats |

Progressive disclosure should reduce initial complexity, not remove the information needed to avoid a wrong conclusion.

**Case study - a project-level Vision report.** In the supplied brief, clients want both a consolidated report and collapsible detail on long response pages. Design the report as a reproducible snapshot: study objectives and behavioural questions; source/processing coverage; codebook version; key observations; said/observed comparisons; counts with units; supporting and contrary evidence; interpretation and alternatives; review status; and unresolved limitations. A highlight reel can illustrate the report, but must not replace the complete evidence set. Qualtrics and Dscout document clip/reel workflows; those are communication facilities, not evidence that selected clips are representative. [31][32]

Use a disclosure path of **narrative -> observation groups -> code definitions -> record-level values -> original video**. Avoid reducing raw values to booleans when "unknown", "not applicable" and "not processed" are possible. A compact default can still expose a count of records needing review.

**Exports - Must:** preserve provenance outside Compass. CSV should include study/response and participant identifiers where permitted, unit of analysis, source modality, code ID/definition/version, value, missingness reason, temporal span, review status and analysis snapshot. Use a separate evidence-link table where one claim has multiple sources. Reports and PPT should carry claim-linked evidence references, base sizes, scope and the snapshot date; a screenshot of a chart alone is insufficient. Respect access controls when clips are opened by recipients.

**Collapsible response section - Should:** keep the heading, completion state and any material warning visible when collapsed. Start expanded when the task is behavioural review or the response has an unresolved difference; a compact/collapsed default may suit transcript-first browsing. There is no reviewed evidence establishing one universal default. Test role, task and return-visit behaviour, and remember an explicit user preference.

**Evidence strength:** HAI guidance and vendor patterns; audience layering, export schema and default expansion are design recommendations, not experimentally established outcomes.

**Decision:** simplify the first screen while keeping every shared conclusion traceable to the same underlying records.

## 12. Treat Behavioural Analysis As A Purpose And Privacy Decision

**Finding.** Permission to record a video does not automatically settle whether new AI behavioural analysis, sensitive inference or model training is within the disclosed purpose. Equally, consent is not the only possible legal basis under data protection law. Research ethics, the processing purpose, applicable legal basis and any special-category condition need separate consideration.

| Authority | Relevant requirement or distinction | Compass implication |
|---|---|---|
| MRS AI guidance interpreting its Code | Inform participants before collection about AI personal-data processing and consequences; maintain oversight and traceability | Explain behavioural observation and uses; retain an auditable human-review route |
| Insights Association Code | Disclose AI use, purpose, technique/model information and accuracy/data-source matters; distinguish generated material from participant data | Label AI observations as generated analysis, not respondent testimony |
| ESOMAR AI buyer guidance | Ask about validation, human oversight, data origin, processing and privacy | Provide a supplier/governance explanation, not just a feature description |
| UK GDPR / ICO guidance | Video is not automatically biometric data; special-category biometric treatment depends on relevant identifying processing/purpose | Do not call every face-camera recording special-category biometrics; assess the actual processing |
| EU AI Act | Physical-action observation, emotion inference and sensitive biometric categorisation are different categories | Keep capability boundaries explicit; do not import emotion/fraud claims through wording |

These sources have different legal status: professional codes and buyer guidance are not substitutes for applicable law. [27][28][29][26][30]

**EU AI Act boundary.** The Act defines emotion recognition in relation to inferring emotions or intentions from biometric data. Recital 18 distinguishes mere detection of observable expressions, gestures or movements unless used to infer emotion. Workplace/education emotion inference is prohibited subject to the specified medical/safety exception; sensitive biometric categorisation has separate prohibitions. Relevant emotion-recognition/biometric systems also raise transparency and potentially high-risk obligations. Ordinary observation of pouring or opening a can is not automatically emotion recognition simply because it uses video. [30][62]

**Case study - expression analytics versus action evidence.** Medallia documents expression-to-emotion output; Barrett and colleagues' scientific review cautions that facial movements vary with context, culture and individuals and are not diagnostic of specific emotions. This tension is exactly why "looks frustrated", "is dishonest" and "pours directly" should not be interchangeable observation types. It does not establish that all physical-action detection is invalid. [16][33]

**UX - Must:** show response-level permission/eligibility status, analysis purpose and review restrictions; block unauthorised processing. Provide warnings or stronger controls for proposed emotion, identity or sensitive inference. Disclose relevant suppliers, retention, access and correction/deletion routes. Review existing recordings against their original notice and legal basis before reuse; do not assume a generic video notice covers every later inference. MRS and IA guidance also distinguish research processing from model-training use. [27][28]

**Backend/legal - Must:** enforce those controls, involve privacy counsel/DPO and assess whether a DPIA is required. **Evidence strength:** operative legislation, regulator guidance and professional standards; application depends on deployment and jurisdiction.

**Decision:** position the feature as contextual observation, never a lie detector or a route around consent.

## 13. Compete On Auditability, Not Unbounded AI Vision Claims

**Market finding.** The global competitive field combines AI-moderated research, video repositories and expression/behavioural measurement. Public material supports three directional trends: richer multimodal capture, conversational analysis connected to evidence, and more explicit review/activation controls. It does **not** provide a defensible standalone market size for "Say Do Gap UX", or comparable accuracy benchmarks across the named products. Buying decisions should therefore use workflow and governance fit rather than an invented TAM or feature-count ranking.

### Research Platforms: Public Behaviour Versus Marketing Claims

| Player | Observation and evidence proposition | Provenance/confidence | Activation, empty states and cost: what is verified |
|---|---|---|---|
| **Outset** | Vendor describes Visual Intelligence observing products/actions and probing; diary analysis develops across rounds | Summaries/themes are described; action-confidence UI not verified | Detailed empty states, per-run opt-in and cost not established in reviewed material |
| **Conveo** | Task-observation documentation supports camera or screen capture per question, with explicit capture limits | Analysing indicator; limitations include missing rapid/small/off-screen actions | Invitation/private beta and displayed price uplift documented |
| **Listen Labs** | Vendor Research Agent material describes source-linked findings, numbers/charts and clips/exports | Traceability claimed; physical-action coding and confidence UI not established | Detailed processing-state, opt-in and cost behaviour not verified |
| **Discuss.io** | Help documents self-paced tasks, Genie summaries, theme clips and quote-to-source links | Source links can identify included tasks/activities; clips linked when available | Unsupported language/no transcript can prevent summary; Vision-specific cost/activation not established |
| **Medallia Video / LivingLens** | Help documents facial-expression/emotion timelines and aggregate filters | Clickable timeline; quality limitations; multi-face attribution caveat | Edition restrictions and representative-led activation/pricing documented; detailed empty states not established |
| **Rival** | Vendor describes AI insight generation and highlight reels | Claims traceability and low-confidence review flags | AI features described as opt-in/off by default; detailed failure states and cost not verified |
| **Qualtrics** | Video answers, automatic transcription/topic/sentiment analysis, clips and highlight reels | These features do not establish observed physical-action comparison | Say-do-specific confidence, empty-state and run-cost controls not established |
| **Dscout** | Video/photo/screen-recording questions, longitudinal activities, reminders and reels | Rich contextual capture; automatic said-versus-action inference not established here | Pacing and operational support documented; Vision-equivalent opt-in/cost not established |

Public help documentation establishes described interactions, not independent model accuracy. Vendor product pages are a lower-strength basis for claims about effectiveness. "Not established" does not mean a feature is absent. [38][58][52][59][16][53][31][32]

**Case study - Conveo's bounded observation.** Its documentation describes capture equivalent to once-per-second screenshots and expressly excludes click tracking/heatmaps and reliable capture of very fast, small or off-screen actions. This is a useful commercial counterpoint to vague "sees everything" language. Voxpopme can adopt the principle of explicit capability boundaries without copying the capture architecture or claiming equivalent performance. [58]

### Facial And Behavioural Analytics: Transfer Quality Signals, Not Psychological Certainty

| Player | Publicly described output | Useful transferable lesson | Caveat and public-detail gap |
|---|---|---|---|
| **Realeyes** | Integration brochure describes facial landmarks and time-based expression/attention measures | Align measurement with the original timeline | Brochure claims are not independent validation; confidence, empty-state and cost UI not verified |
| **Affectiva / Smart Eye** | Vendor material describes engagement/valence and speech/speaker-related measures | Make temporal and speaker scope explicit | These measures are not equivalent to correctly detecting product-use actions; detailed correction/cost UI not verified |
| **iMotions** | Realeyes integration material describes recorded-video import, analysis and export | Synchronised evidence and exportable records can support audit | Platform integration does not establish the validity of an inferred emotion; detailed opt-in/empty-state UI not verified |
| **Noldus FaceReader** | Documentation shows intensity charts, quality indicators, gaze/head measures and missing/FIT-FAILED states | Represent capture failure and missingness explicitly | An intensity value from 0 to 1 is not a probability that a psychological interpretation is true; cost/opt-in details not established here |

The clearest transfer is **measurement quality and temporal traceability**, not the idea that every facial or behavioural signal has a single psychological meaning. [17][54][51]

**Case study - multi-face attribution.** Medallia's documentation states a limitation in associating detected emotion with a particular face when multiple faces are present. Noldus separately documents input-quality constraints and missing/failure states. These show why "a result exists" is not enough: source attribution and assessability must accompany the output. [16][50][51]

**Opportunity for Voxpopme - Should:** own the workflow from a project-level behavioural codebook through deterministic counts, source-specific claims, a correct temporal clip, correction history and provenance-preserving export. This is a strategic opportunity, not a verified claim that no competitor offers these capabilities. **Could:** extend into longitudinal behaviour once coverage/versioning are robust; Outset and Dscout already demonstrate relevant longitudinal positioning. [38][32]

**Evidence strength:** mixed vendor help, product marketing and a scientific counterweight on emotion inference; no independent cross-vendor performance comparison was found.

**Decision:** differentiate through bounded, inspectable evidence rather than escalating claims about what AI can infer about people.

## 14. Design For Ambiguity, Missingness And Unspoken Distrust

**Finding.** The difficult cases are not peripheral. They determine whether an apparently simple tag is a defensible observation. Competitor documentation already identifies rapid/off-screen action limits, lighting/angle problems and multi-face attribution constraints; these are useful failure categories, not measured Compass error rates. [58][16][50]

| Edge case | Failure to prevent | Required behaviour |
|---|---|---|
| Screenshare or non-face-camera recording | Treating absence of a face as absence of useful behaviour, or promising unsupported processing | Check actual Compass capability; label supported input/task types explicitly |
| Poor lighting, occlusion, off-camera action | Coding "not done" when it is not observable | Use "cannot assess" and preserve the reason |
| Several people in frame | Attributing one person's action to the respondent | Identify the actor where defensible; otherwise withhold person-level attribution |
| Ambiguous or culturally variable action | Treating a gesture or practice as a universal signal | Use descriptive codes; show alternatives; involve contextual expertise |
| Quantity or damage inferred from appearance | Claiming measured volume or causal damage without adequate evidence | Require appropriate scale, temporal evidence and operational definitions |
| Fewer than 10 participants | Letting fluent prose imply population prevalence | Use exact counts, cases and explicit sample limits; no automatic generalisation threshold |
| Very large projects | Retrieval selects vivid examples while claiming exhaustive analysis | Separate exhaustive aggregation from example retrieval and expose coverage |
| New responses after analysis | Old answers appear current or silently change | Queue according to policy; timestamp snapshots and mark stale outputs |
| Different study codebooks | Comparing labels as if they measure the same construct | Review a crosswalk or report separately; preserve versions |
| Screener/answer mismatch | Inferring fraud from different wording, timing or context | Show both records and ask for contextual review |

The design should prefer a truthful **unknown** to a confident false negative. More data does not remove classification or selection problems.

**Case study - emotion labels and context.** Barrett and colleagues' review challenges the assumption that a facial movement uniquely identifies an emotion across people and settings. The transfer to Compass is not "never analyse behaviour". It is to define the observable construct narrowly, avoid universal psychological interpretations, and preserve the contextual material a researcher needs to disagree. [33]

**What researchers may not say openly.** Treat the following as hypotheses, not established hidden attitudes: "I cannot tell whether the AI cherry-picked"; "checking it takes longer than doing it myself"; "a correction will not reach the client deck"; "the vendor is turning subjective judgement into a spurious number"; "the clip is persuasive but not representative"; and "challenging AI makes me look resistant to innovation". No reviewed evidence proves that these are the private beliefs of Compass users.

Test these concerns through behaviour: ask researchers to prepare a client-ready conclusion, estimate its defensibility, find a counterexample and explain what they would withhold. Use private retrospective interviews and an anonymous critical-incident prompt after the task. Compare their confidence with actual error detection and rework, not just public enthusiasm in a stakeholder interview. Cognitive-forcing research supports the importance of distinguishing preference from performance, but does not validate this exact interview protocol. [1]

**Evidence strength:** vendor-documented limitations and peer-reviewed contextual caution; researcher-distrust hypotheses require primary research.

**Decision:** evaluate the cases where Vision should abstain as rigorously as the cases where it should identify a behaviour.

## 15. Release Gates: Must First, Should Next, Could Later

The three existing blockers are necessary but not sufficient. They protect completeness, scope knowledge and evidence identity; code semantics, consent and bounded language determine whether the resulting answer is still misleading. The following is a **proposed acceptance framework**, not a statement that the current product passes or fails it.

| Priority and gate | Backend/model requirement | UX requirement | Acceptance evidence |
|---|---|---|---|
| **Must - B1: every relevant response** | Explicit eligibility; reliable jobs/retries; new-response queue; permissions and budget policy | Counts and states distinguish pending, failed, unsupported and unassessable | Reconcile the full response ledger, including new arrivals and failures; complete claims refer to a defined snapshot |
| **Must - B2: Compass knows coverage** | Queryable processing ledger; answer-level aggregation scope; stable study/filter IDs | Persistent scope/coverage; no silent study substitution; partial-result action | Seed partial datasets and unavailable studies; check every displayed base and requested scope |
| **Must - B3: correct evidence** | Stable claim-response-asset-span binding; support validation | Relevant timestamp, observation label and mismatch reporting | Audit identities, spans and claim support separately, including negative and ambiguous cases |
| **Must - semantic and count integrity** | Canonical project codes; deterministic counts; explicit units and versions | Count-to-record inspection; unknown distinct from false | Reconcile displayed counts and membership against adjudicated fixtures |
| **Must - permission and truthful language** | Enforced eligibility, purpose/access controls and constrained numeric generation | Source labels, sample framing, meaningful recovery and cost confirmation | Test unauthorised inputs, small samples, unsupported formats and overclaiming prompts |
| **Should - usable verification** | Evidence preview endpoints and correction invalidation | Attributed evidence, panel/drawer, lightweight review and accessible playback | Improved supported/unsupported-claim discrimination without excessive time cost |
| **Should - enterprise sharing** | Versioned report/export records | Project report, CSV/PPT provenance, stale-output warnings | Recipients can recover scope, counts and evidence after export |
| **Could - advanced optimisation** | Validated confidence and alignment services | Calibrated confidence displays, merge suggestions, richer comparison charts | Add only when tests show benefit beyond complexity and review burden |

A passing interface test cannot substitute for B1-B3 engineering verification. Conversely, backend accuracy alone does not establish that users understand limitations. Citation research and confidence experiments show why both layers matter. [7][13][45]

**Operational metrics - Should:** track eligible-response processing completion and delay; failed/retried jobs; count reconciliation; wrong-response and wrong-span rates; claim-support errors; proportion of observations that are unassessable; stale answers after new data/corrections; and time from a reported mismatch to resolution. Segment these by action type, recording conditions and codebook version. Do not merge all errors into one reassuring "AI accuracy" number.

**Release interpretation.** Zero known wrong links in a finite acceptance set is a useful gate, not proof of a zero-error product. Predeclare risk tolerances, severity handling and rollback rules. Continue a controlled rollout if major failure modes remain unresolved; do not compensate with stronger disclaimers. PAIR explicitly recognises inevitable errors and the need for useful correction or fallback. [15]

**Decision:** make B1-B3 demonstrable system properties, then verify that the interface makes those properties and their limits understandable.

## 16. Concept Test Plan: Eight Hypotheses About Calibrated Reliance

**Purpose.** Choose an evidence interaction model and identify residual release risks. This is not a preference poll or an attempt to establish population-level market demand. The proposed study uses controlled errors because citations, confidence and explanation can influence trust without reliably improving correctness. [1][13][45]

### Recommended Sample And Method

**Proposed sample:** begin with **8 moderated formative sessions**, followed by **32 counterbalanced comparative sessions**: 16 hands-on brand researchers, 8 agency researchers/leads and 8 insight managers. Recruit across the UK/Europe, North America and APAC, with a spread of AI familiarity and qualitative experience. This is a pragmatic discovery/evaluation sample, not a statistically powered claim about small effects or globally representative behaviour. Add local-language studies before broad localisation conclusions.

Use a modular, counterbalanced incomplete-block design rather than asking everyone to evaluate every possible combination. Each person should see correct, ambiguous and incorrect cases, but not repeat the same content in every layout. Match tasks for complexity. Use silent timed tasks followed by retrospective replay; concurrent think-aloud can itself prompt verification and distort timing.

Build consented or synthetic study materials with independently adjudicated observations, multiple qualified reviewers and recorded disagreements. Include direct pouring, opening a can and possible dough damage; avoid defining the AI output as the ground truth. Disclose the simulated nature of the task appropriately and debrief seeded errors.

| Hypothesis | Concepts/stimuli to compare | Task | Primary success measures |
|---|---|---|---|
| **H1 - Source labels improve calibration** | Unlabelled findings versus claim-level Transcript/Video/Combined labels | Identify which claims concern speech, visible action or interpretation; choose what to report | Source-identification accuracy; acceptance of supported claims and rejection of unsupported ones |
| **H2 - Connected evidence improves verification** | Current inline video versus attributed text with expansion versus linked side panel | Produce a short finding and detect a wrong or irrelevant clip | Wrong-clip detection; relevant-span inspection; time to defensible finding; reading comprehension |
| **H3 - Coverage plus action prevents complete-sample errors** | Generic caveat versus processed/eligible strip plus completion action | Interpret a 34-of-102 partial project and decide whether to publish a count | Correct denominator; recognition of incompleteness; appropriate completion action; time |
| **H4 - Bounded counts outperform spurious precision** | Percentage/MOE-style presentation versus exact n/N, visibility counts and typed uncertainty | Assess whether a finding can be generalised and explain uncertainty to a client | Population-inference errors; denominator comprehension; decision accuracy and confidence calibration |
| **H5 - Layered interpretation reduces unjustified accusations** | Single "What it means" narrative versus Said/Observed/Possible interpretation | Review a screener mismatch and an ambiguous action | Detection of inferential leaps; alternative explanations; avoidance of unsupported fraud/dishonesty claims |
| **H6 - Lightweight code review gives useful control** | Read-only tags versus preview, spot-check and targeted accept/reject/merge | Resolve overlapping codes, correct one observation and inspect a revised answer | Semantic correction quality; count reconciliation; correction propagation; review burden and skipped checks |
| **H7 - Explicit activation improves informed commitment** | Auto-detect suggestion versus manual settings, both with/without a structured cost/scope preview | Enable analysis, change Compass inclusion and handle later arrivals | Cost and scope comprehension; mode recall after an intervening task; unintended starts; discoverability |
| **H8 - Scope echoes and state-specific recovery prevent hidden substitutions** | Generic chat confirmation versus exact study/filter/codebook echo and actionable states | Compare an unavailable study; recover a failed run; add new data and update a saved report | Silent-substitution acceptance; recovery success; stale-result detection; correct next action and completion time |

The winning concept should improve **correct reliance and error recovery**, not simply generate more clicks or higher trust ratings. Some successful designs may lower confidence because they reveal real limitations.

### Measures And Interpretation

Record unaided judgement where useful, then assisted judgement. Report separately: accepting correct findings; rejecting incorrect findings; unnecessary rejection of correct findings; and residual uncertainty. This distinguishes appropriate reliance from indiscriminate distrust. A confidence score alone is not the outcome.

Count verification only when participants inspect relevant evidence, not merely open a panel. Measure error-detection rate by error type, time to first useful evidence, time to an accurate client-ready conclusion, count/scope accuracy, correction effort and subsequent rework. Collect preference, perceived workload and stated trust after behavioural measures.

Predeclare decision rules and practically meaningful trade-offs with the team. Analyse within-person differences where the design permits, report uncertainty and inspect role/experience differences as exploratory. If evidence is inconclusive, run a larger focused comparison rather than claiming a winner from small preference differences. Add an accessibility pass with keyboard and screen-reader users; general research participants do not substitute for it. [24]

**Evidence strength:** proposed primary-research design informed by HAI experiments; sample sizes and hypotheses are recommendations, not literature-derived power calculations.

**Decision:** choose the concept that helps researchers know when Compass is right, wrong or unable to tell.

## Synthesis

The core strategic choice is between **invisible intelligence**, **exhaustive disclosure** and **progressively auditable assistance**. The evidence does not support equating more confidence, more citations or more information with better decisions. Citation studies show an authority effect with limited checking; confidence research shows calibration gains without guaranteed accuracy gains; cognitive forcing can improve reliance while reducing preference. [13][45][1]

| Approach | Mechanism and scope | Evidence basis | Workload/time trade-off | Principal risk |
|---|---|---|---|---|
| "Same interface, invisibly smarter" | Adds modality behind fluent answers | Direct evidence for this exact Compass change is absent | Lowest immediate interaction cost | Users apply transcript-era assumptions to observational inference |
| Full detail and confidence everywhere | Attempts transparency through continuous disclosure | PAIR cautions that confidence can distract or be misinterpreted | High reading and review burden | Apparent precision and ignored detail |
| Mandatory review of every observation | Human oversight before every result | Selective-friction research is encouraging but task-limited | Slowest path; may become ritual | Skipped or superficial checking, especially at scale |
| Progressively auditable Compass | Persistent source/scope signals plus targeted evidence and correction | Supported by HAI principles and documented repository patterns; exact design still needs testing | Small constant cost, deeper effort when consequential | Requires strong backend lineage; disclosure cannot rescue wrong evidence |

The recommended approach combines **deterministic aggregation, explicit scope, local provenance and selective human review**. It avoids two false choices: familiar chat versus transparency, and backend accuracy versus UX. Compass can retain its conversational identity while changing how it warrants claims.

The competitive comparison also reveals a useful tension. AI-moderated platforms emphasise richer capture and faster synthesis; expression-analytics products expose useful timelines and quality signals but may invite stronger psychological interpretations than the science supports. Voxpopme should transfer the **measurement discipline**, not the implication that observation reveals a person's hidden truth. [58][51][33]

Finally, a project-level codebook and deterministic counts are not merely engineering preferences: they make comparison, correction and export coherent. But perfectly consistent counts can still count the wrong construct. Code definitions, assessability and evidence support must therefore travel with the numbers.

**Final recommendation:** keep the flag-controlled rollout until B1-B3 are demonstrated and users can recognise modality, scope, uncertainty and evidence relevance. Run the targeted concept study before committing to a default evidence layout or a full code-review interface. The defensible product promise is **"See how this finding was derived, and change it when the evidence warrants it"**, not "AI knows what respondents really did or meant".

## References

1. *Cognitive Forcing Functions Can Reduce Overreliance on AI ...*. https://www.eecs.harvard.edu/~kgajos/papers/2021/bucinca21trust.pdf
2. *AI Guidance and using Related Technologies*. https://www.mrs.org.uk/standards/guidance-on-using-ai-and-related-technologies
3. *Biometrics | AI Act Service Desk*. https://ai-act-service-desk.ec.europa.eu/en/biometrics
4. *Guidelines for Human-AI Interaction - Microsoft Research*. https://www.microsoft.com/en-us/research/project/guidelines-for-human-ai-interaction
5. *AI Coding - ATLAS.ti 23 Windows - User Manual*. https://doc.atlasti.com/ManualWin/SearchAndCode/AICoding.html
6. *REPORT OF THE AAPOR TASK FORCE ON NON- PROBABILITY SAMPLING*. https://aapor.org/wp-content/uploads/2022/11/NPS_TF_Report_Final_7_revised_FNL_6_22_13-2.pdf
7. *Evaluating Verifiability in Generative Search Engines*. https://arxiv.org/html/2304.09848
8. [[PDF] MRS Guide: Observers – legal and ethcial responsibilities](https://www.mrs.org.uk/pdf/MRS%20Guideline%20Observation.pdf)
9. *COMMUNICATION FROM THE COMMISSION Commission Guidelines …*. https://ai-act-service-desk.ec.europa.eu/sites/default/files/2026-01/guide-prohibited_en.pdf
10. *Margin of Sampling Error*. https://aapor.org/wp-content/uploads/2023/01/Margin-of-Sampling-Error-508.pdf
11. *Guidelines for Human-AI Interaction - Microsoft Research*. https://www.microsoft.com/en-us/research/publication/guidelines-for-human-ai-interaction
12. *Conveo | Product*. https://conveo.ai/product
13. *Citations and Trust in LLM Generated Answers*. https://arxiv.org/html/2501.01303v1
14. *Chat improvements to citations, navigation and more*. https://dovetail.com/changelog/chat-updates
15. *Explainability + Trust*. https://pair.withgoogle.com/chapter/explainability-trust
16. *Facial Emotion Analytics | Medallia Documentation*. https://docs.medallia.com/en/medallia-video/medallia-video/analytics-module/facial-emotion-analytics
17. *Realeyes Facial Expression Analysis*. https://imotions.com/wp-content/uploads/brochures/iMotions%20Realeyes%20Partnership.pdf
18. *Human Trust in AI Search: A Large-Scale Experiment*. https://arxiv.org/html/2504.06435v1
19. *AI Coding - ATLAS.ti 23 Mac - User Manual*. https://doc.atlasti.com/ManualMac/SearchAndCode/AICoding.html
20. [
            Lies, Damned Lies, and Survey Self-Reports? Identity as a Cause of Measurement Bias - PMC
        ](https://pmc.ncbi.nlm.nih.gov/articles/PMC5639921)
21. *Elicit: AI for research & decision-making*. https://elicit.com/
22. *Data quality - Analytics Help*. https://support.google.com/analytics/answer/12856703
23. *Standalone Copilot experience in Power BI (preview) - Power BI | Microsoft Learn*. https://learn.microsoft.com/en-us/power-bi/explore-reports/copilot-chat-with-data-standalone
24. *Media Accessibility User Requirements*. https://www.w3.org/TR/media-accessibility-reqs
25. *Highlights*. https://docs.dovetail.com/help/projects/highlights
26. *Biometric recognition | ICO*. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/lawful-basis/biometric-data-guidance-biometric-recognition/biometric-recognition
27. *Microsoft Word - MRS_AI_RelatedTechnologies_Guidance_April2025_Final*. https://www.mrs.org.uk/pdf/AI+RelatedTechnologies_MRSGuidance_April2025.pdf
28. *CODE OF STANDARDS AND ETHICS FOR MARKET RESEARCH AND DATA ANALYTICS*. https://email.insightsassociation.org/hubfs/IA%20Code%20Standards_August2025_FinalV2.pdf
29. *ESOMAR 20 Questions to Help Buyers of AI-Based Services for Market Research and Insights*. https://esocorpwebsitestg.blob.core.windows.net/strapi-uploads/uploads/cltn6755401khqe3v0od2y6ut_esomar_20_questions_to_help_buyers_of_ai_based_services_0277e1b5eb.pdf
30. *Consolidated TEXT: 32024R1689 — EN — 27.07.2026*. https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:02024R1689-20260727
31. *Qualitative + Quantitative Research & Analytics Software*. https://www.qualtrics.com/en-au/strategy/research/qualitative-quantitative
32. *Diary Studies For Longitudinal UX Research | Dscout*. https://www.dscout.com/platform/methods/diary-studies
33. *Emotional Expressions Reconsidered: Challenges to Inferring Emotion From Human Facial Movements*. https://pubmed.ncbi.nlm.nih.gov/31313636
34. *Emotional Expressions Reconsidered: Challenges to Inferring Emotion From Human Facial Movements - Lisa Feldman Barrett, Ralph Adolphs, Stacy Marsella, Aleix M. Martinez, Seth D. Pollak, 2019 *. https://journals.sagepub.com/doi/10.1177/1529100619832930
35. *Emotional Expressions Reconsidered: Challenges to Inferring Emotion From Human Facial Movements – Association for Psychological Science – APS*. https://www.psychologicalscience.org/publications/emotional-expressions-reconsidered-challenges-to-inferring-emotion-from-human-facial-movements.html
36. *Crowdsourcing graphical perception | Proceedings of the SIGCHI Conference on Human Factors in Computing Systems*. https://dl.acm.org/doi/10.1145/1753326.1753357
37. *The effects of communicating uncertainty on public trust in facts and numbers | PNAS*. https://www.pnas.org/doi/10.1073/pnas.1913678117
38. *Introducing Diary Studies | Outset*. https://outset.ai/resources/blog/diary-studies
39. *Self-Paced Activities: A Guide for Researchers – Discuss Help Center*. https://discussio.zendesk.com/hc/en-gb/articles/4625013220753-Self-Paced-Activities-A-Guide-for-Researchers
40. *Diary Studies: Understanding Long-Term User Behavior and Experiences - NN/G*. https://www.nngroup.com/articles/diary-studies
41. *Crowdsourcing graphical perception | Proceedings of the SIGCHI Conference on Human Factors in Computing Systems*. https://dl.acm.org/doi/pdf/10.1145/1753326.1753357
42. *Managing and changing tags*. https://condens.io/help/using-condens/structuring-and-analyzing/managing-and-changing-tags/
43. *AI Coding - ATLAS.ti 26 Windows – User Manual*. https://manuals.atlasti.com/Win/en/manual/SearchAndCode/AICoding.html
44. [Effects of icon arrays to communicate risk in a repeated risky decision-making task
](https://www.sas.upenn.edu/~baron/journal/21/210615/jdm210615.html)
45. *Effect of Confidence and Explanation on Accuracy and Trust Calibration in AI-Assisted Decision Making*. https://arxiv.org/pdf/2001.02114
46. * AI Coding: Documents - MAXQDA*. https://www.maxqda.com/help/ai-assist/ai-coding/coding-documents
47. *"I'm Not Sure, But...": Examining the Impact of Large Language Models' Uncertainty Expression on User Reliance and Trust*. https://dl.acm.org/doi/fullHtml/10.1145/3630106.3658941
48. *Merging Codes  - ATLAS.ti 26 Windows – User Manual*. https://manuals.atlasti.com/Win/en/manual/Codes/CodesMerging.html
49. *Use chat in Gemini Notebook - Gemini Notebook Help*. https://support.google.com/notebooklm/answer/16179559
50. *FaceReader 10 - Technical Information and Requirements - Noldus*. https://noldus.com/shared/resources/book/noldus-product-documentation/chapter/facereader/page/facereader-10-technical-information-and-requirements
51. *FaceReader 10 - Core Features and Capabilities - Noldus*. https://noldus.com/shared/resources/book/noldus-product-documentation/chapter/facereader/page/facereader-10-core-features-and-capabilities
52. *Research Agent - Listen Labs | Trusted AI Research for Leading Brands*. https://listenlabs.ai/features/research-agent
53. *Rival's AI Agents and Capabilities for Research and Insights*. https://www.rivaltech.com/ai
54. *Smart Eye Extends Use of Affectiva Emotion AI for Qualitative Research with Conversational Engagement and Valence Metrics - Affectiva : Affectiva*. https://www.affectiva.com/news-item/smart-eye-extends-use-of-affectiva-emotion-ai-for-qualitative-research-with-conversational-engagement-and-valence-metrics/
55. *AI Assistant*. https://community.lumivero.com/s/article/NV15Win-Content-ai-ai-assistant
56. *Marvin | The #1 AI-native customer insights platform*. https://heymarvin.com/
57. *🤖 How AI Notes on Looppanel Work | Looppanel Help Center*. https://help.looppanel.com/en/articles/8267823-how-ai-notes-on-looppanel-work
58. *Task Observation*. https://conveo.ai/docs/setup-to-launch/event-detection
59. *Insights Agent- Genie for Interview Summaries, Questions, Themes, Quotes and Recaps – Discuss Help Center*. https://discussio.zendesk.com/hc/en-gb/articles/15371955307537-Insights-Agent-Genie-for-Interview-Summaries-Questions-Themes-Quotes-and-Recaps
60. *How does Perplexity work? | Perplexity Help Center*. http://perplexity.ai/help-center/en/articles/10352895-how-does-perplexity-work
61. *What happened with AI Overviews and next steps*. https://blog.google/products-and-platforms/products/search/ai-overviews-update-may-2024
62. *Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence and amending Regulations (EC) No 300/2008, (EU) No 167/2013, (EU) No 168/2013, (EU) 2018/858, (EU) 2018/1139 and (EU) 2019/2144 and Directives 2014/90/EU, (EU) 2016/797 and (EU) 2020/1828 (Artificial Intelligence Act)Text with EEA relevance.*. https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L_202401689
63. *Tags in Channels 2.0*. https://dovetail.com/changelog/tags-in-channels