Summary

Replace the current monolithic Go testing.T-based validation pipeline with a container-per-validator execution model where each validator is a standalone OCI image run as a Kubernetes Job.

Motivation

The current validator architecture has fundamental limitations:

• Fragile result parsing — results are extracted from go test -json output using custom string markers, which breaks on log corruption
• Tightly coupled — adding a new check requires writing Go code and rebuilding the validator image
• Monolithic execution — all checks share one pod; a single OOM kill loses everything
• Non-standard output — custom ValidationResult type with no ecosystem tooling interop

Goals

Self-contained, modular validators

Each validation check runs in its own container image. Components own their own tests. This decouples the validation lifecycle from the core CLI, allowing developers to test individual validators in isolation without understanding the entire codebase.

Language and tooling agnostic

Since validation logic is encapsulated in a container, the system is no longer tied to Go tests. Teams can use the best tool for the job (shell scripts, Python, existing conformance suites) as long as the container follows the evidence contract.

Declarative validator catalog

New validators are added via YAML configuration — no Go code changes required. The catalog defines what image to run, which phase it belongs to, timeout, and resource requirements.

Standardized contract

Validators communicate results through a simple, universal protocol:

• Status: exit codes (pass / fail / skip)
• Evidence: stdout
• Debug info: stderr

This generic grammar makes it easy for the orchestrator to determine whether a result is a failure or a warning, and to version the API inputs/outputs as requirements evolve.

Scalable execution via Kubernetes Jobs

Running validators as K8s Jobs enables fault isolation (one validator failure doesn't affect others), partial results collection, and a clear path to parallel execution.

Incremental migration

The new engine should coexist with the current validator so existing Go-based checks can migrate incrementally without a big-bang rewrite.

Non-Goals

• Replacing the readiness phase (inline constraint evaluation needs no cluster access)
• Parallel execution in the initial implementation (clear future optimization)

Acceptance Criteria

• Validator orchestrator deploys and manages validator Jobs
• Declarative YAML catalog for registering validators (no Go code to add a check)
• Exit code protocol for pass/fail/skip with stdout evidence capture
• RBAC lifecycle management (create before run, cleanup after)
• Structured result format with ecosystem tooling interop
• Coexists with current validator (opt-in activation)
• Unit tests with race detector passing
• At least one reference validator image demonstrating the contract