Voice Registration and Trusted Circulation

Executive Summary

This whitepaper proposes a unified institutional design for voice management: the voice registry as the point of governance, the voice feature sheet as the standard record, the voice store as the controlled custody facility, the voice codebook as the matching resource shared between authorized parties, the voice seed as a lightweight transmission object, and verifiable receipts running through registration, use, revocation, and destruction.

The design is not centered on any one cloud vendor, synthesis model, or compression algorithm. A vendor's speaker ID can be replaced without invalidating a voice identity's registration number; a synthesis engine can be upgraded, but a historical seed must still be able to state which voice, which version of which feature library, and under what authorization it used; a registration can be permanently retained as a record without granting the underlying raw voice and biometric material any "keep forever" privilege.

Eight founding principles:

1. Register before use. Without valid registration and authorization, no one may clone, match, synthesize, or publish output in another person's voice.
2. Identity is decoupled from engine. A permanent voice identity number must never be made equivalent to a Volcano Engine, ElevenLabs, or other vendor's speaker ID.
3. Three domains are kept separate. Public registration metadata, restricted voice features, and private raw samples must be stored in separate zones, under separate permissions and separate keys.
4. Purpose is scoped. Consent to use a voice for meeting readout does not automatically extend to advertising, identity verification, public distribution, or model training.
5. Versions are pinned. Every match, transmission, and synthesis event must be traceable to a specific feature sheet, codebook, engine, and authorization version.
6. Revocation is effective. After revocation, no new output in that person's voice may be produced; historical registration and revocation receipts may be kept, but private material should be deleted, sealed, or retained only as legally required.
7. Failure must not impersonate. When a match cannot be made, cannot be verified, or authorization is insufficient, the system must fall back to a generic voice, text, or an explicit error — never silently substitute another voice or fake success.
8. Claims must be provable, not just asserted. Compression ratio, similarity, latency, security, and weak-network performance must each be tied to a stated test condition and evidence.

Chapter 1 — Scope and Normative Levels

1.1 Scope

This whitepaper applies to: collection, registration, updating, revocation, and destruction of a natural person's voice samples; voice feature extraction, feature-sheet generation, codebook creation, and version management; storage of original voice material, feature vectors, audio units, seeds, and synthesis output; lightweight transmission based on text, unit numbers, timing, prosody, or difference data; matching, splicing, generation, cloning, and playback based on already-registered voices; and voice exchange within an organization, between authorized contacts, or across systems.

This whitepaper does not claim to replace judicial registration, notarization, identity-management law, privacy law, or dedicated biometric regulation. Before commercial deployment, qualified professionals in the applicable jurisdiction should review consent text, rules for minors and the deceased, cross-border data flows, retention periods, and dispute-handling terms.

1.2 Normative Levels

The system uses a four-layer structure: a governance layer deciding who may register, authorize, review, revoke, and audit; a data layer defining the fields and versioning of the registry, feature sheets, manifests, receipts, and status; a protocol layer defining query, hit, transmission, reassembly, acceptance, degradation, and error handling; and an implementation layer where a given product chooses its database, object storage, algorithms, models, and network transport. Upper layers constrain lower ones — no implementation may use "it is technically possible" as a reason to bypass authorization, revocation, purpose limits, or audit requirements.

1.3 Key Terms

Must / must not denote requirements a compliant implementation cannot omit. Should denotes a rule that must be followed in principle and may be departed from only with a recorded reason. May denotes an optional capability for a compatible implementation.

Chapter 2 — Core Objects and Unified Terminology

"Voice identity" is not the same as "voiceprint authentication". The former manages the rights, expression, and synthesis use of a voice; the latter judges whether a given person is a specific real subject. Unless a separate security assessment has been completed, a synthesized voice under this system must not be used as the sole authentication factor for banking, access control, or account login.

Chapter 3 — Voice Registration

3.1 Eligibility

