The Open World

HungerSync — The Open World

This is the canonical source of truth for the HungerSync world. Every case study, training intake, and cloud playthrough references this document. It is written in neutral capability vocabulary — no vendor, cloud, or service names. Concrete technology lives only in playthrough overlays, never here.

Companion artifacts:

Architecture (software): c4/ — System Context, Container, Component models.
Architecture (business): ../business-architecture/ — BMC, value streams, capability map, etc.
Curriculum: ../case-studies/curriculum-master.md.

1. How to use this document

The world is fixed and shared; the playthroughs are lenses on it. A case states a problem in the world’s neutral terms; a playthrough (AWS, and later GCP/Databricks/Azure) binds those neutral capabilities to concrete services in a clearly-fenced overlay. If a term would change when you switch clouds, it belongs in a playthrough, not here.

Direction of authority: business need → platform architecture → narrative. Nothing in this world exists to showcase a technology or satisfy a certification.

2. Premise

Predictable flight disruptions strand travelers at large hub airports with time to kill, money to spend, and no easy way to get food they actually want before they have to move. HungerSync turns public and edge signals into foresight — predicting which flights will slip and what those passengers will crave — and gets food to the gate before the crowd forms. It sells that foresight to airlines (as a better disruption experience), to concessionaires (as demand they’d otherwise miss), and to passengers (as “fed before you miss your connection”).

Logline: anticipate the hungry crowd a delay is about to create, and feed it where it stands.

3. Setting

The pilot is Hartsfield-Jackson Atlanta International (ATL) — the world’s busiest airport, a hub-and-spoke fortress where a single afternoon thunderstorm can cascade into a ground stop and thousands of simultaneously stranded, hungry passengers. ATL is kept real; commercial entities around it are lightly fictionalized for future publication.

The crucible: a summer supercell parks over the field, the FAA issues a ground stop, and HungerSync’s platform must hold while demand spikes across every concourse at once. This recurring event is the stress test the whole world is designed around.

4. The problem and the value proposition

Today a delayed passenger either walks the concourse hunting for something acceptable (and often gives up), or redeems a paper airline meal voucher at a counter with a line. The airline eats goodwill, the concessionaire misses the sale, and the passenger goes hungry. HungerSync compresses that to a conversation: “I’m at B12, my flight slipped two hours, find me something fast and good” → a grounded recommendation that’s available now, safe for any stated dietary need, and deliverable to the gate.

Value, per side: airlines get a measurably better irregular-operations (IROPS) experience and a digital meal-voucher rail; concessionaires get surfaced demand and fulfillment; passengers get speed and fit; the airport authority gets a calmer terminal.

5. Cast and entities

The company. HungerSync — a pilot-stage venture proving itself on the Peachtree contract at ATL.

Customers, partners, gatekeepers.

Peachtree Airlines — the Delta-archetype hub carrier; the wedge customer paying for the digital IROPS voucher rail.
Skyline Air — a secondary carrier; later expansion.
Skyport Hospitality Group — the HMSHost-archetype concessionaire operating many gate-area outlets; supplies menus and fulfills orders.
Atrium Dining Co. — an OTG-archetype competitor concessionaire.
City of Atlanta Department of Aviation — the airport authority; the gatekeeper (a cost and approval center, not a payer).
SkyVue In-Flight Systems — an in-flight-entertainment vendor; a future in-seat ordering channel.
An unnamed robot-fleet vendor — supplies the autonomous delivery robots that operate from launch under HungerSync’s human-on-the-loop supervision (real-world archetype: the LG/Woowa-style airport delivery robot deployed at Incheon).

Personas (passengers).

Wade Tanner — a sales manager for an agricultural-equipment manufacturer who flies constantly to large farms; grew up on a family farm in south Georgia. A frequent business flyer who values speed and predictability above all.
The Restrepo family — a Catholic Colombian family who travel, eat, and pray together. They keep Catholic observances (no meat on Fridays and during Lent, fasting days), value communal meals and simplicity, and need no-alcohol-to-minors safety.
Jun-seo Park — a Korean international business traveler connecting on a tight, anxious layover; already accustomed to robot food delivery from his home hub.
Brody Lanier — a University of Georgia student intensely focused on fitness and appearance, who wants protein-forward options and accurate, transparent nutrition information for what he orders.

