The consent plane

The consent plane is VFTE's single source of truth for one question: may this person's voice be recognized, and may their name be shown? It is separate from workspace membership and from sharing.

The controls

• subject_consent (per edge) — the core naming decision:
  • allow — "say my name."
  • anonymous — "know me, but hide my name" (recognized, not labeled).
  • denied — "don't recognize me at all here."
• id_visibility — adder-only vs scope-wide: who gets to see that it's you.
• enroll_allowed — pause enrollment entirely (stop new voiceprints forming).
• Forget / erasure — hard-delete a voiceprint; an append-only ledger row + signed receipt remain.

The old flat identify_allowed boolean was folded into subject_consent (task #2) and its alias retired (#35).

Propose → Confirm → Deny

Recognition never silently names someone:

1. A host tags a speaker → POST /v1/propose → the match goes pending.
2. The subject confirms or denies from their inbox (GET /v1/me/pending). Self-tagging auto-confirms.
3. The proposal can carry a clip_ref so the subject can play the clip that named them — via a short-lived Ed25519-signed capability, so VFTE itself never streams the bytes (#3).

Recognition transparency

Even a consented auto-recognition is recorded and notified every time (POST /v1/recognitions → the subject's GET /v1/me/recognitions inbox), with metadata and controls — but no transcript access. Recognized-but-still-told (#3c).

Member ≠ recognized

A crisp distinction the whole model rests on: being a member of a workspace (you hold a key) is not the same as being recognized in it (your voiceprint is on file). The consent plane governs only the second. See Workspaces.

Source: FEATURE-SPEC.md §4.3 & §2.5, FPM/CONSENT-PLANE.md, discoveries/WORKSPACES-AND-VFT-GRAMMAR.md.