Established

Consent and data ownership

Explicit control over what the system may retain, train on, and share, stated before capture.

MCallNorthfield Dental · renewal Not recording yet

What Milky keeps from this call

Transcript and summary

Shared with all 3 attendees afterwards

Audio recording

Deleted automatically after 30 days

Use to improve Milky's models

Off for every call with a customer · workspace policy

Consent

YYou · host✓ Agreed 9:56
LMLeo Martin✓ Agreed 9:58
APDr. Ana Patel · Northfield DentalWaiting

Capture is locked until every attendee answers.

What Ana sees as she joins

M Milky will take notes on this call

Leo Martin invited Milky, an AI notetaker. Before it starts, here's what it keeps:

✓Transcript and summary, shared with the 3 attendees
✓Audio, deleted after 30 days
✕Never used to train AI models

You can change this at any time during the call. Notice v3.

Try it: Answer Ana's join prompt either way. Nothing is captured until she does, and her answer switches the recorder itself, not just a label.

In the wild

How one product ships this pattern. Click a screenshot to enlarge it.

Otter pre-meeting email to all participants with highlighted text saying joining means the meeting will be recorded, and to ask the owner to turn off recording if you prefer not to be — Otter
Before the meeting starts, Otter emails every invitee that the call will be recorded and tells them how to opt out.
Source: Otter help center ↗

When to use

Anything recording people, and every enterprise or regulated deployment.

Seen in

Meeting-recorder consent notices, training opt-outs, voice-clone permission, enterprise retention settings.

For engineers

Consent state must gate the pipeline, not just the UI; log the basis and version of what was agreed.

Build prompt

A neutral, component-only prompt for a coding agent. Edit the stack block or anything else to fit your project, then copy it.

# Build the "Consent and data ownership" pattern: `CaptureConsentPanel`

## Stack (edit this block to match your project)
- React 18+ with TypeScript: one function component, typed props, no `any`.
- Tailwind CSS, using your design system's tokens if you have them.
- Presentational only: data comes in through props, decisions go out through callbacks. No fetching or global state inside.
- If your codebase already has conventions (naming, shared components, tokens), follow them over this spec.

## What the pattern is for
Explicit control over what the system may retain, train on, and share, stated before capture.

Use it when: Anything recording people, and every enterprise or regulated deployment.

## What to build
A panel shown at the moment of sensitive capture (a recording, a transcript, an upload) that states what will be kept, for how long, who it is shared with and whether it is used for training, and collects an explicit answer from each person affected. Capture stays locked until everyone has answered, and each answer is recorded with the notice version. It renders before a call, recording or data collection starts, and as a join prompt for participants.

### Props
- `retention`: Array<{ id: string; label: string; detail: string; enabled: boolean; editable: boolean; policyNote?: string }>, e.g. transcript shared with attendees, audio deleted after 30 days, training off by workspace policy.
- `onToggleRetention?(id: string, enabled: boolean)`: for the host, before capture starts.
- `participants`: Array<{ id: string; name: string; role?: string; consent: "waiting" | "agreed" | "declined"; at?: Date }>.
- `viewer`: "host" | "participant", which view to render.
- `noticeVersion`: string, shown and recorded with each answer.
- `captureStatus`: "locked" | "capturing" | "not-capturing", controlled by the parent, which gates the actual pipeline.
- `onAnswer(participantId: string, allow: boolean)`: records a participant's choice. The component never starts capture itself.
- `onRevoke?(participantId: string)`: lets a participant withdraw during capture.

### States it must render
- Host, waiting: retention list with switches, the participant list with "Agreed 9:56" or "Waiting", and the line "Capture is locked until every attendee answers"; the badge reads "Not recording yet".
- Participant prompt: a plain list of what is kept (ticks) and what is never done (crosses, e.g. "Never used to train AI models"), with "Join and allow notes" and "Join without recording" as equal-weight buttons, and "You can change this at any time. Notice v3."
- Capturing: a red badge naming exactly what is being recorded, e.g. "Recording transcript + audio", and when capture started.
- Declined: capture stays off for the session, with "Not recording: one attendee declined".
- Consent record: who agreed to what, the basis ("Join prompt, notice v3") and when.

### Interactions
- Participant buttons call `onAnswer`; neither option is pre-selected or styled as the default.
- Host retention switches are disabled once capture has started; changes after that require a new notice.
- Revoke during capture calls `onRevoke` and the badge switches immediately to not capturing once the parent confirms.

### Edge cases
- A participant who joins late: capture shows as paused or excluded for them until they answer.
- Everyone agreed but the host turned every retention item off: say "Nothing is kept" rather than showing a recording badge.
- The notice changes between answers: earlier answers are marked as given to the older version and those participants are asked again.
- Training use governed by workspace policy: show the switch locked with the policy note.

## Must avoid
Consent buried at signup that never resurfaces when the sensitive capture actually happens.

## Engineering constraint
Consent state must gate the pipeline, not just the UI; log the basis and version of what was agreed.

## Accessibility
- The participant prompt is a dialog labelled by its heading, with focus on the heading, not on the allow button.
- Announce capture starting and stopping, and each participant's answer in the host view.

## House rules
- Real `<button>`/`<input>` elements, full keyboard use, visible focus; announce status changes with `aria-live="polite"`; respect `prefers-reduced-motion`.
- All user-facing text comes from props (or a `labels` prop) so it can be translated.
- One consistent accent marks anything the AI made or is doing; amber means "needs a person", red means risky, green means done. Never rely on colour alone.
- Fits a 360 px wide container without horizontal scrolling.

## Acceptance checks
- [ ] Every state above can be rendered by passing props, with no internal fake data.
- [ ] Every interaction and edge case above behaves as described.
- [ ] Nothing in "Must avoid" can happen with this component.

## Deliver
1. The component file with its exported prop types.
2. A short usage example that renders each state.

Download this prompt as Markdown, or every prompt as JSON for an agent.

Critique checklist for trust indicators

0 of 4 checked

These questions apply to every pattern in this family. Ticks are saved in this browser.

Can a claim be traced to a source in one click?
Does uncertainty change the interface, not just the wording?
Is confidence calibrated, or decorative?
Does the design make verification cheaper than re-doing the work?