TheblueprintforapremiumAI-nativetravelplatform.

Top risks · explicit mitigations.

Side by side.

ATOL legal model — confirmed at kick-off.

ATOL compliance is not primarily a software question. It is a question of who is legally principal for each package booking. The answer is a kick-off decision — and it determines who issues the ATOL Certificate, who holds customer money, and which booking system is mandated. The platform implements to whichever model AX confirms.

Pioneers Club — discount and membership layer.

AX’s loyalty and acquisition model. Members get early access, exclusive trips, and discount codes scoped at trip or cohort level. Built into the data model from commit one so AX can run promotions from launch — not bolted on after.

Agent takeover.

Layer-by-layer.

Booking-ops vendor evaluation — Week 0 / Week 2 gate.

The AX brief leaves the vendor open between FacilitaTrip and Travel Compositor (§004b makes the comparison explicit). Week 0 is sales calls and demos with both. Week 1-2 is contractual and technical review of whichever vendor AX confirms — sandbox access, payload examples, sandbox booking proven end-to-end, gap analysis. AX retains the right at this gate to descope, defer, or proceed at the original scope.

FacilitaTrip vs Travel Compositor — both are candidate connectors.

Pricing for both: not publicly available. FacilitaTrip starts at €1,500/user/month per Capterra. Travel Compositor is tier-based (‘choose 8 of 20 engines’). Both require sales conversations as a Week 0 gate item.

Connector inventory · MVP / Phase 2 hedged by booking-ops choice.

Flight connectors — the named primary.

The named primary flight connector is the Lyme / Aviate consolidator — two sides of the same business: Lyme handles British Airways and the broader BA group; Aviate handles all other airlines. Both expose an API (recently introduced; their previous model was offline-only via phone, email, or manual entry). They are named here as the most likely default for MVP and Phase 2, not as a required dependency — additional flight inventory sources can be added as connectors over time.

Why the booking-ops choice cascades.

Production targets per region.

Targets measured at the median of real-world traffic captured by Vercel Speed Insights. Lighthouse scores measured on mobile profiles in CI before each release.

How we hit them.

Reference points.

Browser support matrix.

Coverage figures from StatCounter UK, rolling 90-day window. On iOS, third-party browsers (Chrome, Firefox, Edge) run on the same Safari / WebKit engine, so the Safari row covers them. Older browsers receive a simplified server-rendered fallback — bookings still complete, with reduced visual polish.

Three breakpoints, intentional layouts.

PWA-ready architecture — home-screen install activates in Phase 2.

QA pipeline + accessibility.

FX rate freeze — five points, named.

Travel pricing is a finance system requirement, not a feature. The platform defines exactly when an FX rate is sourced, when it freezes, who bears exposure, and how refunds compute. Five named points; nothing implicit.

i18n architecture — six languages at launch.

Five tiers of coverage.

What blocks what.

Four environments.

Pipeline · code → production.

1. 01PR opened. Vitest + ESLint + type-check + axe-core + Percy diff. Vercel preview URL posted to PR.~3 min
2. 02PR merged. Playwright golden flows on Chromium. Auto-deploy to staging.~6 min
3. 03Staging deployed. Cross-browser Playwright on BrowserStack. Smoke test against real Stripe sandbox + ATOL sandbox.~12 min
4. 04UAT sign-off. AX runs structured acceptance script. Tickets opened against any failures.Ad-hoc
5. 05Production promote. Manual click in Vercel dashboard. Database migrations run via Neon branch-then-merge.~2 min + monitor

Database migrations · Neon branch-then-merge.

Migrations are the highest-risk part of any deployment. Neon's branching model lets us rehearse each migration against a real copy of the database before touching production.

Catalogue layer.

AX-owned. Pre-built structured content. The differentiation lives here — AX’s curated tours, pricing rules, supplier mapping. Year 3 FacilitaTrip swap leaves this layer untouched.

Booking layer.

