Bodhi Platform
System Architecture · ASR + TTS

Bodhi Platform, end to end

How a live speech request is served and billed, how the AI team manages and deploys every model, and how the logs those models produce flow back into a QA and finetuning loop — all on the new API Platform.

Auth & billing dwarpal Catalog bodhi-api-platform Event lake ClickHouse Retiring streaming-asr
↻
Continuous improvement loop  A new model version deployed to the servers feeds the runtime, whose logs drive QA and finetuning, which produce the next version.
Scope: this is the plan for ASR model deployment.

TTS is shown here for context, but its rollout will be planned separately once the ASR pipeline is finalised — it's early days, so nothing about TTS is committed yet.

1

Runtime

Serving & logging a live request.

Customer
Your application
ASR / TTS API call
▼
bodhi-api-platform-be
API gateway · playground · billing UI
▼
ASR
bodhi-go-server
dwarpal
auth · entitlement · metering · billing
TTS
bodhi-tts-server
every request does two things
▼
dwarpal bills
ledger entry
Emit event
async · queued
▼
Platform DB store
customers · API keys · dwarpal ledger · model catalog · bodhi-api-platform (dev + prod)
what the model produced
▼
ClickHouse event lake store
asr_events · tts_events — immutable, append-only
  • Servers load their models from the catalog at boot (loadModelsFromDB).
  • Billing goes to the dwarpal ledger; the event write never blocks the request.
2

Model Platform

The control plane — how the AI team manages & deploys models.

AI team
upload · configure · promote · retire
works only here
▼
Model Management Dashboard
The single front door for models — upload, families & versions, entitlements, promote Test→Live, retire, “who runs where”.
the new platform
▼
Model catalog
writes: families · models · deployments · entitlements
Jenkins pipeline
click “Deploy” · Test→Live
sync catalog + rolling restart
▼
ASR + TTS pods
re-read the catalog on restart → load their models
  • Control plane = dashboard + catalog + Jenkins, all separate from the running servers.
  • Servers (the data plane) only ever read the catalog.
  • Retire never deletes: deprecate → undeploy → archive; the row stays so logs resolve.
3

Feedback Loop

How logs become better models.

ClickHouse event lake
what the models produced · each event carries model_id + version + transaction_id
find issues
▼
LC dashboard
search logs · find failures / regressions · make corrections
write corrections
▼
bodhi-lc store
Postgres — LC scores · human corrections · datasets · mutable labels
build training set
▼
AI team finetunes
use LC data → finetune → produce new version (model_id + version)
↑ new version → back to the dashboard (§2)
↺
  • Model attribution lets the platform say “v3 regressed on Hindi numbers vs v2.”
  • The loop spans both ASR and TTS (TTS planned later — see scope note).

Where everything lives

The Platform DB stays lean; high-volume logs, mutable labels, and big binaries each get the right store. Nothing floods the Platform DB.

StoreHoldsMutable?Detailed in
Platform DB
bodhi-api-platform / -prod		customers, API keys, dwarpal ledger, model catalogyesModel Management
ClickHouseasr_events, tts_events — what models producedno · append-onlyData Platform
bodhi-lc
Postgres		LC scores, human corrections, datasetsyesData Platform
OCI registry
(ECR / ACR)		models as encrypted, signed KitOps ModelKits (versioned)no · immutableModel Management
Blob / mountaudio & synthesized speech payloads—Both

End-to-end flow

How parts 1 → 2 → 3 connect into one system.

1

Serve & log

  • Customer calls ASR / TTS
  • Served using a model from the catalog
  • dwarpal meters & bills
  • Event logged to ClickHouse (async)
2

Manage models

  • AI team uploads / configures on the dashboard
  • Promote to Test → Live
  • Jenkins deploys + rolling-restarts pods
  • Servers load the updated models
3

Feedback loop

  • Analyze logs in the LC dashboard
  • Write corrections to bodhi-lc
  • Build a training set & finetune
  • Upload the new version → deploy (back to 1)

The keys that stitch it together

Two identifiers connect the three planes.

transaction_id

Joins a single request across its ClickHouse event and its LC labels in bodhi-lc.

model_id  (+ version)

Joins logs and LC labels back to the exact entry in the model catalog.

Dive deeper

Model Management →
Model upload, deploy, retire, families & entitlement — the full catalog design.
Data Platform →
Event logging, the LC platform, and the finetuning dataset builder.