.status.validation field.
Reconciliation flow
The controller resolves a persona to its Deployment by walking an ordered fallback chain againstspec.name: the app.kubernetes.io/name label on the Deployment, then the app label, then metadata.name, then spec.selector.matchLabels. No label on the Deployment object is required, so workloads labelled only on the pod template (Helm, kustomize, most hand-written YAML) are validated too. A persona that resolves to nothing reports NoDeployment, and one that matches several Deployments on the same rung reports AmbiguousDeployment rather than validating an arbitrary one. See discovery.
Validation checks
Resource validation
Checks container resource limits and requests against persona constraints.Replica validation
Checks the deployment replica count against the persona’s scaling parameters.Health probe validation
Checks that the deployment configures probes matching the persona’s health specification.Security context validation
Checks pod and container security settings against persona policies.Severity levels
Phase determination
The persona phase is derived from validation results and deployment health:Health derivation
The controller derives health from the deployment’s status conditions:
When health is not
Healthy, the controller also queries pod statuses for specific failure reasons:
CrashLoopBackOffImagePullBackOff/ErrImagePullCreateContainerConfigErrorOOMKilledRunContainerError
.status.health.podFailures[] with the pod name, container name, reason, and message.
Conditions
The controller sets two standard Kubernetes conditions:Checking validation status
Use the CLI to inspect validation results:Webhook validation
Block non-compliant deployments at admission time
CRD specification
Full ApplicationPersona and ClusterPersona schema