pilot-fleet-conformance

To generate a Kubernetes fleet-wide conformance verdict, aggregate three-way and source-truth evidence across clusters or namespaces. This rolls per-resource outcomes into a single strategy-anchored PASS, WATCH, ASK, or BLOCK decision for governance workflows.

GitOps conformance checking flags cross-cluster mismatches by comparing resource states against a View baseline. It aggregates evidence to detect outliers across multiple clusters, supporting fleet-level escalation decisions when configurations diverge from the expected source-truth.

You can use namespace or full cluster scope for compliance automation checks if a View is unavailable. A ConfigHub View is the preferred scope for fleet-wide verdict synthesis, but the system falls back to namespace or cluster boundaries as needed.

You need connected mode to verify and save per-resource evidence receipts for compliance tickets. Connected mode is required for View-based and fleet outlier surfaces, ensuring the conformance verdict is backed by verifiable source-truth data.

PASS, WATCH, ASK, and BLOCK verdicts represent escalating severity levels in multi-cluster compliance. The system rolls per-resource outcomes into one fleet-level verdict using max-severity framing, where BLOCK indicates hard failures and WATCH or ASK flag issues needing review.

Kubernetes conformance verification stays strictly read-only during a GitOps audit and does not modify cluster resources. It computes per-resource conformance by comparing evidence and generating a verdict, while Pilot handles the verdict framing without applying changes.