What problem does it solve?
It solves the problem of figuring out where a specific Kubernetes field value came from (the controller that wrote it, the git source behind it, or a ConfigHub Link binding) so you can answer “why is this value like that?” during drift, audit, or investigation.
Core Features & Use Cases
- Per-field mutation attribution: Enriches three-way compare and explain output with
cause, managerHint, and evidence derived from Kubernetes metadata.managedFields.
- Git-source provenance: Reports the controller-derived
{repoUrl, revision, path} and, when a local checkout is available, adds raw YAML file:line back-resolution.
- ConfigHub binding lineage (connected mode): Identifies which ConfigHub Link(s) and upstream unit/path(s) feed a given field via
bindingSource and incomingBindings[], supporting “upstream intent vs live field” investigations.
- Use case: When a deployment’s
replicas differs between live and governed intent, you can identify whether it’s likely controller-driven drift vs a manual override and trace the value to its upstream unit/path.
Quick Start
Ask your AI to run a three-way compare for a field mismatch and include attribution details: “Show me the provenance of replicas on Deployment/api in namespace prod, and explain whether it’s controller-drift or manual-edit.”
