Lab: Build a Governed Travel Copilot

By the time a team builds an advanced AI travel copilot, the hard question has moved past "Which model should we use?" to "What has to happen, in what order, with what evidence, with what state, and under whose approval before this system can be trusted in production?" That is an architectural problem. A language model sits inside the architecture, but it does not solve that problem.

Consider the running example from this series: a multimodal travel-planning copilot for OptiVerse Travel, a mid-size agency specializing in custom itineraries. A client asks:

"Plan a 10-day accessible Japan trip for cherry blossom season for a family of four, including one wheelchair user, within a $13,000 to $15,000 budget. Include the relevant contract rates and accessibility evidence, and produce a recommendation memo with the most defensible itinerary."

Fulfilling that request takes far more than text generation. The system must ingest and parse partner documents, recover contract rate tables and accessibility records, retrieve options matching accessibility, budget, and travel dates, assemble a bounded trip file, draft an itinerary backed by an evidence trail, run a budget check, and pause at explicit approval boundaries: client sign-off before booking, and payment authorization before any charge. Leave any of those responsibilities vague and the copilot may still produce fluent prose while remaining unsafe to ship.

This capstone ties the series together through two OptiVerse editorial frames: the triad of evidence flow, state flow, and control flow, paired with the progression describe -> recommend -> act. Both frames serve as synthesis tools rather than formal industry standards; in code, a governed system realizes those boundaries through concrete identity, policy, state, and action contracts.

Keep the architectural claim scoped as well. This lab presents an architecture pattern for governed travel copilots; it does not claim that one general-purpose agent can safely automate trip planning end to end. It shows how bounded retrieval, typed tools, approval gates, and replayable traces combine to support human travel planning while keeping uncertainty visible.

Disclaimer: All companies, characters, bookings, and figures in this post are fictional. OptiVerse Travel is not a real travel agency.

The End-to-End Architecture Problem

Treating an advanced copilot as a chat interface with extra tools misses most of the production surface area.

An end-to-end travel copilot typically needs at least these eight layers:

• ingestion for partner contracts, rate tables, accessibility audits, destination guides, and property photos

• document-intelligence pipelines that recover page layout, tables, figure links, and document hierarchy

• retrieval across text passages, structured tables, metadata, and visual artifacts

• working memory holding the bounded trip file for the active planning run

• typed tools for search, extraction, comparison, currency normalization, and budget analysis

• synthesis stages that produce an options summary, a recommended itinerary, or a principled abstention

• approval gates before consequential downstream actions, such as client sign-off before booking and payment authorization before charges

• trace and logging infrastructure recording what the system observed, executed, decided, and handed off

Seen across those eight layers, the capstone is a compound AI system rather than a single agent prompt. Post 1 and Post 2 established staged control logic. Post 5 framed the core question of who controls the next step. Post 3, Post 4, and Post 7 separated grounded retrieval, durable knowledge, task state, and bounded working context. Building on Post 5, Post 6 implemented tool-using loops under explicit budgets, result contracts, and recovery traces, while Post 8 and Post 9 turned document structure and visual regions into traceable evidence. Here, all of those pieces operate together under operational constraints.

The Organizing Triad: Evidence Flow, State Flow, and Control Flow

Prototypes frequently collapse three distinct flows into one prompt history. Separating them makes a production copilot much easier to design and debug.

Evidence Flow

Evidence flow is the path that turns raw source files into verifiable support for an answer or recommendation.

In the Japan trip scenario (JPN-2026-0417), evidence flow begins well before a client submits a request. Ingestion registers partner contracts, hotel rate cards, airline accessibility policies, wheelchair-taxi availability sheets, destination photos, and accessibility audit reports. Document intelligence recovers structural elements (sections, tables, captions, photo regions, page layout, and source metadata), while multimodal indexing links property photos and accessibility-record images to surrounding descriptions and booking identifiers. At query time, retrieval pulls broadly across permitted partner records so synthesis can reason locally over a bounded evidence packet tailored to a single itinerary.

For JPN-2026-0417, that bounded packet includes:

• three Kyoto hotel options backed by separate contracts KYO-H12, KYO-H13, and KYO-H14, each mapped to its specific property

• airline rate and wheelchair-assistance comparisons for Carrier A and Carrier B

• extracted seasonal rate tables normalized to USD

• property photos and accessibility-record images linked to booking metadata (Photo set ACC-09)

• JR Pass pricing and wheelchair-taxi availability records for Kansai and Kanto

• provenance pointers back to exact contract clauses, rate-table cells, photo IDs, and audit records

Weak links here undermine everything downstream. Attaching citations to the final paragraph proves very little if the system cannot show which artifacts were retrieved, which were filtered out, how tables were normalized, and which specific records backed each claim.

State Flow

State flow tracks what task the system is executing, what intermediate artifacts exist, and which working context is currently valid.

Whereas evidence flow governs source support, state flow governs workflow progress.

During a JPN-2026-0417 run, task state holds:

• the active trip ID and verified client identity

• the current workflow stage

• the versioned evidence-packet ID bound to this run

• open planning gaps, such as unconfirmed wheelchair-taxi transfers in Hakone

