Change validation

Before a proposed change reaches your repository or your release process, FixControl can validate it — and record exactly what that validation proved. This page describes the two validation environments, how the choice between them is made, and what evidence a run leaves behind.

FixControl can validate changes in isolated multi-container environments and, where configured, continue validation inside customer-controlled Kubernetes environments before release.

Change (proposed by a developer or by FixControl's AI)
   ↓
isolated Docker validation                (where configured)
   ↓
optional validation in your own cluster   (policy-driven, via the FC Agent)
   ↓
evidence frozen into the approval
   ↓
your existing CI/CD, Kubernetes and Argo controls

Isolated Docker validation

Where multi-container validation is configured (a per-organization setting, off by default, offered as part of a pilot), FixControl runs the change next to the services the application actually needs:

• The repository's Compose file is read as configuration — never executed. Every service, image and option passes a strict policy: unsupported or dangerous constructs (host mounts, privileged containers, port publishing, build instructions and more) are refused, not skipped quietly. The rules in customer language are listed under Projects → Multi-container environments.
• Services start in one isolated network per run, without internet access and without access to your source code; the run is cleaned up afterwards, and a sweeper removes anything a crashed run leaves behind.
• Image references are resolved to digests before the run, so the evidence names the exact software versions the change passed against.

This lane answers: does the change build, pass its tests and behave next to its database, cache and background services? It is fast, reproducible and disposable.

Validation in your own environment

Where configured during pilot onboarding, validation continues inside your own Kubernetes cluster, executed by a validation runner that the FC Agent install package deploys:

• The instruction to run arrives as a signed, expiring, single-use operation the agent fetches outbound; the workspace travels over the same channel. Your cluster is never exposed to FixControl.
• The runner creates a short-lived test namespace, starts the same declared services, runs the same plan, and cleans up. It is a separate identity from the agent, cannot touch rollouts, and an admission policy blocks its writes outside its own test namespaces.
• Secret values never appear in FixControl's stores, operation payloads, logs or evidence. Where a validation needs secrets, the bindings are set up during pilot onboarding so runs reference them by name and the values themselves stay in your cluster.

This lane answers a different question: does the change behave in the environment it will actually ship to — your cluster's runtime, policies and dependencies. It is not the Docker run duplicated.

Which validation runs

The choice is policy-driven and explicit — configured per project together with your team during pilot onboarding, not inferred:

• Docker only — the isolated lane is required.
• In-cluster only — validation runs in your environment.
• Docker, then in-cluster — the isolated lane runs first; only after it passes does the in-cluster lane run. The gate then requires both results.

Two honesty rules hold throughout:

• A required in-cluster validation is satisfied only by in-cluster evidence — a Docker-only pass is never substituted for it.
• If a required lane is unavailable (for example, the agent is disabled), the run fails closed with a clear reason. It does not fall back to a weaker validation without saying so.

FixControl also detects when a repository clearly targets Kubernetes (Helm charts, Kustomize, manifests) and records that signal with the run, so a Docker-only validation of a cluster-heavy application is visible for what it is. The signal informs; it never silently changes the configured strategy.

Evidence

Every green run records:

• the normalized environment configuration (a hash of the validated topology),
• the exact image digests the services ran with,
• the executed plan (which steps ran),
• for in-cluster runs: where it ran — agent, cluster, namespace, operation.

Together these form the run's validation fingerprint. A changed patch, image, configuration or plan produces a different fingerprint, so stale evidence never carries over. The result — including the fingerprint and, where applicable, the per-lane results — is frozen into the approval that relies on it, and appears in the deployment provenance trail alongside the approval and the rollout it led to.

Where your governance policy requires it, the patch gate refuses to apply a change whose current version lacks matching green evidence (see Governance & policy, verification policies).

When validation fails

A failure produces structured evidence, classified by kind:

• Application failures — a red test, a crash at startup, a service that never became ready. These can feed a new AI-prepared revision of the change, which goes through validation and approval again from the start.
• Infrastructure failures — an image that would not pull, an unreachable runner, an expired operation. These surface as health findings for an operator and deliberately do not trigger a code change: a broken environment is not a bug in your application.

In both cases governance stays between analysis and execution: a failure never means an unreviewed change reaches your systems.

See also: FC Agent · DevOps & CI/CD · Governance & policy.