kubernetes-ontology is open: what Kubernetes failure mode should the graph explain next?

[Colvin-Y]

Hi folks, I just open-sourced kubernetes-ontology and would love feedback from people who debug Kubernetes clusters, build platform tooling, or experiment with AI-agent operations.

Repo: https://github.com/Colvin-Y/kubernetes-ontology
Landing page: https://kubernetes-ontology.vercel.app

kubernetes-ontology is a read-only Kubernetes topology and diagnostic service. It reads objects from the Kubernetes API, builds an in-memory evidence graph, and exposes CLI / HTTP queries plus a local topology viewer.

The current MVP focuses on:

• Pod and Workload diagnostic entrypoints
• ownerReference chains, including Pod -> ReplicaSet -> Deployment
• Service selector matches
• Pod links to Node, ConfigMap, Secret, ServiceAccount, Image, and PVC
• PVC -> PV -> StorageClass -> CSIDriver storage paths
• ServiceAccount to RoleBinding / ClusterRoleBinding evidence
• Kubernetes Event and admission webhook evidence
• HelmRelease / HelmChart evidence from standard Helm labels and annotations
• stable JSON output for downstream AI agents

The safety model is intentionally conservative: no observed workload mutation, no mutating webhook, no business CRD requirement, no graph database requirement, and no runtime writes to the Kubernetes resources being diagnosed.

I am especially looking for feedback on three things:

1. Which failure mode should the graph explain next? CrashLoopBackOff, Pending scheduling, DNS / Service routing, volume attach / mount, webhook admission failures, RBAC, Helm upgrade failures, or something else?
2. Are the current graph edges and provenance fields useful enough for real incident workflows?
3. What would make the quickstart easier to try in a private or air-gapped cluster?

If you try it, opening an issue or replying here with a concrete failure mode would be hugely helpful. Stars are appreciated too, but concrete debugging stories are the real fuel for the next iteration.