Restoring a saved checkpoint changes whether a fresh host process can resume and apply a pending itinerary change. This example shows checkpoint continuation in a generic Python travel-booking flow.
The domain is a small travel-booking change flow.
The user requests a change from the current itinerary to a new itinerary. That change requires confirmation before the host applies it.
This is a generic Python example.
It does not call an LLM.
It does not use directive drafter.
Context Compiler owns:
- authoritative policy state
- the pending confirmation continuation state
- the checkpoint that captures both
In this example, the pending checkpoint state is what makes the resumed confirmation meaningful.
Restoring authoritative state alone is not enough to resume the pending change.
The host owns:
- the booking record
- checkpoint persistence
- request/process boundaries
- the runtime behavior that actually applies the itinerary change
The host reads authoritative Context Compiler state after confirmation and decides whether to apply the booking change.
This example does not re-send hidden instructions to a model.
The observable behavior change is host-side: the booking record changes only after a restored engine resumes the pending confirmation and authoritative state changes.
- The host starts with a booking on
boston_trip. - The user initiates a switch to
chicago_trip. - Context Compiler enters a pending confirmation state.
- The host exports and persists the checkpoint.
- A fresh host process restores that checkpoint into a new engine.
- If the user confirms, the host applies the itinerary change.
- If the user rejects or sends unrelated text, the booking remains unchanged.
From the repository root:
uv run python python/examples/checkpoint_continuation/example.py
uv run pytest python/tests/test_checkpoint_continuation_example.pyFor a request-boundary example, see python/examples/checkpoint_continuation/fastapi/README.md.