The specification, in reading order

Six documents, Draft v0.1, published for public technical review — written to be handed to a dev team cold. A competent team should be able to add a compliant endpoint to an existing in-house system in days, without adopting anyone's stack.

The source of truth is the public repository: these pages render github.com/OpenYacht/protocol at every deploy. Accepted review changes amend the drafts in place, each carrying a note citing its source and date. Open questions are marked ⚠ inline; to respond, open a GitHub issue with the “Consultation response” form.

OpenYacht Federation Protocol

Identity, trust, keys, discovery, request signing. Start here.

spec/federation-protocol.md

Yacht Identity, Authority, and Provenance

Who owns a record: canonical URIs, authority, copies, provenance, usage terms.

spec/yacht-identity.md

Federation API

Endpoints, sync (updated_since + tombstones), subscriptions, errors.

spec/api-design.md

Listing Wire Schema

The field-by-field wire payload of a listing.

spec/listing-schema.md

Conformance Checklist

Every MUST, collected into one self-certification sheet.

spec/conformance-checklist.md

Request-Signing Test Vectors

Byte-exact test vectors for the request signing.

spec/signing-test-vectors.md

Machine-readable companions

The prose specification is normative. The JSON Schemas and the OpenAPI description are normative for JSON shape only; on any conflict the prose wins and the schema is defective. Schemas and registries live at permanent URLs and are meant to be vendored, never fetched at request time.

/schemas/v1/ — JSON Schemas (2020-12) for every wire payload · 6 files
/registry/builders.json — the fixed builder vocabulary · versioned like tzdata
/registry/categories.json — the shared category vocabulary
/registry/destinations.json — the charter destination vocabulary
/openapi/openyacht-v1.yaml — OpenAPI 3.1 description of the federation API