calm/ and is
validated in CI by pnpm gate:calm — so the architecture description can’t silently drift from the system.
What’s modeled
calm/architecture.calm.json is the runtime / data-flow view: the standing services
(gateway, meeting-api, agent-api, admin-api,
runtime), the runtime-spawned workers (bot, agent-worker —
deployed-in the runtime kernel), the redis transcript fabric, the durable
stores (postgres, object storage), and the first-party, self-hostable STT boundary.
| Layer | Nodes |
|---|---|
| Edge | gateway — the one authenticated door (auth · routing · WS fan-out) |
| Services | meeting-api (collector hub) · agent-api (copilot) · admin-api (identity) |
| Workers | bot · agent-worker — ephemeral, spawned per meeting / per dispatch |
| Carriers | the redis streams + pub/sub (transcript live + durable planes) |
| Stores | postgres (transcripts · identity) · object storage (recordings) |
| STT | transcription — first-party GPU service, tenant-hosted by default |
Controls (governance, machine-checked)
The model carries governance controls, each backed by a JSON-Schema requirement incalm/controls/:
- single-writer (P23) — every data carrier declares exactly one producer; readers never re-derive a producer’s data.
- render-only — the terminal renders transcript and cards; it never re-derives or republishes.
- data-egress — the
bot → transcriptionedge declares its egress posture. Default is tenant-hosted, so meeting audio need not leave the tenant.
The pattern
calm/patterns/meeting-intelligence.pattern.json is a reusable CALM pattern a meeting-intelligence
deployment must conform to: a single authenticated edge, a capture worker, a collector, a copilot, a
render-only client, and a declared STT egress boundary. Conformance is fail-closed — a design that
omits the egress control or the render-only client is rejected:
calm generate a conformant starter architecture from the
pattern and validate your own deployment against it with the FINOS calm-cli.