Skip to main contentProjects
Projects represent the primary entities (nodes) in the Knowledge Graph, modeling Cloud Native projects or add-ons such as Istio, cert-manager, or ArgoCD. Each Project encapsulates the complete software entity including its development lifecycle, release patterns, and ecosystem relationships. Projects serve as the primary organizational unit for tracking functionality, compatibility, and upgrade paths across the Cloud Native landscape. Similar to how deps.dev models package ecosystems, Projects form the foundational entities from which all dependency relationships emanate.
Project Components
Project Components are logical sub-entities within a Project, such as control planes, webhooks, operators, or data planes. These represent compositional relationships within the Knowledge Graph, allowing fine-grained tracking of how different parts of a project evolve, interact, and impact upgrade decisions. For example, Istio’s control plane and data plane components may have different upgrade requirements and compatibility constraints, creating distinct relationship paths in the graph.
Project Release
A Project Release represents a versioned instance entity of a Project, capturing the coordinated publication of one or more Release Artifacts having the same Version string. These entities form temporal relationships in the Knowledge Graph, connecting different states of a Project over time and enabling upgrade path analysis.
Project Release Series
A Project Release Series groups related Project Releases into logical collections, identified by a simple string unique to the Project. Typically following a major or major.minor version pattern (e.g., “4” or “1.28”), though some Projects use date-based names like “2024.04”. These create hierarchical relationships within the Project’s version topology.
Packages
Packages represent distribution entities that bundle Projects into deployable forms, including Helm charts, Kubernetes Operators, container images, or other deployment artifacts. Packages bridge the gap between upstream Projects and their actual deployment forms, creating packaging relationships in the Knowledge Graph. This modeling aligns with deps.dev’s approach to tracking how software is distributed across different packaging ecosystems.
Package Components
Package Components are modular entities within a Package—modules, containers, or Custom Resource Definitions (CRDs). They represent the granular building blocks that create dependency relationships at the most detailed level of the deployment stack, enabling the Knowledge Graph to track fine-grained dependencies and compatibility matrices.
Package System
A Package System identifies and categorizes packaging ecosystem entities (e.g., Helm, container images, operators), creating classification relationships that group related packaging approaches and enable ecosystem-wide reasoning.
OCI Artifacts, Repositories, and Tags provide comprehensive indexing entities for container registries and Helm repositories, creating artifact relationships that link deployment artifacts to their corresponding Project releases. This enables tracking of the actual software artifacts used in deployments and their relationship to upstream releases.
Versioning Scheme
Versioning Scheme defines the semantic rules and patterns that govern how version relationships are structured and compared within the Knowledge Graph. This captures how projects structure their version numbering (semantic versioning, date-based, custom schemes) and enables the Knowledge Graph to correctly parse, compare, and reason about version relationships and upgrade paths.
Version Compatibilities
Version Compatibilities represent critical compatibility relationships between different Project entities in the Knowledge Graph. These cross-project compatibility matrices define which versions can work together safely, creating complex multi-dimensional relationship networks. For example, mapping which Istio versions are compatible with specific Kubernetes versions enables safe multi-component upgrade planning through graph traversal.
Support Model
Support Model tracks temporal lifecycle relationships for entities, including End-of-Life (EOL) dates, Long-Term Support (LTS) windows, and deprecation schedules. These relationships enable proactive identification of support risks and help plan upgrades before critical support boundaries, similar to how dependency graphs track package lifecycle states.
Changelogs & Release Notes
Changelogs & Release Notes serve as input data sources that are AI-parsed and enriched to capture deltas, breaking changes, security fixes, and feature additions between releases. The Knowledge Graph processes this unstructured release documentation into structured, machine-readable change relationships that enable automated impact analysis and upgrade planning.
Service Health & Readiness Checks
Service Health & Readiness Checks are diagnostic entities that validate cluster and 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 through the Knowledge Graph’s relationship network.
Upgrade & Migration Instructions
Upgrade & Migration Instructions are AI-derived structured entities that provide step-by-step guidance through procedural relationships for safely upgrading between versions. These instructions are contextualized for specific deployment patterns, configurations, and infrastructure topologies, leveraging the full relationship context of the Knowledge Graph to generate environment-specific guidance. 
