Registering a Voice
Eight steps from application to certificate
A standard registration establishes a rights basis before it establishes a technical record.
-
Open an application record
An application number is created, recording the applicant, the voice subject, and the relationship between them (self, guardian, authorized agent, or estate representative).
-
Verify identity and live consent
The applicant's identity and present willingness are verified. A high-authority registration cannot be completed on the strength of a historical recording alone.
-
Present purpose-scoped consent
The subject selects, purpose by purpose, what the voice may be used for: readout, private communication, internal meetings, public presentation, commercial advertising, research, or model training. Consent to one purpose is never treated as consent to another.
-
Collect or import the sample
A sample is captured or imported, together with device, timestamp, format, sample rate, channel count, language, and quality metadata.
-
Digest and screen the original
A cryptographic digest is computed over the original file, and it is screened for malicious content and duplication.
-
Generate the feature sheet and codebook
A voice feature sheet and codebook manifest are generated, recording the exact algorithm and model versions used to produce them.
-
Risk review
A registrar or an automated rule set completes a risk review. High-risk purposes require a human reviewer.
-
Issue the certificate and receipt
A registration certificate and receipt are issued, and the voice identity record becomes active.
Stable Identity
A registration number that outlives any vendor
Every registered voice receives a voice_profile_id that does not depend on which synthesis vendor or model is behind it.
The recommended display format is VR-AU-YYYY-NNNNNN-C, where the regional code identifies the registry or governing scheme, not a nationality. Machine interfaces use a random UUID or an opaque identifier of equivalent strength. A vendor's speaker_id, an internal model embedding ID, or a filename is stored only as a provider_ref — never as the permanent registration key. If a vendor reference is leaked, expires, or migrates, the voice identity record itself remains valid and unaffected.
Status Machine
Every registration has exactly one current status
Status changes are appended as new events; they never overwrite the record they replace.
PENDINGDocumentation or review incomplete — synthesis is not permitted.ACTIVEUsable within the authorized scope.SUSPENDEDPaused during a dispute, risk flag, or security event.REVOKEDWithdrawn by the subject or a rights holder — no new output in that voice is permitted.EXPIREDThe authorization period has lapsed.ARCHIVEDRetained only as a legal or evidentiary record — not usable in production.DESTROYEDPrivate material that required deletion has been verifiably destroyed.
Recovering from SUSPENDED requires a fresh review receipt. REVOKED cannot be reversed by an ordinary administrative action — restoring use requires creating a new authorization version, not reopening the old one.
Verifying a Voice
A query returns a status, not a guess
The registry is designed to answer "is this authorized, right now, for this purpose" — not merely "does this voice exist".
A registry query must return one of six explicit states: ACTIVE, RESTRICTED, SUSPENDED, REVOKED, EXPIRED, or NOT_FOUND. Every action that changes a rights status — registration, authorization, transmission, acceptance, or revocation — must produce both a human-readable receipt and a machine-verifiable one. Those receipts are chained: each new receipt incorporates the digest of the one before it, so the sequence as a whole can be verified for tampering, not just checked entry by entry.
The registry ledger itself stores only the minimum needed to support that public proof: the registration number, subject-indicating information, status, an authorization summary, feature sheet version, codebook summary, timestamps, the issuer, and a receipt summary. Original audio, full embeddings, and vendor credentials are never written into the registry ledger.
Revoking a Voice
Revocation stops future use — it does not rewrite history
Revocation immediately blocks new matching and synthesis tasks. The system may retain a minimal registration number, summary, timestamp, and revocation basis, to prove that a voice "was registered and has since been revoked". What it must not do is use ledger immutability as a justification for permanently retaining the original samples and feature material that could directly reconstruct that person's voice — those are deleted, sealed, or retained only as legally required, and a destruction receipt is issued when they are.
See It Running
The registry demo implements this flow
The demo workspace lets you register a voice, attach a feature sheet and codebook, and verify the receipt chain — entirely in your browser, with no data leaving your machine.