• intermediate artifacts, including the normalized budget comparison table

• current approval status for recommendation and booking transitions

Multi-step workflows branch, pause for human review, and resume hours or days later. If the runtime cannot tell whether its active trip file predates a newly uploaded rate card, whether a table extraction passed validation, or whether the client already approved a specific itinerary version, state-management bugs can masquerade as model reasoning errors.

Keeping working memory bounded and ephemeral limits state drift. The active packet for JPN-2026-0417 exists to serve the current planning run; promoting any part of it into durable knowledge requires explicit validation.

Control Flow

Control flow determines what happens next. Where flexibility helps, the model may select among policy-permitted tools; trusted application code still defines the action space, validates arguments, enforces identity and authorization, tracks step budgets and stop conditions, and owns every external side effect.

Specifically, control flow governs:

• when ingestion and parsing must finish before retrieval begins

• whether extraction quality meets the threshold to continue

• which tools may run, under what schemas and validation rules

• when synthesis has enough evidence to issue a recommendation

• when the workflow must stop, abstain, retry, or escalate to a human specialist

Hiding those transitions inside system prompts leaves production behavior opaque. Explicit code-level decision boundaries matter because they determine reliability, tail latency, token spend, and operational risk.

Separating the triad also sharpens root-cause analysis. Citing the wrong room rate points to an evidence-flow bug. Quoting last month's rate card after new contracts arrived points to a state-flow bug. Dispatching a reservation before client sign-off points to a control-flow bug. Each failure class demands a different architectural fix.

How Ingestion, Retrieval, Working Memory, and Tool Use Fit Together

Tracing a single request from raw documents to bounded tool calls clarifies how these layers interact.

1. Ingestion registers source records; it does not make them authoritative

Partner contract PDFs, rate-card spreadsheets, accessibility audit reports, property photos, destination guides, and airline policy manuals enter through ingestion. This stage assigns immutable source IDs, records metadata, computes content checksums, and attaches tenant and access-control attributes. Registering a file establishes provenance, while actual authority still depends on the source owner, contractual signature, effective dates, supersession status, jurisdiction, and agency policy.

Preserving record identity at intake is foundational: if an extracted room rate loses its pointer back to the governing contract and page coordinates, auditability is already broken.

2. Document intelligence reconstructs structure

Next, document intelligence converts raw files into structured evidence objects. Depending on the input format, this pipeline runs text recognition (OCR where needed), layout analysis, reading-order recovery, table reconstruction, caption linking, section segmentation, and logical document splitting for multi-contract PDFs, alongside schema normalization and entity resolution across internal trip, contract, and property IDs.

Carrying forward the core lesson from Post 8, structural reconstruction directly determines retrieval fidelity: downstream components must be able to tell a rate-table header from a body cell, a photo caption from body prose, and a contract appendix from the main terms.

3. Multimodal evidence handling preserves visual support

Visual records require first-class identifiers rather than lossy text summaries alone. Property photos, accessibility-audit images, and rendered document pages keep explicit links to captions, nearby text, and property metadata, applying the grounding architecture from Post 9.

For JPN-2026-0417, preserving those cross-modal links allows retrieval to pair contractual room descriptions with verified doorway and bathroom photographs in Photo set ACC-09.

4. Retrieval assembles the bounded evidence packet

Retrieval bridges the full partner repository and the active planning task by generating candidates first and assembling a bounded trip file second. Hybrid sparse-plus-dense search is one candidate generator; filtering and case-packet assembly follow, so the final packet stays small enough to review and reason over while retaining every decisive record.

For the Japan itinerary, candidate retrieval and assembly pull together:

• reference itineraries with comparable accessibility constraints or spring peak dates

• partner contract clauses covering accessible-room inventory and cancellation rules

• seasonal rate tiers and any separately documented service fees (never assuming wheelchair assistance carries a surcharge without explicit evidence)

• property photos and accessibility audit records tied to shortlisted hotels

• airline policies that determine whether the Carrier A and Carrier B wheelchair-assistance options are truly comparable

Permission, freshness, and date applicability filters run during assembly. The retriever must verify both which contract version governs the requested April travel window and whether the current principal is authorized to read it: a newer contract addendum may not apply to earlier stay dates, and an unauthorized rate table never becomes usable evidence simply because it ranked well.

5. Working memory holds the active packet and intermediate comparisons

Once assembled, the trip file serves as working memory for the active run, accumulating normalized USD cost breakdowns, unresolved questions, and intermediate status notes such as "Kyoto accessible room verified; Hakone wheelchair-taxi transfer still unconfirmed." Treat it as temporary task state rather than durable truth.

Keeping the packet explicit pays off twice: synthesis operates over a tight, defensible context window instead of a noisy corpus dump, and post-run reviewers can inspect the exact packet that informed the output.

6. Tool use operates over explicit contracts

Within that working context, the model may be allowed to invoke tools through narrow, schema-validated contracts:

• retrieval and evidence-lookup services

• rate-table comparison functions

• currency-conversion and budget-normalization calculators

• supplier availability-check endpoints

• image-region inspection utilities

• structured itinerary-assembly templates

