Bookable Pattern

The base pattern for anything an AI agent can discover, trust, and transact with.


Bookable is not a protocol—it's a pattern that domain-specific extensions inherit from. Think of it as the DNA that all bookable entities share.

The Problem

1. Determine Fit

Does this entity match what the user actually wants? Not just availability—true alignment with intent.

2. Defend the Choice

Can the agent explain why it recommended this? With citations, not vibes.

3. Complete the Transaction

Can it actually make the booking? With proper authentication and error handling.

Traditional APIs give agents data. Bookable gives agents understanding.


The Six Blocks

Every Bookable record is built from six interconnected blocks:

Identity

Verifiable existence. Who is this entity, where are they, and can we cryptographically prove they control this record?

{
  "identity": {
    "name": "The Griffin Inn",
    "location": {
      "address": "Beacon Vale, Beaconshire LD3 0UB",
      "coordinates": [51.9634, -3.3842]
    },
    "domain": "griffininn.co.uk",
    "did": "did:web:griffininn.co.uk"
  }
}

Evidence

Proof supporting claims. Every assertion links to sources with confidence scores and verification status. No more "trust me, it's dog-friendly".

{
  "evidence": {
    "dogFriendly": {
      "claim": "Dogs welcome in all areas including restaurant",
      "confidence": 0.95,
      "convergence": "strong",
      "sources": [
        { "type": "human_observation", "sourceRef": "DMO site visit Oct 2024" },
        { "type": "curator_certification", "sourceRef": "Visit Beaconshire credential" }
      ]
    }
  }
}

Fit

Explicit intent alignment. What the entity is good for—and critically, what it's not good for.

{
  "fit": {
    "strong": [
      { "intent": "romantic getaway", "confidence": 0.95 }
    ],
    "weak": [
      { "intent": "family with young children", "reason": "Adult-focused atmosphere" }
    ]
  }
}

Actions

What operations can an agent perform? Check availability, get rates, book, modify, cancel.

{
  "actions": {
    "capabilities": ["check-availability", "get-rates", "book", "modify", "cancel"],
    "endpoint": "https://example.com/api/agent",
    "protocol": "jsonrpc"
  }
}

Presentation

UI components for human confirmation. Agents choose, humans confirm.

{
  "presentation": {
    "components": {
      "summary": { "type": "card", "template": { ... } },
      "gallery": { "type": "image-grid", "template": { ... } }
    },
    "layouts": {
      "detail": ["gallery", "summary"]
    }
  }
}

Answers

Pre-computed responses to common questions, linked to evidence for citation.

{
  "answers": [
    {
      "question": "Is this place dog friendly?",
      "answer": "Yes, dogs welcome in all areas including the restaurant.",
      "confidence": 0.98,
      "basedOn": ["evidence.dogFriendly"]
    }
  ]
}

Why Evidence Matters

Traditional Approach

Hotel says "dog-friendly". Agent trusts it. Guest arrives with dog to find they're only allowed in one annexe room and banned from the restaurant.

Result: Frustrated guest, complaint, refund request.

Evidence-Based Approach

Evidence block shows DMO site visit confirming dogs welcome throughout, Visit Beaconshire accessibility credential, and photos of water bowls in the bar.

Result: Agent can cite verifiable sources. Reality matches the claim.

Now the agent can say: "I recommend The Griffin because Visit Beaconshire verified dogs are welcome in all areas during their October inspection, and the DMO confirmed water bowls are provided in the restaurant"—not just "it says it's dog-friendly".


Declaring Weak Fit

Most systems only describe what they're good at. Bookable encourages entities to declare what they're not good for.

This is counterintuitive but powerful:

Prevents Bad Matches

A romantic adults-only hotel shouldn't be recommended for a family trip—even if it has availability.

Reduces Friction

No more book-then-complain-then-refund cycles. Set expectations upfront.

Builds Trust

Honesty about limitations signals integrity. Guests trust venues that are upfront.


Extensions

Bookable is the base. Extensions add domain-specific vocabulary:

ExtensionDomainWhat It Adds
VenuePhysical locationsFacilities, vibe, neighbourhood context
StayBooking lifecycleStates, transitions, holds, cancellations
FolioFinancial recordsCharges, payments, refunds
CuratorAggregatorsCuration, distribution, attribution

An agent can interact with any extension as a Bookable without knowing its specific type. The base pattern is universal.


Type Hierarchy

Bookable (base)
└── Venue (hospitality)
    ├── Hotel, BnB, Hostel
    ├── Restaurant, Cafe, Bar
    ├── Museum, Tour, Activity
    └── Spa, Salon

Stay, Folio, and Curator are complementary specs—not venue types. Stay tracks the booking lifecycle, Folio handles payments, Curator manages aggregation.


Specification

Full technical specification with schemas, requirements, and conformance rules.

Venue Examples

See Bookable in practice through complete Venue records.