Trust / Cryptographic attestation

Proof, not promises.

Every Felarity report ships with an Ed25519-signed Merkle attestation chain. Anyone, anywhere, can verify it against our published public key — no Felarity account required, no network call to us at verification time.

The chain at a glance

Every meeting analysis produces an 8-node SHA-256 Merkle chain. Each node represents a discrete stage of the forensic pipeline: audio capture, transcription, contradiction detection (before attribution), diarization, attribution binding, acoustics, topology, and the final report. Each node hashes the prior node concatenated with the new stage output, which means any tampering at any stage invalidates everything downstream of it.

The chain root — the hash of the final node — is signed with an Ed25519 private key held in our HSM. A verifier replays the hash chain from the recorded inputs at each stage, checks the signature against our published public key, and reports a single Boolean: valid or not. There is no partial pass.

The 8 nodes

  1. AUDIO_CAPTURE — hash of every chunk file, in order. Captures both the bytes and the sequence in which they arrived.
  2. TRANSCRIPTION — Whisper-large-v3 output hash, total word count, model identifier and weight checksum.
  3. CONTRADICTION_DETECTION — contradiction set hash, council and NLI model identifiers. Critical: this stage runs before speaker attribution, so contradictions are detected against the content of what was said, not against who said it.
  4. SPEAKER_DIARIZATION — pyannote-3.1 segment hash, speaker count, segment boundary checksum.
  5. ATTRIBUTION_BINDING — retroactive binding of detected contradictions to diarized speakers. The chain note for this node explicitly records that detection preceded attribution.
  6. ACOUSTIC_ANALYSIS — speech rate, pause distribution, and stress indicators per speaker.
  7. TOPOLOGY_ANALYSIS — NetworkX classification of the contradiction graph (cycles, hubs, isolated denials, cascade structure).
  8. FINAL_REPORT — report content hash. Chain complete; signed root produced.

Why the order matters

For legal teams, the chain is conventional chain of custody — file-level integrity from intake to output. For investigators, it is something more specific: a bias proof. The ordering of operations is itself attested. A reviewer can confirm from the chain alone that contradictions were detected before the system knew who said what, which removes a class of objection ("your model just flagged the witness it disliked"). For compliance officers, the result is a tamper-evident audit trail that can sit in a regulatory file for the legally required retention period without further intervention.

Signing

Each chain root is signed with an Ed25519 private key held in hardware. The corresponding public key is published at /.well-known/felarity-signing-key.pem together with its fingerprint. We rotate the signing key annually and publish all historical keys at the same well-known path, so reports signed under any previous key remain verifiable indefinitely. Each signed chain records the fingerprint of the key that signed it, so the verifier knows which historical key to check against.

Verify a report yourself

Every signed chain JSON file Felarity emits can be checked against the public key with a single API call. The verifier is stateless — it does not log or retain the chain you submit.

curl -X POST https://api.felarity.com/api/verify \
  -H 'Content-Type: application/json' \
  -d @attestation_chain.json

The response is a small JSON document:

{
  "valid": true,
  "errors": [],
  "nodes_verified": 8,
  "signing_key_fingerprint": "SHA256:7c4f...e2a1"
}

Prefer not to call our API at all? Drag and drop the chain JSON into the in-browser verifier at /trust/attestation/verify and get the verdict client-side. The verifier runs entirely in your browser using WebCrypto; the chain never leaves your machine.

What the chain does not prove

The chain proves the analysis pipeline was not tampered with after the fact. It does not prove that the original speakers were correctly identified by name — diarization assigns labels like "Speaker A," and the binding of those labels to real people is a human step performed at review. It does not prove the recording was made with the consent of every participant; consent is the customer's responsibility under the jurisdiction in which the recording took place. And it does not prove the conclusions are correct. The contradiction set and the council's interpretation of it remain subject to human review, and we publish per-claim confidence so reviewers know where to look first.

Daubert and admissibility

The attestation chain is designed to support a Daubert-style challenge by giving the proponent a reproducible record of method, model versions, and the ordering of operations — the same record on which the analysis was originally produced. Whether any specific result is admissible depends on jurisdiction, the court, the rules of evidence, and the facts of the case. We make no guarantee of admissibility, and we do not provide expert testimony as part of the standard product. We can refer customers to outside experts who have testified to forensic ML pipelines in U.S. and EU jurisdictions.

Reading the chain offline. The chain JSON is a plain, human-readable document. A reviewer with a copy of the public key and a SHA-256 implementation can verify it on an air-gapped machine without any Felarity software. The full file format is documented at docs / attestation chain format.

Last updated: June 7, 2026