How does Yaari prove the difference between recommendation, payment, and booking?

Yaari proves the difference by making each step of a trip a separate fact, with its own approval and evidence trail. A recommendation is only a suggestion. Payment is only allowed after explicit traveller approval and bounded authority. Booking is only real when the supplier or merchant returns confirmation. Cancellation and refund settlement are separate again. That is how Yaari keeps a trip calm, traceable, and easy to verify.

The short version: suggestion, permission, and confirmation are not the same

In Yaari, these stages do not blur together. That matters because many travel tools sound helpful but leave the traveller guessing what was merely recommended, what was actually paid for, and what was truly booked.

Stage	What it means in Yaari	What counts as proof
Recommendation	A ranked itinerary or option set based on your intent, budget, dates, visa state, and flexibility	The generated plan itself
Traveller approval	Your explicit “yes” to a chosen option	Your approval record
Payment authorization	Permission to spend within a defined limit	The bounded authority you approve
Merchant checkout / supplier booking	The actual transaction with the hotel, airline, or other supplier	Supplier or merchant confirmation
Cancellation	The original booking is ended	Cancellation evidence from the supplier
Refund settlement	Money is actually returned	Refund settlement evidence

This separation is part of Yaari’s product promise. The system is designed so that recommendations, approval, payment authorization, merchant checkout, booking confirmation, cancellation, and refund settlement remain separate facts.

How Yaari keeps the evidence clean

Yaari begins with natural-language trip intent. It asks only for the missing essentials: travellers, dates or flexibility, overall budget, departure city, pace, interests, room needs, visa state, and refundability tolerance. From there, the recommendation layer proposes a plan. It does not itself spend money.

The money and authority side is handled differently. Yaari’s documentation is explicit: a recommendation does not authorize payment. Deterministic policy and explicit traveller approval control ordinary payment. In simple terms, the system may narrow the options, but your approval is what opens the door to spending.

Yaari also keeps provenance for every event. Internal evidence is treated differently depending on its source:

LIVE means the result came back from an external sandbox or API.
CONTROLLED means the data came from Yaari-owned merchant or demo-clock data.

That gives a clear trail for judges and administrators. They can see model calls, provider calls, token usage, latency, transaction state, budget exposure, failures, and immutable evidence. The traveller sees a calm, friend-like interface. The proof sits underneath it.

A simple travel example: refundable Rome stay while visa is unresolved

Here is how the separation works in a real trip flow.

If the visa is still unresolved, Yaari admits only refundable accommodation that covers every required night and matches the traveller’s constraints. It does not quietly switch to a cheaper non-refundable room just because the price looks better. Refundability is treated as a policy input, not a marketing badge.

That policy matters because the trip is still changing. A pending refund does not reduce current trip spend in Yaari. Gross exposure still includes money already paid or reserved until refund settlement evidence arrives. So if a hotel is cancelled, the system does not assume the money is back in hand. It waits for the actual settlement proof.

The ordering is also important. If a cancellation opens a repair cycle, an ordinary replacement purchase still needs fresh user-present approval. In other words:

Yaari recommends a protected, refundable option.
You approve it.
Payment authority is granted within the agreed bounds.
The supplier booking is confirmed.
If the plan changes, cancellation is recorded separately.
If money comes back, refund settlement is recorded separately.

This is how Yaari avoids mixing up a suggestion, a payment, and a booking.

Why this matters for Indian international travellers

For travellers from India, the clean split is especially useful because international trips often move across time zones, visa timing, and refundable booking windows at the same time.

A calm, explicit system helps with:

Budget clarity: you can see what is merely reserved, what is paid, and what is still exposed.
Visa safety: while visa timing is unresolved, Yaari keeps the plan protected instead of over-optimising for price.
Change handling: if flights or stays shift, recovery is bounded and visible.
Refund tracking: expected refunds are not treated like settled money.

That means fewer surprises after you have already committed to the trip. You know what Yaari recommended, what you approved, what got booked, and what was later changed.

Quick answers

Does a recommendation authorize payment?

No. A recommendation can narrow the options, but it does not spend money.

Does payment authorization prove a hotel is booked?

No. Payment authorization is not the same as merchant checkout or supplier booking confirmation.

Does a refund being expected mean the money is already back?

No. Yaari tracks refunds separately until settlement evidence arrives.

Can Yaari choose a cheaper non-refundable room while the visa is pending?

No. While the visa is unresolved, Yaari keeps the trip on refundable accommodation that covers the required nights and fits the constraints.

The bottom line

Yaari proves the difference between recommendation, payment, and booking by treating them as separate, evidence-backed stages. The recommendation helps you choose. Your approval sets the boundary. Payment authorization allows spending within that boundary. Booking confirmation comes from the supplier. Cancellation and refund settlement remain their own facts.

That separation is what keeps the trip coherent when plans change.