Note: allergen safety is a cross-cutting requirement for every passenger, not one persona’s trait — the platform fails closed on any stated constraint (allergen, religious, or dietary) it cannot confirm.

Story figures.

Tessa “Tess” Calloway — a Georgia Tech grad (industrial & systems engineering) who grew up in Warner Robins, Georgia; a senior engineer thrust into the architect seat when the platform buckles during the first big ground stop.
Colonel (ret.) Wendell “Mac” McClain — on his second career after the Air Force, where he rose from C-5 Galaxy pilot to base commander. A veteran mentor who answers questions with questions and frames every problem in the language of airlift logistics and command-and-control — load planning, throughput, and the fog of a ground stop.

6. Business model

Multi-sided. The wedge is airlines paying for the digital IROPS meal-voucher rail. Layered on: a concession commission on orders, a per-order passenger service/delivery fee, and (later) SaaS to concessionaires. The airport authority is a gatekeeper, not a payer — its approval and constraints are a cost center.

The taste profile that powers recommendations is aggregate-first (built from route, time, and history at the segment level); individual PII is used only on explicit opt-in. This is both a privacy stance and the solution to cold-start for one-time flyers.

(See ../business-architecture/ for the canvas, value streams, revenue flow, and SWOT.)

7. The platform — four neutral layers

HungerSync reads bottom-to-top: a data foundation feeds prediction, prediction feeds the application, the application is driven by the agent. Each layer is a capability, not a product name. See the Container model in c4/c4-02-container.puml.

Layer 0 — Data platform. Lands flight, weather, vendor, order, and voucher data from many feeds into one durable, queryable shared fact store, modeled so every consumer reads the same conformed facts (dimensions: flight, gate, vendor, passenger-segment, time; facts: orders, deliveries, vouchers, delays). Owns ingestion, cataloging, lifecycle, modeling, and data quality. Systems: S3 ingestion, the fact store.

Layer 1 — Prediction. Turns the fact store plus live edge signals into foresight: will this flight slip, how long will passengers dwell, how hungry will they be, what will they crave. Owns features, training, evaluation, serving, drift, and retraining. Systems: the prediction & pre-positioning engine.

Layer 2 — Application. The grounded discovery and ordering experience and the trust layer around it: recommend only items that are available and safe, cite sources, enforce guardrails, run the voucher rail, and keep cost/ops bounded. Grounded discovery is hybrid retrieval: a vector index handles fuzzy menu text (“vegan and fast”), while a knowledge graph of flights, gates, vendors, and dietary constraints answers the relational, multi-hop part (“an open vendor reachable from B12 that’s safe for a nut allergy on this delayed flight”) — which is also what makes a recommendation fail-closed and explainable. Systems: discovery, ordering, vendor/menu, safety & privacy.

Layer 3 — Agent. The conversational resolution agent a stranded passenger talks to, and the dispatch coordinator that orchestrates fulfillment with human-on-the-loop remote operations. Owns agentic reasoning, tool use, escalation, and the internal build/dev tooling. Systems: resolution agent, dispatch orchestration, remote ops.

The systems (capability inventory)

ID	System	Layer
S1	Passenger ordering & resolution agent	3
S2	Prediction & dispatch pipeline	1 / 3
S3	Public-data & edge ingestion	0
S4	Taste-profile & discovery (hybrid retrieval: vector + knowledge graph)	2
S5	Vendor enablement & menu/availability	2 / 0
S6	Voucher rail & settlement (deterministic, financial)	2
S7	Remote operations / fleet monitoring (human-on-the-loop)	3
S8	Platform build & delivery (the team building HungerSync)	3
S9	Safety, privacy & governance (cross-cutting)	⟂
S10	Observability, evaluation & cost	⟂

Each system’s internal structure is (or will be) a Component diagram under c4/, authored as its feeding cases mature.

8. Delivery model

