Travel Booking

One itinerary can involve a flight, a room, a car and four different systems of record. The assistant that stitches them together handles traveler identity and stored payment details in the same breath. This starter is the control layer for that work. It acts on the question before the model runs, and on the answer before a traveler reads it.

Travel questions arrive in bursts and cross many suppliers. A traveler asks about a fare, then a hotel, then a car, inside one conversation. The prompt collects a passenger name, a loyalty number and sometimes a stored payment token along the way. This starter aims at that accumulation.

Screening for injected instructions runs before the model is called, which matters when itinerary text comes from a supplier feed. Redaction then masks payment and card token strings of eight to sixty four characters. The traveler keeps a usable answer, because the value is masked rather than refused.

Three phrases stop a request completely. A bulk customer export is refused, which closes the fastest route to a passenger list. A private key and a gift card pin are refused under the same rule. Anyone who sends one of them sees a refusal, and the request never reaches a model provider.

Answers face a quality gate before delivery. A combined score of 0.78 is required, together with accuracy of 0.80 and relevance of 0.78 at equal weight. An answer must also reach 120 characters and two sentences, which suits an itinerary summary. Keyword safety screening applies the built-in term list, since no custom terms ship with this starter.

Provider choice is not constrained here, so which model receives the traffic remains your decision. The starter adds no identity check either, and no review step is configured. Audit marking allows each request and creates neither storage nor retention on its own. Ticketing rules, refund entitlement and fraud screening stay with the systems that own them. Choose the Hotel Chain starter when the assistant serves one lodging brand from end to end.