| Resource | What a version captures |
|---|---|
| Metrics | The scoring configuration (judge prompt, type-specific settings, manager). |
| Test sets | The test-set configuration and a snapshot of its test-case grid. |
| Personas | The persona prompt, voice, language, and behavioral metadata. |
| Agents | The connection and behavior configuration (model type, endpoint, prompt, workflows, attached metrics and test sets, and more). |
Copy-on-save
Each resource has a current version (its live state) and a history of prior versions, kept newest first. The history grows automatically as you work — you don’t create versions by hand:- Every config-changing save snapshots the prior state. When you save a change that affects how the resource behaves, Coval records the previous configuration as a version and advances the current version to your new state. The history is the trail of states the resource has moved through.
- Cosmetic and no-op edits don’t create a version. Only behavior-affecting configuration is versioned. Renaming a resource, editing its description, or re-saving without changing anything that matters leaves the history untouched — so the history stays meaningful and isn’t cluttered with edits that don’t change results.
- Existing resources start versioning on their next save. Resources that predate versioning pick up their first version the first time they’re saved or used in a run, with nothing to migrate.
Test sets version the grid, not just the config. A test set’s behavior is defined by its test cases, so a test-set version snapshots an ordered copy of its test cases along with the test-set configuration. The snapshot is taken when you save the test set — editing cells in the editor and then saving records one version for the batch, not one per cell. Re-saving without changing any test-case content creates no new version.
Reviewing version history
You can review a resource’s history in two places:- In the app — open the resource and view its version history, newest first, with who made each change and when.
-
Through the v1 API — call the resource’s
versionsendpoint to pull the full history programmatically:Each resource also exposes its live version inline as aResource Endpoint Metrics GET /v1/metrics/{metric_id}/versionsTest sets GET /v1/test-sets/{test_set_id}/versionsPersonas GET /v1/personas/{persona_id}/versionsAgents GET /v1/agents/{agent_id}/versionscurrent_versionfield on its API resource, so you can read the current version number without a second request. Built-in metrics carry no per-organization history and return an empty list.