World Integrity Check

HungerSync — World Integrity Check

After folding in four certifications, this validates that the world is still realistic, feasible, and believable, and that the three narratives reinforce rather than fight. The governing rule: business drives architecture drives story — never the reverse, and never a cert.

1. The three narratives nest in one direction

BUSINESS NARRATIVE  (why HungerSync exists, who pays, the value streams)
        ↓ drives
TECHNOLOGY PLATFORM (the four-layer architecture that delivers the value)
        ↓ is dramatized by
HUNGERSYNC NARRATIVE (the protagonist building/operating it under storm pressure)

Certifications sit outside this chain as an overlay on the platform layer. The flow is always business → architecture → story. If a teaching point ever wants to run the other way (cert → architecture → forced business reason), that’s the smell to stop.

2. Business-first causality (each layer earns its place without any cert)

Layer	Business driver (cert-independent)	Would exist if no cert existed?
0 Data platform	HungerSync sells foresight; you cannot predict without first landing and modeling flight/weather/ops data into shared facts.	Yes — it’s the precondition for the whole premise.
1 Prediction	The moat is anticipating demand and pre-positioning capacity before the crowd forms; funded surge is the profit lever.	Yes — it’s the moat.
2 Application	Passengers must discover and order; airlines need the voucher rail; vendors need orders. This is the revenue interface.	Yes — it’s where money changes hands.
3 Agent	A stranded, one-time passenger won’t navigate a menu; conversational resolution + autonomous dispatch is what makes “fed before you miss your flight” real.	Yes — it’s the value proposition’s UX.

Every layer traces to a driver that predates and is independent of the certifications. No layer is tech-for-tech’s-sake. This is the test the world passes.

3. Conway’s Law check

Organizations ship their org chart. The architecture mirrors team communication structure; the interfaces between teams become the interfaces between layers.

The four layers map to four believable functions:

Layer	Team	Owns the interface to…
0	Data Platform	…everyone, via the conformed schema / shared facts
1	Forecasting / ML	…the app, via the prediction contract
2	Product / Application eng	…the passenger, airline, vendor
3	Agent / Platform eng + Remote Ops	…fulfillment and the dev toolchain
⟂	Trust & Safety / Governance	…cross-cutting (sits across all layers)

The case boundaries we drew are Conway boundaries: DE1↔ML1 is the data-platform↔ML team seam (the conformed schema / feature contract); ML↔app is the prediction API; app↔agent is the tool/protocol seam. That’s why those boundaries felt natural rather than arbitrary — they’re where real teams would hand off.

Maturity caveat (important for realism). A pilot-stage HungerSync would not have four clean teams on day one — it’s a small crew wearing every hat, and the layers start entangled. The clean four-layer separation is a maturity state the company grows into. The narrative should let the layers differentiate as the company scales, with the ground stop exposing exactly where the early entanglement hurts (a data-platform shortcut that the ML team inherits; an agent reaching past its seam into prediction). This is more believable than a fully-formed architecture and gives the story its tension. Present the four-layer model as the destination, not the day-one state.

4. Realism stress-test

Claim	Verdict	Note
Robot delivery	✅ realistic	Supervised (human-on-the-loop) autonomous delivery from day one, alongside human runners; grounded in Incheon’s deployed Air Dilly service. Maturity curve = rising autonomy, not deferred introduction.
Prediction from public data	✅ feasible	BTS, FAA NAS/SWIM, NOAA/NWS, FIDS, TSA waits are real and predictive of delay/dwell.
Edge feeds	✅ real	ADS-B (PiAware) and a weather station are genuine telemetry; the hardest part to fake, and now load-bearing in DE1/ML1.
Airline IROPS voucher rail	✅ believable	Meal vouchers during controllable delays are real (EU261, tightening US DOT); digitizing them is a credible product.
Aggregate-first taste profile	✅ believable + privacy-sound	Route/time/history aggregates; individual PII opt-in only. Solves cold-start for one-time passengers.
Multi-sided revenue	✅ believable	Airline wedge + concession commission + passenger fee; airport as gatekeeper not payer.

No element of the world depends on a technology that doesn’t exist or a behavior that isn’t already observed in the market. The world holds.

5. Tech-driven-stretch watchlist (where folding in certs could have distorted the world — and the fix)

These are the spots where a cert task could tempt an unrealistic addition. Each is resolved by anchoring in a real business need, not by bending the world.

FM fine-tuning (MLA 2.2 / AIP 1.2.4). Stretch risk: making the demand model a fine-tuned foundation model just to cover the task. Fix: the believable home for fine-tuning is messy vendor-menu text — normalizing chaotic free-text menus and classifying cuisine/dietary tags is a genuine NLP need a small fine-tuned model serves well. The delay/demand models stay classic ML (gradient-boosting), which is what they’d really be. Business-first: vendor menu data is a mess. ✅ resolved in ML2.
Multimodal (AIP 1.3.2). Stretch risk: shoehorning image processing. Fix: keep it optional, justified only by a real feature — e.g., a passenger photographing an allergy card as an accessibility path. Don’t force it; tag it as opt-in enrichment.
Warehouse breadth (DEA D2). Stretch risk: bloating the data store with warehouse features the pilot wouldn’t need. Fix: model only the facts/dimensions the business questions actually require (revenue by concourse, demand by terminal, voucher redemption). Breadth grows with scale, mirroring the Conway maturity caveat.
Streaming (AIP 2.4.2). ✅ no stretch — real-time delivery of the agent’s response to a waiting, anxious passenger is a genuine UX need.
Vector / open-table features (DEA 2.1). ✅ no stretch — a lakehouse with semantic retrieval for the taste/menu data is a normal modern design.

6. Agnosticism guardrail (the discipline to hold)

The world layer and every case brief use neutral capability vocabulary only. Vendor, cloud, and service names live exclusively in the per-cert playthrough overlays, never in the world.

Watch the near-brand terms specifically:

“open table format” in the world → (overlay names Iceberg/Delta/Hudi)
“shared fact store / conformed schema” → (overlay names a warehouse/lakehouse engine)
“feature store,” “prediction service,” “agent-tool protocol,” “agent orchestration” → neutral; (overlay names MCP, the SDK, the FM provider, etc.)

Rule of thumb: if a term would change when you switch from the AWS playthrough to a Databricks/GCP/Azure playthrough, it belongs in the overlay, not the world. The business problem (“recommend only available items,” “don’t charge the wrong passenger,” “the feed died mid-storm”) never changes across playthroughs — that’s how you know it’s world-layer.

7. Verdict

The world survives the four-cert fold-in intact and more complete, not distorted. Each layer is independently business-justified; the layer boundaries are real Conway seams; nothing depends on non-existent tech; the three narratives nest in one honest direction; and the agnosticism discipline keeps the world portable across every future playthrough. The two things to actively maintain as we write cases: (a) let the layers differentiate as the company matures rather than presenting them fully formed, and (b) hold the neutral-vocabulary line in every world-facing brief.