Skip to content

DraftLint Model Training

Status: Active model-development and serving operations Shared annotation surface: https://cvat.adeelyj.com Last verified: 2026-07-16

Source And Runtime Identity

  • Variant ID: draftlint-model-training
  • Primary Windows workspace: D:\02_Code\49_yolotraining_firstdataset
  • Parallel CVAT/Roboflow workspace: D:\02_Code\50_CVAT_RoboFlow
  • Historical predecessor: D:\02_Code\41_Training_drawing_roboflow_windowscode
  • Remote repositories: No Git remotes recorded for these workspaces
  • Training runtime: local preparation plus remote GPU training where appropriate
  • Run tracking: W&B for remote YOLO runs
  • Serving runtime: IONOS CVAT and Nuclio, exposed to applications through the DraftLint Detector Gateway
  • Not to be confused with: the Railway Validator application repository

Responsibility

This lane owns the model lifecycle, not the customer-facing review application:

  1. label drawings in CVAT,
  2. normalize/export datasets,
  3. train YOLO or evaluate Roboflow models,
  4. track runs and preserve artifacts,
  5. deploy selected models as Nuclio functions,
  6. register/refresh their CVAT metadata,
  7. expose promoted models through the gateway,
  8. verify both CVAT and application consumers.

Operational Workflow

Step Activity Primary location Output
1 Label and review drawing regions CVAT Versioned task/job annotations
2 Export and build training dataset D:\02_Code\49_yolotraining_firstdataset Dataset plus manifest and split
3 Train/evaluate Vast.ai or another documented GPU runtime Checkpoints, metrics, run identity
4 Track and compare W&B plus local manifests Provenance and model-selection evidence
5 Copy selected artifacts back Primary training workspace Durable best weights and config
6 Package Nuclio function Training/deployment helpers Function YAML, handler, weights/proxy config
7 Deploy to IONOS CVAT/Nuclio Ready function with current host port
8 Refresh ensemble/model metadata IONOS /opt/cvat-inference Detector 26 backend URLs and gateway registry
9 Verify consumers CVAT, gateway, RapidDraft .ai and .io Real prediction evidence

Current Serving Rule

Applications use the DraftLint Detector Gateway. CVAT keeps its native Nuclio AI Tools path.

This division is intentional:

  • applications receive one stable HTTPS contract,
  • CVAT retains native interactive auto-annotation,
  • model redeploys can change internal ports without changing application configuration,
  • the verification script detects metadata drift before it becomes a confusing product failure.

Promotion Gate

A model is not promoted merely because training completed. Record and verify:

  • dataset/task/job identity,
  • train/validation split,
  • model family and task type,
  • exact checkpoint and checksum where available,
  • metrics and comparison result,
  • label mapping to the shared vocabulary,
  • Nuclio function name and detector ID,
  • threshold and runtime assumption,
  • CVAT prediction test,
  • gateway prediction test,
  • RapidDraft discovery/default behavior,
  • rollback artifact.

Model Naming

Names should expose family, task, version, and runtime assumption. Examples:

  • YOLO26m Drawing Detect v2 / Job75 (IONOS CPU)
  • YOLO26l Feature Control Frame Seg v01 (CPU)
  • YOLO26l Specialist Ensemble v01 (CPU)

Avoid publishing an unqualified best.pt without its model directory, dataset manifest, and run identity.

Shared Runtime Invariants

  • CVAT server and annotation worker must use the intended Django settings configuration.
  • Nuclio's advertised status.httpPort must match Docker's actual host-published port.
  • Detector 26 must be refreshed after any of specialists 22 through 25 changes port.
  • A healthy CVAT page does not prove model invocation works.
  • A healthy gateway registry does not prove CVAT's native lambda path works.
  • Run a real prediction through both paths after changes.

Repository Provenance Gap

The active Windows workspaces and IONOS gateway directory currently have no verified Git remotes. They are therefore operational sources, not reviewable shared repositories.

Recommended correction:

  1. create private repositories for training/deployment code that is intended to be shared,
  2. keep datasets and large weights in artifact storage rather than normal Git history,
  3. commit manifests, label maps, function definitions, scripts, and checksums,
  4. link each deployed detector to a repository commit and artifact version.

Until that exists, this wiki must say No Git remote recorded rather than inventing a link.

Open Questions

  1. Which private repository should own model-deployment code and manifests?
  2. Where should weight artifacts and dataset snapshots be stored with immutable versions?
  3. Should the CVAT catalog be regenerated automatically from the gateway and training manifests?

Sources

  • Central playbook 04_playbooks/DRAWING_MODEL_TRAINING_AND_CVAT_MODEL_SERVING.md
  • IONOS verifier and live gateway registry verified 2026-07-16
  • D:\02_Code\49_yolotraining_firstdataset
  • D:\02_Code\50_CVAT_RoboFlow
  • DraftLint System Family