Skip to main content

Roadmap

Hand-maintained, not derived from an issue tracker. 'Shipped' means it is on main today; 'Planned' items are design work that has not landed and may change after measurement. Update this file when scope actually changes; never describe work that isn't planned.

Shipped

v0.6.0

Faster ingest and assist runs: selective VLM labeling, bulk ingest, measured GPU pipeline steps

The measured first half of the Triton throughput plan (decode once, uint8 inputs, FP16 PE image encoder, GPU decode, multi-GPU embedding, coalesced writes) plus assist runs, bulk and S3 ingest, detection-only ingest and a repository cleanup. Numbers are in docs/PERFORMANCE.md.

  • Assist runs (/assist/runs): send a crop, box, selection, cluster, sub-cluster or filter to the VLM; cluster label proposals applied explicitly
  • Prompt-pack attributes replace the hard-coded make and model; a project calls no VLM until one is activated
  • Bulk ingest of a folder, manifest or S3 with a preview; detection-only ingest
  • Ingest speed-ups: decode once, uint8 inputs, FP16 PE image encoder, GPU decode, data-parallel PE encoding, coalesced writes, Lucene vector engine for new projects
  • Breaking: CROPWRIGHT_* env names are OP_CROPWRIGHT_*; /vlm/label_cluster and /vlm/verify_regions are replaced by /assist/runs; the evaluator has its own compose profile
  • Repository cleanup: guards, dead code removed, large files split, one typed env module, one docs source of truth
Planned

v0.7.0

Triton throughput: keep images on the GPU

The rest of the measured optimization plan: keep each decoded image resident on the GPU across the models that need it, with every change behind a flag, a parity gate against today's outputs and a p50/p99 benchmark gate. The 1M-image scale step is a goal here, not a claim. None of this has shipped.

  • Smaller model outputs (end2end secondary detector, in-graph OCR argmax) and a GPU-resident OCR BLS
  • GPU JPEG decode (DALI or nvJPEG, chosen by bake-off) and static Triton ensembles for /detect and /embed
  • A GPU-resident curation ingest pipeline (BLS) that cuts crops and embeddings from the full-resolution frame
  • Faces from original resolution via a face_pipeline BLS
  • The SAM 3 segmenter served from Triton as TensorRT engines instead of a PyTorch process
  • A final tuning pass over instances, batch sizes, memory pools and CUDA graphs
Later

Later

Known gaps in the curation subsystem

Gaps stated in docs/CURATION.md and docs/ARCHITECTURE.md that are expected follow-ups once the subsystem graduates out of experimental status.

  • Optional API authentication (today there is none on any route)
  • More than one active region detection profile per process
  • An ingest decode path for promoted YOLO26 engines, so a promoted model can serve as the ingest detector