All first-class versioned entities in Modulo

One of the core principles of Modulo is that everything affecting a run's outcome is versioned, pinned, or snapshotted. If it changes the result, it is recorded. Here is the full list.

PipelineSnapshot

The entire run definition frozen at run-start. Every agent version, schema pin, connector binding, model backend pin, prompt version hash, and environment profile is captured in a single immutable snapshot. The run executes against this snapshot, not against whatever the current configuration is. This is what makes runs reproducible: pause for a week, resume, and the run behaves exactly the same.

Schema

Every input and output boundary in a pipeline is a typed contract defined by a JSON Schema. Schemas are org-scoped, versioned with semver, reusable, and composable. When a schema changes, existing runs are unaffected because they reference the schema version pinned in their snapshot. Schema inference can generate drafts from connector data.

Connector

Connectors are the bridge between Modulo and external systems - GitHub, GitLab, model providers, and anything with an API. Each connector instance is versioned, with its credential bindings and configuration pinned at run-start. A connector can be updated without affecting in-flight runs.

ModelBackend

Every agent in a pipeline references a model backend: the provider (OpenAI, Anthropic, etc.), the model ID, and the default parameters. Model backends are pinned at run-start, so swapping from GPT-4 to Claude does not change the behavior of a run that is already in progress.

Agent

Agents are defined by their prompt template, model binding, schema bindings, and connector type references. The agent definition is versioned through the pipeline snapshot - each run records exactly which agent configuration was used.

Prompt

Prompts are versioned and hash-pinned in snapshots. Editing a prompt creates a new version; existing runs continue using the version they started with. This means you can iterate on prompts without worrying about breaking in-flight pipelines.

EnvironmentProfile

Environment profiles define the environment variables and secret references available to a run. They are versioned and pinned at run-start, so a configuration change does not affect running pipelines.

AuditEvent

Every state-changing action produces an immutable audit event: actor, action, resource, timestamp. Audit events are append-only at the database level and linked in a SHA-256 chain for verifiability. There is no edit or delete for an audit event.

FeedbackRecord

When a gate catches a problem and spawns a correction run, the feedback record is immutable after creation. The original output stays as it was, and the correction is a new run with the feedback attached. This is what makes the correction loop trustworthy: you can always see what the original output was and what the gate caught.

Eval definition

Eval definitions specify the gate configuration: the check type (regex, JSON Schema, custom function, scored eval), the pass threshold, and the block-or-warn behavior. Eval definitions are versioned, so changing a gate's threshold does not affect runs that are already in progress.

Library primitive

Schemas, agents, and pipeline templates in the library are versioned with provenance tracking. When you copy a community primitive, the copy records its origin. Edits to the copy do not affect the original, and the provenance chain is preserved.

Pipeline definition

The pipeline graph itself - nodes, edges, and their configurations - is versioned through the snapshot mechanism. Each run records which version of the pipeline definition it executed against. You can diff two runs and see exactly what changed in the pipeline configuration between them.

Why this matters

Every entity on this list is versioned because every entity on this list can change a run's outcome. If any of them were mutable, you could not reproduce a run, audit a failure, or trust the history. The snapshot model is the foundation that makes governed automation possible.

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