Core objects
Provider
The root object: identity, coverage, capabilities, credentials.
ServiceCapability
One service, its price model and required credentials.
AvailabilitySlot
A bookable window. Server-authoritative, always.
BookingRequest / Confirmation
The transaction pair, with a human principal required.
ComplianceCredential
Machine-verifiable register references, honestly labelled.
ReviewAttestation
Portable review summaries with provenance.
Transport bindings
REST binding
Four endpoints, OpenAPI 3.1 description, canonical error codes.
MCP binding
Three tools mapping 1:1 onto the REST endpoints for tool-using assistants.
Normative language
MUST, MUST NOT, SHOULD and MAY are used per RFC 2119. Three rules are absolute in v0.1: slots are server-authoritative (agents propose, servers confirm); every booking carries a human principal (agent.on_behalf_of_human=true); and listings marked demo:true MUST NOT be booked.
Relationship to schema.org and retail agent protocols
Field names align with schema.org where a clean mapping exists (legal_name ↔ legalName). We diverge deliberately where local services need precision schema.org lacks: postcode-district coverage, VAT treatment on prices, statutory credential references, and hold semantics on slots. A mapping appendix in the REST binding shows how a UKLSP quote-and-book flow surfaces through a retail-style agent checkout, so operators can bridge into ACP/UCP-shaped experiences without forking this spec.
Versioning & extension
New service_code values, credential types and review sources are added by the governance process as data. Breaking field changes require a minor version and a migration note. Unknown fields MUST be ignored by readers, so implementers can trial extensions under x_ prefixes.