Transactional. Regulated (ATOL audit). Linked to FacilitaTrip via booking reference but not dependent on FacilitaTrip's schema.

User layer.

Identity, preferences, GDPR audit, AI session state. The only layer carrying personally-identifiable information at scale.

Versioning + audit — example.

The PricingMatrix is the most temporally-sensitive table. Below is its shape. Every other transactional table follows the same audit-column pattern.

CREATE TABLE pricing_matrix (
  id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tour_template_id UUID NOT NULL REFERENCES tour_template(id),
  date_band_start DATE NOT NULL,
  date_band_end   DATE NOT NULL,
  party_size      party_size_enum NOT NULL,
  hotel_tier_id   UUID NOT NULL REFERENCES hotel_tier(id),
  room_type       room_type_enum NOT NULL,

  -- Costs in supplier currency, sells in GBP
  net_cost        NUMERIC(12,2) NOT NULL,
  net_currency    CHAR(3) NOT NULL,         -- ISO 4217
  sell_gbp        NUMERIC(12,2) NOT NULL,
  margin_pct      NUMERIC(5,4) GENERATED ALWAYS AS
                  ((sell_gbp - (net_cost * fx_to_gbp)) / sell_gbp) STORED,

  -- Validity window, versioning
  valid_from      TIMESTAMPTZ NOT NULL,
  valid_to        TIMESTAMPTZ,            -- NULL = current
  superseded_by   UUID REFERENCES pricing_matrix(id),

  -- Audit
  created_at      TIMESTAMPTZ NOT NULL DEFAULT now(),
  created_by      UUID NOT NULL REFERENCES users(id),
  version         INT NOT NULL DEFAULT 1,

  CONSTRAINT no_overlap EXCLUDE USING gist
    (tour_template_id WITH =, party_size WITH =, hotel_tier_id WITH =,
     tstzrange(valid_from, valid_to) WITH &&)
);

CREATE INDEX idx_pricing_lookup
  ON pricing_matrix (tour_template_id, party_size, hotel_tier_id)
  WHERE valid_to IS NULL;

Versioning rules — applied across the model.

Try it. The advisor is live, scoped to a sample of AX's catalogue.

This is the actual claude-sonnet-4.6 model running through Vercel's AI Gateway against 157 real AX toursscraped from the existing site. The model is bounded by the same guardrails described below — try asking for Antarctica or somewhere AX doesn't cover, and watch what happens.

This demo is an illustrative example. The production advisor — its prompts, conversational flow, and behaviour — is tailored to AX following detailed requirements discussions.

How it's wired.

Tool-calling schema.

The model interacts with the platform through four named tools. Conversation orchestration is the model’s job; data retrieval and scoring belong to deterministic Cold Lava code.

Hallucination guardrails — three layers.

Cost model and controls.

Cost model: pay-as-you-go metered API with multi-layer cost controls. Per-session cost, with optimisations applied: £0.08–0.15; pessimistic ceiling £0.20. AI / API run-rate costs are carried by Cold Lava through the build and testing phases; metered cost passes to AX at handover.

The £400-per-booking concern — where the maths breaks down.

A fair question raised in scoping: could pay-as-you-go LLM costs, in a worst case, eat into tour margin? The reasoning — roughly £0.40 per advisor session against a 1-in-1,000 visitor conversion is ~£400 of LLM cost per booking, which a 10–15% gross-margin tour could not sustain. The arithmetic is sound. Three of the inputs are not.

At current Anthropic pricing, a 25,000-token session breaks down as below. With the optimisations in the six layers — prompt caching, model tiering, structured outputs — the working cost lands at £0.08–0.15, with £0.20 a pessimistic ceiling. £0.40 was a deliberately conservative pre-optimisation estimate, not the working assumption.

The 0.1% figure is the conversion rate across all visitors from a channel. Visitors who engage the advisor are a different population — they have self-selected by describing their trip in detail, which signals materially higher intent. Comparable high-intent conversational funnels convert at 3–5%, often higher on deep engagements: 30–50× the baseline channel rate. Using the general rate to price advisor cost dramatically overestimates cost per conversion.

Without protection, a single attacker could generate thousands of pounds of API spend in an hour. The answer is not a different pricing model — it is to stop automated traffic reaching the API at all. The bot-protection layer below reduces automated abuse to effectively zero before it generates any token cost.

Even on the pessimistic line, £30 of LLM cost on a £2,500 average booking is 1.2% of revenue — comfortably inside tour gross margin. The £400-per-booking figure requires every input at worst case simultaneously and every protective control absent; the architecture is built specifically to prevent that combination.

Six-layer defence-in-depth on run-rate.

Try the matching engine live.

Drag the sliders. The top-5 reorders in real time as the engine rescores every catalogue trip against your preferences. The score breakdown bars show which dimensions drove each placement. Six dimensions shown here for clarity — the production engine runs the full set detailed below, across both stages.

This demo is an illustrative example. The production matching engine — its filters, dimensions, weights, and scoring — is tailored to AX following detailed requirements discussions.

Try the structured trip builder.

The 6-step structured path — the default flow for most visitors. Each step writes to the same structured field set the matching engine consumes. This mirrors the functionality of AX’s existing trip builder, rebuilt to the platform’s design language.

This demo is an illustrative example. The production trip builder — its steps, options, and flow — is tailored to AX following detailed requirements discussions.

Matching engine: hard filters and scored dimensions.

The engine ranks trips against the customer’s stated preferences and returns a small ranked set — a top-5 with an overall match score. Not every input plays the same role. Some define structural feasibility and are applied as hard filters; the rest are weighted, scored, and ranked. A walking holiday returns walking trips — never a city break that happened to score well on budget and dates.

Applied before any scoring. A trip that fails one of these is excluded — or down-ranked so heavily it effectively never appears in the top results.

Run only on the trips that pass the hard filters. These contribute to the overall match score but do not exclude trips outright. Pace is decomposed into two underlying dimensions — physical intensity and schedule tempo — because it means two different things.

Safety and suitability overlay.

Certain combinations of customer attributes and trip attributes are treated as hard fails regardless of overall score:

The safety overlay is deliberately conservative. It is better to exclude a marginal-fit trip than to recommend something that would be unsafe or unpleasant for the traveller.

Configurable weighting.

The matching engine is data-driven, not hard-coded. Each scored dimension carries a weight (0–100) that determines its contribution to the overall match score. Weights are stored as a configurable data record, editable by Awesome Experiences without code changes, and new dimensions can be added with their own weights.

The initial weighting profile is provided by Awesome Experiences’ founder, William Burton, drawing on two decades of operating a tour-matching business. The weights themselves are provided at project kick-off; every weight shown or implied in this document is placeholder and illustrative until then. The relative shape is deliberate: destination and category weights sit very high — at near-hard-filter levels — while pace and adventure are important but subordinate, and other soft preferences lower still.

Booking-conversion data then refines the weights over time. The refinement is conservative— adjustments are small, validated against booking outcomes, and reversible if they degrade match quality. A poor initial profile destabilises the feedback loop, so AX’s existing operating intuition is the starting position; data-driven refinement layers on top of it, it does not replace it.

Damped feedback loop — how the algorithm learns.

The update rule.

# Pseudo-code — scored-dimension weights only.
# Hard filters (destination, activity type) and the safety
# overlay run before this; only trips that pass are scored
# and ranked here.

def update_weights(prefs, ranked_top5, selected_index, weights, alpha=0.15):
    selected = ranked_top5[selected_index]

    for dim in SCORED_DIMENSIONS:
        dim_score_selected = score(prefs[dim], selected[dim])
        dim_score_others = mean(score(prefs[dim], t[dim])
                                for t in ranked_top5
                                if t is not selected)

        # Reinforce dimensions where selected outscored others
        delta = alpha * (dim_score_selected - dim_score_others)

        # Damped update with bounds
        new_weight = weights[dim] * (1 + delta)
        weights[dim] = clamp(new_weight,
                             0.25 * INITIAL[dim],
                             2.00 * INITIAL[dim])

    return weights

Pace and adventure: getting the wording right.

The TripBuilder asks about pace and adventure in language that distinguishes the underlying dimensions without overwhelming the customer with questions. “How physically demanding do you want this trip to be?” drives the physical-intensity dimension. “How busy do you want your days to be?” drives the schedule-tempo dimension. Each question carries short helper text, so the customer always knows what it controls — the wording deliberately avoids the common mistake of conflating walking intensity with itinerary busy-ness.

Adventure level is asked separately again, and kept distinct from activity type — activity type is the categorical need, matched as a hard filter, not a slider. Where an answer is genuinely ambiguous, conversational follow-up and disambiguation are the job of the LLM Advisor: the structured TripBuilder stays structured, the Advisor is the conversational path, and both feed the same engine.

Two paths in, one engine.

The TripBuilder is the default flow for most visitors — its structured 6-step path handles the majority of trip-planning needs efficiently and intuitively. The AI Advisor is available for visitors with complex, multi-constraint, or free-form needs the structured path cannot easily express: pasted dream-trip descriptions, voice input, or unconventional combinations of regions and themes. Most visitors complete a trip via the TripBuilder; the AI Advisor is a power-user path.

Allowed actions — six, named.

Constraint engine — declarative DSL, evaluated per action.

Every action passes through a constraint engine before it commits. Rules are declarative (per-tour configuration, not hard-coded). If a rule fails, the customer sees an explanation, not a broken itinerary.

Live re-pricing pipeline.

Triggers and side effects.

Every transition is owned by a named event. The events listed are the load-bearing ones — the ones that move money, issue regulated documents, or notify external systems. Everything is logged to the immutable audit trail with correlation ID.

DMC email-confirmation model — edge cases.

Phase 1 uses an email-based DMC confirmation, not API integration. That constrains the failure modes we need to handle explicitly in the state machine. Each one below has an enforced behaviour, not an aspirational one.

Agent takeover.

Deposit + balance, decoupled.

Deposit and balance are separate Stripe PaymentIntents linked by booking reference. A partial refund on deposit does not corrupt balance state. A failed balance does not reverse the deposit. Each intent has its own webhook, its own state, its own audit row. Two money events are not one event.

Accounting webhook — the contract.

Every Stripe state transition fires a webhook to the accounting layer (Xero or QuickBooks at MVP launch, configurable). The webhook payload carries the fields below. AX’s accountant uses these to compute TOMS quarterly — the platform records the data, the accountant runs the calculation. TOMS-aware journal entries direct from the platform are Phase 2.

Capture points — six, distributed.

Every capture writes a row to the GDPR consent_ledger with timestamp, IP, and wording version. The platform never silently captures or repurposes data.

Recovery automation — five trigger paths.

CRM record shape.

The platform syncs records to AX's CRM (HubSpot at MVP launch, or equivalent — configurable) on every meaningful state change. The record below is the canonical shape; CRM-specific field mapping is configurable.

Email deliverability · ATOL certificates must never land in spam.

SendGrid handles transactional sends with Postmark as fallback (§015 stack). Beyond the provider choice, deliverability is its own discipline:

Deliverability monitored via SendGrid + Postmark dashboards plus weekly DMARC report review. ATOL cert delivery rate is a tracked SLO (target: 99.5% inbox placement, p95).

Screens · ten of them, all in MVP scope.

Role-based access · four roles.

What the portal covers.

After booking — a personalised checklist.