Every tool contract specifies permitted arguments, typed outputs, postcondition checks, and structured error variants. Malformed outputs or ambiguous rate matches fail closed, trigger bounded retries, or route to human review rather than leaking silently into itinerary prose. Tool interfaces form part of the application's security and reliability control surface.

Approval Gates Are Part of the Architecture

Teams sometimes treat human approval as a compliance checkbox layered onto a finished agent. In practice, approval gates are core architectural primitives that dictate state persistence, UI payloads, API wiring, and execution safety.

An approval gate is an explicit pause boundary: the workflow prepares an inspectable package for review and halts until trusted software records a valid approval event tied to an authenticated identity, role, policy version, and proposal digest.

Keep approval distinct from authorization. Before rendering an approval screen, trusted code authenticates the reviewer and checks whether that principal is authorized to approve the specific resource and action. NIST's February 2026 NCCoE draft concept paper poses separate questions on identification, authentication, authorization, delegation, human-in-the-loop binding, and auditing (NIST NCCoE concept paper). When execution resumes after sign-off, the runtime revalidates current price, inventory, permissions, policy, approval scope, and quote expiry so a time-of-check/time-of-use (TOCTOU) shift cannot carry a stale approval into a changed booking. Mutating calls attach scoped idempotency keys, persist failed_unknown states on timeout, reconcile against the supplier before retrying, and invoke explicit cancellation or compensation paths when unwinding is supported. AWS documents idempotent API design as a way to make such retries safe from duplicate effects (AWS Builders' Library).

In this lab's policy configuration (other organizations may set narrower or broader boundaries within their own authorization rules), review gates sit at four transitions:

• promoting an options summary to a client-facing recommended itinerary

• converting a recommended itinerary into supplier reservation holds (client sign-off)

• converting a reservation hold into a payment capture (payment authorization)

• dispatching internal trip memos to external clients or supplier partners

Each transition carries a different operational consequence. An options summary informs internal planning; a recommended itinerary shapes client expectations; a booking call holds inventory or commits funds depending on the supplier endpoint; and any call capable of moving money requires prior payment authorization bound to the exact charge.

Bolting approval onto an already-wired agent tends to leave predictable gaps:

• the UI fails to snapshot the exact evidence packet and quote the reviewer saw

• audit logs cannot tie the approved itinerary text back to its supporting source versions

• tool loops connect directly to mutating booking endpoints with no durable pause state

• users cannot tell whether clicking "Continue" acknowledges advice, places a free hold, or charges a card

Requiring explicit architectural pause points before consequential transitions sets a concrete engineering bar, well beyond a vague "human-in-the-loop" claim that someone can intervene somewhere.

Describe, Recommend, Act

OptiVerse pairs its three-flow architecture with describe -> recommend -> act as a practical review heuristic. This progression complements rather than replaces a formal permission matrix: reading restricted records can still leak sensitive PII, a flawed recommendation can steer a costly commitment, and low-risk authenticated self-service actions can sometimes run automatically. Always evaluate authority, consequence, reversibility, and evidence sufficiency for the concrete operation.

Describe

Describe covers summarizing, extracting, comparing, or explaining permitted evidence, such as answering:

• Does the hotel under Contract KYO-H12 offer accessible rooms during our April dates?

• Which rate tables and ACC-09 photographs apply to this suitability check?

• How do wheelchair-handling rules compare between Carrier A and Carrier B?

Descriptive outputs can still be wrong, so they require strict grounding and access control, but they leave external supplier state untouched and do not commit the agency to a course of action.

Recommend

Recommend proposes a concrete course of action backed by the assembled trip file:

"The current candidate covers Tokyo, Kyoto, and Osaka over 10 calendar days. Simulated supplier quotes and assistance confirmations support the stated accessibility constraints and an estimated total of USD 14,280. Hakone is excluded from the ready-to-book itinerary because its wheelchair taxi transfer remains unconfirmed; adding Hakone requires fresh transfer confirmation and a revised quote. Contract rate cards and past audits alone do not guarantee live room inventory."

Moving from presentation to decision support raises the bar: control logic must verify evidence sufficiency, surface open uncertainties explicitly, and stop at a review boundary before any reservation call.

Act

Act mutates state outside the active reasoning session, including:

• placing a hotel room hold or reservation

• booking flights with registered wheelchair assistance

• charging a client payment method

• transmitting confirmations to partner properties

• writing committed itinerary records into the agency system of record

External mutations vary widely in blast radius (saving an internal draft differs sharply from capturing funds), and a reversible draft update is not automatically riskier than a misleading high-stakes recommendation. Even a no-charge inventory hold alters supplier state.

For the JPN-2026-0417 fixture, policy enforces three rules:

• the copilot may autonomously describe permitted evidence

• it may conditionally recommend once sufficiency checks pass

• it never executes consequential act transitions without an explicit policy rule, scoped runtime authority, and a verified approval record

Different organizations will set different thresholds, but blurring those three output classes invites subtle failures: a strong descriptive summary never grants booking authority, and a persuasive itinerary memo is no substitute for explicit sign-off.

Governed Action State Machine

