FixControl
Change validation · Pilot

A change proves itself before it reaches your release process.

FixControl validates a proposed change in an isolated environment first — and, where configured, continues validation inside your own Kubernetes environment through the FC Agent. The evidence travels into the approval, and your existing CI/CD, Kubernetes and Argo controls stay authoritative. Nothing gets replaced.

Isolated multi-container validationEvidence recorded on every runYour CI/CD stays in charge
The path of a change

From proposal to release, with proof at every step

  1. 01Change
    A change is proposed

    A developer — or FixControl’s AI, preparing a fix from a support ticket — proposes a change for a project. Nothing about it has touched your systems yet.

  2. 02Validate
    It runs in isolation first

    Where configured, FixControl starts the database, cache and background services the application needs — read from your repository’s Compose file as configuration, never executed — in one isolated network without internet access, and runs the tests there.

  3. 03Evidence
    Every green run is specific

    A passed validation records exactly what it passed against: the normalized environment configuration and the exact image versions (digests). If the images or the configuration change, the old evidence no longer counts.

  4. 04Approve
    A person decides, with the evidence in front of them

    The validation result is frozen into the approval. The person deciding sees what ran and against which versions — before anything reaches a repository or a pipeline.

  5. 05Deliver
    Your CI/CD takes over

    The approved change travels as a normal merge request through your existing pipeline. FixControl does not replace your CI/CD — your pipeline’s own checks, approvals and deployment steps stay authoritative.

  6. 06Release
    Your deployment controls decide the rollout

    Where configured, a deployment pause your pipeline already holds — or a paused Argo rollout — opens one more FixControl approval, executed through your CI host’s or Argo’s own primitives. Release stays your process.

Two validation environments

Isolated first. Your environment where it matters.

The two environments answer different questions — they are not the same test run twice.

Isolated Docker validation

Fast and reproducible: a fresh, disposable multi-container environment per run, isolated from production and from the internet, cleaned up afterwards. It answers: does this change build, pass its tests and behave next to the database, cache and services the application needs?

Validation in your own environment

Where configured through the FC Agent, validation continues inside your own Kubernetes environment before release: real runtime context, your cluster’s dependencies and constraints. It answers: does this change behave in the environment it will actually ship to? Same evidence contract, different question.

Which validation runs

Policy-driven, never silent

The combination is a choice, not a coincidence
Isolated Docker validation is the default lane where multi-container validation is configured. Validation in your own environment is optional and policy-driven: it is enabled per project during pilot onboarding, and FixControl’s validation architecture supports running the isolated lane first and the in-cluster lane after it passes — with a required in-cluster validation satisfied only by in-cluster evidence, never silently by a local run.
When validation or a rollout fails

A failure produces evidence, not an automatic retry

Governance stays between analysis and execution
A failed validation or rollout comes back as structured evidence, not as an automatic change to production. FixControl distinguishes an application failure — a red test, a crash at startup — from an infrastructure failure such as an image that would not pull. An application failure can feed a new AI-prepared revision of the change, which goes through validation and approval again from the start; an infrastructure failure surfaces as a health finding for an operator. In both cases, a person stays between the analysis and the next action.
FAQ

Validation questions

Do both validations always run?+
No. Isolated Docker validation is the default where multi-container validation is configured. Validation in your own environment is optional and policy-driven, enabled per project during pilot onboarding. Where both are required, each needs its own green result.
Does this replace our CI/CD pipeline?+
No. FixControl validates before your pipeline and governs pauses your pipeline already has. Delivery is a normal merge request; your pipeline’s checks, approvals and deployment steps remain authoritative.
What evidence does a validation produce?+
The normalized environment configuration, the exact image digests it ran against, the executed plan and the result — recorded per run and frozen into the approval that relies on it. A changed image or configuration invalidates old evidence.
Does a failed rollout mean AI changes production again?+
No. A failure comes back as structured evidence and analysis. Any new change starts the same controlled loop — validation, evidence, approval — and by default nothing reaches your release process without a recorded human decision.
Do we need to expose our cluster for in-cluster validation?+
No. In-cluster validation runs through the FC Agent: an outbound-only connection, signed single-use operations, and a separate least-privilege identity for the validation runner. Your cluster stays private.

See a change earn its release

Book a demo and follow one change from proposal through isolated validation, evidence and approval into your own release process.