PROJECTS
Platform Engineering·2026–2026·Active

ComputerVisionPlatform

YOLO + FastAPI + React Operator Runtime

An active internal CV platform built around a shared YOLO inference core, a formally assembled FastAPI runtime, PostgreSQL-backed catalog services, and a React operator frontend designed for real deployment workflow, not demo.

PythonFastAPIReactYOLOPostgreSQLAlembicRTSPDocker
Platform Facts
Inference core
Shared
One YOLO + RTSP truth across route groups
Route groups
4
Inference, catalog, assistant, streams
Catalog backend
PostgreSQL
Alembic migrations + seed flow
Frontend surfaces
Operator UI
Built for real workflow, not demo polish
02 · Architecture

Formal Runtime Composition

The core design decision was to treat the platform as a composed runtime rather than a pile of inference endpoints. That meant drawing a hard line between operator surfaces, route groups, shared vision services, and catalog persistence.

Platform Architecture
A · Operator Surface
+Browser / operator runtime
+React web app
+Inference, catalog, assistant, and stream surfaces
B · Backend Entry
+FastAPI entrypoint
+`create_app()` assembly
+Router mounting
+`GET /health`
C · Route Groups
+/inference
+/catalog
+/assistant
+/streams
D · Shared Inference Core
+Shared YOLO core
+Shared RTSP core
+Model registry + weights
+Segmentation extension in progress
E · Data Layer
+PostgreSQL catalog
+Alembic migrations
+Seeded demo environment
F · Outputs
+Detection results
+Annotated previews
+Catalog-backed operator history
+Stream inference outputs
Dev Workflow
Windows backendPostgreSQL + AlembicFastAPI runtimeWSL2 frontendBrowser health check
03 · Current Build

Where the Surface Is Strongest

Frontend Runtime

A React operator surface organized around the workflows that matter in practice: inference, model and source management, stream operations, and catalog visibility.

Backend Assembly

The FastAPI side is assembled through an explicit `create_app()` pattern so new route groups can be added without collapsing runtime structure.

Inference Core

Every inference path delegates to the same shared core, so model state, preprocessing, and route behavior do not drift apart over time.

Catalog Backbone

Detection history and model metadata live behind a PostgreSQL-backed catalog with migration discipline, which makes the environment reproducible for dev and ops.

04 · Design Principles

The Decisions That Made It Hold Together

Single Runtime Truth

One process owns all route groups and all shared inference responsibilities. That constraint keeps debugging sane and prevents parallel model instances from silently diverging.

Formal Assembly Over Script Growth

The backend was treated as an application that needed composition, not as a collection of scripts that happened to run. That is what made the platform extensible.

Operator Workflow First

The UI is not arranged around technical subsystems alone. It is arranged around what an operator needs to inspect, configure, and trust during deployment.

05 · Related Notes

Where This Work Connects Outward

The platform now connects into the broader writing and lab surfaces, so the runtime lessons can be read as engineering strategy instead of staying trapped inside the project page.