Architecture

Every service in docker-compose.yml and how they talk: clients reach api, which calls Triton over gRPC and OpenSearch; the opt-in profiles add the multi-project curation workers, segmenter, VLM endpoints, trainer, evaluator, MLflow and monitoring. Start here.

How src/ is organized: src/main.py mounts the core and curation routers (curation routes are scoped by project), which are thin adapters over FastAPI-free services, configured by the src/config dataclasses and the per-project config store. The curation workers import the same detection and labeling services.

The OpenSearch indexes: each project's six curation indexes (images, items with their region_boxes, classes, UMAP state, configs, legacy labels) plus its class registry and exports, the global project and config indexes, and the separate visual-search indexes the core /ingest route writes.

What /detect, /faces, /embed and /ocr do: CPU preprocessing in the API, then TensorRT models in Triton. OCR is a single call to the ocr_pipeline Python BLS model, which runs detection and recognition inside Triton.

The active-learning loop inside a project: ingest or import, PE-Core embeddings, clustering, VLM suggestions, human review, reprocess after config changes, export, training, bake-off and promote, with probe predictions feeding the next review cycle.

The detection worker's cascade for a project's active region profile: region detector, then the segmenter leg, then an OCR text-hinted re-segment; up to max_regions_per_item candidates are selected, verified by the VLM in one numbered call, and each box gets its own verdict and text.

The API and the trainer exchange only files on the shared /jobs volume, in each project's own directory. The GPU arbiter claims GPUs for the run and releases them afterwards; promote checks the eval gate, writes the project-prefixed model into the repository and loads it into Triton.