Accounting release candidate

This is the release boundary for immutable pricing and exact accounting contract version 1. The authoritative store is SQL: SQLite for a single-node deployment and PostgreSQL for a collector deployment. All supported accounting write and read paths (/v1/accounting/*, /api/accounting, and get_accounting_status) use that SQL ledger.

Storage boundary

ClickHouse continues to support legacy request telemetry and cost dashboards. An exact-accounting ClickHouse projection is not part of this release. No supported accounting endpoint reads ClickHouse, the reserved SQL projection table has no producer, and no pending_delivery field is exposed. Projection schema, consumer, replay, deduplication, recovery, and central projection-health reporting are deferred together so the product never reports a queue that no worker maintains. The producer-side SQLite outbox is different from that deferred projection. It is supported and exposes pending, rejected, failed_delivery, oldest age, memory depth, and capture failures through AccountingOutbox.health().

Compatibility matrix

Surface	Release status	Verified combination
Python	supported	project minimum 3.11; release tests on 3.12
Embedded SQL ledger	supported	SQLite through the complete suite
Collector SQL ledger	supported	PostgreSQL 16 with asyncpg
Native LiveKit capture	supported	livekit-agents 1.5.7; package constraint `>=1.5,<1.7`
Pipecat accounting capture	supported through the shared sink adapter	covered by component tests; not part of the native LiveKit acceptance matrix
ClickHouse legacy telemetry	unchanged	existing ClickHouse tests
ClickHouse exact-accounting projection	unsupported/deferred	no supported accounting path depends on it
Exact-ledger file export	unsupported/deferred	tenant report API is the supported read path
MCP per-caller tenant identity	unsupported	shared token is process authority; bind one accounting tenant per process

Acceptance evidence

The committed gates are repeatable and use synthetic identities only:

test_accounting_postgres_release.py migrates a disposable PostgreSQL, creates a runtime role without schema-create or ledger-delete privileges, and verifies immutable revisions, independent sides, concurrent activation, Decimal rating, concurrent deduplication, mixed receipts, project/tenant isolation, acquisition privacy, delayed pinned prices, restart, and lost ack.
test_livekit_accounting_integration.py uses native LiveKit STT, TTS, LLM, and realtime base instances. It covers registration timing, cancellation, cache and realtime quantities, missing measurements, streaming segments, stable duplicate replay, ownership modes, tracing context, outage retention, and failed-delivery health.
test_release_boundary.py installs a fail-on-use ClickHouse sentinel and proves the supported accounting API/dashboard reads remain SQL-only and do not expose pending_delivery. It also freezes the legacy export privacy boundary.
test_accounting_sync_example.py runs the executable synchronization example against the ASGI API, including readback hash verification and delayed usage pinned to an older active price.

Release rehearsal commands:

uv run pytest -q src/voicegateway/tests/accounting
VOICEGW_DB_URL=postgresql+asyncpg://... \
  uv run pytest -q \
  src/voicegateway/tests/integration/test_postgres_collector.py \
  src/voicegateway/tests/integration/test_accounting_postgres_release.py
uv run --frozen pytest -q -rsxX
uv run --with 'mypy<2' --with types-PyYAML mypy
uv run --with ruff ruff check .
uv run python docs/_check_docs.py
npm --prefix src/dashboard/frontend run build
uv build

The final release record must attach the exact pass counts, skip/xfail classification, built artifact name, and SHA-256 digest from the candidate run. The 2026-09-05 candidate rehearsal produced this sanitized result:

Gate	Result	Release effect
Complete Python suite with Pipecat installed	4,001 passed, 33 skipped, 3 expected failures	pass
Disposable PostgreSQL 16 collector + accounting matrix	3 passed	pass
Additional PostgreSQL dialect round trip	1 passed	pass
Ruff over `src` and `examples`	clean	pass
Mypy over 310 source files	clean	pass
Documentation	85 pages validated	pass
Dashboard production build	built successfully	pass; existing bundle-size advisory only

Skipped tests are classified by prerequisite and capability:

Count	Reason	Affected capability	Blocks accounting v1?
9	optional load-test fixture bundle absent	load-generator report replay	no
15	local node/exporter services not running	live infrastructure scrape	no
4	provider-recorded streaming fixture bundle deferred	legacy provider replay fixtures	no; representative native SDK streaming is covered
4	PostgreSQL environment variables absent from the all-tests process	PostgreSQL collector/accounting/dialect	no; all four passed separately on PostgreSQL 16
1	optional local-model plugin absent	local-model provider smoke	no

The three expected failures are pre-existing contracts outside the accounting v1 boundary: one storage-architecture reach-through and two open telemetry security gaps (unauthenticated audit-log read and an unscoped legacy project parameter). They do not affect the principal-aware /v1/accounting/*, dashboard accounting, or tenant-bound MCP accounting paths verified here. They do block claiming those separate architecture/security items complete.

Deployment and forward recovery

Deployment order:

Back up PostgreSQL and upgrade the collector so migration a6c9e2f4b817 is applied.
Start with the restricted runtime role and verify /health plus accounting capability discovery.
Synchronize and read back acquisition and selling revisions independently; activate only after canonical hashes and complete dimension sets match.
Prepare one binding per offering, configure ownership, then roll producers forward. Monitor every producer outbox before using ledger totals for an invoice.
Reconcile selling totals and completeness before retiring any legacy report.

Application rollback is supported; destructive database downgrade is not. Stop new accounting producers, preserve or drain their outboxes, deploy the previous application, and retain the additive tables. To recover forward, restore the candidate application and drain the same outboxes: stable event IDs return duplicate receipts without a second row or charge. The migration’s downgrade() raises before changing schema so an automated rollback cannot erase the ledger or API-key project allowlists.

API

CLI

MCP server

Architecture

Help

Contributing

Accounting release candidate

Storage boundary

Compatibility matrix

Acceptance evidence

Deployment and forward recovery

​Storage boundary

​Compatibility matrix

​Acceptance evidence

​Deployment and forward recovery

Storage boundary

Compatibility matrix

Acceptance evidence

Deployment and forward recovery