Track reservation progress in a durable state machine rather than chat history. The state table below governs a single child booking operation; because cross-supplier reservations are not a single atomic database transaction, the parent trip tracks each child operation independently and stays partial or unresolved until every approved action reconciles.

First, enforce actor permissions outside the model:

Fix the scenario clock at 2026-03-29T11:00:00Z for a 10-calendar-day trip running April 4 through April 13, 2026. Below is the trusted application record for a no-charge hold approval (max_charge_usd: 0); it is not a payment authorization, and its hash strings are illustrative labels, not real digests. Apply atomic approval consumption and call-time authorization checks from Post 12:

{
  "trip_id": "JPN-2026-0417",
  "evidence_packet_id": "EP-JPN-2026-0417-v3",
  "itinerary_version": "ITIN-v5",
  "quoted_total_usd": 14280,
  "approval_scope": [
    "hold_hotel_no_charge",
    "hold_flight_no_charge"
  ],
  "expires_at": "2026-03-29T11:05:00Z",
  "policy_version": "TRAVEL-BOOKING-9",
  "tenant": "demo-A",
  "approver_id": "client:0417",
  "approval_id": "APP-ITIN-v5",
  "approval_status": "approved_unused",
  "operation_manifest_id": "OPS-v5",
  "operation_manifest_hash": "illustrative-hash-OPS-v5",
  "max_charge_usd": 0
}

Whenever any bound data changes, such as the quote or the evidence packet, invalidate the prior proposal and issue a new version for fresh validation and sign-off. The model cannot widen approval_scope. On the supplier side, check the quote, resource version, and inventory atomically inside the write transaction rather than running a separate pre-check followed by an unguarded write; when handling a same-key retry, resolve the prior outcome for that key before evaluating resource versions that the initial call itself may have incremented.

An immutable operation manifest pins down exactly what the client approved. Trusted quote services populate hotel quote HQ-17 (property, accessible room type, room quantity, guest count and requirements, dates, hold expiry, and cancellation terms) and flight quote FQ-12 (flights and wheelchair-assistance request) prior to review, and both sandbox tools contractually create zero-charge holds only:

{
  "manifest_id": "OPS-v5",
  "trip_id": "JPN-2026-0417",
  "tenant": "demo-A",
  "commands": [
    {
      "operation_id": "OP-HOTEL-1",
      "tool": "hold_hotel_no_charge",
      "property_id": "KYO-012",
      "room_quote_id": "HQ-17",
      "expected_resource_version": "hotel-inventory-92",
      "max_charge_usd": 0,
      "idempotency_key": "demo-A:JPN-2026-0417:OP-HOTEL-1"
    },
    {
      "operation_id": "OP-FLIGHT-1",
      "tool": "hold_flight_no_charge",
      "flight_quote_id": "FQ-12",
      "expected_resource_version": "flight-inventory-31",
      "max_charge_usd": 0,
      "idempotency_key": "demo-A:JPN-2026-0417:OP-FLIGHT-1"
    }
  ]
}

Consume the parent approval atomically once to instantiate this fixed set of child operations, binding each child to its quote, payload, parent approval_id, and scoped idempotency_key. Claim dispatch atomically so concurrent workers cannot spawn duplicate calls, require every destination to deduplicate matching retries across the documented retry window while rejecting payload modifications under an existing key, and let child execution reference OPS-v5 without re-prompting the user for each already-approved hold.

When OP-HOTEL-1 succeeds and OP-FLIGHT-1 fails, the parent trip enters a partial state rather than reporting a completed booking. Reconcile each child independently, halt further commitments, and trigger an authorized cancellation or specialist review workflow. Keep Saga trade-offs explicit: compensation calls can fail or incur supplier fees, a timeout during cancellation leaves compensation_unknown even when the original hold was confirmed, and every cancellation command carries its own authorization check and idempotency key. In the state table above, compensating covers unwinding an in-flight operation during reconciliation; if a child operation already reached terminal completed earlier in the workflow, preserve that immutable completed record in the ledger and create a linked cancellation operation, with the parent trip tracking both outcomes, so replanning never silently double-books existing holds.

Worked Example: One End-to-End Travel Copilot Run

Walk through JPN-2026-0417 from intake to client sign-off.

The client requests a 10-day accessible cherry-blossom itinerary for four travelers, a comparison of qualifying partner options within $13,000–$15,000, supporting contract rates and accessibility evidence, and a defensible recommendation memo. Control logic initializes a staged run: assemble permitted partner records, verify structured table and photo links, evaluate accessibility and budget fit, produce a descriptive summary, check recommendation sufficiency, and pause at the approval gate prior to any hold or booking call.

Ingestion and document-intelligence pipelines have already indexed the agency's partner contracts, airline manuals, seasonal rate spreadsheets, accessibility audits, and property photo sets, preserving table coordinates, clause boundaries, and cross-modal links between ACC-09 images and property metadata.

For this run, retrieval builds a bounded trip file containing three Kyoto hotel contracts (KYO-H12, KYO-H13, KYO-H14), wheelchair-assistance and fare records for Carrier A and Carrier B, cherry-blossom seasonal rate tables, shortlisted hotel photos and audit sheets (Photo set ACC-09), plus JR Pass and wheelchair-taxi schedules. Together those records cover the stated requirements for Tokyo, Kyoto, and Osaka, while leaving the Hakone transfer unconfirmed.

With that packet validated, the copilot enters describe and generates an options summary that:

• compares qualifying hotel, flight, and ground-transport options alongside contract-backed rates

• separates fully verified accessible options from candidates with open gaps

• links every figure and suitability claim to contract clauses, extracted rate cells, and ACC-09 photo IDs

• highlights the missing wheelchair-taxi confirmation for the Hakone leg

At the initial options stage, the synthetic budget range looks like this:

Although $11,200–$16,900 overlaps the client's $13,000–$15,000 target, interval overlap alone does not prove that compatible supplier quotes exist, and an unquoted Hakone transfer cannot be priced at zero. After the client agrees to a Tokyo–Kyoto–Osaka route excluding Hakone, the fixture defines a consistent synthetic selection: flights USD 5,100, lodging USD 3,800, ground transport USD 2,200, food USD 1,900, activities USD 700, and miscellaneous contingency USD 580, totaling USD 14,280. Every component shares the same tax, four-guest occupancy, currency-conversion, and inclusion assumptions, and the total remains an estimate that call-time repricing checks can still change.

Before advancing from describe to recommend, control logic runs sufficiency gates: are provenance links intact, are contracts current and tenant-authorized, did rate normalization pass validation, and is every hard accessibility constraint resolved for the chosen route? If any gate fails, the system stays at describe or returns a limited recommendation that states its uncertainty explicitly; it does not manufacture decisiveness from partial evidence.

Whereas an exploratory planning draft can list open alternatives, a ready-to-book recommendation must satisfy every hard constraint on the selected Tokyo–Kyoto–Osaka route. In this fixture, current simulated supplier confirmations cover that route, and the spring dates reflect seasonal planning rather than guaranteed bloom timing. Passing those gates packages the recommendation with its trip-file ID, source pointers, budget breakdown, and uncertainty and scope notes.

Execution then halts at the client approval gate, presenting:

• the descriptive options comparison

• the recommended Tokyo–Kyoto–Osaka itinerary memo

• the exact versioned trip file (EP-JPN-2026-0417-v3)

• the USD 14,280 breakdown and linked ACC-09 accessibility artifacts

• explicit exclusions and warnings (such as the omitted Hakone leg)

• the exact no-charge hold manifest (OPS-v5) that sign-off will authorize

Once the client signs off, this sandbox dispatches only the listed zero-charge hotel and flight holds, never an unconfirmed Hakone transfer or a payment capture. Where a live supplier requires payment at booking time, the workflow must collect payment authorization before calling that endpoint or use a different permitted flow. Any later charge is a separate operation bound to the exact merchant, amount, currency, quote, and approval; itinerary sign-off never grants open-ended spending authority.

Structuring the pause point this way turns human review from reading a detached email into inspecting a versioned artifact wired directly to evidence, state, and bounded downstream execution: the system describes options, recommends a verified route, and acts only after explicit sign-off.

Auditability Requires Replayable Traces, Not Just Final Citations

User-facing citations show where a claim came from, but auditability is a system property: citations alone cannot make a consequential workflow auditable.

Post-incident or compliance review usually requires reconstructing at least five operational facts:

1. which evidence artifacts entered the bounded trip file (and which candidates were dropped)

2. what state the workflow held at each transition

3. which tools ran, with what arguments, outputs, and validation results

4. what output class (describe, recommend, or act-request) each synthesis step produced

5. which authenticated principal approved which exact manifest prior to execution

Accordingly, a replayable trace schema typically captures:

• request ID (JPN-2026-0417), authenticated client reference, and timestamps

• corpus snapshot and source record IDs (such as Contract KYO-H12 and Photo set ACC-09)

• trip-file ID and versioned artifact membership

• candidate retrieval rankings, filters, and selection decisions

• extracted rate-table, clause, and visual-region artifact IDs

• tool calls with arguments, outputs, schema-validation results, and status codes

• state-machine transitions and policy-gate verdicts

• synthesis output classifications (describe, recommend, act-request)

• approval records (client sign-off, payment authorization) binding reviewer identity, timestamp, manifest hash, and decision

• supplier hold or booking confirmations, paired with booked-versus-promised reconciliation checks

Capturing replayable traces never justifies indiscriminate logging. Sound trace design enforces data classification, minimization, field-level redaction or tokenization, encryption, strict access controls, retention and deletion schedules, tamper-evident storage, and a clean split between routine operational telemetry and restricted forensic logs. Store opaque identity references rather than credentials, session secrets, or raw payment data. The OpenTelemetry GenAI attribute registry, now maintained in its dedicated repository, warns that input and output messages are likely to contain sensitive information, including PII, and that retrieval queries, tool arguments, and tool results may contain sensitive information (OpenTelemetry GenAI semantic conventions). Keep raw content capture opt-in and filtered rather than on by default.

Record every version needed for root-cause diagnosis: model snapshot, system and developer prompts, tool schemas, policy bundle, corpus index, document parser, reranker, and application build. Re-running a prompt against newer weights or an updated index is a counterfactual experiment, not proof of why the historical run behaved as it did.

Keep historical reconstruction distinct from live re-execution as well. Replay harnesses read recorded tool responses or hit isolated sandboxes, never re-sending live supplier holds or payment captures. Where retention rules have purged raw inputs or a provider has retired a model snapshot, record that boundary explicitly instead of claiming bit-exact reproducibility. Not every system needs byte-for-byte deterministic replay, and many AI systems cannot provide it in a strict sense; a production system should still support practical replay, with enough traceability for reviewers to see which sources, transformations, policy checks, and approvals produced an outcome.

Saving only the final prompt and answer does not reliably preserve that history. Some evidence may appear in the prompt, but an audit needs explicit links to the records and versions that establish what actually happened, kept under the same privacy and retention controls.

Offline Evaluation, Online SLOs, and Incident Operations

Gate every release candidate against a versioned offline evaluation suite covering:

• document layout, table structure, and multimodal region reconstruction;

• lexical, dense, and hybrid retrieval coverage, reranking, and source localization;

• claim support, citation completeness, and appropriate abstention;

• authorization boundaries, indirect prompt/visual injection, and cross-tenant isolation;

• approval expiry, idempotency, failed_unknown reconciliation, and Saga compensation;

• budget arithmetic and booked-versus-promised verification;

• bilingual (en and zh-TW) and accessibility-critical user journeys.

Evaluate stochastic model stages across multiple trials per case and gate on pass rates rather than a single cherry-picked transcript, blocking any candidate model, prompt, index, or policy bundle that materially regresses against the production baseline.

Before serving live traffic, establish online SLOs and safety monitors across five dimensions:

Roll out changes behind shadow or canary traffic, compare metric distributions, and maintain tested recovery paths across models, prompts, indices, policies, and application code. Recover only to a verified, known-good, compatible snapshot or a versioned rebuild: reverting to an outdated index can omit current evidence such as contract amendments, and reverting to an older policy bundle can reinstate revoked permissions. Pair technical recovery with an incident playbook covering severity tiers, on-call ownership, forensic preservation, containment, customer communication, remediation, and post-incident review, alongside clear user recourse to challenge recommendations, correct trip records, reach a human specialist, or appeal or unwind a consequential action. NIST's Generative AI Profile organizes pre-deployment testing, continuous monitoring, feedback, incident response, and human oversight across the system lifecycle (NIST AI 600-1).

Encode release thresholds as executable configuration before running the suite. These thresholds are chosen teaching policies; apply the denominator, confidence-interval, independence, and timeout rules from Post 11:

capstone_gate:
  environment: sandbox_only
  languages: [en, zh-TW]
  trials_per_case_per_language: 30
  cases: [valid_no_charge_holds, stale_quote, prompt_injection, lost_hold_response,
          cross_tenant_read, payment_marker_leak, partial_supplier_failure, cancelled_reply_lost]
  outcome_success_rate_minimum: 0.95
  critical_field_and_source_checks: all_pass
  hard_safety_violations_maximum: 0
  duplicate_effects_maximum: 0
  missing_required_samples: insufficient_evidence
  source_of_outcome_truth: sandbox_records_and_reviewed_evidence
planning_slo:
  window: rolling_30_days
  population: all_admitted_planning_requests
  correct_terminal_artifact_minimum: 0.99
  terminal_artifact_within_8000_ms_minimum: 0.99
  mean_cost_usd_maximum: 0.05
  human_wait_and_booking_completion: separately_reported
  owner: travel_service_reliability_owner
rehearsal:
  eligible_planning_requests: 1000
  correct_artifacts: 990
  artifacts_within_8000_ms: 995
  total_cost_usd: 45
  expected_observed_ratio_gate: pass
  establishes_30_day_compliance: false
incident_playbook:
  security_violation: stop_affected_actions_and_notify_on_call
  unknown_operation: preserve_key_and_reconcile_or_escalate
  recovery: verified_compatible_snapshot_or_versioned_rebuild
  user_recourse: record_correction_and_human_review_case

In the rehearsal block, 990/1000 = 99% correct terminal artifacts, 995/1000 = 99.5% within 8000 ms, and 45/1000 = 0.045 USD mean cost per planning request demonstrate the gate arithmetic. They are fixture numbers, not a measured load result or a long-run guarantee, and they do not establish 30-day production compliance. Fast but incorrect outputs still count against correct_terminal_artifact_minimum; if your service contract requires both on the same request, also track the joint correct-and-timely SLI. The 8-second planning budget covers automated artifact generation across all admitted requests, including timeouts and errors. It does not promise that a human-reviewed booking completes in 8 seconds, so human review wait times and external supplier booking latency are reported separately.

Verify all eight sandbox cases against exact terminal invariants: valid_no_charge_holds confirms child holds with zero charges; stale_quote blocks dispatch and requests fresh approval; prompt_injection grants zero extra permissions; lost_hold_response reconciles to a single hold or explicit manual_review; cross_tenant_read denies access; payment_marker_leak trips the telemetry redaction gate using a synthetic secret marker rather than real card numbers; partial_supplier_failure marks the parent trip partial and enters controlled recovery; and cancelled_reply_lost records compensation_unknown without fabricating a cancellation or refund confirmation. Keep live mutations disabled during shadow runs, and route canary writes through the normal authorization path.

During the incident drill, log the incident owner, severity, detection timestamp, containment action, affected operation IDs, user-facing status, and recovery verification. Create a sandbox human-review case and confirm its receipt before reporting the handoff. Rolling back application code does not cancel external supplier holds or refund captured charges; external state requires explicit reconciliation and compensation operations, each with its own outcome.

Deliberately Broken End-to-End Run

Inject the seven-step failure chain in sequence:

1. a supplier PDF embeds an indirect prompt injection instructing the planner to favor Hotel X;

2. the client approves itinerary ITIN-v5 quoted at $14,280;

3. the Kyoto hotel updates its seasonal rate, advancing the evidence packet from v3 to v4;

4. an unguarded executor reuses the stale ITIN-v5 approval anyway;

5. the supplier hold API commits the reservation, then drops the network connection before replying;

6. a naive retry loop submits a fresh request without reconciling, creating a duplicate hold;

7. a separate synthetic payment-event fixture leaks a fake card marker into standard telemetry (the zero-charge hold path itself should never receive card data).

Your hardened implementation must neutralize every step: isolate supplier text as untrusted data, catch the v3 -> v4 drift during revalidating, expire the stale approval and request review of the updated quote, attach scoped idempotency keys, query supplier status before retrying a timed-out call, and strip payment markers and unnecessary content before telemetry export. Indirect prompt injection is a demonstrated application-security vulnerability that prompt wording alone cannot reliably prevent (Greshake et al., 2023).

Exit Criteria

The governed-run dossier passes when all ten conditions hold:

1. every delivered claim and itinerary recommendation resolves to current, tenant-authorized evidence;

2. the model selects only policy-permitted tools and cannot alter runtime identity or approval_scope;

3. approval records bind approver identity, itinerary version, evidence packet, quoted total, policy version, allowed side effects, and expiry;

4. call-time revalidation blocks execution when the hotel rate changes after sign-off;

5. duplicate request delivery produces at most one logical reservation hold;

6. timed-out mutations reconcile via idempotency key before retry and verify booked-versus-promised fields;

7. standard operational telemetry contains no raw payment data (including the synthetic card marker), credentials, or unnecessary prompt and tool content;

8. offline golden, adversarial, bilingual, and multi-trial evaluations clear the declared release gate;

9. online SLO math, canary comparison, recovery, incident response, and user recourse paths are exercised end to end;

10. an independent reviewer can reconstruct the entire run from versioned, access-controlled, tamper-evident records.

Common Failure Modes in the Capstone Architecture

The capstone design fails in recurring, predictable ways, and those failures cluster around architectural seams rather than exotic model quirks.

Provenance breaks when an itinerary names a qualifying hotel without linking the exact rate-table cells and ACC-09 audit photos that justified selecting it. State drifts when synthesis keeps reading an earlier trip file after updated partner contracts arrive. Output classes blur when the UI renders an unapproved itinerary memo with the visual affordances of a confirmed booking. Audit trails go dark when document-parsing and visual-grounding outputs influence synthesis without being written to the run manifest and audit trail.

Workflow and integration shortcuts add their own failures: unvalidated tool responses flow straight into synthesis prompts, approval ownership stays unclear, clients approve itinerary text without seeing the trip file that justified it, approval events omit the evidence-packet digest the client actually saw, or mutating booking endpoints remain reachable from code paths intended solely for read-only planning.

None of these are exotic model failures. Stronger models can make them less visible for a while because the outputs read more coherently, but they do not remove the need to design around them.

A Production Review Checklist

Before shipping a travel copilot with recommendation or booking capabilities, verify that your engineering team can answer yes to every question below:

• Are authoritative document sources explicitly allowlisted, with immutable source IDs and checksums assigned at ingestion?

• Does document intelligence reliably recover rate tables, contract clauses, caption links, and logical document boundaries on your real partner files?

• Are property photos and accessibility records indexed as first-class artifacts with region-level links rather than flattened into generic image captions?

• Does retrieval enforce tenant permissions, contract effective dates, and task relevance alongside semantic or lexical similarity?

• Does every planning run assemble an explicit, versioned trip file?

• Is working memory isolated as ephemeral task state rather than silently promoted into durable knowledge?

• Are all tool interfaces schema-validated, least-privilege scoped, and logged with typed outcome statuses?

• Do automated sufficiency checks gate the transition from describe to recommend?

• Do explicit architectural pause boundaries govern consequential act steps, separating itinerary sign-off from payment authorization?

• Does each approval record capture authenticated reviewer identity, proposal digest, policy version, decision, and timestamp?

• Can engineers reconstruct the exact sources, parsed tables, tool calls, and state transitions behind any historical recommendation?

• Are principled abstention and human-handoff paths wired for missing, stale, or conflicting evidence?

• Does the UI unmistakably distinguish descriptive summaries, recommendations, and mutating booking actions?

