Skip to main content
← All posts

Why we version everything (and what happens when you don't)

Modulo Team

versioningauditgovernance

Why we version everything (and what happens when you don't)

Version control for source code is a solved problem. Every team uses git, every commit is recorded, and you can check out any point in history and see exactly what the code looked like.

Version control for everything else is not solved. Most teams do not version their CI pipeline configuration, their deployment scripts, their model settings, their prompt templates, or their gate thresholds. When something breaks, they cannot reproduce the failure because they do not know what version of the pipeline ran.

What happens when you do not version

Consider a typical scenario. Your agent pipeline has been running smoothly for weeks. Suddenly, a run fails in a way you have never seen before. You need to answer three questions:

  1. What version of the pipeline ran?
  2. What version of each component was used?
  3. What changed between the last successful run and this failure?

If your pipeline configuration is mutable - if someone edited a prompt, swapped a model backend, or changed a gate threshold without recording it - you cannot answer any of these questions. The pipeline that ran is not the pipeline that exists now. You are debugging against a ghost.

This is the normal state of most agent pipelines today. Prompts are edited in place. Model backends are swapped by changing a dropdown. Gate thresholds are tuned by sliding a number. Every change is invisible until something breaks.

What Modulo does differently

Modulo versions everything that affects a run's outcome. When a run starts, we freeze the entire pipeline definition into a snapshot: every agent version, schema pin, connector binding, model backend pin, prompt version hash, and environment profile. Nothing resolves live. The run executes against this frozen state.

This means:

  • You can inspect any past run and see exactly what configuration it used.
  • You can diff two runs and see what changed between them.
  • You can reproduce a failure by running the same snapshot against the same inputs.
  • You can change any component without affecting in-flight runs.

The snapshot is not optional. It is how the system works.

What this means for audit and governance

If your audit trail records what happened but not what configuration produced it, the trail is incomplete. Knowing that a gate failed is useful. Knowing that the gate threshold was changed thirty minutes before the failure is what tells you whether the failure was a real problem or a configuration mistake.

Versioning everything means every run carries its own context. You never have to ask "what version of the pipeline was running at that point?" because the answer is in the run record.

The principle behind this: immutability of runs - a run executes against a frozen snapshot, so the run you inspect is the run that happened.

For the full list of every versioned entity in the system, see all first-class versioned entities in Modulo.