Coverage
Use coverage to decide whether a twin can exercise the vendor operations your app needs. The catalog groups implementations by vendor, package and publisher. Each release's README describes its supported operations and limitations; its assessment describes what was measured. Choose a twin walks through the decision.
Detection is not operation coverage
volter world init detects vendors from the app's dependencies and env names, then reports which
have an available implementation. A vendor being covered by a World does not mean every API
operation is supported or that your app's tests exercise it. Review the selection before keeping it.
Read each measurement by its scope
| Measurement | What it says | What it does not establish |
|---|---|---|
| Declared HTTP surface | Instrumented HTTP operations served, gaps and total operations | Separate command tables, other protocols or correctness for every argument or state |
| Exercised HTTP operation coverage | HTTP operations called by the recorded journeys, against their declared denominator | Coverage of your application's tests or unmeasured protocols |
| Deterministic replay | Whether those runs had equal results under their recorded conditions | Real-vendor parity or every possible execution |
| Chromium journey replay | HTTP operations exercised through the report's stated Chromium transport and response observation | Application-origin CORS, native cookie handling, DOM, UI or source-code coverage unless separately measured |
| Conformance results | Results of the named checks in the report | Behavior outside those checks |
| Not measured | No recorded measurement is available | A pass, a failure or zero coverage |
Keep the operation names and conditions alongside any percentage. Supported surface and exercised coverage have different meanings. A trusted publisher or admitted release is not a complete fidelity guarantee, and another implementation's larger version number is not a coverage ranking.
An HTTP customer journey can cross vendor hosts and name different actors' headers. The catalog's per-origin Chromium replay retains those authored headers and observes HTTP responses, including redirect and cookie headers. It does not claim that JavaScript running at your app's origin can read those responses, or that a browser's native cookie jar supplies the same actor. Read each report's scope and its fields marked “Not measured.”
Check the application's behavior
Run the actual SDK calls your workflow makes, through volter world run. Assert on responses,
read-after-write state, errors and callbacks relevant to your app. Seed stored data through the
vendor's API; script stateless answers and faults with handlers. Freeze the World clock when
timestamps matter and repeat from the same starting state.
Generative vendors return labeled stubs or scripted answers in simulation. Those calls can check tools, usage and state effects; they cannot establish the quality of a real model's prose. Run your test suite and shape the World for a test show application assertions and scenarios.
When an operation is missing
An unsupported operation fails with the vendor's unknown-request response. Do not invent a
successful mutation in a handler or interpret a refused route as proof of an app bug. Check the
selected package/version, its README, /twin manifest and the request your app made. Report the
gap to the publisher with a reproducible SDK call and synthetic data.
Catalog snapshots, recommendations and installed World pins are distinct. See update a twin before changing an existing application.