---
title: "Fidelity contract"
description: "Every replica should publish a versioned manifest that labels each operation verified, modeled, or unsupported."
canonical: "https://agenttwin.si/docs/fidelity/"
---

# Fidelity contract

Every replica should publish a versioned manifest that labels each operation verified, modeled, or unsupported.


<Info>These concepts describe the broader product contract. The current runtime uses explicit fixtures, supported operation mappings and reprovisioning. Automatic shared-identity compilation, coordinated snapshots and comprehensive provider conformance are not shipped. See [current capabilities](/status).</Info>

A twin that silently diverges from production can create false confidence. A replica should publish a **versioned manifest** that declares its limits, and every operation needs one of three labels.

<CardGroup cols={3}>
  <Card title="Verified" icon="lucide:badge-check">
    Behavior compared against a real provider's allowed test environment.
  </Card>
  <Card title="Modeled" icon="lucide:ruler">
    Behavior implemented from documentation or observed examples, with assumptions visible.
  </Card>
  <Card title="Unsupported" icon="lucide:circle-slash">
    Behavior unknown or outside the scenario. Tests must not silently pass through it.
  </Card>
</CardGroup>

## What the manifest records

- **Provider version** the twin was built against.
- **Fixture source** for starting state and seed data.
- **Last verification date** — when the behavior was last compared with reality.
- **Configuration fields** that were captured, and which were not.
- **State boundaries** — what the replica covers and where it ends.
- **Known differences** from the real provider.

## Evidence, not just a response

A passing response cannot hide a bad write. Every run should show:

1. **A trace** of provider calls and state transitions, in causal order.
2. **A before/after state diff** across the systems involved.
3. **Assertions against final state and invariants**, not only the agent's explanation of what it did.

<Info>
  The current runtime records operation coverage, source digests, service events and final-state assertions. Custom HTTP collections and the Slack subset have explicit limits; passing their checks does not establish full provider conformance. PostgreSQL and Redis run as real services in the hosted world.
</Info>

<Card title="How safety follows from fidelity" icon="lucide:shield-check" href="/safety">
  Isolated credentials, sanitized records, and disposable execution.
</Card>