A mixed, supervised fulfillment fleet from day one. HungerSync fulfills with both autonomous delivery robots and human runners, coordinated by the dispatch layer and overseen by human-on-the-loop remote operations (system S7). The robots operate autonomously by default — navigating the concourse to bring an order to a gate or seat — while a remote operator monitors the fleet and intervenes on exceptions (a blocked path, a crowd surge, an age/ID check for a restricted item). This is supervised autonomy running now: not full unsupervised autonomy, and not a deferred future phase.

Why this is realistic, not a stretch. Incheon International Airport already runs exactly this: its Air Dilly service (operated by Woowa Brothers / Baemin with LG service robots) lets a passenger scan a QR code at the gate, order food and drink in an app, and have a robot deliver it to their seat — at one of the world’s largest hubs, expanding since its 2022 pilot and still operating today, with robots reaching gates hundreds of meters out. The deployed precedent is what makes day-one supervised robot delivery feasible; deferring it would under-reach the state of the art.

Human runners remain first-class, not a fallback — they cover what robots can’t yet do well (heavy or multi-order loads, cross-concourse hops bridged by the Plane Train, and any exception the operator routes to a human). The maturity curve is about autonomy, not introduction: over time the operator’s intervention rate falls and robot coverage widens, but humans never fully leave the loop where safety or judgment is involved (e.g., handing a restricted item to a verified adult).

Channels: QR/web and app at launch (scan at the gate, order, receive at the seat — the Incheon pattern), plus gate kiosks and airline SMS; in-seat in-flight ordering as a future flagship channel via the IFE partner.

9. Edge and sensing

HungerSync augments public feeds with edge nodes: an aircraft-tracking edge node (ADS-B) and an atmospheric edge node (a weather station) provide low-latency local truth that public feeds lag. These are real, operable, and the hardest part of the world to fake — which is why they anchor the data and prediction layers rather than decorate them. (Reference implementation: a home ADS-B receiver + weather station.)

10. Data and privacy

The fact store is aggregate-first. Recommendations derive from segment-level patterns (route × time × history), not individuals, unless a passenger opts in. Allergen and minor-safety constraints are treated as fail-closed: when the platform cannot confirm an item is safe and available, it does not recommend it. Data residency and who-saw-what are auditable. (Safety/privacy/governance is system S9; its build lives in the Trust & Safety case.)

11. The three narratives, and how they nest

BUSINESS NARRATIVE  (why HungerSync exists, who pays, the value streams)
        v drives
TECHNOLOGY PLATFORM (the four-layer architecture — this doc §7 + the C4 model)
        v is dramatized by
HUNGERSYNC NARRATIVE (Tess building/operating it under the ground-stop clock)

Certifications are an overlay on the platform layer, never a driver. The flow is always business → architecture → story.

12. Maturity and Conway’s Law

The four clean layers are a destination, not a day-one state. Pilot-stage HungerSync is a small crew wearing every hat, with the layers entangled; they differentiate into distinct responsibilities (and, later, teams) as the company scales. The ground stop exposes exactly where the early entanglement hurts. The layer boundaries are the seams where real teams would hand off — which is why they are also the boundaries between cases and between C4 containers.

13. Neutrality discipline & canonical vocabulary

World-layer terms (left) and what playthroughs may bind them to (right, examples only):

World term (use this)	Playthrough may render as
shared fact store / lakehouse	a warehouse/lakehouse engine
open table format	a specific table format
feature store	a managed feature store
prediction service	a model endpoint
knowledge base / grounded retrieval	a vector store + retrieval API
knowledge graph / relational store	a graph store (e.g., Neo4j, Neptune, a graph-capable warehouse)
hybrid retrieval (graph + vector)	a graph store paired with a vector index (GraphRAG)
agent-tool protocol	a specific tool/connector protocol
agent runtime / orchestration	a specific agent SDK
guardrail	a specific content-safety service
edge node	specific receiver/sensor hardware

If you find a vendor or service name in this document or in any case brief, it’s a bug.

14. Pointers

Software architecture: c4/ — start with the Context then Container model.
Business architecture: ../business-architecture/.
What this world teaches & how it’s organized: ../case-studies/curriculum-master.md and ../case-studies/world-integrity-check.md.