Application Architecture: Canonical Domain Analysis (12 Primitives)

Status: Canonical reference. Full 12-step analysis of the complete application architecture surface — both internal data management and external interaction. Supersedes: analysis-application-architecture.md (9-primitive version focused on data management only) Derived from: Fresh analysis across diverse application types, abstract surface role mapping, 3/3b iteration testing internal/external separation.

Step 1 — Information Gathering

1.1 What we're analyzing

The full structural space of what software applications DO — all of it. Not just data management, not just backend architecture, but the complete surface of software capability. This includes internal data operations, external interaction with users and environment, computation, and system architecture.

1.2 Why 12 and not 9

The original 9-primitive analysis captured data management concerns but missed the external-facing dimension. Testing against real applications (social media, games, creative tools, streaming, embedded systems) revealed the gap: the abstract surface roles Perception and Action were unfilled.

The 3/3b iteration confirmed Perception and Access are genuinely separate (different sources, timing, reliability), and Presentation and Mutation are genuinely separate (different targets, timing, fidelity). The digital medium gives access to structural concerns that other substrates keep implicit — every data management decision is an explicit design choice in software.

Step 2 — Landscape Analysis

2.1 What recurs across ALL software

Every application, regardless of type or platform:

Internal data concerns:

1. Operates on some form of content (data, state, entities)
2. Content has structure (types, schemas, formats)
3. Content must be findable internally (query, lookup, indexing)
4. Content changes (write, update, append, transform)
5. Changes may spread internally (events, notifications, reactive updates)
6. Concurrent changes must not corrupt (transactions, ordering, merges)
7. Changes may need to be tracked (history, undo, audit) — not always
8. New values may be derived from existing data (computed views, formulas, rules) — not always

External interaction concerns: 9. The system receives external input (user actions, sensor data, incoming messages) 10. The system produces external output (display, audio, API responses, actuation)

System architecture concerns: 11. Components are separated and communicate across boundaries 12. Access is controlled (permissions, capabilities, isolation)

Step 3/3b — Primitives and Partial Levels

3.1 The twelve primitives

Internal (Content-rooted):

External:

System:

3.2 Abstract surface role mapping

All 7 universal abstract roles filled. Plus 5 domain-specific: Ac, Mt, Pg, Hs, Ev — internal data management concerns that the digital medium makes explicit.

3.3 Stability under 3/3b iteration

Tested and confirmed separate:

• Access ≠ Perception (internal vs external source, different timing/reliability)
• Mutation ≠ Presentation (internal vs external target, different fidelity concerns)

Potential collapses investigated and rejected:

• Propagation into Mutation — independently variable (mutation without propagation in batch; propagation without new mutation in replay)
• History into Mutation — independently variable (many systems mutate without history)
• Evaluation into Mutation — independently variable (pure computation without state change)
• Perception into Access — independently variable (external input without internal query; internal query without external trigger)

Conditional primitives:

• History (Hs) — genuinely absent in embedded systems, stateless services, ephemeral processors
• Evaluation (Ev) — present wherever derived values exist (spreadsheets, computed views, reactive expressions). Likely universal at low levels but explicit only when the substrate exposes open evaluation.

3.4 Partial levels

Data (D):

Phase transition: D1→D2 (Typing). Data gains type — validation, interop, structural operations become possible. (Levels renamed Ct→D for consistency with the primitive id; "Ct" was stale naming inherited from the superseded 9-primitive "Content" version.)

Shape (Sh):

Phase transition: Sh2→Sh3 (Enforcement). Shape is ENFORCED — data integrity becomes a system property.

Access (Ac):

Phase transition: Ac1→Ac2 (Indexing). Find content by WHAT IT IS, not just where it is.

Mutation (Mt):

Phase transition: Mt2→Mt3 (Transactions). Changes become atomic — all-or-nothing.

Propagation (Pg):

Phase transition: Pg1→Pg2 (Push). Real-time behavior begins.

Coherence (Ch):

Phase transition: Ch2→Ch3 (Automatic resolution). Conflicts resolve without human intervention.

History (Hs) [conditional]:

Phase transition: Hs2→Hs3 (Version control). Any previous state reconstructible.

Evaluation (Ev) [conditional]:

Phase transition: Ev1→Ev2 (Reactivity). Derived values update automatically when inputs change.

Perception (Pc):

Phase transition: Pc2→Pc3 (Interactive). The system responds to individual human actions in real time.

Presentation (Pn):

Phase transition: Pn2→Pn3 (Interactive display). The display responds to user actions — the reactive UI.

Boundary (Bn):

Phase transition: Bn2→Bn3 (Network). Distributed systems concerns become relevant.

Authority (Au):

Phase transition: Au2→Au3 (Capabilities). Authority becomes delegatable without central coordination.

Step 4 — Dependencies

