Plan the trip.
Review each booking.

01 / Positioning

The opportunity is dependable execution

The customer problem hypothesis is fragmented decision-making: flight timing changes the useful holiday days, hotel location changes transport costs, and activity slots determine whether the itinerary works. A list of individually attractive recommendations can still make a poor trip. The product should optimize the complete experience within the customer's budget, then remain responsible for explaining and resolving what happened when purchases were attempted.

This is already a competitive category. Mindtrip advertises preference-aware planning, direct booking and a travel assistant that monitors changes. Layla presents AI planning with a human expert who checks and books the trip. These are their first-party claims, not independently tested performance findings. An AI-generated itinerary alone is therefore a weak differentiation. Mindtrip; Layla.

Proposed promise: “A trip that fits your life and budget, with every choice explained and every booking under your control.” Differentiate through comparable total prices, honest source coverage, evidence for hotel fit, clear permission to spend, and a unified recovery path. Do not promise the cheapest price everywhere, complete review coverage, or universal automatic booking.

The first decisive proof is whether travelers prefer this coherent, explainable plan to assembling the same trip themselves and whether the business can fulfill it at a sustainable contribution. A polished prototype tests comprehension and preference. It does not establish demand, commercial viability or production access.

02 / Product boundary

Make the first promise narrow enough to keep

The narrow market is a hypothesis, not a discovery about existing customers. Select destinations only after verifying supplier coverage, practical transfer information and reliable support. Preserve destination and origin flexibility in the data model without presenting unsupported routes as bookable.

Ask for origin, destination, dates, party size and total budget first. Clarify whether the budget includes meals, transfers and discretionary spending. Optional preferences should include pace, interests, hotel priorities, cabin/baggage, maximum travel duration, refundable options and mobility requirements. Never silently interpret a hard accessibility need as a soft preference.

Guest planning can precede registration. Require a verified account, necessary traveler details and explicit payment authorization before purchasing. Offer a clear unsupported-request outcome. The fallback may be a useful plan or an external provider link, but the interface must identify what the app cannot book.

One account means one relationship with this product. Supplier reservations, payment statements and terms may remain separate. Explain this before the customer commits, rather than introducing it after payment.

Accepted front-page direction: separate, directly editable From and To fields on the homepage, plus one shared date-range calendar dropdown for departure and return, similar to the Google Flights interaction. For round trips, the calendar stays open after departure selection and closes automatically after return selection. One-way mode requires only departure and must not introduce a return flight or return date. This supersedes the earlier shared route-dropdown instruction. Keep advanced options collapsed initially and show a concise summary of any saved defaults that will apply. Airport/city choices must resolve to authoritative location IDs with clear city and airport labels; free text alone must not become a purchase location. An accessible swap action should exchange both selected IDs and labels.

Selected local pilot: default From is IAD and To is Istanbul as a city. Do not silently choose an Istanbul arrival airport; the final airport must come from an explicitly selected, verified flight offer. One-way travel still needs separate hotel check-in/check-out dates or an expressly chosen planning horizon before pricing nights or constructing a complete day-by-day stay. Missing stay dates must remain unresolved rather than being guessed.

Restaurant, event and hotel-area preferences are part of the general profile. The traveler can set cuisines, dining price comfort, atmosphere, meal timing, event interests, preferred hotel areas and pace, then override them for a particular trip. Explicit hotel-area preferences may reorder only verified property locations; do not infer budget fit without a dated live room quote. Restaurant discovery and a top-10 map/list are in the selected experience; automatic table reservations remain dependent on a separate approved booking integration.

03 / End-to-end experience

From intention to a trip the traveler can rely on

Support the user's requested “Approve and book this item” interaction. The button must expose the exact payable amount, applicable terms and consequences for the remaining plan. The customer may commit a flight while the hotel remains unbooked.

Recommended default: allow component selection first, then an explicit “Book selected items” spending consent. This makes whole-trip tradeoffs easier to review. “Select” must never secretly mean “purchase.” Keep the direct item-booking mode available as a deliberate alternative.

