Sound Title Office

A title registry for the human voice.

In 1858, South Australia invented the Torrens system and taught the world how to register land — a public record that settles, once and for all, who owns a parcel and what claims sit against it. Voice has no equivalent today. Sound Title Office is a proposal and reference design for one: a public registry that establishes who a voice belongs to, what it may be used for, and whether that authorization still stands.

Voice should not be managed as just another audio file. Once it enters a digital system, it carries identity, biometric, authorship and performance, computable, and licensable properties at once. A voice system must therefore register rights and permitted uses first, register features and versions second, and only then allow storage, transmission, matching, recomposition, or synthesis.

That is the founding premise of the Voice Registration and Trusted Circulation Whitepaper v0.1. Sound Title Office is the institutional home for the registry it describes: a register of voice identities, a chain of tamper-evident receipts for every authorization and revocation, and a verification interface that returns an unambiguous status rather than a bare "yes or no".

Three Pillars

Register. Verify. Prove it happened.

The registry rests on three functions, each with its own data, its own access rules, and its own record of what happened.

01

Register

Every voice receives a stable, vendor-independent registration number (voice_profile_id). A vendor's speaker ID or model embedding ID is stored only as a replaceable reference — never as the permanent identity key. Registration records purpose-scoped consent, a status, and a version history that is appended to, never overwritten.

02

Verify

A query against the registry returns one of six explicit states — ACTIVE, RESTRICTED, SUSPENDED, REVOKED, EXPIRED, NOT_FOUND — never a simple match/no-match. Every action that changes a rights status must produce both a human-readable and a machine-verifiable receipt.

03

Receipt Chain

Registration, authorization, transmission, acceptance, and revocation each leave a signed, hash-chained receipt. The chain is a tamper-evident ledger of events, not a store of the underlying recordings or biometric material — it proves that something happened without holding the sensitive content itself.

Two Tiers of Registration

Identity first, technical detail second

The registry separates who-and-what-for from how-it-sounds. A voice is registered as an identity before it is ever registered as a technical fingerprint.

1

Identity registration

Establishes the voice subject, the rights basis (self, guardian, authorized agent, or estate representative), purpose-scoped consent (private communication, meeting readout, public presentation, commercial, research, model training), and a status of PENDING, ACTIVE, SUSPENDED, REVOKED, EXPIRED, ARCHIVED, or DESTROYED. This is the record the public registry query resolves against.

2

Feature & codebook registration

Once an identity is registered, technical records — versioned voice feature sheets and codebooks — can be attached under it. Each version is immutable and version-pinned: a synthesis or transmission event must record exactly which feature sheet, codebook, and engine version it used, never "latest".

Three Privacy Tiers

Not every field deserves the same protection

A voice feature sheet is classified field-by-field into three tiers, rather than treated as one uniformly sensitive block.

R0 — Registry public

Public registration facts

Registration number, public label, status, permitted public languages, certificate digest. Safe for public registry lookups.

R1 — Business restricted

Operational detail

Authorization scope, quality metrics, codebook version, engine compatibility, audit information. Available to authorized processors, not the public.

R2 — Biometric private

Biometric material

Raw voiceprints, embeddings, reversible features, source sample locations, key material. Never enters public queries, logs, analytics, or client caches — regardless of whether it is "audible" on its own.

Go Deeper

Read the full proposal

The whitepaper lays out the registration flow, the storage model, the transmission protocol, and the phased rollout in full. The demo shows the registration workspace this design implies.