Capability catalogue
Main job: book a flight, a hotel, or both. Supporting map below: what Maya must know, may share, and must never invent. Freeze this loop as SDD once product + eng agree.
Asto (23 Sep) — proposed main capability.
“Maya sebenarnya yang dilakukan cuma 2: booking pesawat, hotel atau keduanya.”
Iman: highlight this as main capability so the purpose stays correct; review → then SDD.
Main loopIntent → summary → search → book → confirm
MVP rules3 options · geo · intent flex · photos
Must knowInternal capability Maya needs to reason
May shareSafe to say to travelers
Never inventOnly OMS / tools may assert
Tool gatesAUTO vs CONFIRM
Main capability — booking loop
Scope is deliberately narrow. Maya does not try to be a general travel encyclopedia. Every turn should advance or protect this loop.
flowchart TD A[1. Detect intent
flight / hotel / both] --> B[2. Complete slots
build trip summary] B --> C{User clicks Search?} C -->|no| B2[Update summary from chat] B2 --> B C -->|suspect intent change| D[Re-confirm intent] D --> A C -->|yes| E[3. OMS search via MCP
present ≤3 best options] E --> F{User clicks Book?} F -->|no| E2[Re-search / next 3 from chat] E2 --> E F -->|yes| G[4. Verify all intents met] G --> H[5. Confirmation page
per flow design]
| # | Step | Rule |
|---|---|---|
| 1 | Detect intent | Only three valid intents: flight, hotel, or both. |
| 2 | Fill for summary | Collect every slot needed for a clear trip summary before search. |
| 3 | Summary without Search | If user does not click Search, treat chat as edits to the summary — update slots, do not search yet. |
| 4 | Intent drift | If chat suggests a different intent (e.g. hotel settled, then “cari pesawat ke Jogja”), re-confirm and follow the new intent — do not insist on the old one. |
| 5 | After Search | Show ≤3 options for flights and hotels (same UX). Live OMS via MCP. |
| 6 | Options without Book | User can ask for another set. Re-search from chat prefs; do not invent options. |
| 7 | After Book | Check that all stated intents are fulfilled, then show the confirmation page per flow design. |
Training and NRCP may change wording. They must not invent a third product job
that pulls Maya off this loop.
MVP rules (team, 23 Sep)
Locked while proving the happy path to booking. Edge cases come after the spine works.
| Rule | Detail | Source |
|---|---|---|
| ≤3 options | Hotel same as flight: first batch of 3; user may ask for more if not a fit. | Asto |
| Hotel photos | Show OMS property photos in options. Map through MCP before Maya presents them. | Asto / Iman |
| Geo exact | “Kuta Bali” must not silently return “Kuta Lombok”. Prefer named place; disambiguate if ambiguous. | Asto bug |
| Intent flexible | After hotel pick, “cari pesawat ke Jogja” is a valid intent change — re-confirm and search flights. Do not dig in on hotel-only. | Asto bug → SPEC |
| Positive path first | Use normal scenarios until booking works. Separate “AI IQ” from “flow broken” (Yogi: optional Gemini only to validate flow, market stays on our model). | Yogi / Iman |
What Maya must know (capability)
These are skills and context Maya needs in order to answer without guessing.
| Capability | Source | Notes |
|---|---|---|
| Trip intent & slots (origin, destination, dates, pax) | Conversation + SPEC-001 | Summarize → confirm before search (ADR-001) |
| Flight-only vs hotel-only vs flight+hotel focus | Session state | Hotel ask must not dump flights after flight pick |
| Traveler prefs in session (airline, stars, breakfast, bed) | Session memory | Must not leak across unrelated trips |
| Company policy / plafon (corporate) | OMS via MCP | Deterministic filter — LLM does not invent policy |
| How to ask for confirmation (Ya, cari / Ya, book) | NRCP pack | Clickable confirm CTAs where channel allows |
| Honest empty inventory messaging | Tool result + compose rules | Broaden CTA — never fabricate hotels/flights |
What Maya must never invent
Fares, availability, hotel names, ticket numbers, approval outcomes, and policy
exceptions are factual. If the tool did not return them, Maya must not invent them —
even when the traveler presses for an answer.
| Never invent | Must come from |
|---|---|
| Flight prices, seats, baggage rules beyond tool payload | OMS flight search / add-ons |
| Hotel names, rates, photos, breakfast flags | OMS hotel discovery / room-rate |
| Policy allow / deny | OMS travel-policies / filtered offers |
| “Booking confirmed” / e-ticket issued | OMS booking status / files fetch |
| Credentials, API keys, other tenants’ data | — |
AUTO vs CONFIRM tools (via Anamaya MCP)
Tool permission is hard-gated in runtime. NRCP cannot weaken CONFIRM.
| Tool | Gate | OMS area |
|---|---|---|
search_flights / add-ons | AUTO | flight.search |
search_hotels / rates | AUTO | hotel.search / rate |
check_travel_policy | AUTO | policy.read |
recommend_itinerary | AUTO | Maya ranker ≤3 |
list_approvals / booking detail | AUTO | booking.read |
create_esppd / attach docs | CONFIRM | booking.write |
create_booking_shell / attach flight|hotel | CONFIRM | booking.write |
approve_booking / reject | CONFIRM | booking.approve |
process_payment / cancel / reschedule | CONFIRM | payment / change |
Preferred chatbot path:
MAYA_OMS_VIA_MCP=true → Anamaya MCP REST facade.
Paths MCP does not expose yet may fall back to direct OMS.