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.
From proposal to release, with proof at every step
- 01ChangeA 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.
- 02ValidateIt 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.
- 03EvidenceEvery 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.
- 04ApproveA 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.
- 05DeliverYour 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.
- 06ReleaseYour 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.
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.
Policy-driven, never silent
A failure produces evidence, not an automatic retry
Validation questions
Do both validations always run?+
Does this replace our CI/CD pipeline?+
What evidence does a validation produce?+
Does a failed rollout mean AI changes production again?+
Do we need to expose our cluster for in-cluster validation?+
How FixControl reaches private infrastructure — outbound only.
Evidence in, one recorded decision, one promotion.
Isolation, governance, evidence and audit in depth.
The full doc: strategies, evidence contract, secret bindings and failure behaviour.
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.