FamilyTrip OS
AI can propose. Rules decide. Families stay in control.
Inspiration
Most AI travel planners are designed to generate an itinerary from scratch. But real family travel becomes much harder after hotels, flights, tickets, accessibility needs, and shared commitments have already been agreed upon.
At that point, a plausible AI suggestion can still cause real problems: it may overwrite a protected activity, ignore travel time, move the wrong family member, or silently replace an itinerary everyone already trusts.
I wanted to explore a different model:
What if AI could propose a change, without becoming the authority that decides whether the change is safe?
Before OpenAI Build Week, this project was a static travel companion for a family itinerary. During Build Week, I transformed it into a governed AI patch system with server-owned state, deterministic validation, exact approval binding, atomic application, and safe restoration.
The submitted version uses a sanitized, real-world-inspired Phu Quoc itinerary with synthetic dates, demo flight identifiers, generic traveler descriptions, and public-safe hotel labels.
What it does
FamilyTrip OS allows GPT-5.6 to propose a bounded, typed Trip Patch instead of rewriting an entire itinerary.
The model may propose:
- the affected time window;
- the travelers involved;
- protected commitments that must remain unchanged;
- known replacement activities;
- bounded itinerary operations;
- a natural-language rationale and provenance.
The model cannot decide:
- whether its own proposal passes validation;
- whether it has been approved;
- whether canonical itinerary state should change;
- whether a new itinerary version should be created;
- whether history should be restored or rolled back.
Those decisions belong to deterministic server rules.
The fully executable demo follows one governed hotel/stale-data correction scenario:
- Revision 1 is proposed by GPT-5.6.
- The model describes it as plausible, but the deterministic server calculates that the family would be ready at 18:33, later than the protected 18:20 threshold.
- Revision 1 is rejected, and canonical SQLite state remains unchanged.
- Revision 2 incorporates structured validator feedback and passes at 18:03.
- Human approval is bound to the exact base version, proposal hash, and validation-report hash.
- Apply revalidates everything inside one SQLite transaction and creates
trip-v13. - Restore creates
trip-v14with the baseline itinerary content while preserving the complete event history.
The interface also presents rainy-day and reduced-mobility scenarios as governed previews for where the same architecture can be applied next. They are clearly labeled as previews rather than separate executable histories.
The UI is English-first and includes deterministic local dictionaries for Traditional Chinese, Japanese, Korean, and Vietnamese. No runtime translation API is required.
How I built it
The application uses:
- Node.js and Express for the same-origin server;
- SQLite as the canonical itinerary and audit-state store;
- typed JSON proposal contracts;
- canonical serialization and versioned SHA-256 hash profiles;
- recorded GPT-5.6 fixtures for reproducible Demo Mode;
- an optional server-side GPT-5.6 Live Mode;
- browser automation for end-to-end verification and demo capture;
- FFmpeg, WebVTT, and local speech synthesis for the final narrated video.
Codex acted as an autonomous delivery controller throughout the Build Week work. It inspected the repository, divided the implementation into bounded tickets, wrote and revised code, added regression tests, ran isolated worktrees, performed browser verification, generated submission media, and created a fresh privacy-sanitized release repository.
I used Codex with GPT-5.6 not only to generate code, but also to make and verify product, architecture, testing, privacy, and release decisions. Codex was instructed not to treat passing tests as sufficient when those tests did not prove the intended authority boundary.
Claude Code was additionally used as a read-only adversarial reviewer on bounded review packets. Its findings were advisory: Codex independently reproduced and verified each returned finding before accepting or rejecting it.
Challenges
Keeping the model useful without making it authoritative
The hardest architectural problem was separating a useful AI proposal from an authoritative state transition. The solution was to constrain GPT-5.6 to a typed proposal layer and keep validation, approval, apply, and restore entirely server-owned.
Making the demo deterministic
A live model call is not ideal for a judged demo because network behavior and generated output can vary. I created recorded GPT-5.6 fixtures with raw-response, normalized-proposal, and provenance hashes, allowing Demo Mode to reproduce the same proposal flow without credentials or runtime network access.
Proving failure-path safety
It was not enough to prove that the successful path worked. Tests also tamper with fixtures, validation reports, approvals, proposal hashes, state transitions, and transaction steps to verify that rejected operations leave canonical state unchanged.
Turning a pre-existing project into a meaningful Build Week extension
The original project was a static itinerary interface. The Build Week contribution is the governed Trip Patch runtime: Express and SQLite state, typed GPT-5.6 adapters, deterministic validation, exact approval binding, transactional apply, forward restore, fixture provenance, browser verification, multilingual framing, and submission tooling.
Privacy-safe release engineering
The source project contained details from a real future trip. Before submission, Codex created a fresh repository with no inherited Git history, a GitHub noreply identity, synthetic dates and flight identifiers, generic traveler language, sanitized hotel names, newly generated media, and a final privacy release gate.
What I learned
The most important lesson was that reliable AI systems are often created by reducing what the model is allowed to decide.
GPT-5.6 is valuable because it can understand context and propose a useful change. The system becomes trustworthy because deterministic code verifies the proposal, binds approval to exact evidence, mutates state transactionally, and preserves an auditable recovery path.
I also learned that autonomous development works best when agents are given explicit authority boundaries, reproducible acceptance gates, independent review, and truthful requirements about what has and has not been verified.
FamilyTrip OS is ultimately not about having the largest destination catalog. It is a concrete demonstration of a reusable principle:
AI may propose the future, but trusted systems must still decide how reality changes.
Log in or sign up for Devpost to join the conversation.