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
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “Rendering source”The .puml source lives in the project repo under quarto/world-source/c4/ after the migration (was world/c4/ in the original HungerSync repo). 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.