Exploration: Application Architecture — Fresh Analysis Without Extension Bias

Status: Exploration. Deriving application architecture primitives WITHOUT looking at the entity system's extensions. Starting from what applications across the full software landscape actually need. Purpose: Stress-test the existing 9-primitive app architecture {D,Sc,Re,Mu,Ra,Cn,Vs,Co,Au} by deriving it independently, then comparing. Rule: No reference to entity system extensions (Compute, Sync, Subscription, etc.) during derivation. Compare AFTER.

1. What is application architecture?

Application architecture is the domain of structural concerns that EVERY application must address, regardless of what it does or what substrate it runs on. It's the functional surface — what systems DO — above the substrate (what they're made of) and below the ecosystem (the community they participate in).

To derive its primitives fresh, survey what real applications across DIVERSE categories actually need.

2. Survey across diverse application types

Deliberately spanning beyond the entity system's sweet spot (distributed data management):

2.1 Web application (e.g., Gmail, Notion)

• Stores user data (messages, documents)
• Has structure (folders, workspaces, types of content)
• Users find things (search, navigation, filtering)
• Users change things (compose, edit, delete, move)
• Changes appear in real time (notifications, live updates)
• Multiple users don't corrupt each other (concurrent editing, conflict resolution)
• You can undo / see history (drafts, version history)
• Components talk to each other (frontend ↔ backend ↔ database ↔ email service)
• Not everyone can do everything (permissions, sharing, roles)

2.2 Video game (e.g., Minecraft, a multiplayer FPS)

• Has a world with entities (blocks, characters, items, terrain)
• Entities have types and properties (health, position, inventory)
• Players interact with entities (mine, place, shoot, craft)
• The world changes continuously (physics, AI, day/night)
• Changes propagate (other players see your actions, explosions affect nearby blocks)
• Multiple players' actions are reconciled (who shot first, block placement conflicts)
• Some state is recoverable (save games, replays — but usually not full version history)
• Client ↔ server communication, peer-to-peer for some games
• Permissions (admin, moderator, anti-cheat)

2.3 Scientific computing pipeline (e.g., genomics, climate modeling)

• Operates on large datasets (genomes, temperature grids)
• Data has rigid structure (file formats, schema — FASTA, NetCDF, HDF5)
• Querying is specialized (BLAST search, spatial queries, time-series retrieval)
• Transformations applied in sequence (alignment → variant calling → annotation)
• Reactivity is mostly absent — batch processing, not real-time updates
• Consistency matters for reproducibility (same inputs → same outputs, versioned pipelines)
• Provenance/lineage tracking (which pipeline version produced this result)
• Components orchestrated (workflow managers — Nextflow, Snakemake, Airflow)
• Access control (data governance, patient privacy, institutional boundaries)

2.4 Embedded system (e.g., car ECU, IoT sensor)

• Manages device state (sensor readings, actuator positions)
• State has strict types (fixed-point numbers, bit fields, protocol frames)
• Retrieval is by address or register, not by query
• State changes through interrupts, timers, direct writes
• Reactivity through interrupt handlers, event loops
• Consistency through atomic operations, memory barriers (not transactions)
• History usually absent (limited memory — no versioning)
• Communication via CAN bus, MQTT, serial protocols
• Access control through hardware isolation, signed firmware

2.5 Creative tool (e.g., Photoshop, Blender, DAW)