The confirmation page must distinguish confirmed, still processing, unsuccessful and unpurchased components. It should show real supplier references, ticketing status where relevant, amounts paid and due later, refund rules and a support action. A celebratory all-done screen is appropriate only when the evidence supports it.

Selected results direction: T01A and T05A

Preserve the 01A homepage and TravelTiger identity. The selected results direction combines T01 daily structure with the T06 side map as T01A. Also build T05A, a compact two-track alternative with a restaurant map, using the same trip data. Show flights, hotel stays, restaurants and events within the daily timeline, with a side map and an accessible list alternative. Selecting a marker focuses its corresponding card; selecting a card highlights the marker without losing the user's scroll position. The day-by-day timeline reveals travel, hotel and activity dependencies. Keep rows compact with secondary detail collapsed by default, while leaving the category, name, day/time or unknown status, booking state and key actions visible. Keep the daily structure visible and avoid category tabs, decorative introductions or confirmation dialogs for reversible edits. A one-way itinerary ends at its chosen planning horizon, not an invented return-home milestone. Keep the cost ledger reachable throughout.

Restaurants are timeline entries

Adding a restaurant inserts a real planning entry into the chosen day, not a detached wishlist. Give each entry a stable ID and store its venue reference, target day, optional user-set time and planning status. The day selector should sit beside the add action, prefilled with the currently focused day where one exists. “Add to day” is one action once the target is selected; it does not reserve a table or assert opening hours. Prevent accidental double additions from repeated clicks and explicitly allow a second visit only as a separate intended entry.

Show a direct remove action on each restaurant entry and an undo action after removal. Undo restores the same entry and day without duplicating it. Persist the trip's planning entries locally with a clear browser-storage notice; reload and T01A/T05A layout changes must preserve the same additions, removals and selected days. Keep any future account synchronization separate and consented. Changing the destination must not carry restaurants from the previous city into the new timeline.

Distinguish restaurant pins already in the timeline from available alternatives, using text/legend and accessible markers as well as color. Selecting a pin highlights the matching entry or candidate; an alternative does not become “in your plan” until added. Omit unverified coordinates while retaining the real address and external source link. A restaurant without a verified pin remains usable in the timeline. The map must not fabricate routes or travel times.

The restaurant view presents up to ten verified candidates that fit the current brief. Cards show why each suits this traveler, source-linked review information, exact returned address and relevant known hours. “Add to plan” schedules an idea; “Reserve” is shown only where a supported reservation path exists. Opening hours alone do not establish table availability. An event listing likewise needs an actual date, venue and provider evidence before it can be treated as a timed bookable item.

04 / Procurement and integrations

Choose bookable channels before promising coverage

These capabilities come from official documentation: Duffel flights, Duffel Stays, Rapid setup, Demand prerequisites, Amadeus FAQ, Viator access, GetYourGuide access.

Propose Duffel as the first flight adapter and evaluate Duffel Stays against Rapid for the first lodging adapter. Investigate Viator Full + Booking because it can retain the onsite journey with Viator as merchant of record. A merchant arrangement may provide a different payment experience but changes financial and service obligations. Do not assume acceptance.

Add a second hotel channel after the first completes booking and servicing tests. A connector showing prices is not a booking integration. Track content, search, quote, hold, purchase, retrieve, cancel, refund and disruption capabilities separately. Booking.com's current overview documents attractions as search/redirect rather than onsite booking. Demand service matrix.

05 / Hotel evidence

Reviews are licensed evidence, not a free data lake

Google Places returns at most five reviews for a place, ordered by relevance, alongside separate overall rating and count fields. That is insufficient to claim the model read the entire review history. Attribution, storage and map-display rules also apply. Preserve the source's rating and review count instead of manufacturing a cross-site star score. Place reference; Places policies.

Google now offers Maps Experience agent tools with specific permissions for LLM grounding. Those permissions are distinct from unrestricted transformation of raw Places content. Use the applicable tool, model compatibility, source links, retention limits and restrictions on training. Record which terms and billing region govern the integration. Agent tools; Service-specific terms.

