CLAIMED and C3: turning notebooks and scripts into container images and KubeFlow components

What C3 solves for notebook-first machine learning teams

The gap C3 targets is the one between a working notebook and a running pipeline. A data scientist finishes an analysis in Jupyter, and someone else has to reproduce the environment, pin the dependencies, build an image, push it to a registry, and hand-write the pipeline component that calls it. C3 automates that transformation. The README states it takes arbitrary assets (Jupyter notebooks, Python scripts, R scripts) as input, creates container images, pushes them to container registries, installs the required dependencies into the image, generates KubeFlow Pipeline components, and produces Kubernetes job configs.

The intended user is not a general Python developer. It is a team that already has a cluster and a workflow engine and wants the notebook to be the unit of delivery. The README frames the goal as low-code/no-code rapid prototyping that CI/CDs into production, and notes that C3 can be triggered from CI/CD pipelines. If your deployment story is a single long-running service behind a load balancer, the component model here is the wrong shape.

How C3 turns a script into a component

The mechanism is a compiler, not a runtime. You point a command-line entry point at a code asset and a target registry, and the tool derives the build and deployment artefacts from it. The repository layout supports this reading: the top level holds configs/, bin/, src/, examples/ and a bench/ directory, and the examples folder contains operator_example.py, operator_example.ipynb, operator_example.yaml, operator_example.cwl and operator_example.job.yaml side by side. The same conceptual operator appears as a Python file, a notebook, a pipeline definition and a job configuration, which is what you would expect from a tool that emits several artefacts per input.

Dependency installation is handled during image creation rather than declared by hand, per the README bullet list. That is convenient and also the place where surprises live: the environment is reconstructed from what the tool can infer, so anything your script imports dynamically, or any system package it shells out to, is a candidate for a missing dependency.

The other half of the architecture is grid compute. The README describes grid compute parallelization as the most utilized feature, and states that the Machine Learning eXchange (MLX) is integrated as the backend for the grid computing system, tracking data, models, jobs and related resources. The examples directory contains a folder_grid_wrapper_example/ and a jobcoordinator_example/, plus shell scripts such as run_ccc_gridfm_example.sh, which suggests the grid path is exercised through wrapper scripts rather than a single documented command.

Installing claimed and running c3_create_operator once

The README gives a single install line. It installs the package named claimed from PyPI.

pip install claimed

The package metadata requires Python 3.11 or later, so an older interpreter will fail at install time rather than at run time. Once installed, the compiler is exposed as a command-line entry point. The README's usage section shows exactly one invocation, with the code asset as the positional argument and the registry and namespace supplied through --repository.

c3_create_operator "<your-operator-script>.py" --repository "<registry>/<namespace>"

Replace both placeholders with real values: the path to your script, and the registry host plus namespace where the image should land. The README does not show sample output, so what appears on the terminal is not documented. The help text is available and is the safer way to discover the remaining flags:

c3_create_operator --help

One constraint matters before you run anything. The README says your code needs to follow certain requirements explained in GettingStarted.md, and links to that file in the c3 repository. Treat that document as required reading, not optional background. Running the command against a script that does not meet those requirements is the most likely first failure.

The pre-alpha label and the documentation gaps

The honest limitation is maturity. The project's own pyproject.toml carries the classifier Development Status :: 2 - Pre-Alpha, while the most recent release listed is v0.5.0 from 2026-06-30 and the package metadata in the repository declares version 0.6.0. A pre-alpha classifier on a 0.x package is the maintainers telling you the interfaces can move.

The second limitation is documentation coverage. The README documents the install command and one usage command. It does not document rollback of a pushed image, it does not enumerate the supported workflow execution engines beyond calling them pluggable, and it does not list the requirements your code must satisfy, deferring those to GettingStarted.md. For a tool whose value proposition is CI/CD integration, the absence of documented rollback semantics in the README is a real gap: if a generated component is wrong, the README does not say how to undo the push.

A third case where this is the wrong tool: if you need a stable, versioned API surface that you can pin against for years, a pre-alpha compiler that regenerates container images from source on each run is a poor fit. The generated artefacts become your interface, and the generator can change under them.

Where terratorch-iterate fits, and what the bundle changes

The README bundles a second project, terratorch-iterate, and the package description in pyproject.toml reads "The CLAIMED framework (now bundling terratorch-iterate)". Iterate is a different kind of tool: it does benchmarking and hyperparameter optimization over TerraTorch models, using MLflow for experiment logging, Optuna for the search and Ray for parallelization. The dependency list mixes both halves, with nbconvert, ipython, traitlets, pandas, boto3, s3fs and toml alongside terratorch, optuna-adjacent packages such as scikit-learn and Jinja2, and pytorch-lightning.

From iterate v0.3 the tool can optimize over arbitrary code running on arbitrary workload managers. The README states Slurm and LSF are supported, with Kubernetes/OpenShift and PBS described as coming soon. That is the concrete alternative to reaching for C3 when your goal is parallel execution: if what you want is to sweep hyperparameters across a Slurm or LSF cluster and log the results, iterate's own command line does that directly, with --wlm lsf and --metric yval, and an Optuna dashboard pointed at a SQLite study file.

The difference in approach is worth stating plainly. C3 compiles code into deployable components. Iterate runs an existing script many times with different parameters and records the outcomes. They share a repository and a dependency list, not a workflow. Installing claimed gets you both, which also means the dependency footprint of the hyperparameter tooling comes along whether or not you use the compiler.

Licence, maintenance and upgrade cost

The project is released under Apache License v2.0, stated at the end of the README and confirmed by the License :: OSI Approved :: Apache Software License classifier in pyproject.toml. For most teams that is a permissive licence with a patent grant, and it imposes no copyleft obligation on your own code. The one practical consequence to check is attribution: Apache-2.0 requires that notices be preserved in redistributed copies, so if you vendor the source rather than installing from PyPI, keep the LICENSE file with it. This is a description of the licence text, not legal advice; your own counsel decides how it applies to your distribution.

The repository is not archived, and the last push was on 2026-07-07. Recent releases exist, with v0.5.0 on 2026-06-30 and two releases in April 2026. That is a project with recent activity, though the pre-alpha classifier says the activity is still pre-stabilisation.

The upgrade cost is structural rather than cosmetic. Because C3 generates container images and pipeline components from your source, a version bump can change the generated artefacts even when your script is untouched. The repository carries a CHANGELOG.md and a release_process.md at the top level, and reading the changelog before bumping is the cheapest way to find out whether the generated output changed. The repository also carries a .pre-commit-config.yaml, a tox.ini and a run_tests.py, so if you fork, the test entry points are already laid out.

Editorial conclusion

Adopt CLAIMED if you already run KubeFlow or Kubernetes and want notebook-based work to reach a cluster through a CI/CD job rather than a manual container build. Do not adopt it if you need a documented rollback path, a stable API, or a project that is past pre-alpha; pyproject.toml still declares Development Status 2 - Pre-Alpha. Before committing, verify three things in your own environment: that your registry credentials work with the repository argument of c3_create_operator, that your code satisfies the requirements listed in GettingStarted.md, and that the KubeFlow component C3 generates matches the pipeline engine you actually run, since the README describes the execution engine as pluggable but does not enumerate the supported ones.

Frequently asked questions

Official sources

1. claimed-framework/claimed on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases