> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chkk.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Concepts

> Core concept definitions for Chkk's Knowledge Graph.

## Project

A ***Project*** is software that provides some functionality.

The term "project" was chosen to align with a similar [deps.dev](https://deps.dev) concept.

Each Project has a ProjectType. Valid ProjectTypes include:

* *platform*: The Project represents a software platform, such as the Cloud Native Project itself.

* *addon*: The Project represents a Cloud Native Project, which is defined as some software that extends the functionality of the Platform it is running on.

* *application-service*: The Project represents application code that provides essential services to the rest of the application stack.

* *control-plane-provider*: The Project represents a control plane service, such as GKE, EKS, or NKP.

* *application*: The Project represents customer-specific or internal code.

***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:

* Versioning scheme and release cadence
* Licensing and support models
* Source code locations
* Releases and release artifacts
* Components and images
* Dependencies
* Bugs, issues and risk assessments
* Changelogs, upgrade considerations, and migration guides
* Related packages–Helm charts, Kustomize Overlay Directories, etc.
* Version compatibility matrices
* Deprecation and end-of-life schedules
* Service health and readiness checks

## Project Component

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!

## Project Release and Release Series

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.

## Change

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).

## Package

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](https://deps.dev) concept.

A Package has a ***Package System*** which indicates the format of the Package. Chkk supports two package systems:

* *helm*: Helm Charts
* *kube*: Raw manifests, including Kustomize overlays

**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.

## Package Component

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.

## Service Health & Readiness Checks

**Service Health & Readiness Checks** are diagnostic entities that validate project health through **validation relationships** before, during, and after upgrades. These checks are curated for specific project versions and deployment patterns, providing automated validation of upgrade success and system stability.
