scout-attribute

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