Voice registration must be based on a verifiable source of rights: registration by the person themselves, by a legal guardian, by a clearly authorized agent, or — within what applicable law and platform policy permit — by an estate or next-of-kin rights manager. Simply holding a recording is not the same as owning the right to clone, synthesize, or publicly distribute the voice within it.

3.2 Registration Flow

A standard registration completes the following steps: open an application record noting the applicant, the voice subject, and the agency relationship; verify identity and live willingness, so that a high-authority registration is never completed on a historical recording alone; present purpose-scoped consent covering readout, communication, internal meetings, public distribution, commercial advertising, research, and model training, selected separately; collect or import the sample, recording device, time, format, sample rate, channel count, language, and quality; compute a cryptographic digest of the original, and run malware and duplicate-sample checks; generate the voice feature sheet and codebook manifest, recording algorithm and model versions; complete a risk review by a registrar or automated rule — high-risk purposes require human review; and issue a registration certificate and receipt, activating the voice identity record.

3.3 Stable Numbering

Each voice identity receives a non-reusable voice_profile_id. The recommended display format is VR-AU-YYYY-NNNNNN-C, where the regional code denotes only the registry or governance domain, not nationality; machine interfaces should use a random UUID or an opaque identifier of equivalent strength. A vendor's returned speaker_id, an internal model embedding ID, or a filename is stored only as a provider_ref, never as the permanent registration key. The voice identity record remains valid even if a vendor reference leaks, expires, or migrates.

3.4 Status Machine