Tripadvisor's legacy Content API and newer Terra platform must not be conflated. Legacy reviews are limited and legacy AI use is narrowly constrained. Terra offers Agentic Search and package-dependent content, but its Master Partnerships Terms allow chatbot summaries only when the Agentic service is included in the applicable Order. They prohibit combining licensed content into a new aggregate rating/review system and co-display with third-party booking or inventory functions, unless the governing agreement changes the relevant position. The Order takes precedence. Legacy reviews; Terra; Master terms.

Proposed implementation: an evidence panel with source-separated ratings, licensed excerpts, dates, author attribution and an explicit coverage statement. Request written permission for the exact AI ranking, summaries, mixed-source display and booking-adjacent screens. If unavailable, remove that source from the purchase experience. Never solve a contractual constraint by scraping the same content.

Restaurant and map source contract

Use a rights-aware place adapter to retrieve candidate IDs, names, provider coordinates, formatted addresses, categories, known operating status/hours, price information where supplied, rating/count fields and permitted review excerpts. Keep field-level source and fetched-at metadata. Re-fetch detail fields when the user opens a card or prepares a reservation. Unknown price, dietary accommodation, hours or availability must remain labeled unknown; do not infer them from the restaurant's name.

Google-sourced places shown on a map must follow Google's map and attribution rules. Show the required Google and contributor attribution, preserve review author/source links, and do not transplant Google Places content onto an unrelated map. A different licensed map/data pair is possible only after checking its own terms. Store only permitted fields for permitted durations, keeping location IDs under the applicable exception. The top map must use exact provider coordinates and returned addresses; an illustrative prototype map must be labeled and must not imply verified navigation or distances. Google Places display and retention policies.

The same Google AI-grounding and Tripadvisor Terra constraints above apply to restaurant recommendations. A rating can be displayed separately from an AI explanation, but that does not automatically permit using review text as model input or combining it into a new rating. Without required rights, omit that input and explain suitability from permitted structured fields and the traveler's explicit preferences. Reviews describe past experiences; neither a high rating nor a source snippet guarantees a particular meal or allergy accommodation.

Local prototype boundary: the current pilot is IAD to Istanbul; Istanbul evidence is being prepared and must be verified before display. The earlier researched London sample is retained as historical material with the original gallery. It must not appear as Istanbul recommendations. Neither city sample establishes an exhaustive search or a claim to the ten best restaurants in that city. Do not invent numerical ratings or reviews. External Google Maps search links can provide a source-checking action until a licensed integration is available; a link alone does not authorize importing the destination page's reviews or turn an illustrative map into a live Google map.

06 / Fair comparison

Compare equivalent offers and the complete bill

Create a canonical property identity using licensed identifiers, coordinates, address and explicit mapping confidence. Room identity is harder: a matching property does not make two room offers equivalent. Compare occupancy, bed configuration, room class, meal plan, refund deadline, no-show policy, payment timing, inclusions and accessibility commitments. Mark uncertain equivalence; do not show a savings claim for unmatched rooms.

For flights include actual airports, dates and time zones, segment sequence, cabin, fare conditions, baggage, seats if selected, connections and protected versus separate tickets. An overnight arrival changes hotel dates and available activity time. For experiences compare supplier, option, duration, language, meeting point, age rules, slot and cancellation terms.

The trip ledger should separate amounts payable now, mandatory amounts payable later, refundable deposits and discretionary allowances. Include taxes, resort/property charges, luggage, required transfers, platform fees and known payment/FX charges. Meals and unpriced local transport remain explicit unknowns or user-entered allowances, never invented estimates. Missing mandatory cost information prevents an unqualified “within budget” claim.

Preserve supplier charge currency and amount. Informational conversion needs an identified FX source and timestamp, with the actual billing currency visible. Reprice before commitment. Booking.com distinguishes display, total and online-charge amounts; Rapid requires specific price and payment disclosures. Demand pricing; Rapid requirements.

Use “lowest comparable price found among connected providers,” showing providers checked, freshness and failures. Comparison rights must be agreed separately from API access. Booking.com's legacy rules illustrate restrictions on using its content in multi-platform comparison; confirm the current contract rather than assuming that legacy terms govern a new deal. Legacy usage rules.

07 / Curation