D → (nothing; root 1 — internal hub)
Sh → D (shape constrains content)
Ac → D (access finds content)
Mt → D (mutation changes content)
Pg → Mt (propagation triggered by mutation)
Ch → Mt (coherence coordinates mutation)
Hs → Mt (history tracks mutations)
Ev → D (evaluation derives from content)
Pc → (nothing; root 2 — external input, independent)
Pn → D (presentation requires content to present)
Bn → D (boundary scopes content)
Au → Bn (authority operates at boundaries)

Two independent roots:

• D (Content) — internal hub. Everything about data management depends on having content.
• Pc (Perception) — external input. Arrives independently of internal state.

This mirrors the SSA's two-root structure: En (encoding) and Cx (context).

DAG:

D (root 1)                    Pc (root 2)
  ├── Sh                         (independent — external input)
  ├── Ac
  ├── Mt → Pg
  │     ├── Ch
  │     └── Hs
  ├── Ev
  ├── Pn
  └── Bn → Au

Depth: Maximum chain: D → Mt → Pg (depth 2) or D → Bn → Au (depth 2). Shallow — consistent with surface domains.

Step 5-6 — Pairs and Load Classification

C(12,2) = 66 pairs. Classifying the most structurally significant:

Heavy pairs

15 heavy of 66 (23%). Moderate — consistent with a surface domain with both tightly coupled internal pairs and loosely coupled external ones.

Medium pairs

Light pairs

20 medium, 31 light of 66. Distribution: 15 heavy (23%), 20 medium (30%), 31 light (47%).

The Pc-Pn pair

Pc-Pn (perception-presentation) is the INTERACTION LOOP — the external cycle where the app perceives input and presents output. This is the pair that makes software INTERACTIVE. At Pc0+Pn0: no interaction (batch/background). At Pc3+Pn3: full interactive application.

This pair is the app architecture equivalent of organism architecture's Sn-Rs (sensing-response) — the environmental interaction pair.

Anchor pairs

D-Mt (content-mutation) is the internal anchor — most internal compositions cluster around it. Pc-Pn (perception-presentation) is the external anchor — all interaction compositions include it.

Step 7 — Coherent Sub-lattice

Dependencies

D and Pc are independent roots. Given D:

• Sh, Ac, Mt, Ev, Pn, Bn each need only D
• Pg, Ch, Hs need Mt (which needs D)
• Au needs Bn (which needs D)

