# One project, four names, two readmes and a version nobody has released > A component compiler that turns notebooks into containers and Kubernetes jobs, bundled with a second tool whose guide recommends a Python the combined package refuses to install on, published under a distribution called something else and a tag one release behind the tree. **claimed-framework/claimed** — The goal of CLAIMED is to enable low-code/no-code rapid prototyping style programming to seamlessly CI/CD into production. - Repository: https://github.com/claimed-framework/claimed - Stars: 2,304 · Forks: 3,904 - Language: Jupyter Notebook - License: Apache-2.0 - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/claimed-framework-claimed ## The repository, the project, the tracker and the package have four names The repository is called claimed and its readme's headline is a different thing: C3, the CLAIMED component compiler. Then the links diverge. The getting-started link points into a repository named c3. The issue tracker link and the discussions link both point into a repository named component-library. The install command installs a distribution called claimed. So a reader who arrives, installs the package, and then tries to file an issue is looking at a different repository from the one they cloned, and the code the install line refers to lives in a third. The two commands that make up the whole usage section are these: ```sh pip install claimed ``` ```sh c3_create_operator ".py" --repository "/" ``` The second one is named after the third of the four names, and it takes a registry and a namespace, so the tool assumes you already have somewhere to push images. There is a reason for part of it, and the packaging configuration shows it. The build tool derives the version from the repository tag and writes it into a file under a directory called c3 inside the source tree. So the import path still carries the old name even though the distribution has been renamed, and a rename of the distribution never became a rename of the module. That is a normal kind of technical debt. The part that is not normal is that nothing in the readme warns a reader about it, and a first-time user has no way to guess which of the three repositories is the live one until they read a link inside a link. ## The readme is two projects with a funding block between them The document changes character about two thirds of the way through. The first part is the component compiler: a summary of what it does, a section on grid compute, an install line, a usage line, help and contribution pointers, a credits block naming three research funders, and a licence statement. Then a horizontal rule, a heading that says the second tool is bundled, and a second heading that begins an entirely different user guide. The second guide has its own install command, its own prerequisites, its own usage examples for running locally and on a scheduler, its own configuration reference, and its own version history. Nothing introduces it beyond the word bundled. A reader who came for the component compiler has to work out on their own which half answers their question. The two halves also come from different organisations, which the readme never mentions. The bundled tool's development instructions tell you to clone a repository under one corporate account, while the commands immediately above them download example files from a different account, and the description of the tool it tunes links to a host that is not the public code host at all. Three naming authorities inside one document. And the version of the second tool is spelled wrong in its own section: the sentence introducing its current command names a variant with an extra letter. Small, but it is in the line that tells you what to type. ## The version in the tree is ahead of every published release The package configuration says version 0.6.0. The three most recent releases are 0.5.0 from the end of June, 0.2.7 from April, and 0.2.6 from the same April day. The last commit to the default branch is in July. Three things fall out of that sequence. The tree is one release ahead of anything published. The version line skipped from 0.2.7 to 0.5.0, so intermediate minors were either never tagged or were abandoned. And the release names are not formatted consistently: one carries a prefix and a capitalised name, the other two are bare version strings. The version is not a literal in the configuration anyway. A build-time plugin reads it from the repository tag and writes it into a file inside the source tree, which is the right way to do it. The consequence for a reader is that the number in the manifest tells you where the branch is, and the tag list tells you what you can actually install. The development status classifier is worth reading next to the release history. It says pre-alpha. So the project describes itself as pre-alpha, publishes a 0.5, and has an unreleased 0.6 in the tree, and none of those three statements is unusual on its own. ## A useful-commands example binds a dashboard to every interface Under a heading labelled useful commands, the bundled guide offers two lines. The first installs a dashboard package for a search study. The second runs it, and the host argument in that line is all zeroes followed by a dot. That is the address every machine on the network, not the loopback interface. A hyperparameter search dashboard is a web application that reads a database and usually offers a way to inspect and sometimes to cancel studies, and binding it to every interface with nothing in the example about authentication means any host that can route to the machine can read the study database. The second line also names the database the first example committed to the repository. The example directory contains a search study file, so the command in the readme is meant to be run against a database that is already public in the repository. That is fine for a tutorial and it is also a reminder that the two lines belong on a laptop rather than on a shared server. There is a smaller version of the same problem a few lines earlier. The prerequisite steps create a virtual environment in a directory whose name starts with a dot, and then the activation command refers to a directory without the dot. Run the two lines as printed and the second one fails. ## The bundled guide recommends a Python the combined package refuses The package configuration states a minimum Python version of 3.11 and lists classifiers for 3.11 and 3.12. The bundled guide recommends three versions: 3.10, 3.11 and 3.12. That contradiction was created by the bundling rather than by either project. Before the two were combined, the second tool could recommend 3.10 and the first could require 3.11 without anyone being wrong. Now one distribution carries both statements, and a user on 3.10 who follows the bundled guide cannot install the package at all. The same is true of the structure. The classifiers for the combined package are the first tool's, and the development status of one project now describes a package that contains two. When a release note says a version is pre-alpha, it is not clear which half it refers to. None of this is hidden, and all of it is checkable in about a minute by anyone who reads the packaging file and the guide side by side. That is the useful thing about a framework that ships its own metadata: the mismatches are legible. ## Three ownership files and two ways to report a vulnerability The repository root carries a code owners file, a file of owners, and a maintainers document. Three mechanisms for the same question, in one flat directory, none of them referenced from the readme. Disclosure is split the same way. There is a security policy and a separate vulnerabilities document, and the readme points only at the second. Someone who goes looking for how to report a problem and searches for the word security finds one file, and someone who reads the readme finds the other. Whether they contain the same instructions is not something the repository tells you. Continuous integration is also doubled. There is a GitLab pipeline file at the root and a directory of GitHub workflows beside it. Both can be the right answer for a project with contributors on two platforms, and both being present without a note about which is authoritative means a contributor filing a merge request does not know whether it will run. The rest of the root is a research project's toolkit: a secrets baseline, a dependency-update configuration, a pre-commit configuration, a source scanning configuration, a test runner script, a tox file, a documentation site configuration, a test requirements file, and a generated coverage badge committed as an image. ## Three build files for one package, one of them a stub that says so The build configuration is a modern one. It declares a build backend with a minimum version, keeps the version in a plugin setting that writes it into the source tree, and describes the package with a name, a description that mentions the bundling, a Python floor, a licence file reference, keywords, eight authors and two maintainers. Then there is a setup configuration file, and then there is a setup script. The script is four lines long and its own comment block explains why it exists: the guidance is to prefer the modern configuration, to use the older configuration file for anything the modern one does not support, and that the script is discouraged and included only as a stub for legacy tools that lack support for the current editable install standard. So a reader opening the build files finds a deliberate hierarchy, and the stub says so in the file rather than leaving you to guess. That is good practice, and it is also a small monument to a migration that has not finished. The author list is the other thing worth reading. Eight names, most without an email address, one with a corporate address, and a single project address for the first entry. For a framework funded by three public programmes and maintained by a named group, that is a reasonable record. One last detail about the readme. The entire usage section is a single command with a script path and a registry and namespace, and the sentence after it says your code needs to follow certain requirements, which are explained in a getting started file in a different repository. So the one command in the readme is the smallest possible example, and the constraints on your code live somewhere else entirely. ## Conclusion This is a research framework with real ambition and a public funding record, and the ambition is stated crisply: a notebook in, a container image and a Kubernetes job out, with a pluggable execution engine behind it. What an adopter inherits is a repository that is part documentation and part working notes. Four names, two concatenated readmes, a version in the tree that no release matches, a dashboard example bound to every network interface, and a committed example database. None of that makes the project unusable, but none of it is something a release engineer would want either. Before depending on it, confirm which of the four names is the one you actually want, read the getting-started file the readme points at rather than the readme itself, and pin a version that exists on the package index. ## FAQ ### What does the CLAIMED framework do? Its component compiler takes arbitrary assets such as notebooks, Python scripts and R scripts and turns them into container images, pushes them to a registry, installs the dependencies, generates workflow components and Kubernetes job configurations, and can be triggered from a pipeline. The execution engine it targets is described as pluggable. ### What is the difference between CLAIMED, C3 and the component library? The repository is called claimed, the readme's project is called C3, the issue and discussion links point into a repository named component-library, and the distribution you install is called claimed. The source tree still keeps its original name in one place because the build writes the version file into it. ### Which Python version does the CLAIMED package need? The packaging file requires 3.11 or newer and lists classifiers for 3.11 and 3.12. The bundled tool's guide in the same readme recommends 3.10, 3.11 or 3.12, so a 3.10 user cannot install the combined package. ### Is there a second tool bundled into CLAIMED? Yes. The readme has a section for it, and the package description says the framework now bundles it. It is a benchmarking and hyperparameter optimisation tool that uses a search library for tuning, an experiment tracking library for logging and a parallel execution library, and it comes with its own user guide and version history in the same document. ### How is the CLAIMED version determined? Not from a number in the packaging file. A build plugin reads the repository tag and writes the value into a file inside the source tree. The tree says 0.6.0 while the newest release is 0.5.0, and the version line jumped from 0.2.7 to 0.5.0. ## Sources - [claimed-framework/claimed on GitHub](https://github.com/claimed-framework/claimed) - [Issues](https://github.com/claimed-framework/claimed/issues) - [License: Apache-2.0](https://github.com/claimed-framework/claimed/blob/main/LICENSE) - [README](https://github.com/claimed-framework/claimed/blob/main/README.md) - [Releases](https://github.com/claimed-framework/claimed/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/claimed-framework-claimed