> ## Documentation Index > Fetch the complete documentation index at: https://www.composer.id/llms.txt > Use this file to discover all available pages before exploring further. # How carriers are proven > The five rungs of evidence behind each destination's Intent ID carrier, from a cited vendor page to a live tenant, and what each one proves. composerID publishes one value into many systems: the Intent ID, written into one field on the destination's own record, where it can be read back. That field is the **carrier**. This page explains how far each carrier is proven, and what each level of proof does and does not show. Read it before relying on a destination page's Carrier evidence row. Most destination vendors offer no free developer sandbox, so a carrier cannot always be proven by a live round trip. Each carrier is instead placed on a ladder, and every destination page states the rung it has reached, the vendor source it rests on, and the date that source was last checked. ## The ladder A page on the vendor's own site documents the field on that object, or documents API-writable custom fields on it. Third-party write-ups do not count. For a custom-field carrier the vendor proves the mechanism; the field's name is configured in the customer's tenant at onboarding. The vendor publishes a machine-readable API specification (OpenAPI or Swagger). The operations composerID calls are vendored into this repository, and on every push CI finds the carrier field on the write operation's request body and, where one is recorded, on the read operation's response. A vendor renaming or dropping the field fails the build when the specification is refreshed. A local fake of the destination, built from that specification, accepts a publish, stores the Intent ID in the carrier field, and returns it on a read or a filter. This proves composerID's own adapter end to end, offline. The same round trip has passed against the vendor's own developer sandbox, with the date and a reference recorded. The carrier is confirmed against a live customer tenant during onboarding. ## What the evidence covers Every rung below Tenant-proven is a claim about the vendor's published contract, not about a particular customer. Tenants add their own rules: mandatory fields, picklists, custom-field definitions and permissions. That is why every destination page says its carrier field is indicative until it is confirmed at onboarding, whatever rung it has reached. A destination is Carrier mapped only when at least the Cited rung holds. Where no vendor-owned source can be found, the destination is Documented instead: its API posture is recorded, but no carrier is claimed. ## Keeping it current The registry records each carrier's evidence with its source URL and the date it was read. A monthly docs watch fetches every cited vendor page and reports any that changed or stopped resolving, and the vendored specifications are refreshed deliberately, so a change in a vendor's contract arrives as a reviewed commit. ## Next steps Every destination with its coverage status and its evidence rung. Plan, preflight and publish: how the carrier gets written. The ways composerID reaches a destination, and how to read a destination page.