How Single Core Labs Uses KitOps

Single Core Labs (SCL) uses KitOps as the packaging and versioning layer for every trained model, dataset snapshot, and evaluation artifact that moves through its ML pipeline.

Instead of coordinating model storage, dataset versioning, experiment tracking, and container packaging as four separate systems, SCL packages each artifact as a single OCI-compliant ModelKit that carries weights, data references, code, and metadata together.

Consolidating onto KitOps reduces infrastructure spend, cuts engineering time lost to artifact glue work, and removes the most common source of failed deploys: mismatched versions between model weights, training code, and the dataset they were trained on.

SCL is an early-stage AI systems engineering and infrastructure company based in Pune, India, founded in April 2026.

The team builds low-level infrastructure for running and evaluating AI models: a Rust and CUDA LLM inference engine, an enterprise command-line coding agent, and a safety and evaluation harness for vision-language-action (VLA) robot models. Because the company is young, this story describes a compact, fast-moving pipeline rather than a large production fleet, which is the environment most small ML teams will recognize.

Team

Roughly 6–10 technical staff: ML/AI engineers, core systems engineers, and forward-deployed engineers, led by a founder-CEO/CTO with a Head of AI and a COO.

Projects and models

Open-weight LLMs served through SCL's own inference engine (including quantized W4A16 and FP8 exports), models used inside the coding agent, and open VLA robot policies evaluated in simulation. Quantized variants of the same base model are a major source of artifact versions.

Scale and environment

About 15 active model and artifact versions per quarter, developed and tested on NVIDIA GPU hardware and packaged through the same OCI registry used for container images.

Use cases

The pipeline currently serves SCL's own product development and research.

Bundling weights, code, and dataset references into one immutable ModelKit removes the most common root cause of version-mismatch incidents.

That root cause is a deploy target picking up a model built against a code or data version other than the one intended.

SCL's pipeline has four stages: training, evaluation, registry, and deployment. KitOps sits at the boundary of every stage transition.

1. 01 · Training → Kitfile definition

   Each training run is described by a Kitfile, a declarative YAML manifest that references:

   model

   weights artifact (checkpoint or quantized export)

   datasets

   exact dataset version used for training/fine-tuning

   code

   training/eval scripts and configs

   docs

   model card: architecture, parameters, intended use, eval scores

   The Kitfile is checked into the training repo, so its history is Git-tracked even though the large binaries it references are not.

2. 02 · Packing → ModelKit as unit of transfer

   kit pack builds a ModelKit from the Kitfile: an OCI artifact containing the weights, dataset references, and code as separate, independently addressable layers inside one versioned package. Because it's OCI-compliant, it pushes and pulls through the same container registries SCL already runs for Docker images, with no separate model-artifact service to operate.

3. 03 · Registry → Single source of truth

   kit push publishes the ModelKit with a semantic tag (e.g. v0.4.2-fp8). Anyone on the team, or any downstream system including the evaluation harness and inference engine, pulls the exact same package with kit pull, unpacking only the layers they need (e.g. weights only, for a deploy target with no need for training code).

4. 04 · Deployment → Version alignment

   Because the ModelKit is the same artifact from training through deployment, the weights loaded at inference are verifiably tied to the dataset version and code commit that produced them. This directly targets the version-mismatch failure mode that caused rollbacks under the previous stack.