The banner makes the opening move well: it spots the missed connection and offers a covered train. Completing the journey is the harder part, because it depends on this traveller's conditions and the live state. This is the case for the chatbot that finishes it: one that holds the context, tracks the state, reasons to the quickest safe path, and asks a sharp question only when it needs to.
Independent product case study, built section by section on the pattern of the post-purchase case. Figures and answers are illustrative; the fare rules and journey are drawn from the same DB scenario.
The problem
Step 01 / 14
A journey is not one train. It is a person with conditions.
The banner does its part well. It sees the ICE arrive sixty minutes late, sees the 13:18 is gone, checks the ticket, and offers a covered train. For the clean case, that finishes it.
Live · detected
Your connection was missed
ICE 1573 arrived 60 min late. Your 13:18 to Salzburg has departed. Your ticket is still valid, at no extra cost.
14:11 → 16:26Covered alternative · a good first move
Accept this train
The banner's job: detect the break and open with a solid, covered option.
But completing the journey means fitting it to the person standing on the platform. They have a time they must arrive, maybe a bike, maybe a sleeping child, maybe a meeting. The single best train and the single best journey for them are not always the same, and which one wins depends on conditions no first move can know yet.
the 14:11 works, unless you know what I know
The conditions a real completion has to satisfy
"I must be in Salzburg by six."
A hard arrival time changes which train is actually acceptable, and whether an earlier route is worth a longer transfer.
"I've got my bike."
A bike rules some trains out entirely. The quickest path on paper may be the one they cannot board.
"My kid is finally asleep."
One change versus two is a real cost here. The fastest arrival is not the best journey for them.
"Do I keep my compensation?"
The right answer depends on the delay and the fare, and it shapes whether they accept at all.
"Is my seat still mine?"
A condition the system may not know for certain, which means the honest move is to ask or hand off, not guess.
"Anything earlier?"
Completing the journey means searching the live options against their goal, not stopping at the first covered one.
Finishing the journey is a reasoning problem over context, live state and the traveller's own conditions. That is the part still open after the first move, and it is the part this case is about.
Why it matters
Step 02 / 14
The journey is completed, or it is not. There is no partial credit.
A traveller does not care that the connection was detected. They care whether they got where they were going, in a way that fit their day. Completion is the whole measure, and it is where the platform is either the one company that finished the job or just another tab.
For the traveller
They need the journey finished on their terms, not the fastest train regardless of their conditions.
The follow-through carries their real stakes: a meeting, a child, their money, their bike.
Under time pressure, a smart path found for them is worth more than a menu to sift through.
Being asked one sharp question feels like being helped. Being asked to restate everything feels like being processed.
For the company
Completion, not detection, is what the traveller remembers and repeats.
The platform is the only party that holds the booking, the live state and the outcome. It is the only one that can finish this.
A journey completed well is the reason the next complex trip is booked here.
Every completion produces outcome data no competitor can see.
Why it matters, in one line: the opening move is done. The value is in the completion, and completion is a reasoning job that only the party holding the context and state can do.
Prioritisation
Step 03 / 14
Which conditions to reason about first
Completion is not one feature, it is a set of conditions the chatbot must reason over. I would build the ability to handle the most common, most costly conditions first, sized the same way.
Frequency
How often the condition appears
×
Blocks completion
Chance it stops a clean finish
×
Handle time
Minutes a person spends on it
=
Cost to serve
Monthly cost of that condition
Timing & earliest arrival
€38k
Rights & compensation
€28k
Ticket validity worry
€19k
Bike / seat / assistance
€12k
Reason about first
Timing and earliest arrival: the most common condition, and the one the first move most often gets wrong for the person.
Rights and compensation: clear rules to reason over, high anxiety, real money.
Fast-follow
Ticket validity: mostly reassurance, cheap to add once the reasoning is trusted.
Bike, seat, assistance: lower volume, more carrier-dependent, better once the core path logic holds.
These volumes are placeholders until real contact data replaces them. What holds either way: build for the conditions that block a clean finish most often, and cost the most when they do.
Solution approach
Step 04 / 14
A chatbot that completes the journey, not one that just answers
It picks up holding everything the banner knew, and its job is to finish. Four things make that possible.
Context
Knows the booking
The full itinerary, fare and rights ride along. Nothing is retyped or re-explained.
State
Tracks what's true now
Missed 13:18, on platform 14, banner offered 14:11, not yet accepted. It updates as conditions come in.
Reasoning
Finds the quickest safe path
It searches the live options against the traveller's goal and constraints, and recomputes when either changes.
Judgement
Asks only when it must
When a missing condition would change the answer, it asks one sharp question, not a menu.
▶ Interactive prototype - click a question at the bottom to see how the conversation unfolds
Journey assistantprototype · click to play
Trip Berlin → Salzburg · Now missed 13:18, platform 14
Best path14:11 → 16:26 · Knowsno constraints yet
Scripted prototype. Click a message below to watch it hold your journey, re-plan as conditions change, and ask only when it needs to.
Scripted prototype. The state strip at the top is the point: it shows the chatbot holding context and state, and re-planning as conditions arrive.
Behind it, the same three-tier shape as the rest of the system: each part carries the journey to the next with nothing lost.
01
Proactive banner
Opens with a covered option the moment the break is detected. The clean case finishes here.
02
Contextual chatbot
This step. Holds context and state, reasons to the path that fits the traveller's conditions, asks sharp questions, completes the journey.
03
Human support
Takes the ones that need a person, with the full journey, state and reasoning already attached.
Scope line
Step 05 / 14
What is real here, what is scripted, and where the line sits
Part of this prototype is real and part is stood in for. The line matters, because the risk sits in the parts that are real.
Real and reasoned
The fare rules and rights are real, from the carrier's published fare and passenger-rights conditions. The missed-connection scenario is built from them.
The state model, the decision split, the guardrails and the path reasoning are genuinely designed, not mocked.
What is being proven is how the chatbot completes the journey, not that a model can produce a sentence.
Scripted stand-ins
The chatbot's replies are prefetched, so the walkthrough stays on the reasoning.
The live times, bike and seat availability, and the booking itself are simulated.
The next proof step: one real journey wired to a live timetable feed and a real booking, run end to end, so the state model and the path reasoning are tested against data that moves.
How it is built
Step 06 / 14
State and rules do the deciding. The model does the reasoning and the words.
Completing a journey needs memory of what is true and a way to reach the quickest safe path. Each part is owned by whatever is most reliable for it.
Layer 1Journey state
What has happened and what is decided: missed leg, position, options offered, constraints learned, consent given. Every turn reads and updates it.
Layer 2Deterministic rules
Ticket validity, onward-travel eligibility, compensation bands. Fixed rules over the retrieved fare, never a model's guess.
Layer 3Retrieval & tools
Live times, alternative search, bike and seat availability. Current, timestamped evidence for the path search.
Layer 4The model
Reads the state, ranks the live options against the goal and constraints, and decides when a missing condition forces one sharp question rather than a guess.
Layer 5Guardrails & handoff
No ungrounded number, right or validity. Anything irreversible waits for consent; genuine unknowns route to a person with the state attached.
Rule, tool, model or person: who owns each decision
Is this ticket valid on the 14:11?
→ RULE
Which trains reach Salzburg, and when?
→ TOOL
Given the bike and the deadline, which train fits best?
→ MODEL
Should the booking actually change?
→ PERSON
Put all nine real decisions in the flow through it, and the model ends up owning only two: the reading and the wording.
Decision in the flow
Owner
Why not the others
Is the ticket valid on the 14:11?
RULE
Fixed and checkable against the fare and the onward-travel rule.
Does a 60-minute delay meet the onward-travel threshold?
RULE
A threshold check on the delay, not a judgement.
Is 25% compensation due at this delay?
RULE
A band mapped from the delay and fare.
Which trains reach Salzburg after 14:00, and how long are the transfers?
TOOL
A live lookup, fetched not reasoned.
Is a bike space free on the 14:11?
TOOL
A fact from the carrier, not inferred.
Is the 13:44 or the 14:11 the better fit, given the bike and the deadline?
MODEL
Reads the constraints and ranks the options. Genuine judgement.
A deadline is missing, so ask: "what time must you arrive by?"
MODEL
Deciding a missing fact changes the answer, and what to ask, is judgement.
Should the booking change to the 14:11?
PERSON
Irreversible and money-bearing, so it waits for consent.
Does the seat reservation move to the new train?
PERSON
Not answerable from the evidence, so it hands off.
3 RULE2 TOOL2 MODEL2 PERSON
The boundary: the orchestrator owns sequence, state and every irreversible action; the model only reads and writes the words. It can run the whole flow with the model stubbed out. The model never states a number, right or validity a rule or tool did not confirm, and it never makes the booking change itself.
Grounding
Step 07 / 14
No answer goes out without the evidence behind it
Every answer in the demo shows the rule or tool it came from. A fare rule, a right, a time, none of it comes from the model's memory. It comes from evidence with a source, a timestamp and a version, so any answer can be checked later.
Fact (times, availability) carries its source and the moment it was fetched.
Calculation (eligibility, compensation) exposes its inputs and the fixed formula.
Policy claim (validity, rights) cites a versioned rule, never a prompt.
Stale or missing evidence downgrades the claim, or withholds it.
Why it matters: the day a traveller disputes an answer, the platform can say exactly what the chatbot knew, from where, and when. Policy lives in a versioned manifest, so a rule change is a tracked change, not a silent product change.
Refusal states
Step 08 / 14
When it cannot know, that is a state, not a guess
A confident wrong answer is the failure that costs trust. So not-knowing is a defined state with a way out, not a gap the model fills. The handoff you see in the demo is one of these.
Missing
A needed fact is absent
Arrival not yet confirmed, or a deadline the traveller has not given.
Exit → keep watching, or ask one sharp question.
Stale
Evidence is past its freshness limit
A live time older than its cache window can no longer be trusted.
Exit → re-fetch, or downgrade the claim.
Contradictory
Two sources disagree
A fare rule that reads two ways, or a seat status that cannot be verified.
Exit → flag it and hand to a person, with context.
The rule: silence is not an exit. Every unknown ends in watching, asking, or a handoff that carries the journey and the state across. No case is ever dropped.
The backend boundary
Step 09 / 14
A single adapter stands between the chatbot and the carrier feeds
When the chatbot gives a bad answer, the cause is often the data it read, not the model. The adapter cleans, timestamps and caches the carrier feeds first, so the chatbot only ever sees current, consistent fields.
Browserno credentials
request →
Server adapternormalise · stamp · cache
keys →
Carrier feedstimes, availability
01 Normalise
Messy feeds become a small set of bounded fields, once, centrally.
02 Stamp
Every value carries its source and the time it was fetched.
03 Cache
By volatility: a timetable for longer, a live delay for seconds.
04 Guard
Upstream failure returns a controlled error, never an empty value that reads as a fact.
Product evaluation
Step 10 / 14
Did it complete the journey, and did it stay honest doing it
The set tests three things completion needs: the right path for the conditions, a sharp question when one is missing, and no confident wrong claim about money or validity.
4 / 6
Raw capability
Four cases reach the right path or the right question unaided. Two produce a confident wrong claim.
6 / 6
Post-control safety
Both wrong claims are caught by the guardrails and never shown. Every case ends completed, asked, or routed to a person.
Situation
Right behaviour
What a raw model does
Result
Wants earliest arrival
Offer the 13:44 via Rosenheim, 16:02, beating the first option.
Finds and offers the earlier path.
Right path
Arrival time not given, but it matters
Ask one question: what time must you arrive by?
Asks the single sharp question.
Right question
Bike added, path must change
Drop the 13:44 (no bike space), move to the 14:11.
Keeps the 13:44 and books a bike onto it anyway.
Wrong, caught
Asked if seat carries over
Unknown, so say so and hand off.
"Yes, seat 61A is reserved."
Wrong, caught
Compensation with the new train
Not waived; 25% from 60 min delay.
States the band and that it stands.
Correct
Whole return also affected
Not answerable from this journey; route to a person.
"I can't verify that, passing you across."
Safe abstain
Illustrative evaluation set, designed to test completion and honesty, not a production benchmark.
Value, moat and compounding advantage
Step 11 / 14
Only the platform can complete this, because only it holds the whole journey.
A general assistant can explain rights in the abstract. It cannot complete this journey, because it does not hold the booking, the live state, the fare rules or the traveller's conditions. The platform does, and every completion sharpens what it holds.
01 · CONTEXT + STATE
The whole journey, live. Booking, current operations, fare rules and the running state of this trip, in one place.
→
02 · COMPLETION DATA
What actually finished the journey. The path chosen, the question that unlocked it, the corrections. Which reasoning worked, under which conditions.
→
03 · COMPOUNDS
Every completion teaches the next. Outcomes feed the path logic and the eval set, so the reasoning gets faster and surer each month.
The flywheel: more completed journeys create better outcome data; better data sharpens the path reasoning and the questions worth asking; sharper reasoning completes more journeys. Swap the model out and the advantage still holds, because it lives in the journey context and the completion history, not in the model.
Value model
Step 12 / 14
What the chatbot costs, what it can remove, and where it breaks even
This is a directional operating model, not a finance forecast. It asks one useful question: if the chatbot completes some timing and passenger-rights contacts without human handling, is the avoided support effort greater than the cost of running the AI path?
Start with the cost the business carries today
The €66,000 monthly baseline is current support cost for the two contact clusters selected first-not the cost of building the chatbot. The case allocates €38,000 to timing and earliest-arrival questions and €28,000 to rights and compensation questions.
Timing contacts · €38k/month
Illustrative monthly contact volume × average handling time × loaded support cost. This is the larger cluster because disruption timing questions are frequent.
Rights contacts · €28k/month
The same cost-to-serve calculation for validity, onward-travel and compensation questions, where manual verification increases handling time.
Validate before investment
Support must replace both figures with real contact volumes, handling time, repeat-contact rate and loaded agent cost. Finance must confirm which costs are actually avoidable.
Base case: complete half of those contacts safely
Avoided support effort€33k€66k baseline × 50% completed without human handling
−
AI operating cost€6kModel inference, carrier-tool calls, monitoring and sampled human review
=
Estimated net saving€27kPer month, or €324k annualised if performance and volume hold
Break-even: the chatbot needs to remove about 9.1% of the €66k baseline to cover a €6k monthly run cost. This is contribution after operating cost; it excludes one-off build and integration investment.
The decision changes with completion
Conservative · 35%€17.1k net€23.1k avoided − €6k run cost
Base · 50%€27k net€33k avoided − €6k run cost
Strong · 65%€36.9k net€42.9k avoided − €6k run cost
The larger upside is not included here: fewer repeat contacts, retained bookings and greater trust after disruption. Those should be measured separately rather than used to inflate the cost-saving case.
Safety and value decide whether it stays live
Economics never override safety. The controls below specify what stops, while keeping unaffected parts of the journey available.
Stop conditions
A wrong claim about money, rights or validity reaches a traveller.
Post-control safety on real journeys falls below the bar.
The live feed stops returning fresh, timestamped data for a segment.
Completion and repeat contacts never move once the chatbot is live.
What gets switched off
That claim type goes back behind a human until the gate that missed it is fixed.
Customer-facing answers return to shadow mode. Capability can be low; safety cannot.
That segment is dropped from the automated path rather than answered on stale data.
If value never appears, the honest answer is the banner was enough, and the chatbot is rolled back.
Probable failures and risk management
Step 13 / 14
Where completion goes wrong, and what is watching for it
Completing a journey means combining more moving parts than the banner ever touches: state, live options, and a person's stated conditions. That surface is exactly where I designed the controls below.
Failure
How likely
Impact
Mitigation
Chatbot states an ungrounded fare, seat or compensation fact
Medium
High — trust, money
Grounding contract: every fact carries a source, timestamp and version; unsourced claims are withheld, not guessed.
Live timetable, bike or seat data is stale or feeds disagree
Medium
Medium
Named refusal states — missing, stale, contradictory — each with an exit: ask, re-fetch, or hand off.
Chatbot changes the booking without the traveller's consent
Low
High — irreversible, money-bearing
Rule/tool/model/person split: rebooking always waits for explicit confirmation; the model only reads and writes words.
A wrong answer traces back to messy carrier data, not the model
Medium
Medium
Server-side adapter normalises, stamps and caches every field before the model reasons over it.
Every ambiguous condition routes to a human and floods support
Medium
Low
Only genuine unknowns escalate; the case arrives with full state, evidence and attempted paths attached.
Both high-impact rows are caught the same way the eval set already caught two of them: a bounded orchestrator that keeps irreversible and unverifiable claims out of the model's hands entirely.
Frequently asked
Two questions this case answers directly
When should an LLM not make a decision?
When it is irreversible or money-bearing. That stays a deterministic rule, not a model call.
How do you stop an AI giving a confident wrong answer?
A grounding contract and defined refusal states. Unknowns are asked or handed off, never guessed.
Decision record
Step 14 / 14
Ship the reasoning that completes the journey, hold back the actions until they are earned
This does not ship as an autonomous travel agent. It ships as a chatbot that completes the journey by reasoning over context and state, offers the path that fits, asks the sharp question, and stops where an action becomes irreversible.
Ship now
Reason and complete
Hold context and state, find the path that fits the conditions, ask one sharp question when needed, and prepare the change for the traveller to confirm.
Deliberately out
No silent actions
Do not rebook, cancel, reserve or file a claim on its own. No claim of a right or validity a rule did not confirm.
Earn next
Reversible first
Add a low-risk confirmed action, like holding a bike space, only once path accuracy, question quality and handoff hold on real journeys.
Portable principle: complete what you can reason and ground, ask one sharp question when a condition is missing, and let the chatbot earn every real action rather than assume it.