Make “best” a defensible relationship to this traveler

Begin with hard constraints: supported market, available inventory, dates, party eligibility, budget coverage, required accessibility, acceptable connection times and explicit no-go preferences. Reject infeasible candidates before scoring. An inexpensive hotel outside the permitted area is not a bargain for this request. Unknown evidence must remain unknown rather than becoming a positive score.

Then build a Pareto set: options that are not worse on every relevant dimension than another feasible option. Present a small set labeled best fit, lower cost and more comfort only when the data supports those distinctions. Avoid a supposedly objective universal quality number.

Proposed ranking dimensions include comparable all-in price, travel burden, hotel location relative to the plan, licensed review evidence, cancellation flexibility and stated interests. Weighting comes from the traveler or an explicitly described default. Do not average Google and Tripadvisor ratings into a new aggregate. Use only contract-permitted evidence inputs, retain source separation and handle sparse review coverage as uncertainty.

Generate explanations from structured reason codes and allowed evidence: “shorter transfer,” “refundable until the supplier's stated deadline,” or “matches your requested neighborhood.” The language model can turn these facts into readable prose. It must not invent local expertise, review consensus or availability. Commission must not secretly determine ranking; keep monetization out of the recommendation objective and disclose sponsored placements separately if ever introduced.

Test whether explanations change decisions for the right reasons. Capture preference edits with consent, but do not treat a one-off trip choice as a permanent profile trait. Store why an option was rejected so future suggestions can respond usefully.

Preference learning that the traveler can inspect

Accepted product behavior: remember general restaurant/event preferences and improve recommendations over time. Proposed implementation separates three layers. Explicit defaults are user-edited settings and exclusions. Contextual preferences belong to one trip, party, date or occasion and take precedence for that trip. Learned signals are bounded, confidence-labeled suggestions that never override a hard requirement or silently become a permanent explicit default.

Use a versioned scoring configuration with stronger evidence from deliberate preference edits and explicit feedback than from saves, selections or views. A click can mean curiosity, comparison or accidental exposure. Do not interpret a non-click as a dislike. Capture optional negative-feedback reasons such as wrong cuisine, too far, too expensive for this trip or already visited, so the correction affects the right feature and scope. Repeated evidence can adjust a soft weight with confidence and recency decay; a single interaction must not permanently narrow the profile. Validate weights in observed sessions rather than inventing precision.

For cold starts, use only the supplied trip brief and explicit preferences, with a varied set of eligible options. Preserve diversity across cuisine, neighborhood, atmosphere and event type instead of repeatedly showing near-duplicates. Log which candidates were actually exposed and in what position so evaluation can distinguish preference from ranking exposure. Compare outcomes across positions and sufficient eligible alternatives; do not train directly on raw click totals. Exclude commission and paid placement from learned suitability, and label any future sponsorship separately.

Provide a “Why this fits” explanation and a “What TravelTiger remembers” panel. Let users view/edit explicit preferences, inspect learned suggestions, turn learning off, reset learned weights, delete underlying optional interaction history and delete saved preferences. Reset must invalidate relevant cached recommendations. Do not infer health conditions, religion, ethnicity, sexuality or other sensitive traits from dining or event behavior. Sensitive requirements, such as allergies or accessibility, are explicit user-provided constraints with separate handling, not inferred personality features.

The local prototype can remember non-sensitive choices only after an explicit “Remember on this device” choice, disclose that they are stored in this browser, and provide a clear delete action. It does not create an account or prove a production learning system. Future account synchronization requires authenticated storage, consent/version records, retention rules and separate migration consent; never silently upload existing local preferences.

How the restaurant top ten is computed

Retrieve a broader licensed candidate set around the destination and relevant daily itinerary. Deduplicate by provider/canonical place identity. Apply hard filters for geography, verified operating status, requested time where hours are known, explicit exclusions and reliable eligibility evidence. If a hard dietary or accessibility need cannot be verified, flag verification required rather than marking the candidate suitable. Rank eligible candidates using permitted evidence, explicit preferences, current trip fit, bounded learned signals and actual route/time inputs where licensed. Select up to ten with diversity and stable tie-breaking; return fewer when fewer qualify, never invented filler.

