Exploration: Case Studies — Does App Architecture Capture What Applications Actually Do?

Status: Exploration. Testing whether {Ct, Sh, Ac, Mt, Pg, Ch, Bn, Au, Hs} captures the structural concerns of major real-world applications, or whether it's biased toward backend/data-management architecture. Question: What about social media, video games, entertainment, YouTube? Does the app architecture miss human-facing dimensions?

1. Case studies — mapping major applications

1.1 Instagram / TikTok (social media)

What Instagram IS to users: visual content sharing with social graph, algorithmic feed, engagement mechanics (likes, comments, shares, follows).

What the 9 primitives CAPTURE: The entire backend architecture. Every structural concern is addressed.

What they MISS: The feed algorithm is the product's core value — and it maps to Access (Ac) at high levels, which is correct but doesn't distinguish "find data for the system" from "curate content for the human." The PRESENTATION to the user (visual feed, stories UI, reels player) isn't a separate primitive — it's not captured.

1.2 Fortnite / Minecraft (multiplayer game)

What a multiplayer game IS: a shared interactive world with real-time physics, player actions, visual rendering, and social dynamics.

What the 9 primitives CAPTURE: Server architecture, state management, networking, consistency.

What they MISS: RENDERING — the 3D visual output that IS the game experience. Also: real-time INPUT processing (controller/keyboard/mouse → game actions), PHYSICS simulation, and SPATIAL structure (the world as a navigable 3D space). These are continuous real-time processing concerns, not data management concerns.

1.3 YouTube / Netflix (streaming entertainment)

What they MISS: VIDEO PLAYBACK — adaptive bitrate streaming, codec selection, buffering, seek. This is a continuous media delivery concern. Also: the RECOMMENDATION ALGORITHM maps to Access but is really a separate ML-driven concern.

1.4 Photoshop / Figma (creative tool)

What they MISS: RENDERING again — the visual canvas, real-time brush strokes, GPU-accelerated compositing. Also: direct manipulation INPUT — how the user's mouse/pen translates into content mutations.

2. What's consistently missing?

Across all four case studies, the same gaps appear:

2.1 Presentation / Rendering

How the application shows its content to users. Visual display, audio playback, 3D rendering, document layout, video streaming. This is the OUTPUT CHANNEL to the human.

Every interactive application has it. Non-interactive applications (APIs, background services, data pipelines) don't.

Is this a missing primitive or a domain-specific concern?

Arguments for primitive:

• It's present across MANY diverse application types (social media, games, creative tools, streaming)
• The abstract surface has Exchange (Ex) — inter-system communication. Presentation IS the application's communication to the human.
• Organism architecture has Communication (Cm) — how organisms exchange with other organisms. Presentation serves the same role: how the application exchanges with the user.

Arguments against:

• APIs, background services, data pipelines, embedded systems don't have presentation
• It's not a DATA MANAGEMENT concern — it's a user experience concern
• The methodology's UI domain analysis (6 primitives) already captures this as a separate domain

Assessment: Presentation is CONDITIONAL — like History. Present in interactive applications (most consumer-facing systems), absent in non-interactive applications (APIs, pipelines, services). It COULD be a conditional primitive alongside History.

2.2 Interaction / Input

How the user tells the application what to do. Click, tap, type, gesture, voice, controller input. The INPUT CHANNEL from the human.

Every interactive application needs it. Non-interactive applications don't.

Assessment: Interaction is the other side of Presentation — they're the input/output pair for human-facing applications. If Presentation is conditional, Interaction is too.

2.3 Are Presentation and Interaction one primitive or two?

In organism architecture: Sensing (Sn) = perceiving the environment. Response (Rs) = acting on the environment. These ARE two separate primitives.

In the abstract surface: Perception (Pr) and Action (Ac) are separate, and they form the Pr→Ac dependency (action depends on perception).

By analogy: Interaction (input from user) maps to the surface Perception role. Presentation (output to user) maps to... the surface Exchange role? Or is Presentation an Action (the system acting toward the user)?

Actually, the abstract surface has:

• Perception (Pr) = detecting external state → Interaction is the app perceiving user intent
• Action (Ac) = directed output → Presentation is the app directing output to the user
• Exchange (Ex) = inter-system communication → this is about system-to-system, not system-to-human

So Interaction → Pr and Presentation → Ac. Both are already in the abstract surface. The question is whether they're separate primitives at the app architecture level.

In the current 9 primitives:

• Access (Ac) partially fills the Perception role (the system finding data)
• Mutation (Mt) partially fills the Action role (the system changing state)

But Access/Mutation are about the system's relationship to its DATA. Interaction/Presentation are about the system's relationship to its USER. These are different relationships.

2.4 The two-audience problem

The current 9 primitives describe the application's relationship to its OWN DATA:

• Content, Shape, Access, Mutation, Propagation, Coherence, History — all data-facing
• Boundary, Authority — system-facing (how components relate)

Missing: the application's relationship to its USERS:

• Presentation — what the user sees/hears
• Interaction — what the user does

This is a real structural gap, not a domain-specific concern. The application architecture as currently stated describes the DATA MANAGEMENT surface but not the USER INTERFACE surface.

2.5 Why this happened

The v1 analysis derived app architecture from entity system extensions. The entity system's extensions are about DATA MANAGEMENT — Sync, Compute, Subscription, History, Content, etc. The entity system doesn't have a "render to screen" extension or a "process user input" extension because those are client-side concerns, not protocol-level concerns.

