Skip to main content
DecimalAI’s core innovation is version-aware data management. This page explains how agent versions are tracked and what happens when they change.

​
How Versions Are Tracked

​
Manifest

A manifest is a snapshot of your agent’s full configuration at a point in time: which tools, models, prompts, skills, and sub-agents it uses. Manifests can be:
  • Auto-detected — extracted from incoming traces (zero config)
  • Manually registered — explicitly declared via the SDK or API (highest fidelity)
→ See Manifests & Versioning for the full guide.
Manifest vs Version: A manifest is the data (the full snapshot). A version is the label (v1, v2, v3). Each agent has many manifests over time; each manifest has a unique version label. Version labels are NOT semantic versions (major.minor.patch) — they simply auto-increment.

​
Component

A component is a single versioned piece within a manifest. Each component has a type, name, and content hash:

​
Surface

A surface is one independently-versioned policy-grouping of the manifest — a slice you can write its own compatibility rules for. Components are bucketed into surfaces so that, for example, a breaking tool change can replay while a guardrail change merely gets flagged. There are 10 surfaces: Each surface carries its own on_minor / on_moderate / on_major action under the agent’s compatibility policy — see the matrix below.

​
Component Verdict

When the engine diffs a single component across old and new manifests, it assigns one of four per-component outcomes. (This is distinct from the per-trace Compatibility Verdict of keep/repair/replay/drop.)

​
Manifest Hash

A SHA-256 fingerprint of the manifest’s structural components (tools + models). Two manifests with the same hash for the same agent are considered identical — the second registration is idempotent. Prompt changes alone do NOT change the hash — they’re tracked separately via content hashing for drift detection.

​
Manifest Status

​
Revert

When a trace arrives with a manifest hash matching a previously superseded manifest, DecimalAI detects this as a rollback. It re-activates the old manifest and supersedes the current one — no duplicate is created. Your version history stays clean.

​
Compatibility Engine

When a manifest changes, the compatibility engine classifies every existing trace to determine if it’s still usable. This is what makes DecimalAI’s training data lifecycle possible.

​
How Compatibility Works

​
Compatibility Verdict

The per-trace outcome of a compatibility analysis:

​
Severity

When comparing a component between old and new manifests, the engine assigns a severity: Severity is then mapped to a verdict through the agent’s compatibility policy (strict / default / permissive).

​
Severity × Policy Matrix

Each surface has its own rules, but the shape is the same across presets. Here is the tool_registry surface — for each component severity, the action each preset takes: The five possible actions are keep, repair, flag, replay, and drop. A severity of none always maps to keep (nothing changed). Other surfaces shift the actions — guardrails, context_config, and environment are softer (a major change only flags under default), while prompt_stack and model_runtime are stricter. → See Compatibility Policies for policy configuration.
The manifest, the diff, and the compatibility-decision format are all defined by agentversion — the open spec the platform is built on. You can produce the same manifests and verdicts outside DecimalAI with the agentversion package on PyPI.

​
Next

Evaluation

The decision engine combines quality + compatibility into one verdict.

Manifests Guide

Hands-on guide to manifest detection and the impact report.