Vera VB

Every major AI voice platform requires creators to upload audio data. The terms governing that upload — perpetual licenses, irrevocable rights, rights to train on and commercialize the voice — are written to maximize the platform's flexibility and minimize the creator's future options. This is not a new pattern. It is the same pattern the music industry used for decades, now executing at the speed of software deployments rather than contract negotiations.

The problem is structural. There is no platform-independent infrastructure for voice creators to establish verified ownership of their own biometric data before platforms capture it. Existing provenance standards like C2PA are designed to prove file authorship — they do not cover biometric voice identity, clone detection, or longitudinal aging analysis. Vera VB fills that gap: not as a protection tool or a monitoring service, but as an identity layer that creators own independently of any platform relationship.

The most important architectural decision was framing. Vera VB is not a "voice protection tool" — a category that will be marginalized as platform compliance features improve. It is a biometric identity layer — a category that is additive to every provenance standard that emerges, because no provenance standard covers biometric voice identity.

C2PA will commoditize file-level timestamps. Blockchain provenance will handle content authenticity. None of these systems address the biometric identity question: is this voice sample from the same speaker as a reference set registered two years ago, and can that claim be verified independently? That question requires speaker embeddings, longitudinal aging analysis, and clone detection — capabilities that Vera VB builds as its core, not as features.

• Zero-knowledge privacy architecture: Vera VB never stores decrypted audio. Only derived features (cryptographic hashes, speaker embeddings, temporal metrics, synthetic detection scores) are retained on the platform. Users hold their own audio in their own Google Drive.
• Quarterly re-registration as the core product mechanic — each registration adds a temporal layer to a longitudinal biometric record. A single registration is useful. Twelve quarterly data points with documented aging characteristics are something no competitor can retroactively manufacture.
• Open-source ML models requiring assembly rather than invention — the value is in the architecture, the verification stack design, and the accumulated longitudinal dataset, not in proprietary algorithms.
• Five independent proof layers, each independently valuable and independently verifiable — designed so that the failure or commoditization of any single layer does not compromise the others.

The architecture is designed around a single constraint that drives every other decision: Vera VB must never be a voice data honeypot. If the platform held audio, it would be the single most valuable — and most targeted — voice data repository on the internet. By holding only derived features, a breach yields nothing exploitable. This constraint is a structural advantage, not a limitation.

The five-layer verification stack is the core product. Each layer is independently verifiable by a third party — courts, platforms, compliance officers, or the creator themselves:

The processing pipeline is designed for ephemeral execution — decrypted audio is never written to disk. Client-side Web Crypto API encryption precedes upload; Cloud Functions process audio ephemerally in memory; only derived features are written to Firestore and BigQuery. User audio is stored only in the user's own Google Drive, under their own Google account credentials.