Each result must carry a real place ID, exact address/coordinates, evidence source, freshness, review coverage statement and structured suitability reasons. Rating, count and author-attributed reviews remain source-separated. Show when information or reservation access is unavailable. Source outage, empty results or insufficient coverage should change the displayed explanation and candidate count. Evaluate hard-filter violations, source completeness, diversity, user corrections and preference control behavior before optimizing clicks.

08 / Payment architecture

A single account is feasible. Universal card reuse is conditional.

Keep product identity, traveler records and payment instruments separate. Use hosted payment fields and processor vaults; the application stores references and permitted masked details. Card security codes must not be retained, even with customer permission. Hosted collection reduces scope but does not erase the business's PCI responsibilities. Stripe security; PCI SSC rule.

Stripe supports consented future use through SetupIntents, while later payments can still require customer authentication. Its connected-account sharing is a bounded capability, not a token that arbitrary travel suppliers accept. Duffel's direct supplier-card component currently requires CVC input for saved-card reuse. Design a smooth action-required return path rather than promising no further interaction. Saved methods; Connect sharing; Duffel card component.

Select a contracted settlement model per provider: platform collection followed by supplier settlement; supplier-collected payment; approved connected-account flow; or another documented arrangement. Model funding, settlement delay, reserves, chargebacks and refunds before choosing. The cleanest customer interface may impose the largest operational burden on the business.

Each spending authorization must bind account, traveler set, itinerary version, item and offer identifiers, exact or expressly capped amount, currency, expiry, terms version and partial-success instructions. Saving a card grants no unlimited booking authority. Revoke affected consent when material details change. Do not treat a budget cap as permission to substitute an unrelated hotel or fare.

The screen should show who charges each item and what descriptor or separate payment the customer should expect. Keep the payment workflow outside the language model's discretionary control.

09 / Transaction reliability

Build a state machine, not a chain of optimistic API calls

Proposed item states: draft → quoted → selected → consented → payment_action_required / ready → submitting → pending / unknown / confirmed / failed. Confirmed items can proceed through cancellation_quoted → cancellation_authorized → cancelled → refund_pending → refunded. Track flight reservation and ticket issuance separately. A booking reference alone does not establish ticket issuance in a consolidator flow. Amadeus flight lifecycle.

Use durable jobs with persistent steps, transaction locks, unique purchase intents and replay-safe internal operations. Supplier idempotency must be documented and tested; adding a header does not create a guarantee. A timed-out purchase enters reconciliation, querying known identifiers or invoking support before any new attempt. Duffel specifically prohibits blind retries for uncertain booking responses. Duffel response handling.

A trip basket is not an atomic transaction across unrelated suppliers. Revalidate all selected components, acquire documented holds where available, then order commitments according to expiry and recoverability. Capture only through the contracted payment flow. If one component fails, display the already-confirmed commitments and the remaining choices.

Compensation is not rollback: cancelling a confirmed item can incur a penalty or be impossible. Automatically cancel or refund only within a clear, previously authorized recovery rule and actual supplier terms. Otherwise request a concrete decision, such as retaining the booked flight while selecting another hotel. Preserve the original receipt and every adjustment.

Webhooks must be verified, deduplicated and reconciled with authoritative retrieval. “Unknown” must remain visible until resolved. The customer should never need to infer whether money moved from a spinning progress indicator.

10 / Engineering shape

One modular application with explicit boundaries

Propose a typed TypeScript web application, a relational database, durable workflow/job execution, and provider adapters behind a stable internal interface. Choose supported package versions at implementation time from official documentation. There is no need to begin with a fleet of microservices. Separate domains in code so later scaling does not require an early distributed system.

The language model proposes a structured plan. Deterministic services validate money, times, source entitlement and authorization before any action. Separate read tools from purchase tools. A purchase tool accepts only an existing approved intent identifier, not an arbitrary natural-language instruction.

Use one provider registry for capabilities, credentials, commercial mode, supported markets and permitted content handling. Feature flags should disable a broken connector without breaking existing booking retrieval. Instrument latency, source failure, stale quotes, booking outcomes and unresolved financial differences.