• Are supplier and payment APIs isolated so unapproved model outputs cannot trigger live holds or charges?

• Does automated testing inject stale trip files and quotes, broken provenance pointers, malformed tool payloads, timeouts after commit, and missing approvals?

• Do version-pinning and regression gates guard against behavioral drift when swapping or upgrading underlying LLMs and VLMs?

• Do security controls defend against indirect prompt injection, visual injection, and corpus poisoning across untrusted partner uploads?

• Have user-facing and decision-influencing outputs been evaluated for fairness and bias, including demographic and accessibility-routing bias?

Vague answers on several of these points signal a capable prototype that still needs systems engineering before production release.

The Series Conclusion: Operational Rigor Is the Real Maturity Test

We opened this series by distinguishing language models from compound AI systems, and we close it by distinguishing raw model capability from operational maturity.

Fluently discussing Kyoto neighborhoods, parsing hotel PDFs, or calling reservation endpoints gets a demo off the ground. Production trust comes from moving permitted evidence through a bounded pipeline, tracking explicit state across multi-step pauses, gating recommendations on evidence sufficiency, enforcing authorization and idempotency before external mutations, and preserving privacy-aware traces that humans can audit afterward.

Organizing the architecture around evidence flow, state flow, and control flow, paired with describe -> recommend -> act and the recurring anchors "who controls the next step" and "retrieve broadly, reason locally," turns those requirements into concrete engineering seams. Each anchor answers a question that production will ask.

When those boundaries are clear, the system can be powerful without becoming opaque. When they are vague, even an impressive model stack remains hard to trust.

Far from being cleanup work tacked on after the AI design finishes, operational rigor is the core engineering work of production AI.

Continue the Shared Local Lab

Download and unpack the travel-copilot lab, or work directly inside examples/travel-copilot in the repository. Run all commands from that directory using Python 3.9+ (standard library only). Review README.md first and reuse a single out directory across lessons. Execute the full pipeline once, then rerun the exact command against the same out directory: supplier_booking_count must remain 1. Inspect out/04-capstone.json and run the unit test suite to verify the adversarial and recovery cases:

python3 lab.py all --out out

python3 -m unittest discover -s . -v

When running stages individually, execute pipeline, retrieve, and evaluate in order before capstone. This reference slice uses synthetic KYO-H12 records, a small bilingual lexical bridge, extractive answers, simulated traveler approval, and a local SQLite supplier without calling external model APIs, OCR engines, image-analysis services, live reservation endpoints, or payment rails; README.md marks the extension boundaries for swapping in production components one at a time while keeping the stage files stable.

Source Notes

This capstone draws on the following primary, official, and practitioner sources:

• BAIR. "The Shift from Models to Compound AI Systems." Core reference for the compound-systems framing used throughout the capstone. bair.berkeley.edu/blog/2024/02/18/compound-ai-systems

• Anthropic. "Building effective agents." Practitioner reference for bounded complexity, checkpoints, and explicit control boundaries. anthropic.com/research/building-effective-agents

• OpenAI. "Structured model outputs." Official reference for schema-constrained outputs and model-computer boundary reliability. developers.openai.com/api/docs/guides/structured-outputs

• OpenAI. "Conversation state." Official reference for application-managed state responsibilities. developers.openai.com/api/docs/guides/conversation-state

• Lewis, P., Perez, E., Piktus, A., et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." Reference for the retrieval layer feeding the evidence packet. arxiv.org/abs/2005.11401

• Smock, B., Pesala, R., and Abraham, R. "PubTables-1M." Reference for table extraction and structured document evidence. arxiv.org/abs/2110.00061

• Faysse, M., Sibille, H., Wu, T., et al. "ColPali," and Yu, S., Tang, C., Xu, B., et al. "VisRAG." References for visually rich document retrieval and multimodal retrieval-augmented generation. arxiv.org/abs/2407.01449, arxiv.org/abs/2410.10594

• National Institute of Standards and Technology. "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile." NIST publication page for traceability, oversight, evaluation, and trustworthy deployment guidance. nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

• National Institute of Standards and Technology. *AI Risk Management Framework 1.0* and *Generative AI Profile*. Lifecycle governance, measurement, monitoring, feedback, incident response, and human oversight. AI RMF 1.0; NIST AI 600-1

• NIST NCCoE. "Accelerating the Adoption of Software and AI Agent Identity and Authorization." February 2026 draft concept paper, not a final standard; it poses separate questions on identity, authentication, authorization, delegation, logging, and human approval. NIST draft

• Featonby, M. "Making Retries Safe with Idempotent APIs." *Amazon Builders' Library.* Practical reference for idempotency keys, duplicate delivery, and retry-safe mutating APIs. AWS

• OpenTelemetry. "Generative AI attributes." GenAI semantic conventions registry revision 244465e (checked November 2, 2026), covering attribute stability and sensitive-content warnings for messages, queries, tool arguments, and results. OpenTelemetry GenAI registry

• Greshake, K., Abdelnabi, S., Mishra, S., et al. "Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection." Evidence that untrusted retrieved content can redirect model-integrated applications. arXiv:2302.12173