Conclave Docs

P0: diarization

The current active workstream — latency and reliability, in four tracks.

The top engineering priority is diarization latency & reliability (Capture#1) — getting the in-person path to real-time (RTF < 1), the post-pass onto a licensing-clean engine, and identity resilient over long meetings. It's orchestrated as four tracks in task-plan/p0-diarization/.

The tracks

TrackGoalState
0 — eval loop / analyticsShared eval instrument + a test CVM as the merge baseBand 1 built (feat/analytics-cockpit, not merged); test-CVM provisioning in flight
A — replace DiariZen modelOwn WavLM-Base+ diarizer (licensing-clean, competitive DER)✅ validated + GO (DER ~0.201 vs 0.216, parity VRAM); prod-port pending Track 0
B — VFTEE 600s async identityDurable identify job for long meetings (#52)✅ lifted onto feat/identity-async-lift + validated; cross-CVM E2E pending a test FPM CVM
C — live path (diart RTF < 1 + ASR/VAD)Real-time diart + ASR-fallback⛔ blocked on the test Conclave CVM; ASR+VAD sub-design TBD

Only Track C functionally depends on Track 0.

Why it matters

  • diart is the live engine, DiariZen is post-pass — this is a firm product call. The live path must reach RTF < 1; it was compounding (~RTF 1.15, lag growing 20s → 60s over 5 min). The cheap levers: raise step 0.5 → 1.0, ONNX/int8, drop-to-latest cap — all measured on the CVM, not the laptop (threads were backwards: OMP=2 on 4 vCPU).
  • DiariZen weights are CC-BY-NC, so Track A's clean model is required before commercial use.
  • Long meetings exceeded VFTE's identify window; Track B makes identity a durable, resumable job.

Also open

  • DiariZen GPU worker persistence@reboot + repoint-on-deploy + a health signal (it silently rots), tracked as a follow-up (Capture area).
  • parallel ASR — the ~20s baseline lag is serial NEAR Whisper; a small concurrent pool helps.

Source: task-plan/p0-diarization/STATUS.md, README.md, DIART-RTF-FIX-PLAN.md.

On this page