Existing local TypeScript project manifests have been inspected only. No claim is made that their authentication, payments or deployment infrastructure is reusable. Verify ownership, interfaces and data boundaries before borrowing any implementation.

11 / Information model

Store decisions and provenance as first-class records

Core records should include Account, Traveler, TripBrief, ItineraryVersion, Component, ProviderOffer, QuoteSnapshot, EvidenceReference, Approval, PurchaseIntent, ProviderReservation, PaymentTransaction, Refund, SupportCase and AuditEvent. Each money record carries integer minor units or a validated decimal representation, currency and source precision. Never use binary floating-point arithmetic for charge amounts.

Quote snapshots retain permitted fields, supplier IDs, fetch time, expiry, cancellation policy version, inclusions and price breakdown. An approval references an immutable snapshot hash. Evidence references carry source, permitted use, attribution, retention deadline and licensing status. Do not persist restricted source text merely because the general application stores quotes.

Apply tenant isolation to every record, least-privilege roles for support, encryption for sensitive traveler fields and short-lived access for operational tasks. Passport and birth data should be collected only when required and excluded from analytics, prompts and routine logs. Provide deletion and retention workflows that respect lawful booking-record obligations.

Supplier text, reviews and web content are untrusted input. Treat embedded commands as data, prevent content from changing tool permissions, validate structured outputs and allowlist outbound purchase destinations. Keep API secrets and payment data outside model context. Redact logs before they reach monitoring systems.

Record human and automated actions with actor, reason, timestamp, consent and provider correlation IDs. Do not store full sensitive payloads indiscriminately. Test account separation, access revocation, export, deletion and recovery from backup before accepting real traveler information.

Preference and place records

Add PreferenceSetting (feature, explicit value, hard/soft flag, scope, source and update time), LearningConsent (status, version and timestamp), PreferenceSignal (action, reason, trip context, candidate exposure and permitted retention), LearnedWeight (feature, bounded value, confidence, evidence window and model version), CandidateExposure (query, position and eligibility context) and PlaceEvidence (provider ID, permitted field references, freshness and rights). Keep optional behavior history separate from legally required transaction records, so deleting preference data does not erase accounting evidence. Use account isolation for preferences and propagate deletions through derived weights and caches.

12 / Accountable travel operations

The service continues after the booking button

Assign ownership for schedule changes, missing vouchers, hotel disputes, cancellations, refunds, no-shows, chargebacks and uncertain bookings. Provide an escalation route with contracted coverage appropriate to the trips sold. Do not advertise around-the-clock care until staffing or a partner agreement actually supports it. The support console needs evidence, permission boundaries and supplier contact paths.

Legal structure depends on customer market, selling activity and payment role. California has seller-of-travel registration and financial requirements with exemptions. US ticket agents acting as merchants of record have airfare-refund responsibilities in covered cancellation or significant-change situations. Map intended states and roles with a travel specialist before live sales. California FAQ; DOT refund guidance.

UK ATOL can apply to overseas businesses selling covered arrangements to UK consumers. UK package-travel guidance was updated on 28 October 2026; implementation must check actual commencement provisions. In the EU, separate supplier contracts can still form a package. The 2026 amending directive sets transposition by 29 September 2028 and application from 29 March 2029, so its future changes must not be described as current national law in November 2026. CAA; UK guidance; EU guidance; 2026 directive.

Separate approval buttons are not a legal workaround. Establish seller, agent, organiser and merchant roles, privacy notices, insurance, insolvency protection where applicable, financial reserves and complaint handling. AI can prepare the evidence pack; accountable specialists determine the operating model.

13 / Commercial validation

Validate trust, fulfillment and contribution together

Proposed initial audience: adults who value a coordinated leisure trip but still want control over each purchase. Proposed acquisition experiments: destination-specific planning pages, useful comparison content and opt-in partnerships with travel creators or communities. These are hypotheses, not proven channels. Prepare outreach copy but do not send it without authorization.

