C4 Architecture Model

The software-architecture view of the open world, in C4 notation. Tightly paired with the world bible: each container here is a layer there; each system (S1–S10) becomes a component diagram as its cases mature.

The four C4 levels and where they live

Level	Scope	Status	Neutral?
L1 System Context	HungerSync + external actors/systems	rendered below	yes
L2 Container	the four-layer platform + data stores	rendered below	yes
L3 Component	inside one container (per system S1–S10)	one rendered (Agent); more as cases mature	yes
L4 Code	classes/functions/services	playthrough overlays only — never here	no

Level 1 — System Context

The whole HungerSync system as a single box, with the external actors and systems it interacts with. The starting point for every conversation about what this thing is.

Level 2 — Container

The four-layer platform broken into containers, each tagged with its world-layer (L0–L3), its system S-ID, and the owning function (the Conway seam). Container boundaries are team hand-off seams, which are the case-study boundaries — one coherent structure across world, org, and curriculum.

Container ↔ layer ↔ system (S-ID) ↔ Conway seam ↔ case

Container	World layer	System (S-ID)	Owning function (Conway)	Primary cases
Data Platform (+ fact store, knowledge base, feature store)	L0	S3	Data Platform team	DE1, DE2
Prediction Service	L1	S2 (prediction)	Forecasting / ML	ML1–ML3
Discovery & Ordering App	L2	S1 (ordering) + S4	Product / Application eng	CS4, CS8
Vendor Portal	L2/0	S5	Vendor enablement / Partnerships eng	(case TBD)
Voucher Rail & Settlement	L2	S6	Payments / Settlement eng	(case TBD)
Resolution & Dispatch Agent	L3	S1 (resolution) + S2 (dispatch)	Agent / Platform eng	CS2, CS5, CS6, CS7
Remote Ops Console	L3	S7	Remote Ops	CS3, remote-ops case
Build & Delivery Pipeline	L3	S8	Platform eng / Dev productivity	(cross-cutting case)
Trust & Safety	⟂	S9	Trust & Safety / Governance	CS8
Observability & Cost	⟂	S10	SRE / FinOps / Eval	(cross-cutting case)

Future externals (tagged future in both Context and Container diagrams, rendered dimmer): Skyline Air (secondary carrier), SkyVue In-Flight Systems (IFE in-seat channel), Atrium Dining Co. (competitor concessionaire). They appear because the business reality includes them now — even where no integration exists yet.

Level 3 — Component: Resolution & Dispatch Agent

The first component diagram, broken into two halves: Resolution (passenger conversation) and Dispatch (fulfillment), joined where a placed order hands off.

Component → primary case → neutralized capability it exercises:

Component	Case	Neutralized capability
Resolution Agent	CS2	agentic loop / completion control
Case-Facts & Context Manager	CS5	context preservation, session state
Tool Interface	CS2	tool descriptions + structured errors
Enforcement Gate	CS2	programmatic prerequisites & interception
Escalation & Handoff	CS5	escalation, structured handoff
Dispatch Coordinator + Fulfillment Planner	CS3	coordinator–subagent orchestration
Robot Fleet Dispatcher + Operator Intervention Bridge	CS2 / remote-ops	supervised autonomy, human-on-the-loop

Neutrality convention

C4’s “technology” field normally names a stack. In the world model we put a neutral capability there (“grounded retrieval service”, “agent orchestration runtime”), not a vendor. Playthroughs override the technology field with concrete services. The shapes and relationships never change across playthroughs; only the technology labels do.

Rendering source

The .puml source lives with the archived HungerSync source material. All diagrams use the C4-PlantUML standard library via a remote !include, so re-rendering needs network access. Use any PlantUML toolchain or the project’s plantuml -tsvg -pipe pattern.