{
  "schemaVersion": "1.0",
  "title": "Create and manage a Cal.diy booking",
  "description": "Use this guide to create one booking through slot discovery, an immutable plan, trusted approval, a single commit attempt, and durable verification. It then shows how to choose a safe follow-up operation without replaying an uncertain provi",
  "canonical": "https://getaip.org/docs/connectors/cal-diy/guides/create-and-manage-a-booking",
  "route": "/docs/connectors/cal-diy/guides/create-and-manage-a-booking",
  "source": "docs/connectors/cal-diy/guides/create-and-manage-a-booking.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Connectors",
  "documentType": "Connector",
  "language": "en",
  "downloads": {
    "md": "/docs/download/connectors/cal-diy/guides/create-and-manage-a-booking.md",
    "txt": "/docs/download/connectors/cal-diy/guides/create-and-manage-a-booking.txt",
    "json": "/docs/download/connectors/cal-diy/guides/create-and-manage-a-booking.json",
    "pdf": "/docs/download/connectors/cal-diy/guides/create-and-manage-a-booking.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: Create and manage a Cal.diy booking\ndescription: Plan, approve, commit, verify, and safely change one booking\nkind: how-to\naudience: application-developer\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"97be86e9efedf07ecf1783b03800f683f107fb04\"\nconnector: cal-diy\n---\n\n# Create and manage a Cal.diy booking\n\nUse this guide to create one booking through slot discovery, an immutable plan,\ntrusted approval, a single commit attempt, and durable verification. It then\nshows how to choose a safe follow-up operation without replaying an uncertain\nprovider mutation.\n\nThis guide uses the `eventTypeId` branch and no custom duration. Use the\ncapability reference when you need slug, team, recurrence, seating, routing,\nphone-only attendee, or custom-location input.\n\n## Prerequisites\n\nYou need:\n\n- an admitted and healthy Cal.diy connector for the intended tenant;\n- a native AIP endpoint and bearer token already bound to that tenant;\n- a caller authorized to discover and invoke Cal.diy capabilities;\n- a trusted approval process for tenant-policy decisions;\n- a known Cal.diy event-type id;\n- a durable place to retain action, transaction, plan, approval, idempotency,\n  and provider-operation identifiers.\n\nSet client coordinates without putting provider credentials in the shell:\n\n```sh\nexport AIP_URL='https://aip.example.com'\nexport AIP_TOKEN_FILE='/run/secrets/aip-native-token'\nexport EVENT_TYPE_ID='42'\n```\n\nThe deployment resolves tenant, account, connector route, and provider\ncredential from authenticated context. Do not add them to booking input.\n\n## 1. Confirm the admitted contracts\n\nInspect the two capabilities used before any mutation:\n\n```sh\naipctl \\\n  --native-bearer-token-file \"$AIP_TOKEN_FILE\" \\\n  capability list \"$AIP_URL\" \\\n  --capability-id cap:cal_diy:slot.list \\\n  --limit 1\n\naipctl \\\n  --native-bearer-token-file \"$AIP_TOKEN_FILE\" \\\n  capability list \"$AIP_URL\" \\\n  --capability-id cap:cal_diy:booking.create \\\n  --limit 1\n```\n\nRecord the catalog revision plus each contract and schema digest. Confirm that\n`booking.create` is medium risk, approval-required, requires external-account\nidempotency, and requires plan before commit.\n\nCatalog visibility proves admission at one revision. It does not prove that a\nconnector replica or Cal.diy account is currently reachable.\n\n## 2. Discover a bounded slot\n\nChoose a future interval and write `slot-query.json`:\n\n```json\n{\n  \"start\": \"2030-01-03\",\n  \"end\": \"2030-01-04\",\n  \"eventTypeId\": 42,\n  \"timeZone\": \"Europe/London\",\n  \"format\": \"time\"\n}\n```\n\nSubmit a low-risk read with a stable action id:\n\n```sh\nexport SLOT_ACTION_ID='act_cal_booking_slots_001'\n\naipctl \\\n  --native-bearer-token-file \"$AIP_TOKEN_FILE\" \\\n  action call \"$AIP_URL\" \\\n  cap:cal_diy:slot.list \\\n  --action-id \"$SLOT_ACTION_ID\" \\\n  --mode sync \\\n  --input @slot-query.json\n```\n\nChoose an exact date-time from the provider result. In the remaining examples,\nthe chosen start is `2030-01-03T10:00:00Z`.\n\nA slot result is an observation, not a hold. If the workflow needs a temporary\nprovider reservation, use the separate reservation lifecycle and preserve its\nopaque uid. Booking create does not consume a reservation uid in its published\ninput.\n\n## 3. Freeze one booking input\n\nWrite `booking-create.json` once:\n\n```json\n{\n  \"start\": \"2030-01-03T10:00:00Z\",\n  \"eventTypeId\": 42,\n  \"attendee\": {\n    \"name\": \"Avery Patel\",\n    \"email\": \"avery@example.com\",\n    \"timeZone\": \"Europe/London\"\n  }\n}\n```\n\nKeep this file byte-stable for the plan and commit. The runtime binds the\ncapability and canonical input hash, not the filename. Reformatting equivalent\nJSON is normally canonicalized, but changing any semantic value requires a new\nplan and a newly reviewed commit.\n\nReserve stable identifiers and keep them together:\n\n```sh\nexport PLAN_ACTION_ID='act_cal_booking_plan_001'\nexport COMMIT_ACTION_ID='act_cal_booking_commit_001'\nexport TRANSACTION_ID='txn_cal_booking_001'\nexport BOOKING_KEY='cal-booking-001'\n```\n\nNever reuse `BOOKING_KEY` with different canonical input or another external\naccount.\n\n## 4. Create the downstream plan\n\nSubmit the plan action:\n\n```sh\naipctl \\\n  --native-bearer-token-file \"$AIP_TOKEN_FILE\" \\\n  action call \"$AIP_URL\" \\\n  cap:cal_diy:booking.create \\\n  --action-id \"$PLAN_ACTION_ID\" \\\n  --idempotency-key \"$BOOKING_KEY\" \\\n  --transaction-mode plan \\\n  --transaction-id \"$TRANSACTION_ID\" \\\n  --input @booking-create.json\n```\n\nA successful result has validation class `downstream_slot_availability` and\nrecords `side_effect_committed: false`. It checks that the exact requested\nstart appears in a one-day slot query. It does not reserve the slot.\n\nRead the durable transaction and copy the returned plan id exactly:\n\n```sh\naipctl \\\n  --native-bearer-token-file \"$AIP_TOKEN_FILE\" \\\n  transaction get \"$AIP_URL\" \\\n  --transaction-id \"$TRANSACTION_ID\" \\\n  --include-result \\\n  --include-receipts\n\nexport PLAN_ID='paste-the-returned-plan-id'\n```\n\nDo not infer a plan id from the transaction id. The implementation-generated\nplan expires after 15 minutes.\n\n### Understand the reviewed plan limit\n\nThe connector's create planner forwards an id selector and the requested start,\nbut it does not forward `teamSlug`, `lengthInMinutes`, or nested\n`attendee.timeZone` into its slot probe. This guide avoids the first two fields;\nthe attendee time zone remains required booking input but is not part of the\nreviewed provider slot query.\n\nTreat the plan as an exact-start observation, not full validation of team,\ncustom duration, time-zone interpretation, attendee details, or provider\nacceptance.\n\n## 5. Submit the matching commit\n\nUse a distinct commit action id, the same capability and input, the original\ntransaction and idempotency key, and the returned plan id:\n\n```sh\naipctl \\\n  --native-bearer-token-file \"$AIP_TOKEN_FILE\" \\\n  action call \"$AIP_URL\" \\\n  cap:cal_diy:booking.create \\\n  --action-id \"$COMMIT_ACTION_ID\" \\\n  --idempotency-key \"$BOOKING_KEY\" \\\n  --transaction-mode commit \\\n  --transaction-id \"$TRANSACTION_ID\" \\\n  --plan-id \"$PLAN_ID\" \\\n  --input @booking-create.json\n```\n\nThe public commit path requires `plan_id`. The runtime rechecks the capability,\ninput hash, planning principal, tenant and external account, transaction id,\nand plan expiry before it can claim the plan.\n\nWithout an admitted approval decision, the commit action enters\n`requires_human`. Store the returned approval id and leave the commit action in\nplace. Do not submit a replacement commit.\n\n## 6. Complete trusted approval\n\nUse the deployment's approver-facing process to inspect the frozen request and\nsubmit a decision from an authenticated principal with tenant-policy authority.\nThe decision needs the request's policy hash and required reason, input\nsnapshot, and policy-decision evidence.\n\nThe Cal.diy approval validity window is 900,000 ms. The plan also expires after\n15 minutes. If either boundary closes before commit ownership is claimed, stop\nand create a new plan for the current intent. Do not weaken policy or reuse an\nexpired authorization.\n\nApproval resumes the same queued commit. It does not authorize a second action,\nprove that the plan is still valid, or prove that Cal.diy accepted the booking.\n\n## 7. Wait for the durable result\n\nRead the original commit action independently of its submission connection:\n\n```sh\naipctl \\\n  --native-bearer-token-file \"$AIP_TOKEN_FILE\" \\\n  action status \"$AIP_URL\" \\\n  \"$COMMIT_ACTION_ID\" \\\n  --include-result \\\n  --include-receipts \\\n  --wait-ms 30000\n```\n\nProceed only after a terminal `completed` result. Retain the provider request\nid and provider operation id when present. The common connector output requires\n`status`, but it does not guarantee a booking-id field. Validate a non-empty\nprovider booking uid from the actual response contract before continuing.\n\nIf the uid is absent, stop and treat the result as provider-contract drift. Do\nnot derive a uid from the AIP action id, transaction id, or idempotency key.\n\n## 8. Verify by reading the booking\n\nWrite `booking-get.json` with the validated provider uid:\n\n```json\n{\n  \"booking_uid\": \"booking-provider-uid\"\n}\n```\n\nRead it under a new action id:\n\n```sh\nexport VERIFY_ACTION_ID='act_cal_booking_verify_001'\n\naipctl \\\n  --native-bearer-token-file \"$AIP_TOKEN_FILE\" \\\n  action call \"$AIP_URL\" \\\n  cap:cal_diy:booking.get \\\n  --action-id \"$VERIFY_ACTION_ID\" \\\n  --mode sync \\\n  --input @booking-get.json\n```\n\nCompare only the intended start, event type, attendee, and status fields exposed\nby the provider response. Keep the complete input, output, approval evidence,\nand receipts under restricted PII controls.\n\nA completed create and matching read still do not prove that every calendar or\nnotification was delivered.\n\n## 9. Choose a follow-up operation\n\nUse the provider booking uid and select the smallest operation that matches the\nnew intent:\n\n| Intent | Capability | New plan required | Important boundary |\n|---|---|---|---|\n| Read current state | `booking.get` | No | Retry-safe read |\n| Move the start | `booking.reschedule` | Yes | New exact-start plan and approval |\n| Cancel | `booking.cancel` | Yes | Destructive; no rollback |\n| Confirm pending booking | `booking.confirm` | No | Approval and stable mutation key |\n| Decline pending booking | `booking.decline` | No | Destructive and approval-required |\n| Change location | `booking.location.update` | No | Read preflight; no empty update |\n| Add attendee or guests | `booking.attendee.add`, `booking.guest.add` | No | May affect calendars or notifications |\n| Remove attendee | `booking.attendee.delete` | No | Destructive; no compensation |\n| Change absence or owner | `booking.mark_absent`, `booking.reassign` | No | High risk and approval-required |\n\nEvery mutation needs a new action id and a stable idempotency key scoped to that\nexact intent. Reschedule and cancel need their own current plan; the create plan\ncannot authorize either change.\n\nDo not use the create capability's compensation declaration as ordinary\ncancellation. Compensation is a new, approval-required best-effort action\nagainst the original create and has a 24-hour contract window. It is neither\nautomatic nor atomic.\n\n## Recover without replaying a mutation\n\n| Observation | Response |\n|---|---|\n| `connector.cal_diy.slot_unavailable` during plan | Choose a current start and create a new plan |\n| Plan expired or input hash changed | Create a new plan; do not alter the old commit |\n| Commit is `requires_human` | Complete the existing approval workflow |\n| Commit is pending or in flight | Read the same action and transaction; wait |\n| `connector.cal_diy.idempotency_collision` | Stop; the key already owns different input |\n| `connector.cal_diy.outcome_unknown` or ambiguous transport failure | Reconcile the original provider operation |\n| Definitive provider rejection with no uncertain outcome | Correct the cause and begin a new governed intent |\n\nThe CLI at this revision does not expose transaction mode `reconcile`, even\nthough the protocol and runtime define it. Use the deployment's authorized\nreconciliation integration and retain the original action, transaction,\nidempotency, and provider-operation identities. Never replace the key to force\nanother provider call.\n\n## Verify the complete workflow\n\nBefore treating the task as complete, confirm that you retained:\n\n- the catalog revision plus contract and schema digests;\n- slot-read action and exact selected start;\n- immutable booking input and its hash;\n- plan action, plan id, transaction id, and expiry;\n- approval id, policy hash, authority evidence, and terminal decision;\n- commit action, original idempotency key, durable result, and receipts;\n- provider request and operation ids when present;\n- validated provider booking uid and the follow-up read.\n\nThis evidence demonstrates one governed application workflow. It does not by\nitself establish live-provider qualification, notification delivery, calendar\ndelivery, availability guarantees, or production readiness.\n\n## Related documentation\n\n- [Booking capability reference](../capabilities/bookings.md)\n- [Slots and reservations](../capabilities/slots-and-reservations.md)\n- [Approvals and policy](../../../concepts/approvals-and-policy.md)\n- [Transactions and compensation](../../../concepts/transactions-and-compensation.md)\n- [Observe and recover](../../../guides/observe-and-recover.md)\n",
    "text": "Create and manage a Cal.diy booking\n\nUse this guide to create one booking through slot discovery, an immutable plan,\ntrusted approval, a single commit attempt, and durable verification. It then\nshows how to choose a safe follow-up operation without replaying an uncertain\nprovider mutation.\n\nThis guide uses the eventTypeId branch and no custom duration. Use the\ncapability reference when you need slug, team, recurrence, seating, routing,\nphone-only attendee, or custom-location input.\n\nPrerequisites\n\nYou need:\n• an admitted and healthy Cal.diy connector for the intended tenant;\n• a native AIP endpoint and bearer token already bound to that tenant;\n• a caller authorized to discover and invoke Cal.diy capabilities;\n• a trusted approval process for tenant-policy decisions;\n• a known Cal.diy event-type id;\n• a durable place to retain action, transaction, plan, approval, idempotency,\n  and provider-operation identifiers.\n\nSet client coordinates without putting provider credentials in the shell:\n\nexport AIPURL='https://aip.example.com'\nexport AIPTOKENFILE='/run/secrets/aip-native-token'\nexport EVENTTYPEID='42'\n\nThe deployment resolves tenant, account, connector route, and provider\ncredential from authenticated context. Do not add them to booking input.\n1. Confirm the admitted contracts\n\nInspect the two capabilities used before any mutation:\n\naipctl \\\n  --native-bearer-token-file \"$AIPTOKENFILE\" \\\n  capability list \"$AIPURL\" \\\n  --capability-id cap:caldiy:slot.list \\\n  --limit 1\n\naipctl \\\n  --native-bearer-token-file \"$AIPTOKENFILE\" \\\n  capability list \"$AIPURL\" \\\n  --capability-id cap:caldiy:booking.create \\\n  --limit 1\n\nRecord the catalog revision plus each contract and schema digest. Confirm that\nbooking.create is medium risk, approval-required, requires external-account\nidempotency, and requires plan before commit.\n\nCatalog visibility proves admission at one revision. It does not prove that a\nconnector replica or Cal.diy account is currently reachable.\n2. Discover a bounded slot\n\nChoose a future interval and write slot-query.json:\n\n{\n  \"start\": \"2030-01-03\",\n  \"end\": \"2030-01-04\",\n  \"eventTypeId\": 42,\n  \"timeZone\": \"Europe/London\",\n  \"format\": \"time\"\n}\n\nSubmit a low-risk read with a stable action id:\n\nexport SLOTACTIONID='actcalbookingslots001'\n\naipctl \\\n  --native-bearer-token-file \"$AIPTOKENFILE\" \\\n  action call \"$AIPURL\" \\\n  cap:caldiy:slot.list \\\n  --action-id \"$SLOTACTIONID\" \\\n  --mode sync \\\n  --input @slot-query.json\n\nChoose an exact date-time from the provider result. In the remaining examples,\nthe chosen start is 2030-01-03T10:00:00Z.\n\nA slot result is an observation, not a hold. If the workflow needs a temporary\nprovider reservation, use the separate reservation lifecycle and preserve its\nopaque uid. Booking create does not consume a reservation uid in its published\ninput.\n3. Freeze one booking input\n\nWrite booking-create.json once:\n\n{\n  \"start\": \"2030-01-03T10:00:00Z\",\n  \"eventTypeId\": 42,\n  \"attendee\": {\n    \"name\": \"Avery Patel\",\n    \"email\": \"avery@example.com\",\n    \"timeZone\": \"Europe/London\"\n  }\n}\n\nKeep this file byte-stable for the plan and commit. The runtime binds the\ncapability and canonical input hash, not the filename. Reformatting equivalent\nJSON is normally canonicalized, but changing any semantic value requires a new\nplan and a newly reviewed commit.\n\nReserve stable identifiers and keep them together:\n\nexport PLANACTIONID='actcalbookingplan001'\nexport COMMITACTIONID='actcalbookingcommit001'\nexport TRANSACTIONID='txncalbooking001'\nexport BOOKINGKEY='cal-booking-001'\n\nNever reuse BOOKINGKEY with different canonical input or another external\naccount.\n4. Create the downstream plan\n\nSubmit the plan action:\n\naipctl \\\n  --native-bearer-token-file \"$AIPTOKENFILE\" \\\n  action call \"$AIPURL\" \\\n  cap:caldiy:booking.create \\\n  --action-id \"$PLANACTIONID\" \\\n  --idempotency-key \"$BOOKINGKEY\" \\\n  --transaction-mode plan \\\n  --transaction-id \"$TRANSACTIONID\" \\\n  --input @booking-create.json\n\nA successful result has validation class downstreamslotavailability and\nrecords sideeffectcommitted: false. It checks that the exact requested\nstart appears in a one-day slot query. It does not reserve the slot.\n\nRead the durable transaction and copy the returned plan id exactly:\n\naipctl \\\n  --native-bearer-token-file \"$AIPTOKENFILE\" \\\n  transaction get \"$AIPURL\" \\\n  --transaction-id \"$TRANSACTIONID\" \\\n  --include-result \\\n  --include-receipts\n\nexport PLANID='paste-the-returned-plan-id'\n\nDo not infer a plan id from the transaction id. The implementation-generated\nplan expires after 15 minutes.\n\nUnderstand the reviewed plan limit\n\nThe connector's create planner forwards an id selector and the requested start,\nbut it does not forward teamSlug, lengthInMinutes, or nested\nattendee.timeZone into its slot probe. This guide avoids the first two fields;\nthe attendee time zone remains required booking input but is not part of the\nreviewed provider slot query.\n\nTreat the plan as an exact-start observation, not full validation of team,\ncustom duration, time-zone interpretation, attendee details, or provider\nacceptance.\n5. Submit the matching commit\n\nUse a distinct commit action id, the same capability and input, the original\ntransaction and idempotency key, and the returned plan id:\n\naipctl \\\n  --native-bearer-token-file \"$AIPTOKENFILE\" \\\n  action call \"$AIPURL\" \\\n  cap:caldiy:booking.create \\\n  --action-id \"$COMMITACTIONID\" \\\n  --idempotency-key \"$BOOKINGKEY\" \\\n  --transaction-mode commit \\\n  --transaction-id \"$TRANSACTIONID\" \\\n  --plan-id \"$PLANID\" \\\n  --input @booking-create.json\n\nThe public commit path requires planid. The runtime rechecks the capability,\ninput hash, planning principal, tenant and external account, transaction id,\nand plan expiry before it can claim the plan.\n\nWithout an admitted approval decision, the commit action enters\nrequireshuman. Store the returned approval id and leave the commit action in\nplace. Do not submit a replacement commit.\n6. Complete trusted approval\n\nUse the deployment's approver-facing process to inspect the frozen request and\nsubmit a decision from an authenticated principal with tenant-policy authority.\nThe decision needs the request's policy hash and required reason, input\nsnapshot, and policy-decision evidence.\n\nThe Cal.diy approval validity window is 900,000 ms. The plan also expires after\n15 minutes. If either boundary closes before commit ownership is claimed, stop\nand create a new plan for the current intent. Do not weaken policy or reuse an\nexpired authorization.\n\nApproval resumes the same queued commit. It does not authorize a second action,\nprove that the plan is still valid, or prove that Cal.diy accepted the booking.\n7. Wait for the durable result\n\nRead the original commit action independently of its submission connection:\n\naipctl \\\n  --native-bearer-token-file \"$AIPTOKENFILE\" \\\n  action status \"$AIPURL\" \\\n  \"$COMMITACTIONID\" \\\n  --include-result \\\n  --include-receipts \\\n  --wait-ms 30000\n\nProceed only after a terminal completed result. Retain the provider request\nid and provider operation id when present. The common connector output requires\nstatus, but it does not guarantee a booking-id field. Validate a non-empty\nprovider booking uid from the actual response contract before continuing.\n\nIf the uid is absent, stop and treat the result as provider-contract drift. Do\nnot derive a uid from the AIP action id, transaction id, or idempotency key.\n8. Verify by reading the booking\n\nWrite booking-get.json with the validated provider uid:\n\n{\n  \"bookinguid\": \"booking-provider-uid\"\n}\n\nRead it under a new action id:\n\nexport VERIFYACTIONID='actcalbookingverify001'\n\naipctl \\\n  --native-bearer-token-file \"$AIPTOKENFILE\" \\\n  action call \"$AIPURL\" \\\n  cap:caldiy:booking.get \\\n  --action-id \"$VERIFYACTIONID\" \\\n  --mode sync \\\n  --input @booking-get.json\n\nCompare only the intended start, event type, attendee, and status fields exposed\nby the provider response. Keep the complete input, output, approval evidence,\nand receipts under restricted PII controls.\n\nA completed create and matching read still do not prove that every calendar or\nnotification was delivered.\n9. Choose a follow-up operation\n\nUse the provider booking uid and select the smallest operation that matches the\nnew intent:\n\n| Intent | Capability | New plan required | Important boundary |\n\n| Read current state | booking.get | No | Retry-safe read |\n| Move the start | booking.reschedule | Yes | New exact-start plan and approval |\n| Cancel | booking.cancel | Yes | Destructive; no rollback |\n| Confirm pending booking | booking.confirm | No | Approval and stable mutation key |\n| Decline pending booking | booking.decline | No | Destructive and approval-required |\n| Change location | booking.location.update | No | Read preflight; no empty update |\n| Add attendee or guests | booking.attendee.add, booking.guest.add | No | May affect calendars or notifications |\n| Remove attendee | booking.attendee.delete | No | Destructive; no compensation |\n| Change absence or owner | booking.markabsent, booking.reassign | No | High risk and approval-required |\n\nEvery mutation needs a new action id and a stable idempotency key scoped to that\nexact intent. Reschedule and cancel need their own current plan; the create plan\ncannot authorize either change.\n\nDo not use the create capability's compensation declaration as ordinary\ncancellation. Compensation is a new, approval-required best-effort action\nagainst the original create and has a 24-hour contract window. It is neither\nautomatic nor atomic.\n\nRecover without replaying a mutation\n\n| Observation | Response |\n\n| connector.caldiy.slotunavailable during plan | Choose a current start and create a new plan |\n| Plan expired or input hash changed | Create a new plan; do not alter the old commit |\n| Commit is requireshuman | Complete the existing approval workflow |\n| Commit is pending or in flight | Read the same action and transaction; wait |\n| connector.caldiy.idempotencycollision | Stop; the key already owns different input |\n| connector.caldiy.outcomeunknown or ambiguous transport failure | Reconcile the original provider operation |\n| Definitive provider rejection with no uncertain outcome | Correct the cause and begin a new governed intent |\n\nThe CLI at this revision does not expose transaction mode reconcile, even\nthough the protocol and runtime define it. Use the deployment's authorized\nreconciliation integration and retain the original action, transaction,\nidempotency, and provider-operation identities. Never replace the key to force\nanother provider call.\n\nVerify the complete workflow\n\nBefore treating the task as complete, confirm that you retained:\n• the catalog revision plus contract and schema digests;\n• slot-read action and exact selected start;\n• immutable booking input and its hash;\n• plan action, plan id, transaction id, and expiry;\n• approval id, policy hash, authority evidence, and terminal decision;\n• commit action, original idempotency key, durable result, and receipts;\n• provider request and operation ids when present;\n• validated provider booking uid and the follow-up read.\n\nThis evidence demonstrates one governed application workflow. It does not by\nitself establish live-provider qualification, notification delivery, calendar\ndelivery, availability guarantees, or production readiness.\n\nRelated documentation\n• Booking capability reference (../capabilities/bookings.md)\n• Slots and reservations (../capabilities/slots-and-reservations.md)\n• Approvals and policy (../../../concepts/approvals-and-policy.md)\n• Transactions and compensation (../../../concepts/transactions-and-compensation.md)\n• Observe and recover (../../../guides/observe-and-recover.md)\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "6f8e4f8e299664833dc2b13d4f618d35eed80e2d36e3c566facbbce0a170696b"
  }
}