Start with observed planning sessions using the prototypes. Ask travelers to explain what approval does, choose between plans, identify excluded costs and recover from a changed fare. Record confusion and abandoned decisions. Next, compare a permissioned real quote set with the traveler's own alternatives. Finally, conduct an authorized assisted pilot with actual fulfillment and support, measuring the operational work as carefully as bookings.

Track brief completion, plan usefulness, source coverage, quote-to-checkout price drift, approval completion, supplier booking success, unresolved outcomes, support minutes, refunds and repeat use. Establish decision thresholds before experiments using actual baseline evidence and the owner's objectives. No conversion, revenue or timetable forecast is justified yet.

Cash exposure is a separate calculation: supplier prepayments + reserves + refund timing gaps − customer funds actually available for settlement. Gross booking value is not revenue. Recognize cancelled commissions and processing costs correctly.

Evaluate commission-only, transparent service-fee and membership models with real supplier terms and customer research. Avoid a fee promise until economics are known. The business must be viable without secretly steering recommendations toward higher commission.

14 / Autonomous execution

Give the AI bounded work packages and evidence-based exits

Use parallel agents where work is independent: provider research/adapters, planner/ranking, interface/accessibility, and reliability/security. Assign explicit files or modules, schema contracts and integration ownership. A single integrating agent resolves interfaces and runs the end-to-end journey. Do not let several agents edit the same payment state machine concurrently.

Every work package needs inputs, deliverable, acceptance evidence, allowed actions and stop conditions. Keep a shared decision record and issue queue. Agents can continue reversible implementation while a commercial decision is pending, using clearly labeled fixtures only where permitted. They must not substitute invented production data for unavailable access.

Do not attach speculative calendar estimates to external partner approvals. Sequence by dependencies and report actual progress, blockers and verified outcomes. The current authorized scope ends at this strategy and local concepts.

15 / Release evidence

Test the moments that can cost the customer money

Also test keyboard and screen-reader journeys, narrow screens, long place names, currency formatting, empty results, provider outages, invalid traveler details and resumed sessions. Use provider sandboxes for transactional tests and contract-permitted fixtures for isolated failures. Production smoke tests involving money require a concrete approved purchase scope, not a generic deploy permission.

Collect screenshots, event traces with sensitive data removed, provider references and reconciled ledger assertions. Passing a build is not evidence that flights were ticketed or refunds reached the customer.

Selected experience and personalization checks

Verify the separate From and To fields with keyboard entry/selection, ambiguous city names, swapping and invalid input. Verify the single date-range calendar dropdown with departure/return selection, range highlighting, month navigation, clear behavior, keyboard access and invalid-range handling. The first round-trip date click must keep the calendar open and the return-date click must close it; one-way mode requires departure only. Verify that switching modes clears or ignores an inapplicable return without inventing hotel checkout dates; advanced options start collapsed and preserve edits. Check map/list focus synchronization, mobile fallback and exact address matching. Restaurant tests must cover ten, fewer-than-ten and zero eligible real candidates; unknown hours or price; missing reservation access; attribution; restricted reviews; expired evidence and duplicate place identities. No test may pass using fabricated live reviews.

For learning, verify opt-in before local persistence, explicit preference priority, trip override isolation, feedback reasons, weak click evidence, no non-click dislike, diversity, exposure-aware evaluation and commission neutrality. Confirm view/edit/reset/delete behavior, disabled learning, local-to-account consent, cross-account isolation and removal of derived cached preferences. Show the selected tagline exactly: “Less planning. More going.”

New planner acceptance checks, pending: T01A and T05A show the same trip and restaurant entries after a layout switch and reload; adding to a selected day creates one entry; removal is immediate and undo restores it once; no restaurant is treated as reserved; selected map pins differ from alternatives; unpinned venues remain usable; no cross-destination leakage. Check compact collapsed defaults, direct keyboard-accessible actions and mobile map/timeline behavior. These are test requirements, not passed-test claims.

16 / Minimal owner input

Three decision packets, prepared before you are asked

The AI should make routine reversible engineering choices, maintain the decision log, prepare provider questions, implement adapters and tests, and resolve ordinary defects autonomously. It should combine consequential questions rather than interrupting for each library or screen detail.