Registration status is unified as: PENDING (documentation or review incomplete — synthesis not permitted); ACTIVE (usable within the authorized scope); SUSPENDED (paused during a dispute, risk, or security event); REVOKED (withdrawn by the subject or a rights holder — no new output in that person's voice); EXPIRED (authorization period lapsed); ARCHIVED (kept only as a legal or evidentiary record, not usable in production); and DESTROYED (private material requiring deletion has been verifiably destroyed).

Status changes must be appended as new events, never overwriting the prior record. Recovering from SUSPENDED requires a new review receipt; REVOKED must not be reversible through an ordinary administrative button — restoring use requires creating a new authorization version.

3.5 Change and Revocation

Non-substantive fields such as name, label, or contact details may be corrected, but the change history must be preserved. Any change affecting a voice's expression or use — adding a language, updating the core sample, changing commercial permissions, replacing the model, or expanding the set of recipients — must generate a new version.

Revocation must immediately block new matching and synthesis tasks. The system may retain a minimized registration number, summary, timestamp, and revocation basis to prove that a voice "was registered and has since been revoked"; it must not use registry immutability as a reason to permanently retain original samples and feature material that could directly reconstruct that person's voice.

Chapter 4 — Voice Feature Sheet Standard

4.1 Design Goals

A voice feature sheet is not a subjective list of adjectives, nor a single voiceprint vector. It must simultaneously support rights management, technical reproduction, quality assessment, cross-engine migration, and dispute verification, while clearly distinguishing factual records, algorithmic output, and human judgment.

4.2 Required Field Groups

4.3 Data Classification

Feature sheets are classified into three tiers by field, not as a single all-or-nothing document: R0 registration-public — registration number, public label, status, publicly permitted language, and certificate digest; R1 business-restricted — authorization scope, quality metrics, codebook version, engine compatibility, and audit information; and R2 biometric-private — raw voiceprint, embeddings, reversible features, source sample location, and key material. R2 data must not enter public registry queries, ordinary business logs, analytics tracking, or client-side caches. That a vector "cannot be heard directly by a human ear" is never a reason to lower its protection tier.

4.4 Versioning Rules

Feature sheets use immutable versioning. Correcting an error creates a new version linked via supersedes rather than overwriting in place. Every call must record the feature_sheet_version actually used; "latest" may be used for queries only, never written into a final receipt.

Chapter 5 — The Voice Registry

5.1 Function

The voice registry is the institution or software service that manages trusted status and the chain of rights — it is not equivalent to a file drive holding every voice recording. Its core responsibilities are intake, verification, numbering, issuance, query, authorization, suspension, revocation, audit, and dispute flagging.

5.2 Roles

Voice subject decides the scope of authorization and exercises rights to query, correct, revoke, and delete. Applicant submits materials and guarantees the accuracy of the stated source of rights. Registrar reviews identity, consent, and sample completeness, but does not decide commercial use on the subject's behalf. Store custodian maintains storage, keys, backups, and destruction, and may not unilaterally expand authorization. Processor performs matching, transmission, or synthesis within the authorized scope. Auditor checks receipts, access logs, permissions, and deletion proof. Dispute handler takes suspension action on impersonation, authorization conflicts, and abuse reports.

High-risk operations require separation of duties. Whoever can approve public commercial synthesis should not simultaneously hold the power to export original samples and clear audit records.

5.3 Minimum Registry Record

The registry stores only the minimum record needed to support public proof: registration number, subject-indicating information, status, authorization summary, feature sheet version, codebook summary, registration and status-change timestamps, issuer, and receipt summary. Original audio, full embeddings, and vendor credentials must not be written into the registry.

5.4 Query and Receipts

Query results must return an explicit status, not a bare yes/no: ACTIVE, RESTRICTED, SUSPENDED, REVOKED, EXPIRED, NOT_FOUND. Every operation that changes a rights status must produce both a human-readable and a machine-verifiable receipt.

Chapter 6 — The Voice Store

6.1 Three-Domain Storage

Voice assets should be split, physically or cryptographically, into three storage domains: a registration domain holding minimal registry metadata, status, and receipts, replicable for high availability; a feature domain holding embeddings, indexes, codebooks, and acoustic units, accessible only to controlled compute services; and an original domain holding source recordings and high-fidelity intermediates, under the highest protection tier and the shortest necessary retention period. Cross-domain references use opaque IDs and digests, never guessable paths, names, or vendor IDs. Production logs should record only truncated IDs and receipt numbers.

6.2 Content Addressing and Integrity

Files and immutable objects should be content-addressed using SHA-256 or a security-reviewed digest of equivalent strength. The recommended path structure is sha256/<first two chars>/<full digest>. Writes must validate first, then land in a temporary location, then commit atomically, so that no half-written file ever enters the live store. A digest establishes integrity and deduplication — it is not the same as access authorization or a digital signature. Manifests and receipts involved in rights status or cross-subject exchange must be separately signed.

6.3 Encryption and Keys

Data at rest should be encrypted per domain, with distinct data-encryption keys between subjects or tenants. Key rotation must not change the voice identity number, but should generate a new custody event. Backups, disaster-recovery copies, and test copies must follow the same deletion, revocation, and access rules as production.

6.4 Retention and Destruction

Each asset class must have a retention_policy recorded at registration. When the period lapses, the purpose is fulfilled, or authorization is revoked, the system should execute deletion, cryptographic destruction, or dispute sealing as applicable, and issue a destruction receipt. "Might be useful someday" must not be the default justification for keeping an original voice indefinitely.

Chapter 7 — Unified Standard for Voice Compression, Transmission, and Reassembly

7.1 Layering Principle

Voice transmission is unified into four layers: a transport layer (TCP, QUIC, controlled file delivery, or another reliable byte channel); a registry and store access layer (identity authentication, proof of authorization, library version negotiation, and hit queries); a voice seed layer (transmission unit numbers, text/semantics, timing, prosody, difference data, and an acceptance checklist); and a reassembly layer (table-driven assembly, deterministic expansion, or an authorized generative engine). SeedVoice's primary path should be matched communication between authorized parties sharing the same version of a voice codebook; full neural generation is used only for missing units, isolated content, or fallback recovery. A codebook handshake provides an inherent binding to the library and protection against misdelivery, but does not substitute for end-to-end encryption.

7.2 Library Query

Before sending, the sender should query the receiving end's capability using voice_profile_id + library_id + version + manifest_digest. The receiver returns HIT (version and digest fully match — unit references can be sent), NEAR (a compatible baseline exists — a baseline reference plus a diff can be sent), or MISS (no usable library — fall back to a generic voice, low-bitrate original, or an explicit failure, by negotiation). The receiver must not silently use the "most recent version" when versions mismatch — any compatibility mapping must carry an explicit mapping version and acceptance result.

7.3 Decomposition and Manifest

The sender decomposes the target expression into ordered unit references, timing, and necessary differences, producing a voice_manifest. Each segment includes at minimum a sequence number, a unit ID or object digest, start/end time, a segment digest, and a recovery mode. The full manifest includes voice identity, authorization credential, codebook version, content digest, engine requirements, and overall acceptance conditions.

Where only a text-to-unit-number codebook exists today, the system may claim only to have completed "information matching and number-based recovery" — it must not claim to have completed acoustic-segment assembly. Genuine acoustic feature units must contain authorized audio or verifiable features, and must pass continuity, audio-quality, and speaker-similarity testing before being enabled.

7.4 Transmission Priority

The unified fallback order is: (1) exact codebook unit reference; (2) compatible baseline plus a diff stream; (3) an authorized generic synthesized voice; (4) low-bitrate original voice or original file in chunks; (5) an explicit error with the text content preserved. The protocol must not, in pursuit of "never failing", substitute a similar person's voice without authorization. The so-called "no dead end" means preserving information and an explicit status — not unconditionally copying an identity.

7.5 Chunking, Resumption, and Acceptance

When an original file or diff object must be sent, content-addressed chunking should be used. Each chunk and the whole are digested separately; the receiver checks for missing chunks against the manifest, and supports chunk deduplication and resumable transfer. After reassembly, segment digests are verified first, then the overall digest, and finally a voice-quality or semantic acceptance test. Byte-for-byte equivalence applies only to original files or deterministic assembly. Generative recovery can only claim to have passed its stated acceptance test — it cannot broadly claim to have restored the original waveform.

7.6 Minimum Message Family

The unified protocol should provide at minimum: HELLO, HELLO_ACK, LIB_QUERY, LIB_RESULT, VOICE_MANIFEST, SEED_VOICE, RAW_FALLBACK, ASSEMBLY_RESULT, ACK, NACK, ERROR, PING, and PONG. Every data message must include a session ID, sequence number, timestamp, content digest, and authorization reference.

Chapter 8 — Synthesis and Output Management

8.1 Pre-Synthesis Checks

Every synthesis call must pass four checks simultaneously: the voice registration is valid; the purpose is within the authorized scope; the recipient or scenario is permitted; and the required feature sheet and codebook versions are available. Failing any one must prevent the vendor or local cloning engine from being invoked.

8.2 Output Labeling

Synthesized output should carry a machine-readable provenance manifest, and in scenarios where an ordinary person could mistake it for a real-time human speaker, a perceptible "synthesized / AI reproduction" notice should be provided. The output manifest should record at minimum the voice identity, authorization version, input content digest, engine and model version, generation time, and task receipt. Labeling must not rely on a single filename that can be stripped. High-risk public output should combine interface disclosure, metadata or content credentials, and a retained server-side audit receipt.

8.3 Prohibited Uses

Unless a dedicated policy, strong authentication, and risk approval are in place, a registered voice must not be used to: bypass voiceprint authentication; impersonate a person for legal or financial commitments; provide unconsented political or commercial endorsement; harass or defraud; fabricate evidence; or train a model not named in the authorization.

8.4 Vendor Governance

External engines must be managed as replaceable processors. Data sent to a vendor should be minimized, with region, purpose, retention policy, deletion capability, and vendor reference recorded. Engines may be switched on vendor failure, but the original authorization scope must not change, and a vendor's default training terms must never be treated as the subject's consent.

Chapter 9 — Security, Privacy, and Audit

9.1 Threat Model

The system should guard at minimum against: impersonation registration, stolen recordings, unauthorized synthesis, leaked vendor IDs, feature-library scraping, replay attacks, cross-tenant queries, manifest tampering, continued generation from a revoked voice, and log leakage.

9.2 Minimum Controls

Strong authentication is used for registration, authorization expansion, export, revocation recovery, and bulk synthesis; subject, tenant, voice identity, and purpose are jointly required for authorization; devices or contacts perform a mutual signed handshake and verify library digests; the network uses standard encryption, with sensitive payloads under reviewed application-layer authenticated encryption; anti-replay sequencing, time windows, idempotency keys, and rate limiting are all enabled; every task that reads R2 data or produces a person's voice writes a non-repudiable audit event; and keys, originals, embeddings, and full vendor credentials are never written into business logs.

9.3 Incident Response

On suspected leakage or impersonation, the registry should be able to set a voice identity to SUSPENDED with one action, stop new synthesis, freeze related authorizations, preserve necessary evidence, and notify the rights holder. After investigation, only a signed decision may move the case into recovery, revocation, or destruction.

Chapter 10 — Interoperability, Conformance, and Quality Standards

10.1 Interoperability Requirements

A compatible implementation must be able to export a standard registration record, feature-sheet manifest, codebook manifest, authorization receipt, and revocation receipt that contain no vendor secrets. Migration does not require exporting a vendor's proprietary model weights, but must state which capabilities cannot be carried over.

10.2 Conformance Levels

L0 registration-compatible — can exchange identity, status, authorization, and receipts. L1 library-compatible — can query and verify feature-sheet/codebook ID, version, and digest. L2 transmission-compatible — can complete seeding, chunking, acknowledgment, resumption, and integrity acceptance. L3 reassembly-compatible — can perform deterministic recovery for frozen modes, or run the unified acceptance test for generative modes. L4 governance-compatible — can perform revocation, destruction, audit export, and cross-vendor migration. A product must not claim "fully compatible with this standard" on the strength of L0 alone.

10.3 Test Baseline

Conformance testing should include at minimum: wrong signature, wrong subject, wrong codebook version, out-of-library content, tampered chunks, missing chunks, replayed sequences, resumed transfer after disconnection, expired authorization, immediate revocation, vendor unavailability, generic-voice fallback, and audit export. Performance reports must state device, network, sample, encoding, whether a handshake is included, whether initial library build is included, whether model cold start is included, and the comparison baseline. A single-machine lab processing time must not be treated as equivalent to public-network end-to-end latency.

Chapter 11 — Governance and Standard Evolution

11.1 Version Governance

A major version change represents an incompatible change to rights or data semantics; a minor version adds backward-compatible fields; a patch version fixes wording or implementation errors only. The meaning of a field in a frozen version must not be reinterpreted.

11.2 Change Procedure

A standard change should go through issue registration, technical draft, privacy and security review, compatibility testing, public or designated-scope comment, approval, and an effective date. A change that expands default authorization, weakens deletion capability, or weakens identity authentication must not be released as an ordinary technical patch.

11.3 Independent Oversight

At scale, a governance body including technical, privacy, voice-subject representative, and business-operations members should be established. It manages the high-risk use catalog, dispute-handling principles, vendor admission, conformance testing, and transparency reporting, without directly touching day-to-day raw voice data.

Chapter 12 — Phased Rollout

Phase 1 — Institutional and Registration Foundation

Freeze unified terminology, identity numbering, the status machine, purpose-scoped authorization, registration receipts, and three-domain storage. Migrate existing voice registration data so that voice_profile_id is decoupled from vendor speaker_id.

Phase 2 — Lightweight Transmission Loop

Implement codebook query, signed handshake, seed manifest, file chunking, resumption, reassembly, and acceptance receipts. Use the existing text-to-unit-number codebook to demonstrate "information matching", and a small voice file to demonstrate byte-level original recovery — reporting the two separately.

Phase 3 — Acoustic Feature Unit Library

Once clearly authorized, build genuine voice units, a nearest-neighbor index, a diff stream, and splicing-continuity handling. Only after passing blind listening, speaker-similarity, intelligibility, latency, and weak-network testing may acoustic assembly be listed as a production capability.

Phase 4 — Cross-Institution Interoperability

Establish an independent conformance test suite, trust anchors between registries, revocation synchronization, cross-border data policy, and vendor migration tooling, and study the conditions for becoming an industry-body specification or a formal standard proposal.

Appendix A — Minimum Voice Registration Data Model

{
  "schema": "voice-registry-entry/v1",
  "voice_profile_id": "opaque-uuid",
  "display_label": "Founder's Voice",
  "subject_type": "SELF",
  "status": "ACTIVE",
  "consent_version": "consent-v1",
  "allowed_purposes": ["PRIVATE_COMMUNICATION", "MEETING_READOUT"],
  "feature_sheets": [
    {
      "id": "founder-zh-features",
      "version": 1,
      "manifest_digest": "sha256:..."
    }
  ],
  "codebooks": [
    {
      "id": "founder-zh-v1",
      "version": 1,
      "manifest_digest": "sha256:..."
    }
  ],
  "provider_refs": [
    {
      "provider": "replaceable-provider",
      "ref": "encrypted-or-tokenized-reference"
    }
  ],
  "created_at": "2026-07-17T00:00:00Z",
  "expires_at": null,
  "receipt_digest": "sha256:..."
}

Appendix B — Minimum Voice Transmission Manifest Data Model

{
  "schema": "voice-manifest/v1",
  "manifest_id": "sha256:canonical-manifest",
  "session_id": "opaque-session-id",
  "voice_profile_id": "opaque-uuid",
  "authorization_ref": "grant-receipt-id",
  "library": {
    "id": "founder-zh-v1",
    "version": 1,
    "manifest_digest": "sha256:..."
  },
  "mode": "CODEBOOK_REF",
  "segments": [
    {
      "seq": 1,
      "unit_id": 17,
      "t0_ms": 0,
      "t1_ms": 240,
      "segment_digest": "sha256:..."
    }
  ],
  "acceptance": {
    "type": "CONTENT_DIGEST",
    "expected": "sha256:..."
  },
  "created_at": "2026-07-17T00:00:00Z"
}

Appendix C — Boundaries Not to Be Confused

1. Recovering text or information via codebook numbers is not the same as having recovered the voice.
2. Synthesizing a similar-sounding voice is not the same as recovering the original waveform.
3. Reassembling a file from hash-checked chunks is byte transmission and reassembly — it is not the same as acoustic feature compression.
4. A handshake that binds identity and codebook provides inherent protection against misdelivery and one layer of confidentiality — it is not the same as complete end-to-end encryption.
5. A tamper-evident registry does not mean the original voice must be permanently stored.
6. Being able to generate a voice is not the same as having the right to use that voice.

Closing

What future voice systems truly need to unify is not just an audio format or a compression ratio, but the full chain of evidence running from "whose voice is this, and on what basis may it be used" through to "which feature version was used, how was it transmitted, how was it reassembled, who accepted it, and when was it revoked."

Voice registration answers questions of rights and status; the voice feature sheet describes computable properties; the voice store safeguards sensitive assets; the voice registry issues and audits; and SeedVoice/CookSeed carries rules, numbers, and necessary differences efficiently between already-authorized parties. Working together, these five turn voice from an uncontrolled file into a manageable, portable, revocable, and verifiable digital resource.

This v0.1 is an institutional first draft. The next version should be frozen only after real registration workflows, a remote-transmission MVP, revocation drills, an independent security review, and applicable legal review are complete.