Cyan Eclipse Voiceprint — Cyan Eclipse Bazaar

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio

Certification scope

PASS-CONDITIONAL(local, fixture call records) — Verity bench of v0.1.0 (2026-10-27, argus101-program-20261027/wave3/bench-voiceprint.md): builder suite 32/32 re-run clean by bencher; decisive fixture F-V14 independently reproduced on all three branches from the exported pack + pinned keys alone in a fresh process; bencher battery 82/82 after 3 probe-artifact corrections (F-1) — swap/drift exactness (drift never returned as SWAP_DETECTED; binary-exact 0.25 at threshold CONTINUOUS, 0.375 SUSPECT), claim-surface audit (narrowed claim verbatim on README/server.json/statements/verify results; forbidden §11.4 strings zero hits outside SPEC's own enumeration), 14-point delta law, refusal/gap battery, tamper battery (downgrade-never-upgrade on every path), metering exactness, disjoint surfaces, §7.3 fence, privacy fence (no audio capture/playback, telephony, speech, or biometric code path in the tree). Sole condition C1 (verbatim): external anchor required before live/multi-party use (cross-artifact coordinated rollback fenced; local SET anchor binds head + record_count within one pack only). Advisories F-2/F-3/F-4 (non-blocking, disclosed): fixture feature vectors are retained in attestation objects carried in the pack (token artifacts store the hash only; accepted at fixture scope, re-bench required for any real feature data); the §11.2 legend's '(§3.5)' parenthetical appears in README only; token_verify accepts a sealed token's SUSPECT_FEATURE_DRIFT on its identifier aspect only (full drift recompute lives in chain_verify). Scope is exactly: local stdio MCP, fixture call-record metadata only, value_class 'test' on all artifacts; no real audio is captured, processed, or stored, no human speaker is identified, and no live call platform is touched. Novel mechanism (SPEC §2.1, verbatim): per-call continuity tokens seal the speaker model + voice fingerprint, so a voice agent cannot silently swap voices mid-relationship.. Narrowed claim (verbatim): The 'cannot silently swap' claim is provable only at identifier granularity: a swap is proven only by a change in the attested model_id/voice_id (or a chain break); same-model re-voicing behind unchanged identifiers is not detectable.

What it does

Novel mechanism (SPEC §2.1, verbatim) — per-call continuity tokens seal the speaker model + voice fingerprint, so a voice agent cannot silently swap voices mid-relationship.
Per-call continuity tokens — each fixture call is sealed at call close with a dual-signed token (provider attestation signature + Herald counter-signature over token_hash) binding call id, relationship ref, attested model_id/voice_id, audio-feature hash where available (or the explicit feature_hash: unavailable label), timestamps, and the previous token's hash; continuity is recomputed over the chain, never read from deployer logs, and a legitimate voice change is recorded only as an explicit, separately signed re-baseline act that stays visible in the chain forever — there is no silent re-baseline.
Decisive fixture F-V14 — bench-reproduced in a fresh process from the exported pack + pinned bencher keys alone (bencher relationship rel-bench-14, bencher's own §6.4 recompute): (a) calls 1–3 recompute as exactly one baseline era, all CONTINUOUS; (b) call 4 = SWAP_DETECTED, changed_field: voice_id (swapped voice_id, no re-baseline); (c) call 5, re-voiced behind the original unchanged identifiers with in-tolerance features, is returned with observation: no_identifier_change_observed under the §11.2 legend — as not-detectable-by-design, never as a proven-same-voice claim (no such string/field anywhere in the verify result). All three branches pass.
Offline verification (SPEC §6.4) — a pure function of the exported continuity pack + pinned keys alone: record/token hashes, both token signatures, baseline semantics, gap correspondence (every statement gap ↔ a chained gap record, both directions), and the signed SET anchor (head + record_count) are recomputed; any step failing names VOICEPRINT_VERIFY_FAIL:<step>, and unverifiable material is labelled downgraded on its face, never upgraded post-hoc. Keys are pinned out-of-band by fixed refs; a key or key ref is never read from a record.
Honest scope — LOCAL stdio, fixture call records ONLY: no real audio is captured, processed, or stored, no real call, telephony provider, or voice model is contacted, and every emitted artifact carries value_class "test". The 'cannot silently swap' claim is provable only at identifier granularity: a swap is proven only by a change in the attested model_id/voice_id (or a chain break); same-model re-voicing behind unchanged identifiers is not detectable. Closed surface of exactly 8 tools (6 deployer + 2 verifier, disjoint); no audio-capture, identifier-derivation, token-edit, gap-delete, seal-without-attestation, or import verb exists on either surface. Startup is fail-closed (CONFIG_FENCE_REFUSED:<class>) on a non-local endpoint, a telephony/voice-provider credential, a real audio or human-voice sample source, or value_class other than 'test'. Signing is an HMAC fixture stand-in for Herald RS256 (disclosed).

Tools

relationship_enrolcall_sealrelationship_rebaselinerelationship_closerelationship_statuscontinuity_pack_getchain_verifytoken_verify

Problems it addresses

A voice agent's voice is its identity to the counterparty, yet nothing binds it across calls — a deployer (or an attacker, or a provider migration) can swap the underlying model or voice between calls and the counterparty has no evidence the voice they trusted is the voice now speaking; call logs are the deployer's self-report
I need each call's attested voice identity made a signed, chained, third-party-recomputable record — provable offline, from the exported pack + pinned keys alone — so a swapped model_id/voice_id is a proven, named fact (SWAP_DETECTED with the changed field), not an allegation against the provider's current log
I need the claim kept honest on its face: The 'cannot silently swap' claim is provable only at identifier granularity: a swap is proven only by a change in the attested model_id/voice_id (or a chain break); same-model re-voicing behind unchanged identifiers is not detectable. A CONTINUOUS result is a chain statement about identifiers, never 'same voice verified'; feature drift is flagged SUSPECT_FEATURE_DRIFT for human review, never hardened to a proven swap; and gaps are chained records that cannot be removed without breaking the chain

Not tested

Live call-platform integration (real audio / live attestations / human-voice feature data) — counsel gate (SPEC §10, named, unbuilt/unclaimed): processing real call audio, real provider attestations from live calls, or any feature data derived from a real human's voice requires counsel clearance (biometric-identifier law exposure, call-recording/wiretap consent regimes, provider terms on attestation reuse, counterparty disclosure duties, retention limits) before any build toward it; fixture audio metadata only in v0.1.0, no real voice biometrics stored, and there is no dormant live path to flip — live mode is a post-gate, re-benched code change
Same-model re-voicing behind unchanged identifiers — NOT detectable by this product, by design (SPEC §11.2): The 'cannot silently swap' claim is provable only at identifier granularity: a swap is proven only by a change in the attested model_id/voice_id (or a chain break); same-model re-voicing behind unchanged identifiers is not detectable. A CONTINUOUS result proves only that no attested identifier changed; it is never stated as 'same voice verified' and no biometric-identity claim is made — the fingerprint is the attested model/voice identifier set plus an audio-feature hash where available, and the product does not identify human speakers. Never claimed for v0.1.0 are 'voice authentication', 'speaker verification', 'fraud prevention', 'fraud-proof', 'deepfake detection', 'the same voice, guaranteed', or 'voice verified' (SPEC §11.4 strings named here only as never claimed)
Cross-artifact coordinated rollback — CONDITION C1 (bench, verbatim): external anchor required before live/multi-party use (cross-artifact coordinated rollback fenced; local SET anchor binds head + record_count within one pack only). Within one pack the signed SET anchor binds head + record_count and the §6.4 recompute detects tampering; a coordinated rollback across artifacts is fenced, not claimed detected, in the local model
Intra-call voice changes and unattested calls — any voice change inside a single call is outside v0.1 detection (per-call granularity, SPEC §3.5; segment identifier sets are refused as malformed), and any change on a call for which no attestation exists is recorded as a chained gap, not a detection
Production signing — v0.1.0 signing is a fixture HMAC stand-in for the Herald RS256 pattern (disclosed on every face; fixture keys in keys/fixture-keys.json, chmod 600, gitignored, never committed); a live phase requires real Herald signing and a re-bench; a fresh clone generates its own fixture keys to run the full suite
Hosted or live operation / charge path — local stdio only; metering points only per SPEC §9: exactly three Meter-grammar points — call_sealed, chain_verify, continuity_pack_exported — at the $0.03/call price shape attaching to call_sealed; the chain_verify metering point is emitted in the verifier result, not persisted (verifier surface is stateless/pure; counts remain recomputable from the stream + emitted records); no charge path is built, no payment is taken, and no live Meter ingest is claimed

Evaluation-intake listing

This listing records the tool's place in the Bazaar's evaluation and monitoring pipeline, with the evidence gathered so far printed above — verdict, scope, and not-tested items included. It is not sold on this site, and its presence in the catalog is not a claim beyond that evidence. The service behind every verdict is the bench: what a bench run buys →