• Operates on complex documents (images, 3D scenes, audio tracks)
• Rich type structure (layers, meshes, clips, effects, materials)
• Navigation through spatial/temporal browsing (zoom, pan, timeline scrub)
• Editing through direct manipulation (brush, transform, cut)
• Live preview (render preview, audio monitoring)
• Undo/redo is critical (full operation history)
• Collaboration is secondary (some tools support it, many don't)
• Plugin/extension communication (effects, instruments, scripts)
• Licensing/DRM (not structural access control)

2.6 Message queue / event stream (e.g., Kafka, RabbitMQ)

• Manages messages/events (the core data)
• Messages have schemas (Avro, Protobuf, JSON Schema)
• Consumers retrieve by topic, partition, offset
• Producers append (write-only — no mutation of existing messages)
• Consumers react to new messages (the ENTIRE purpose)
• Ordering guarantees, exactly-once semantics (consistency)
• Retention policies, compaction (time-bounded history)
• Multi-service communication (the ENTIRE purpose)
• ACLs on topics and consumer groups

3. What recurs across ALL of these?

Looking at what every application type above needs, regardless of category:

3.1 Universally present

Something to work with. Every application operates on SOME form of structured data — user messages, game entities, genomic sequences, sensor readings, image layers, event messages. The form varies enormously but the NEED is universal.

Shape/structure of that something. Every application constrains what its data looks like — types, schemas, formats, protocols. Even "schemaless" systems have implicit structure.

Finding it. Every application needs to locate specific data — by path, by query, by address, by key, by spatial position, by time offset. The mechanism varies but the need is universal.

Changing it. Every application modifies state — writing messages, placing blocks, running computations, updating registers, painting pixels, appending events. Even "immutable" systems append.

Crossing boundaries. Every non-trivial application has components that communicate — frontend/backend, client/server, service/service, device/cloud, plugin/host.

Controlling access. Every multi-user or multi-component system restricts who can do what — permissions, capabilities, ACLs, hardware isolation, signing.

3.2 Very common but not universal

Reacting to changes. Most interactive systems propagate changes — live updates, event handlers, subscriptions. BUT: batch processing, scientific pipelines, and some embedded systems don't react in real time. They poll or run sequentially.

Is this a primitive at partial level 0 for batch systems, or is it genuinely absent? Batch systems DO respond to input — they just do it on a schedule rather than immediately. The structure is the same (input → processing → output) but the temporal coupling is different.

Assessment: present in all systems but at varying levels — from Lv0 (no propagation, manual poll) to Full (real-time reactive cascade). It's a primitive with a wide partial-level range.

Tracking what changed. Version history, undo, audit logs, provenance. Common but genuinely absent in some systems — embedded systems with limited memory, stateless APIs, ephemeral stream processors.

Assessment: present in most but genuinely absent in some. This might be a conditional primitive (like Resource and Generation in the abstract surface) rather than a universal one. Systems without it aren't broken — they're optimized for contexts where history isn't needed.

Maintaining coherence under concurrent modification. Transactions, locks, conflict resolution, ordering guarantees. Universal for concurrent systems but some applications are genuinely single-threaded or single-user.

Assessment: present when concurrency exists, absent when it doesn't. Could be a conditional primitive. But most modern applications ARE concurrent (even single-user apps have background tasks, network requests, plugin execution). Probably universal-enough to be a primitive.

4. Fresh primitive extraction

Based on the survey, applying the three-test methodology:

4.1 Clearly irreducible (pass all three tests easily)

1. Content (Ct) — What the application operates on. Data, entities, documents, messages, state.

• Minimality: without content, nothing to operate on. ✓
• Productivity: content combines with every other concern. ✓
• Recurrence: universal across all application types. ✓

2. Shape (Sh) — How content is structured. Types, schemas, formats, constraints.

• Minimality: without shape, content is unstructured bytes — no validation, no interop. ✓
• Productivity: shape constrains mutation, enables retrieval, informs communication. ✓
• Recurrence: universal — even "schemaless" systems have implicit shape. ✓

3. Access (Ac) — Finding specific content. Query, lookup, navigation, search, addressing.

• Minimality: without access, content exists but can't be located. ✓
• Productivity: access combines with shape (typed queries), mutation (find-then-modify), communication (remote queries). ✓
• Recurrence: universal. ✓

4. Mutation (Mt) — Changing content. Write, update, delete, append, transform.

• Minimality: without mutation, the system is read-only. ✓
• Productivity: mutation combines with propagation (trigger reactions), coherence (coordinate changes), history (track changes). ✓
• Recurrence: universal — even append-only systems mutate (by growing). ✓

5. Boundary (Bn) — Separating components that communicate. Service boundaries, client/server, device/cloud, plugin/host.

• Minimality: without boundaries, everything is one monolith — no distribution, no isolation. ✓
• Productivity: boundary creates the need for communication, access control, and distributed coherence. ✓
• Recurrence: nearly universal — even single-process apps have logical boundaries (modules, plugins). ✓

6. Authority (Au) — Controlling who can do what. Permissions, capabilities, roles, isolation.

• Minimality: without authority, any component can do anything — no security, no privacy. ✓
• Productivity: authority constrains mutation, access, and communication based on identity/role. ✓
• Recurrence: universal for multi-user/multi-component systems. Single-user local apps may have Au at level 0. ✓

4.2 Present but at varying levels (probably primitives with wide partial-level ranges)

7. Propagation (Pg) — How changes spread. Event notification, reactive updates, subscriptions, webhooks, interrupt handlers.

• Minimality: without propagation, every consumer must poll for changes. Forfeits real-time responsiveness. ✓
• Productivity: propagation combines with mutation (trigger on change), access (dependent re-query), boundary (distributed notification). ✓
• Recurrence: present in most systems at SOME level — even batch systems have "job complete" notifications. ✓

8. Coherence (Ch) — Maintaining consistency under concurrent modification. Transactions, conflict resolution, ordering, idempotency, merge strategies.

• Minimality: without coherence, concurrent mutations corrupt state. ✓
• Productivity: coherence combines with mutation (atomic changes), boundary (distributed consistency), history (conflict resolution). ✓
• Recurrence: universal for concurrent systems. Single-threaded systems have implicit coherence. ✓

4.3 Conditional (present in many, genuinely absent in some)

9. History (Hs) — Tracking what changed over time. Version control, undo, audit logs, provenance, retention.

• Minimality: without history, changes are irreversible — no undo, no audit, no provenance. Real cost for some applications; irrelevant for others.
• Productivity: history combines with access (temporal queries), coherence (conflict resolution via version comparison), boundary (distributed version sync).
• Recurrence: common but genuinely absent in embedded systems, stateless services, ephemeral processors.

Assessment: probably a primitive but conditional — like Resource and Generation in the abstract surface. Present where needed (most data-centric applications), absent where not (ephemeral/embedded).

4.4 Considered and rejected

Orchestration/Workflow — Coordinating multi-step processes. Seems important for pipelines and distributed systems. But: orchestration decomposes into Mutation + Propagation + Coherence — a multi-step process IS a sequence of mutations that propagate and maintain coherence across steps. It's a COMPOSITION rather than a primitive.

Presentation/Rendering — How content is displayed. Important for UI applications but absent from APIs, background services, data pipelines, embedded systems. Domain-specific, not universal.

Computation/Logic — The ability to evaluate expressions, run algorithms. Present in all applications but AMBIENT — every primitive assumes computation. It's the medium, not a separate concern. (Same conclusion as the v1 analysis.)

5. The fresh primitive set

8 universal + 1 conditional = 9 total.

6. Comparison to the v1 analysis

6.1 Side-by-side

6.2 Assessment

8 of 9 are the same concept with minor naming differences. The fresh analysis independently arrived at essentially the same primitive set as the extension-influenced v1 analysis. The naming differs slightly:

6.3 The one real difference: Boundary vs Communication

The fresh analysis found Boundary (Bn) — the separation between components. The v1 analysis found Communication (Co) — messaging across boundaries.

These are related but structurally different:

• Boundary is the STRUCTURE (the division exists)
• Communication is the OPERATION (messages cross the division)

In the abstract surface, both roles exist: Protection (Pt) captures boundary defense, Exchange (Ex) captures inter-system communication. So at the abstract level, these ARE two separate things.

The v1 analysis collapsed them into Communication because the entity system's extensions emphasize messaging (Inbox, Network). The fresh analysis sees the boundary as primary and communication as what happens at boundaries.

For a 9-primitive set, we could either: (a) Keep them collapsed as one primitive (Boundary-and-Communication) — 9 primitives total (b) Split them into two — 10 primitives total

The abstract surface has 7 universal primitives. Having 9-10 at the concrete surface is consistent with the expansion pattern.

Assessment: The v1's 9-primitive set is essentially correct. The Boundary/Communication distinction is the only substantive finding from the fresh analysis. Whether to split depends on whether boundary and communication are independently variable (the primitive test).

Can boundary exist without communication? YES — isolated modules within a monolith have boundaries but don't communicate via messages. They interact through shared memory or function calls.

Can communication exist without boundary? Marginally — if there's no boundary, everything is internal and "communication" is just function calls. Communication in the inter-component sense requires a boundary to communicate ACROSS.

So: Communication depends on Boundary, but Boundary can exist without Communication. They might be two primitives with Comm → Boundary as a dependency.

For now: note the finding, keep at 9 for consistency with v1 and the ~9 surface pattern.

7. What this tells us about the entity system design

7.1 The extensions DID capture real application concerns

The fresh analysis independently arrived at the same 9 concerns. This means the entity system's extensions are NOT arbitrary — they correspond to genuine structural needs that ALL applications face. The design WORKED.

7.2 The naming could be improved

Some v1 names carry entity-system-specific connotations:

• "Reactivity" (Ra) implies entity system's reactive cascade — "Propagation" is more neutral
• "Schema" (Sc) implies database schemas — "Shape" is more general
• "Communication" (Co) implies entity system's Inbox — "Boundary" captures the architectural concern

7.3 Computation IS ambient — confirmed independently

Both analyses conclude: computation is the medium, not a separate application concern. The entity system's X (Execution) is a substrate primitive that becomes ambient at the surface. This holds up under fresh scrutiny.

7.4 History is conditional — confirmed independently

Both analyses flag history/versioning as not-universal. Embedded systems, stateless services, and ephemeral processors genuinely don't need it. It's present when the application's context requires temporal tracking.

8. Proposed canonical primitive set for app architecture

Taking the best from both analyses:

This preserves the 9-primitive count while using more neutral naming from the fresh analysis. The abstract surface mapping is cleaner with these names.

9. Next steps

1. Full 12-step analysis of the proposed canonical set {Ct, Sh, Ac, Mt, Pg, Ch, Bn, Au, Hs} — dependencies, pairs, sublattice, compositions, core triad
2. Extension mapping — map entity system extensions to these primitives (should be clean since they correspond)
3. Manifestation landscape — position real application frameworks (React, Rails, Postgres, Kafka, etc.) in the lattice
4. Bridge analysis — formalize how entity system substrate primitives produce app architecture primitives through extension mechanisms