The moment a booking is confirmed, the portal switches the customer into a personalised to-do list — a clear, ordered view of everything they need to do and submit before they travel. Each item shows its status, what is needed, and a one-click action: upload a document, pay a balance, follow a link. It pulls directly from the pre-travel compliance checks in §018b, so the customer sees the same requirements AX’s staff track — visa requirements, passport validity, insurance proof, balance payments — without chasing or guessing. The journey is designed to be calm and obvious: the customer always knows exactly what is outstanding and what is done.

Why it matters.

JSON-LD structured data — six schemas.

Every page emits structured data. Google reads it for rich results; LLMs read it for retrieval-augmented generation. Both matter for travel discovery.

URL structure.

Server-rendered metadata.

Editorial blog module — Phase 2 framework, MVP foundations.

OWASP Top 10 — every category, named mitigation.

Beyond the checklist.

Disaster recovery · explicit RTO and RPO.

A fair question of any booking platform: what happens if Postgres is down for 4 hours mid-booking? Concrete answer below.

RTO = recovery time objective (how long until service restored). RPO = recovery point objective (acceptable data loss window).

Backup and continuity.

The platform is resilient to multiple categories of failure — regional outage, database compromise, code-host loss, slow corruption, operational error. The continuity model rests on three independent layers.

ATOL Certificate generation.

On confirmed booking (post-DMC accept — see §013 Booking Flow), the platform generates an ATOL Certificate PDF. The certificate is emailed to the customer, stored on the booking record, and an immutable audit log entry is written. ATOL legal model (Option A: AX as principal vs Option B: host operator agency) is confirmed at kick-off — see §002 Operating Model.

GDPR — consent, DSAR, erasure, residency.

Accessibility — WCAG 2.2 AA.

Terms & Conditions — visa requirements clause.

The clause above is indicative wording and is subject to legal review by AX’s solicitor before publication as live Terms & Conditions.

Pre-travel checks · MVP delivery vs Phase 2 upgrade.

Reminder cadence · seven touchpoints from deposit to T-1.

Customer assistance during travel.

Custom dashboards.

Four dashboards ship with the platform. Each is curated for a real AX user role — leadership looks at funnel + revenue, ops staff look at operational, the AX growth lead looks at AI advisor health.

The six principles, applied today.

Year 3 swap — what changes vs what doesn’t.

Mapped against today’s components. The honest assessment: the Integration Bus rewrites; everything above it stays.

Typography scale.

Motion principles.

Communication rhythm.

Test approach — five layers, each in CI.

Every failing test in CI blocks merge to main. No silent passes. Pre-launch: a one-week UAT window where AX staff exercise the platform on a staging URL, identical to production except for test Stripe keys.

Acceptance criteria — per proposal §3 deliverable.

Each deliverable in proposal §3 has a corresponding test that AX or Cold Lava QA executes at UAT. A deliverable is “accepted” when its test passes. AX signs off acceptance per row; aggregated sign-off triggers the final 34% invoice (proposal §6).

The five gates.

Drift protections — controls already in the contract.

The contingency model.

The £40k+VAT headline price covers everything in the agreed MVP architecture. A 10% scope-change contingency of £4,000 sits alongside it, available for items AX requests during the build that fall outside the agreed scope. It is not an automatic uplift and is not pre-billed — it is a pre-approved buffer for fast-tracking small, clearly-defined extras without a full re-proposal each time.

Insurance — three policies in force.

Certificates of insurance available on request before contract signature. Renewal cycle is annual; certificates re-issued automatically.

IP — clean assignment, full transferability.

Continuity — what happens if Cold Lava isn’t around.

Training & handover · seven sessions, then forty days of cover.

AX is replacing phone-call workflows with software. A single pre-launch handover session isn't enough — the schedule below replaces it with seven.

Written runbooks (every operational task).

Every runbook lives in docs/runbooks/ in the repository AX owns. Updated as the platform evolves.

Post-launch support window.

Continuity if Cold Lava is no longer involved.