Owner input cannot be eliminated for legal identity, contractual authority, funding commitments and business risk choices. Travelers must provide required identity information and genuine issuer authentication. An agent must not invent those details or infer consent from silence.

Once a packet is approved, its authorization persists within the recorded scope. Do not repeatedly request the same permission. Escalate only when new facts materially change the choice, such as an unexpected settlement exposure or prohibited content use. Keep independent work moving while that decision is pending.

17 / Failure-aware strategy

Keep the promise useful when an assumption fails

Do not preserve a broad headline by hiding reduced functionality. A planning product with external booking links is a different release from automatic fulfillment. It can be a valid experiment if labeled accurately, but it does not prove the original automatic-booking promise.

Give each risk an owner, next evidence request and decision consequence. Revisit it when evidence changes, not through repetitive speculative warnings. The highest-priority unknowns are access, review rights, settlement compatibility and the cost of accountable post-booking service.

18 / Reusable agent instruction

The autonomous build brief

This is a proposed instruction for a future authorized build. The present deliverables demonstrate design and planning. They neither create an unattended production agent nor authorize purchases.

19 / Product expression

TravelTiger joins the DocDuck family

Selected by the user: the name TravelTiger and a visual identity in the DocDuck.io family. Use the same Baloo 2 display type and Arial body type, deep green #063d2d, orange #c45000, pale sage and white, with a friendly tiger mascot. The approved tagline is exactly “Less planning. More going.” Keep the warm, approachable character consistent from the landing page to confirmation. Open the TravelTiger brand presentation.

The homepage remains 01A. The user selected T01A results: T01 daily structure combined with the T06 side map, and requested T05A as a compact two-track alternative with a restaurant map. Preserve separate, directly editable From and To homepage fields, one shared departure/return date-range calendar dropdown similar to Google Flights, initially collapsed advanced options, a results timeline with all trip categories and a supporting side map. Include saved general restaurant/event preferences, a personalized top-10 restaurant map/list and transparent preference-learning controls. Keep the original alternatives as design history. The new planner is available at trip-planner/index.html, defaulting to T01A with a T05A toggle over the same data. Compact rows, collapsed secondary detail, minimal clicks and plain functional copy are accepted requirements. Restaurant additions and removals change the actual day timeline, with undo and persistence. Selected planner refinement; 01A homepage; original timeline-results gallery; original design gallery.

Selected results treatment: compact day-by-day rows with key information and actions visible, secondary detail collapsed, a side map and a readable cost ledger. Use plain labels such as “Flights,” “Hotel,” “Restaurants,” “Add to day,” “Remove” and “Undo.” Keep the approved tagline, and avoid playful phrases that obscure an action or status.

TravelTiger is the selected product name, not a representation that trademark, domain, company-name or app-store clearance has been completed. Selection of the name and visual style does not authorize commercial launch or real purchases.

Prototype screens must label simulated behavior and show unknown prices or evidence honestly. Do not add invented hotel ratings, discount claims, customer testimonials or booking references for visual polish. Payment screens should demonstrate the flow without collecting real card details. The research and booking safeguards in this strategy remain unchanged by the brand decision.

20 / Evidence and next use

What was verified, and what remains open

Research was checked on 8 November 2026 using official provider, regulator and standards sources. Links adjacent to claims are the primary evidence. Public documentation can change and does not supersede an executed agreement. Before implementation, refresh material capabilities and terms, pin the chosen API contract, and retain the permitted evidence needed for compliance and debugging.

The research notes preserve additional integration detail: supplier evidence memo and reviews, payments and operating obligations memo. They are supporting material, not legal determinations.

The selected T01A planner and T05A alternative for the IAD to Istanbul pilot are implemented, including editable timeline times, restaurant timeline changes, undo, local draft persistence and map state. The desktop workspace now gives the map and recommendations two thirds of the width, with larger text across the planner. Ten hotel suggestion layout concepts are available at hotel-designs/. Hotel candidates remain manually curated, and supplier rates, current availability, multi-site review aggregation, payments and bookings are not connected. The next work is to confirm the operating entity and market details, obtain written supplier access and content rights, and then build and verify one complete supplier-backed quote flow.