The fresh analysis surveyed what applications need but focused on STRUCTURAL concerns — what you deal with regardless of technology choice. Presentation/interaction seemed technology-specific (web vs native vs game engine vs CLI) rather than universal. But that's like saying "metabolism is chemistry-specific" — the mechanism varies but the CONCERN is universal for interactive systems.

3. Revised assessment

3.1 Option A: Keep 9, presentation/interaction are domain-specific

The 9 primitives capture application ARCHITECTURE — the structural concerns of building any data-processing system. Presentation and interaction are handled by a separate domain (UI architecture, which was already analyzed as {E, S, V, L, C, Σ} in the v1 analysis).

Application architecture + UI architecture = complete picture. They're separate domains connected by edges.

Problem: This makes "application architecture" = "backend architecture." The surface should capture what the WHOLE application does, not just the backend.

3.2 Option B: Add 2 conditional primitives (11 total: 8 universal + 3 conditional)

Add:

• Presentation (Pr) — how the application communicates output to users [conditional — absent for non-interactive systems]
• Interaction (In) — how users communicate input to the application [conditional — absent for non-interactive systems]

This parallels the abstract surface's 7+2 pattern. App architecture would have 8 universal + 3 conditional (History, Presentation, Interaction).

Problem: 11 primitives is more than any other surface (all have 9). The abstract surface has 7+2=9. This would be 8+3=11.

3.3 Option C: Presentation+Interaction as ONE conditional primitive

Interface (If) — the bidirectional channel between the application and its users. How the application presents to and receives input from humans. Encompasses rendering, display, input processing, direct manipulation.

This would give 8 universal + 2 conditional = 10. Still higher than other surfaces (9) but closer.

3.4 Option D: Reframe Boundary to include user boundary

Currently Boundary (Bn) captures component-to-component separation. But the application-to-user boundary is ALSO a boundary — the most important one for consumer-facing applications.

If we expand Boundary to include the user-facing boundary, then Presentation and Interaction become ASPECTS of Boundary at specific partial levels:

• Bn0: monolith
• Bn1: logical modules
• Bn2: process boundary
• Bn3: network boundary
• Bn4: trust boundary
• Bn5: USER boundary (the interface between system and human)
• Full Bn: dynamic boundary

Problem: This overloads Boundary. The user-facing boundary is structurally DIFFERENT from component boundaries — it involves perception, rendering, input processing, which are qualitatively different from API calls and network protocols.

3.5 Assessment

Option A (separate domains) seems most consistent with the methodology. Application architecture IS the data management surface. UI/presentation is a different domain that connects to it. The entity system's arrangement might have:

Entity system substrate → App architecture (data management surface) → Digital ecosystem
                        ↘ UI/Presentation architecture (user-facing surface)?

But this makes app architecture NOT the full surface — it's a partial surface. In biology, organism architecture captures BOTH internal function (metabolism, homeostasis) AND external interface (sensing, response, communication). The organism surface isn't split into "internal architecture" and "external interface."

The biology parallel suggests the app architecture SHOULD include the user-facing dimension. Otherwise it's like having organism architecture without Sensing and Response — architecturally valid but missing the external interface that makes organisms functional IN THEIR ENVIRONMENT.

4. What this means

4.1 The app architecture may be incomplete as a surface

If we compare to the abstract surface:

• Structure (St) → Content (Ct) ✓
• Organization (Or) → Shape (Sh) ✓
• Regulation (Rg) → Coherence (Ch) ✓
• Perception (Pr) → Access (Ac)? Partial — Access is system perceiving its own data, not user perceiving system output
• Action (Ac-abstract) → Mutation (Mt)? Partial — Mutation is system acting on its data, not system acting toward users
• Protection (Pt) → Boundary (Bn) + Authority (Au) ✓
• Exchange (Ex) → ? — system-to-user communication is missing
• [Resource] → not present (ambient — computation) ✓
• [Generation] → not present (apps don't reproduce) ✓

The abstract surface roles Perception and Action are partially filled (data-facing) but missing their user-facing aspects. Exchange is unfilled.

4.2 What this means practically

For the entity system papers and the immediate analysis, the 9 data-management primitives are sufficient — they capture what the entity system's extensions address. The user-facing dimension is real but comes from the CLIENT SIDE, which the entity system doesn't specify (it's protocol-level, not UI-level).

For a COMPLETE application architecture domain analysis, the user-facing dimension should be accounted for — either as additional conditional primitives or as a separate connected domain.

4.3 For now

Keep the 9-primitive app architecture as the DATA MANAGEMENT surface. Note that the user-facing dimension (presentation, interaction) is a known gap that maps to the abstract surface's Perception, Action, and Exchange roles. Whether to add it as conditional primitives or treat it as a separate domain is an open design decision.

The digital ecosystem analysis may shed light on this — ecosystems care about what applications DO for users (their ecological role), not just how they're built.

5. The real applications positioned — what the lattice reveals

Despite the presentation gap, the lattice DOES differentiate major application types by their data architecture:

The lattice positions are distinctive and informative even without the presentation dimension. The data architecture IS structurally differentiating — social media's "Access-as-product" is genuinely different from creative tools' "Mutation+History-as-product."

The presentation layer would ADD information (how the data architecture surfaces to users) but doesn't REPLACE it.