The respondent stays in control of what was said.

The workers who sit for an interview hear what will happen before the conversation starts. They consent or decline before the recording begins. Anything they ask to redact is redacted at the redaction stage. If they revoke consent after the interview, every fact derived from their conversation is withdrawn from the intelligence layer through the tombstone mechanism.

This page describes the consent flow at start, the extensible redaction list you control, the revocation path, and how a revocation propagates through derived facts.

The interview agent opens every conversation by describing four things to the respondent: what will be captured (audio plus a structured transcript), how the output will be enriched (typed claims about brand perception, pain points, opportunities), which endpoints the enriched output will reach (your dashboard, the brand-partner API, the agent feed), and what the respondent’s rights are (revocation, redaction request, transparency record).

The respondent confirms verbally. The confirmation is captured in the consent record attached to the conversation. If the respondent declines, the recording does not begin and no datalake entry is written.

The consent script is published. Your legal team can review it before any deployment. The script can be adapted to your jurisdiction (Loi 25 Quebec, GDPR, HIPAA-informed-consent variants) without modifying the underlying flow.

The redaction stage strips names, person identifiers, and evocations from the raw transcript before any enrichment call runs. The default list covers respondent names and common identifier patterns. Beyond the defaults, the redaction list is yours to extend. Anything specific to your business that should never appear in a transcript, you add to the list.

Common extensions: customer account numbers, internal project codes, names of internal personnel who could be identified by their role description, supplier names tied to a confidentiality agreement, names of competitor executives that the respondent might mention. The list is edited in the operator console. Changes take effect on the next conversation.

The redaction list is versioned. A conversation enriched under list version 4 carries a reference to that version on its metadata, so an audit can establish what was redacted at the time of processing.

A respondent who revokes consent contacts the operator (or, in some deployments, uses a self-service link included in the post-interview email). The revocation writes a tombstone event against the conversation identifier in the datalake index. The tombstone carries the revocation timestamp and the requested scope (the entire conversation, a specific topic, or a specific quote).

The tombstone takes effect immediately on the read side. The query worker checks the tombstone flag before serving any data from the affected conversation. The conversation’s entity rows in the fact store are marked invalid at the tombstone timestamp on the next enrichment refresh. Aggregates that ran before the tombstone are recomputed on the next full refresh cycle.

Every fact row in the corpus carries a chunk identifier of the form transcript_id / turn_id / sentence_id pointing back to the source sentence. The chunk identifier is the propagation handle.

When a tombstone is written, the corpus indexer finds every fact whose chunk identifier resolves to the tombstoned conversation and marks the fact invalid_at = tombstone_ts. The bi-temporal query path filters facts whose validity window includes the query time, so tombstoned facts stop being returned. They are not deleted; the audit trail preserves their existence and their tombstone status.

For aggregates already computed before the tombstone, the recompute on the next refresh excludes the tombstoned facts. The pre-tombstone aggregate is retained for audit with a reference to the tombstone event that triggered its replacement.

The tombstone event is permanent. Every fact whose chunk identifier resolves to the tombstoned conversation carries its tombstone reference. A query like “show me every piece of intelligence that derived from the conversation with respondent X, and confirm none of it is currently served on the dashboard” is answerable from the tombstone reference and the bi-temporal validity window.

For regulators who ask for proof of compliance with a right-to-erasure request, the audit trail is the proof. The respondent receives a confirmation that lists every fact derived from their conversation and the timestamp at which each fact stopped being served.

Aggregates already shared in a published report cannot be retracted from the report; what we can do is exclude the respondent’s contribution from the next aggregate and amend the report’s underlying dataset. The tombstone is retroactive on the corpus; it cannot rewrite a PDF that left the platform last quarter.

Statistical artifacts from a single respondent in a large corpus are typically below the threshold of practical re-identification. The tombstone still applies. The corpus operator can decide whether to recompute an aggregate or to leave it as-is with a footnote referencing the tombstone.