Summary

  • A plausible substitute can hide a real account number while presenting a false one as ordinary conversation data. A later human or agent may then send a real refund to the invented account.
  • VCON core can link a derivative to a predecessor, bind referenced content with a hash and identify the signer. Those controls establish lineage and byte integrity; they do not prove that every sensitive span was found, that a replacement is true or that a downstream action is safe.
  • High-consequence consumers therefore need a machine-readable transformation receipt and a local action policy. That receipt is an operational proposal in this analysis, not a requirement already standardized by draft-rosenberg-vcon-redaction-00.

A privacy success can be an evidence failure

Imagine a support call in which a customer asks for a refund and reads an account number. Before the recording is shared, a processor replaces that number with another value of the same shape. The new value does not reveal the customer. It also does not look altered. A service agent—or an autonomous system reading the transcript—sees a credible account number and treats it as the one the customer supplied.

That is not an exotic edge case. It is the example that gives draft-rosenberg-vcon-redaction-00 its sharpest operational consequence. The document was posted on 29 September 2026 as an individual Internet-Draft with intended Informational status. It describes use cases and requirements for discussion. It is not an RFC, not an adopted VCON Working Group item, not evidence of consensus and not a deployment claim.

The risk is easy to misclassify. Privacy strength asks whether the protected value can be recovered or linked back to a person. Evidence safety asks whether the released value may be mistaken for something observed. A realistic fake can score well on the first axis while becoming dangerous on the second. Money movement, account closure, credential reset, entitlement change and incident attribution all turn that distinction into an effect.

What the envelope already says—and what it cannot say

Revision 04 of the VCON core draft defines a redacted object that should name the UUID of an unredacted or less-redacted predecessor. It may include a restricted URL and a content hash; if the URL is supplied, the hash is required. The derivative should be signed by the entity that created it. When a member of an array disappears completely, an empty placeholder is recommended so later indices remain stable.

Those are useful controls. A predecessor reference tells a permitted custodian which record came before. A content hash detects changed referenced bytes. A signature identifies the party asserting the derivative. A placeholder avoids silently moving later objects.

None of them describes the redaction method. VCON core deliberately leaves text, audio and video redaction out of scope. A valid signature therefore means that a key signed these derivative bytes. It does not mean every sensitive field was detected, a retained field is accurate, a substitute is original speech, or the signer had authority to expose the predecessor. A positional placeholder may even preserve information that the privacy purpose meant to suppress.

The redaction draft adds a vocabulary for the missing choices. Was redaction explicitly signaled to software? Does the result reveal the affected position? Does it reveal the participant? Can a person or model notice the edit? Was the value removed, substituted, or merely tagged while remaining present? These properties are independent. Keeping time and speaker can preserve chronology while exposing a protected witness. Hiding both can make a sequence impossible to audit.

Five methods, five different records

Deleting an entire dialog object removes more than the sensitive identifier. It can erase the fact that the caller disputed a charge, change array positions and break references unless they are repaired. The released conversation may look shorter without explaining why.

Keeping a dialog shell preserves parties, start time and duration while removing the body or external media. Indices and chronology survive, but a mixed-purpose turn is lost merely because one span contained personal information. The shell says that something occurred; it does not preserve what non-sensitive claim occurred with it.

Visible substitution—such as XXX or the word REDACTED—warns a human, yet it is not schema. The speaker may literally have said “XXX”; another language may use a different convention; software cannot safely infer whether the token is source content or an editorial mark.

Plausible substitution removes that visible warning. Synthetic speech, reconstructed video or a realistic identifier can protect disclosure while presenting invented content as observation. This is where privacy processing manufactures operational facts.

Tagging takes the opposite risk. The original value remains present and a trusted recipient is expected to hide or reveal it according to authorization. The protection is only as good as every consumer's access control, rendering and onward-sharing behavior.

There is no universally best method. The missing invariant is that a recipient must know what class of record it has and which inferences are no longer available.

The transformation receipt

For consequential use, the derivative should travel with a separate, signed receipt. In this analysis—not in revision 00 as a finished standard—the minimum receipt contains the source and derivative identifiers and commitments; the policy version and purpose; exact machine-readable locations; the pre-transform data class; and the operation at each location: removed, shell-retained, visibly substituted, plausibly substituted, tagged or encrypted.

It should state whether position and participant identity were deliberately retained or suppressed, who processed the record, under which signing-key scope and at what time. Every locator needs a validation result and unresolved locations must fail closed. The receipt also needs consumer restrictions: no payment, credential change, legal attribution or model training from a plausible substitute unless the original is revalidated through an authorized route.

RFC 6901 JSON Pointer can identify a location, but the RFC leaves failure handling to the application; a pointer that no longer resolves is not a minor formatting error. RFC 7515 can sign the assertion. RFC 8785 can make JSON serialization deterministic for repeatable commitments. Together they can bind an intelligible claim. They cannot prove that the processor found every sensitive field or that its policy was correct.

That residual problem requires independent tests: detection coverage, sampled comparison under controlled access, consistent treatment across text, audio and video, and review of new data types. The receipt records what the processor claims it did. It is not a magical proof of completeness.

A signature is not a passport from one reality layer to another

The companion draft on verifiable agent conversations makes the same boundary explicit: a valid signature establishes the signer, not the truthfulness of signed content. It separates runtime, recorder, storage, verifier and decision-maker trust. That separation becomes more important as VCON expands from human calls toward agent prompts, tool inputs, outputs and events. A single session can contain credentials, file contents, identifiers and commands that trigger external effects.

Lu Heng's reality-layer discipline supplies the operating rule. The source conversation is one layer. The privacy derivative is another. The processor's receipt is an assertion about the transition. A later refund is a new event. The authority of the source must not silently pass into a derivative value simply because the derivative looks natural or carries a valid signature.

The later actor should issue a separate action receipt linking its decision to the derivative commitment, the transformation receipt and the local policy applied. Then an investigation can distinguish four questions: what was said, what was changed, what the consumer was allowed to infer, and what the consumer actually did.

Sources and limits

The redaction proposal is early discussion text and contains unresolved design questions. No named contact center, VCON implementation, model provider or redaction vendor is evaluated here. Nothing in this analysis determines legal compliance for a particular jurisdiction. GDPR Article 5 and NIST SP 800-122 reinforce the need to combine minimisation with accuracy and appropriate safeguards; neither turns this proposed receipt into a legal safe harbour.