# Coverage

Every vendor, how complete its twin is, and why it is built in that order.

The full table is generated: **[generated/INDEX.md](../../generated/INDEX.md)**, one row per
vendor, rebuilt by `bun scripts/index.ts` and drift-checked in the gate. This page says how to
read it.

## Where the list comes from

The catalog grows off a survey of the top 100 Node and top 100 Python application repositories
on GitHub: every external vendor any of them talks to, found from their dependencies, their env
names and their source. A vendor's **demand** is how many of those repositories need it. Twins
are built most-demanded first, so the order of the table is the build order, and the queue of
what to build next is derived from it, never hand-listed.

## The columns

| column | meaning |
|---|---|
| **vendor** | the vendor, and the twin package `@volter/twin-<vendor>` when one exists |
| **repos needing it** | demand: how many surveyed repositories need it, split Node / Python |
| **consumers** | products in this organization that use the twin today |
| **status** | the package's support status: Supported, Maintained, Odd Fixes, Orphan, Obsolete, or none when there is no twin yet |
| **completion** | the fraction of the vendor's own spec operations the twin serves, from the twin's census against the vendor's published spec. A twin without a spec source shows its operation count instead |
| **protocol** | the twin protocol major the package targets, and whether the platform serves it |
| **verified** | when the twin's census was last checked against a fresh copy of the vendor's spec |
| **what closes it** | what stands between the twin and a complete census: no spec source, grandfathered operations, never verified |

## Reading a percentage

Completion counts operations, not importance. A twin at 44% may serve every operation your app
uses; one at 90% may miss the one you need. Before relying on a twin, read its README: it lists
what it serves, what it does not serve yet, and what it models of the vendor's
behavior beyond the wire. An operation a twin does not serve fails the way the vendor would fail
it, never silently, so a gap is loud at the first call.

## Two kinds of complete

**Completeness** is the number above: how much of the vendor a twin covers. **Fidelity** is
whether what it covers is right, and is held by conformance against the vendor's spec and
recordings of the real vendor. A twin can be small and faithful. The percentage is the honest
answer to "how done", and a passing conformance suite is the honest answer to "how right";
neither stands in for the other. How fidelity is held is a contributor concern:
[conformance](../contributing/conformance.md).