How we think about meeting forensics, what we ship, and what we will not.
We publish when we have something concrete to say — a system we shipped, an architectural decision we defended, or a piece of methodology we want clients (and skeptics) to understand. No hot takes, no engagement bait, no AI-generated filler. If a post does not survive a re-read a week later, it does not ship.
Transcripts are a commodity. The hard part is what comes after: attributing a sentence to a person, scoring contradictions against earlier claims, and producing something a judge or a board can verify. Here is why we drew that line, and why we will not cross it.
Eight nodes, one Ed25519 signature, and a public key anyone can fetch. A walkthrough of how a Felarity session report is bound to the audio, transcript, and analysis that produced it — and what that buys you in a deposition.
Whisper hears the words. pyannote separates the voices. DeBERTa-v3 re-scores the contradictions on CPU. None of these models is interesting alone. The interesting part is the wiring between them — and the failure modes we had to design around.
No training on customer audio. No selling of voice samples. No third-party analytics on session data. The list of "nevers" is short, specific, and contractually binding. Here is the full list, and the architectural choices that enforce it.
Daubert asks whether a methodology is testable, peer-reviewed, has known error rates, and is generally accepted. We do not pretend Felarity meets that bar autonomously. We do think the attestation chain and per-component error rates make it a useful exhibit when prepared by counsel. Here is how we think about that.
/blog/feed.xml and an email list you can join by writing to hello@felarity.com with the subject "subscribe". We will add you, send you posts as plain text when they go up, and remove you the moment you ask. That is the entire system.