Registration, verification, and revocation, step by step

1. 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).

2. 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.

3. 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.

4. Collect or import the sample

   A sample is captured or imported, together with device, timestamp, format, sample rate, channel count, language, and quality metadata.

5. Digest and screen the original

   A cryptographic digest is computed over the original file, and it is screened for malicious content and duplication.

6. 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.

7. Risk review

   A registrar or an automated rule set completes a risk review. High-risk purposes require a human reviewer.

8. Issue the certificate and receipt

   A registration certificate and receipt are issued, and the voice identity record becomes active.

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.

• PENDINGDocumentation or review incomplete — synthesis is not permitted.
• ACTIVEThe record is active; a separate, current grant must still authorize each use.
• 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.

The proposed API separates registration_status from purpose_authorization. Every action that changes a rights status should produce a human-readable and machine-verifiable receipt. The current legacy receipts are hash-linked, but they are not digitally signed or independently anchored; that stronger proof remains to be implemented.

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.

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.