If Cold Lava ceases to operate or is no longer engaged for any reason, AX has everything required to keep running and developing the platform without us. Concretely:

The platform is built on standard infrastructure (Vercel, GitHub Actions, Postgres) with no proprietary build steps. Any reasonably competent successor developer or agency can take over operation without rebuilding from scratch. Continuity is a transition exercise, not a recovery exercise.

Phase plan, week-by-week.

Visual timeline.

Buffer + slip handling.

Phase 2 inventory.

The problem.

Suppliers send contracts as PDF or Word documents — typically 10 to 20+ pages — defining tour content (route, hotels, excursions, components), date bands and blackout periods, pricing by season, room type and extra-night structure, and child pricing rules and occupancy constraints. Historically this data is manually keyed into the inventory system by staff or outsourced teams. Three concrete problems with that:

The stated goal is to replace the manual loading process with an AI-assisted agent that does the extraction and mapping, runs price sanity checks, and presents the result for human approval. Economically attractive at MVP scale; operationally vital at full scale.

What we will build.

A Contract Ingestion Agent that turns long, semi-structured supplier contracts into structured, quality-checked inventory records, so AX's team only needs to review and approve — not manually re-enter every figure. The agent will:

Requirements cross-reference.

Each requirement, as stated in scoping, mapped to the specific deliverable Cold Lava will build.

This is the layer that protects against the two business risks driving the module: financial catastrophe from price typos — a single mis-typed digit on a long-haul package sold twenty times wipes a quarter of the margin on those bookings, with no path to recover the loss under consumer-protection rules — and operational fallout from mis-interpreted rules, where an unusual child age or blackout pattern accepted as standard leads to bookings that cannot be honoured as priced.

Beyond the structured anomaly flags, the agent generates a short interpretive commentary on every contract — the qualitative “this looks unusual versus the normal pattern” judgement a human reviewer brings, expressed in language a product manager can act on directly.

The commentary draws on three inputs:

• The structured anomaly-detection output from the sanity-check layer (the numeric basis).
• Historical contracts from AX's supplier base (comparative anchors).
• Configured product knowledge: typical bands, standard child rules, typical seasonal patterns.

Worked examples.

Deliberately out of scope (v1).

To keep the v1 build focused, the following are explicitly not included, and would be quoted separately if added later.

Architecture summary.

The whole pipeline runs server-side. Nothing leaves AX's infrastructure except the LLM API calls, handled with the same data-protection controls as the rest of the AX platform.

Commercial structure.

The commercial structure is deliberately benchmarked against the ~£12,000/year cost of a manual contract loader — the role this module replaces. Year One is set to match that benchmark exactly — the same cash outlay as hiring the intern, but for an owned asset. From Year Two onwards the retainer steps up to its standard £4,000/year as volume and API usage scale, leaving the agent meaningfully cheaper than the manual benchmark every year thereafter.

Total cost picture.

Year One matches the outsourced alternative pound-for-pound — £12,000 either way — but that £12,000 buys AX an owned asset rather than twelve months of someone’s time. From Year Two onwards the saving is approximately £8,000 every year. Over three years AX saves roughly £16,000; over five years, roughly £32,000 — and those numbers are before counting the value of pricing errors prevented, which is the higher-impact saving in practice.

Why this is better value than the outsourced alternative.

The case for building this.

Beyond the price comparison, the economic case rests on five reinforcing arguments. Each would justify the investment on its own.

Why now, not later.

Deferring the build means continuing to pay an outsourced loader through Year One, then building the agent in Year Two. The two-year totals compare as follows.

Building the Contract Ingestion Agent alongside the MVP matches the outsourced alternative pound-for-pound in Year One — at the cost of hiring the intern, with an owned asset to show for it — then saves £8,000 every year thereafter, removes the launch-period error risk, eliminates the eventual transition cost, and gives AX a more accurate agent by the time it matters most.

What happens next.

Capabilities discussed.

Contacts.