Given Pc: no dependents (Pc is a leaf in the dependency sense — things may be TRIGGERED by Pc but don't structurally DEPEND on it).

Enumeration

Valid subsets of {Sh, Ac, Mt, Pg, Ch, Hs, Ev, Pc, Pn, Bn, Au} given D always present:

Constraints: Pg→Mt, Ch→Mt, Hs→Mt, Au→Bn. Pc independent. Others need only D.

Let me partition: {Pc} is fully independent. For the remaining 10 {Sh, Ac, Mt, Pg, Ch, Hs, Ev, Pn, Bn, Au}:

Constraints on remaining 10: Pg→Mt, Ch→Mt, Hs→Mt, Au→Bn.

Mt absent: Pg, Ch, Hs all absent. Remaining free: {Sh, Ac, Ev, Pn, Bn, Au} with Au→Bn. Valid combos: 2^6 = 64 minus (Au without Bn = 2^4 = 16) = 48.

Mt present: Pg, Ch, Hs each free. Remaining: {Sh, Ac, Pg, Ch, Hs, Ev, Pn, Bn, Au} with Au→Bn. Valid combos: 2^9 = 512 minus (Au without Bn = 2^7 = 128) = 384.

Total for {Sh,Ac,Mt,Pg,Ch,Hs,Ev,Pn,Bn,Au}: 48 + 384 = 432.

Each can independently include or exclude Pc: 432 × 2 = 864.

Including {} and {D alone}: already counted in the 432 (empty subset of the 10 = just D).

Total coherent subsets of 2^12 = 4096:

• {}: 1
• D + valid combos of 11 (including Pc-independent): 864
• {Pc} alone (Pc is an independent root — coherent with D absent): 1
• Total: 866

Filter: 866/4096 = 21.1%.

Cross-domain consistency correction (task #7): an earlier draft recorded 865, excluding the {Pc}-alone subset on the semantic ground that "perception with no content is meaningless" (logged as judgment call #14, deferred to this consistency pass). Resolution: filter_stringency is the full dependency-coherent presence-lattice BFS, counting independent-root-alone singletons uniformly — physical-hardware already counts {Pw}-alone, and every other one of the 34 corpus files has stored == full BFS. {Pc} is an independent root (no presence dependency), so {Pc}-alone is coherent and counted: 866. The semantic nuance (a perceiving-but-contentless application is a degenerate corner) is noted here but does not change the structural count.

Moderate — similar to the 9-primitive version (21.3%). The added primitives (Pc, Pn, Ev) don't create much additional filtering because Pc is independent and Pn/Ev depend only on D.

Step 8 — Build-up Sequence

Primary path (data-first, then interaction)

Step 0→1: {} → {D}
  Content exists. Something to operate on.

Step 1→2: {D} → {D, Sh}
  Content has shape. Structure is explicit.

Step 2→3: {D, Sh} → {D, Sh, Ac}
  Content is findable internally.

Step 3→4: {D, Sh, Ac} → {D, Sh, Ac, Mt}
  Content is mutable. State changes.

Step 4→5: → add Pc, Pn (perception + presentation)
  External interaction begins. The app perceives input and presents output.
  This is where the app becomes INTERACTIVE.

Step 5→6: → add Pg (propagation)
  Changes spread. Reactive behavior.

Step 6→7: → add Ch (coherence)
  Concurrent changes coordinated.

Step 7→8: → add Bn, Au (boundary + authority)
  System architecture — components separated, access controlled.

Step 8→9: → add Hs, Ev (history + evaluation)
  Conditional capabilities — tracking and derived values.

Alternative: interaction-first path

{D} → {D, Pc} → {D, Pc, Pn} → {D, Sh, Pc, Pn} → add Mt → add Pg → ...

Start with content and external interaction before internal data management. This is the PROTOTYPING approach — build the interface first, then the backend. Common in UI-driven development.

Alternative: distribution-first path

{D} → {D, Bn} → {D, Bn, Au} → {D, Sh, Bn, Au} → add Mt → add Ch → ...

Start with system architecture — boundaries and authority before data management. Common in enterprise and microservices-first architecture.

Step 9 — Load-bearing Compositions

Core triad

{D, Sh, Ac} — Content, Shape, Access.

"What is a data system?" → CONTENT with SHAPE that you can ACCESS. The minimal structured data system. Present in every application.

All three pairs heavy: D-Sh ✓, D-Ac ✓, Sh-Ac ✓.

Secondary triads

{Mt, Pg, Ch} — Mutation, Propagation, Coherence.

"What is a reactive consistent system?" → Changes (Mt) that PROPAGATE (Pg) while maintaining COHERENCE (Ch). The operational core.

{Pc, Pn, Mt} — Perception, Presentation, Mutation.

"What is an interactive application?" → The app PERCEIVES input (Pc), MUTATES state (Mt), and PRESENTS output (Pn). The interaction triangle. This is the external-facing equivalent of the data management core.

{Bn, Au} — Boundary, Authority.

"What is a secure distributed system?" → Components separated (Bn) with controlled access (Au).

Named compositions

Quad

{D, Sh, Ac, Mt} — The CRUD system. Content with shape, accessible and mutable. Minimum viable application.

{Pc, Mt, Pn, Pg} — The real-time interactive. Input drives mutation drives presentation drives updates. The live application.

Higher / full set

{D, Sh, Ac, Mt, Pg, Ch, Hs, Ev, Pc, Pn, Bn, Au} — the complete application platform: all twelve surface primitives active. Peaks at the most-complete applications (Instagram, Kubernetes). Carried as an explicit higher composition for full-set coverage, consistent with the entity-system complete-substrate composition.

Step 10 — Emergent Properties

Step 11 — Cross-Domain Patterns

11.1 Comparison to other surfaces

App architecture has MORE INTERNAL primitives (8 vs ~4) because the digital medium makes every data management concern an explicit design choice. Other surfaces keep these concerns implicit.

The two-root structure (D + Pc) mirrors the SSA's two-root structure (En + Cx). External input is structurally independent of internal content.

11.2 The substrate expansion

Entity system 6 → App architecture 12. Expansion factor: 2×.

How the expansion works:

• E + I (encoding) → D (data). Core encoding becomes ambient content.
• T (tree) → Sh (shape) + part of Ac (path-based access). One primitive separates into two concerns.
• M (emit) → Mt (mutation) + Pg (propagation) + Hs (history). One primitive separates into THREE concerns.
• X (execution) → Ev (evaluation, partially) + AMBIENT computation. Open evaluator creates explicit surface concern.
• P (peer) → Bn (boundary) + Au (authority). One primitive separates into two concerns.
• External → Pc (perception) + Pn (presentation). NEW at the surface — not directly from any substrate primitive. These emerge from the substrate being USED by external entities.

The larger expansion (2× vs ~1.5× in biology) comes from two sources:

1. More internal separation (M→3, T→2, P→2) because digital makes concerns explicit
2. External primitives (Pc, Pn) that emerge from the human-software interaction

Step 12 — Manifestation Landscape

Positioned systems

What the landscape reveals

Interactive consumer apps (Instagram, Minecraft, Photoshop) cluster at HIGH Pc + HIGH Pn — full interactive loop. They differ on internal concerns (Photoshop: History-Full; Instagram: Propagation-Full).

Backend services (Postgres, Kafka, Kubernetes) cluster at LOW Pc + LOW Pn — minimal direct interaction. They're strong on internal concerns and Boundary.

Hybrid systems (React+Redux, REST API) are moderate on both — they serve as the CONNECTION between backend and interactive.

The Pc-Pn diagonal divides the landscape: high on both = interactive application; low on both = backend service; mixed = middleware/framework.

Attractor positions

Summary

Referenced by the model

Cited as a source by 1 model record (browse the model census):

• application-architecture — domain entity/sc1