Chkk’s agentic lifecycle management platform is built on our Collective Learning technology. The Knowledge Graph is a critical part of this foundational technology. The Knowledge Graph models the Cloud Native ecosystem — capturing how projects evolve, depend on one another, and interact at runtime. It provides the contextual intelligence required for safe, automated lifecycle decisions across hundreds of Cloud Native projects.
This article provides a glimpse into the breadth and depth of this rich data layer and introduces terminology that we use to describe the web of interrelated object models that comprise the Chkk data universe.
Chkk has a suite of hundreds of task-specific, source-grounded AI agents. The Chkk Research Team provides oversight over the source grounding corpus to ensure that agents only work with authoritative sources.
These AI agents perform five critical functions that build our Knowledge Graph. First, agents collect raw data from both public and private sources. We then curate this raw data by categorizing, de-duplicating and organizing the raw data. Next, agents link objects to each other, creating a graph of relationships that informs Chkk’s platform and enables product features like our upgrade and version recommendation engines. After the graph of relationships is built, agents refine the curated data and relationship links by doing deep research and validation on previously-discovered facts. Finally, a set of agents works to enrich the refined data and relationships by adding additional context to data models.
We model a large variety of objects in the Knowledge Graph. I’ll describe some of these data models and introduce the vocabulary we use at Chkk to describe these critical objects.
A Project is software that provides some functionality.
The term "project" was chosen to align with a similar deps.dev concept.
Each Project has a ProjectType. Valid ProjectTypes include:
Important: A Project is not the packaging of that software. Packaging of Projects (e.g. Helm, Kustomize, etc.) is described by the Package model–see below.
Chkk collects a variety of raw information about hundreds of Projects, including:
A Project Component is a separate binary, daemon, or subsystem of a Project.
Chkk’s Knowledge Graph stores a wealth of information about the component breakdown of a Project.
We track changes to a Project’s component breakdown over time, allowing us to provide highly-contextual answers to questions like “At what version of ArgoCD was the ApplicationSet controller bundled with the ArgoCD project as a core component?” (hint: the answer is ArgoCD 2.3). This gives Chkk’s Knowledge Graph time-machine superpowers!
A Project may have one or more Project Releases. A Project Release is the versioned publication of a Project and typically has one or more release artifacts tagged with the Project Release’s version.
A Project Release is always associated with a single Project Release Series. The Project Release Series’ version will depend on the versioning scheme the Project uses. For example, if a Project uses Semantic Versioning, the Project Release Series will be the major and minor version number.
A Project Release can have many Changes. A Change describes a change that was made to some code, configuration default or configuration structure. Changes are typically listed in changelogs or release note collections.
Changes can add new functionality, remove functionality, and potentially break customer environments.
A Change can have many Change Enrichments. A Change Enrichment is any refinement or modification made to the original content of the Change record. AI agents enrich a Change record, for example, by adding classification labels, researching the accuracy of a release note, and rewriting it using additional context (e.g. GitHub Issues / PRs).
A Package is a named bundle of software that is bundled (and identified) in the format of a specific PackageSystem.
The term "package" was chosen to align with an identical deps.dev concept.
A Package has a Package System which indicates the format of the Package. Chkk supports two package systems:
Note: Helm is both a Package System and a Deployment System. The Helm Chart is a Package whereas the helm install CLI command is the Deployment System.
A Package has zero or more Package Components. For Packages using the helm or kube Package System, these Package Components represent a Resource (Deployment, DaemonSet or StatefulSet) that is installed by the Package.
Package Components include one or more Project Components. For Packages using the helm or kube PackageSystem, these Project Components represent a Docker Image that is in the spec.templates.spec.containers field of the Package Component's Resource definition.
Thus, the Package itself is associated with one or more Projects via these Project Component -> Package Component -> Package relationships.
Like Project Components, Chkk tracks changes to the composition of a Package and its configuration over time, giving us an ability to view the evolution of a Package.
As of October 20, 2025, the Knowledge Graph contains:
