Live Stream Inference Engine β Machine Learning Framework
LSIE-MLF is a desktop-first monorepo for real-time multimodal inference during live-stream sessions. It combines tethered mobile audio/video capture with external telemetry, synchronizes those inputs into fixed-duration segments, and runs ML analysis for transcription, facial action units, acoustic features, semantic evaluation, and downstream analytics.
The v4 runtime is organized around a host-side desktop process graph:
services.desktop_appis the primary operator/runtime entrypoint- full GUI mode opens the PySide Operator Console
- operator API runtime serves the same loopback API/control graph for CLI use without opening the GUI
ui_api_shellserves the local desktop UI/API surfacecapture_supervisormanages physical capture supervisionmodule_c_orchestratorassembles synchronized inference segmentsgpu_ml_workerexecutes compute-heavy ML tasks and analyticsanalytics_state_workermaintains local analytical statecloud_sync_workerdrains the desktop cloud-sync outbox- shared packages provide schemas and reusable ML utilities
| Desktop process | Responsibility |
|---|---|
ui_api_shell |
Local desktop UI/API shell |
capture_supervisor |
Physical capture supervision |
module_c_orchestrator |
Segment assembly, synchronization, dispatch |
gpu_ml_worker |
GPU-backed ML inference and analytics |
analytics_state_worker |
Local analytical state maintenance |
cloud_sync_worker |
Offline cloud-sync outbox draining |
| Module | Primary responsibility |
|---|---|
| A β Hardware & Transport | Capture raw audio/video from tethered mobile hardware |
| B β Ground Truth Ingestion | Accept external event/telemetry inputs |
| C β Orchestration & Synchronization | Align timestamps, assemble segments, attach context |
| D β Multimodal ML Processing | Run transcription, facial, acoustic, and semantic inference |
| E β Experimentation & Analytics | Persist metrics, run analytics, manage experimentation state |
| F β Context Enrichment | Run asynchronous metadata enrichment workflows |
Android device
-> capture_supervisor
-> module_c_orchestrator
-> gpu_ml_worker
-> analytics_state_worker
External telemetry / webhook ingress
-> ui_api_shell / retained API surfaces
-> analytics_state_worker
-> module_c_orchestrator
-> gpu_ml_worker
Oura webhook deliveries are treated as change notifications. Retained server/API surfaces may still use Redis-backed hydration queues, but the primary v4 operator path starts from the desktop app entrypoint rather than a Docker Compose stack.
/
βββ services/
β βββ desktop_app/ # Primary v4 desktop runtime and process graph
β βββ operator_console/ # Reusable/standalone PySide6 UI-only host
β βββ api/ # Retained API Server routes and ingress surfaces
β βββ cloud_api/ # Cloud API routes, services, repos, and SQL DDL
β βββ worker/ # Retained ML execution, orchestration, and analytics code
β βββ pipeline/ # Orchestration + analytics pipeline code
βββ packages/
β βββ ml_core/ # Shared ML utilities and math
β βββ schemas/ # Pydantic models and schema contracts
βββ services/cloud_api/db/sql/ # Cloud PostgreSQL schema and seed data
βββ pyproject.toml # Canonical dependency declarations, extras, and tool config
βββ uv.lock # Frozen dependency resolution for uv sync --frozen
python -m services.desktop_appis the primary v4 launch path- Shared code in
packages/is available to all services - Heavy ML dependencies belong in the
ml_backendextra, not the base API/runtime environment - No Docker Compose or Dockerfile manifests are tracked for the active v4 desktop runtime; historical/spec references are not launch instructions
cp .env.example .env
# Edit .env with the required credentials and runtime settingsRecommended local prerequisites:
- Python 3.11
- uv
- CUDA-capable NVIDIA GPU and current NVIDIA driver for GPU-backed inference
- ADB / Android device connectivity if using live USB capture
uv sync --frozen --extra ml_backendFull GUI app:
uv run python -m services.desktop_appCLI/API-only workflow:
uv run python -m services.desktop_app --operator-apiBoth modes run preflight and start the ProcessGraph with capture, orchestration, ML, analytics, and cloud-sync workers. The default command opens the PySide Operator Console; --operator-api starts the same loopback API/control surface for CLI use without opening the GUI.
With either the full GUI app or operator API runtime running, the CLI defaults to http://127.0.0.1:8000 or LSIE_API_URL if set:
uv run python -m scripts status
uv run python -m scripts health
uv run python -m scripts sessions start android://device --experiment greeting_line_v1
uv run python -m scripts sessions list
uv run python -m scripts stimulus submit <session-id> --note "test stimulus"
uv run python -m scripts live-session readback <session-id>
uv run python -m scripts sessions end <session-id>If the loopback API selects another port, set LSIE_API_URL once for the shell or pass --api-url <url> on individual commands. The CLI talks only to the loopback API; it does not read SQLite directly.
services.operator_console is a reusable/standalone PySide6 UI-only host. It polls an external API Server's /api/v1/operator/* aggregate routes and does not start capture, GPU inference, SQLite state, or cloud sync.
Use it only when developing or testing the UI against an already-running external API:
uv sync --frozen
uv run python -m services.operator_consoleEnvironment variables (all optional; sensible defaults apply):
| Variable | Purpose |
|---|---|
LSIE_OPERATOR_API_BASE_URL |
External API Server base URL (default http://localhost:8000) |
LSIE_OPERATOR_API_TIMEOUT_SECONDS |
Per-request timeout, default 5 |
LSIE_OPERATOR_ENVIRONMENT_LABEL |
Free-text label shown in the statusline (e.g. dev, staging) |
LSIE_OPERATOR_*_POLL_MS |
Per-surface poll cadences (overview, sessions, health, β¦) β see services/operator_console/config.py for the full list |
The console ships six pages: Overview, Live Session, Experiments, Physiology, Health, and Sessions. Page behavior traces to the spec:
- Live Session's reward explanation uses
p90_intensity,semantic_gate,gated_reward,n_frames_in_window, andau12_baseline_pre(Β§7B). - Physiology surfaces
fresh/stale/absent/no-rmssdas four distinct states (Β§4.C.4). - Co-modulation
nullis rendered as a legitimatenull-validoutcome with itsnull_reason, not as an error (Β§7C). - Health distinguishes
degraded/recovering/errorwith operator-action hints on the error summary card (Β§12).
The current tracked tree has no Docker Compose or Dockerfile manifests for the active v4 desktop runtime. Docker, container, Message Broker, and Persistent Store references that remain in spec extracts or archived artifacts describe retained legacy/server architecture or historical context, not the default operator workflow.
| If you need to change... | Start here |
|---|---|
| API routes, request handling, webhook ingress | services/api/ |
| Worker task execution or ML runtime behavior | services/worker/ |
| Segment assembly, synchronization, analytics pipeline | services/worker/pipeline/ |
| Shared inference helpers or math | packages/ml_core/ |
| Schemas and data contracts | packages/schemas/ |
| Cloud database tables / initialization SQL | services/cloud_api/db/sql/ |
| Dependency placement | pyproject.toml and uv.lock |
Use pyproject.toml as the declaration surface and uv.lock as the frozen resolution surface:
- put shared runtime packages in
[project.dependencies] - put ML-heavy worker/orchestrator packages in
[project.optional-dependencies].ml_backend - refresh
uv.lockwhenever dependency declarations change
This keeps the base API/runtime environment lightweight while preserving a reproducible lockfile for uv sync --frozen.
For desktop-runtime changes, run targeted desktop validation first:
uv run pytest tests/v4_gate0/ tests/unit/desktop_app/ tests/integration/desktop_app/ tests/unit/worker/pipeline/test_orchestrator.py
uv run ruff check packages/ services/ tests/ automation/
uv run ruff format --check packages/ services/ tests/ automation/
uv run mypy packages/ services/ tests/ automation/ --python-version 3.11 --ignore-missing-imports --explicit-package-basesThe full local check scripts are still available for repository-wide pre-push validation:
bash scripts/check.sh # macOS / Linux / Git Bash on Windows
pwsh scripts/check.ps1 # PowerShell on WindowsThere is no standing Docker Compose gate for the active v4 desktop runtime because no compose/Dockerfile manifests are tracked. Historical/spec Docker references should not be converted into launch or validation instructions.
At a minimum, changes touching worker or analytics code should be validated against the full worker test path.
Raw media and inbound telemetry should be treated as processing inputs, not long-term application records. Persistent storage is intended for structured analytical outputs, experiment state, and derived metrics.
Keep README-level guidance brief and put detailed governance, retention, and security rules in the technical specification and implementation docs.
LSIE-MLF is implemented against the single signed specification PDF committed as docs/tech-spec-v*.pdf.
This README is intentionally operational. It explains how the repository is organized, how to run it locally, and where to make changes. Detailed contracts, mathematical formulas, failure handling, and version history belong in the signed specification payload.
If this README and the specification differ, the specification is authoritative.
Confidential. All rights reserved.