Exploration: Completing the App Architecture Surface
Status: Exploration. Working through the 3/3b iteration to figure out if the external-facing primitives are genuinely separate from internal ones, or if they collapse.
1. The question
The abstract surface has 7 universal roles. App architecture fills 4 clearly, 1 partially, and misses 2:
| Abstract role | Current app arch | Filled? |
|---|---|---|
| Structure (St) | Content (Ct) | ✓ |
| Organization (Or) | Shape (Sh) | ✓ |
| Regulation (Rg) | Coherence (Ch) | ✓ |
| Protection (Pt) | Authority (Au) | ✓ |
| Exchange (Ex) | Boundary (Bn) | Partial |
| Perception (Pr) | ??? | Missing |
| Action (Ac) | ??? | Missing |
Plus app arch has additional primitives: Access (Ac), Mutation (Mt), Propagation (Pg), History (Hs), Evaluation (Ev) — internal concerns beyond the abstract surface's 7.
The question: are Perception and Action genuinely missing, or are they implicit in what we have?
2. Testing: does Access absorb Perception?
Access (Ac): Finding specific content within the system. Query, lookup, navigation, search.
Perception (Pr, abstract): Detecting external state. Sensing what's happening outside.
2.1 Can the app receive external input without accessing internal data?
YES. Examples:
- A game receives controller input before any game state is queried
- A thermostat receives temperature readings without accessing a database
- A chat app receives a new message before retrieving conversation history
- A sensor gateway receives data streams without any internal lookup
External input reception is structurally independent of internal data access.
2.2 Can the app access internal data without receiving external input?
YES. Examples:
- A batch job queries a database on a schedule with no external trigger
- A background analytics pipeline reads data without user interaction
- An internal health check queries system state
2.3 Are they qualitatively different?
| Property | Access (internal) | Perception (external) |
|---|---|---|
| Source | Own data stores | External world (users, sensors, other systems, environment) |
| Timing | App-initiated (query when you want) | Event-driven (input arrives when it arrives) |
| Control | App controls what/when to access | External entity controls when to send input |
| Reliability | Internal — predictable | External — unpredictable (user errors, network issues) |
| Latency | Bounded (disk, memory) | Variable (human reaction time, network, physical process) |
| Semantics | Formal (typed queries, structured responses) | Often informal (gesture interpretation, natural language, analog signals) |
These ARE qualitatively different. Different sources, different timing models, different reliability characteristics, different semantic properties.
2.4 Verdict
Access and Perception are SEPARATE primitives. Access is internal (querying your own data). Perception is external (receiving input from outside). Independently variable, qualitatively different.
3. Testing: does Mutation absorb Presentation?
Mutation (Mt): Changing internal state. Write, update, delete, append.
Presentation (would-be Action): Producing external output. Display, audio, API responses, actuation.
3.1 Can the app produce external output without changing internal state?
YES. Examples:
- A static web page serves content without any mutation
- A read-only API responds to queries without changing state
- A display updates to show current time (reading, not mutating, then presenting)
- A game renders a frame (reading game state, producing pixels — no mutation in the render step)
3.2 Can the app change internal state without producing external output?
YES. Examples:
- A background job updates database records with no user-visible output
- An internal reconciliation process corrects data silently
- A message queue consumer processes events without any display
3.3 Are they qualitatively different?
| Property | Mutation (internal) | Presentation (external) |
|---|---|---|
| Target | Own data stores | External world (screens, speakers, actuators, API consumers) |
| Timing | App decides when to mutate | Often must be continuous/real-time (display refresh, audio stream) |
| Reversibility | Often reversible (undo, rollback) | Often irreversible (user saw it, sound played, email sent) |
| Semantics | Formal (typed operations on structured data) | Often perceptual (visual layout, audio mix, tactile feedback) |
| Fidelity concern | Data integrity | Perceptual quality (is it readable? audible? understandable?) |
These ARE qualitatively different. Different targets, different timing requirements, different fidelity concerns.
3.4 Verdict
Mutation and Presentation are SEPARATE primitives. Mutation is internal (changing own state). Presentation is external (producing output to outside). Independently variable, qualitatively different.
4. Testing: does Boundary need to split?
Boundary (Bn): Currently bundles component separation AND inter-system communication.
The abstract surface separates these:
- Protection (Pt) — boundary defense, controlling what crosses
- Exchange (Ex) — inter-system communication, the actual exchange
4.1 Can boundary protection exist without exchange?
YES. A module boundary in a monolith has protection (encapsulation, private interfaces) without inter-system exchange (everything's in one process).
4.2 Can exchange exist without boundary protection?
Barely. Any exchange implies SOMETHING separating the systems. But you could have unprotected exchange — open APIs with no authentication, completely permeable boundaries.
4.3 Are they really separate?
In the abstract surface, Pt and Ex are separate. In organism arch, Df (Defense) and Cm (Communication) are separate. Defense is about KEEPING THINGS OUT. Communication is about LETTING THINGS THROUGH. Opposite directions through the boundary.
But in app architecture, Authority (Au) already covers the protection side. Boundary (Bn) as currently defined is mostly about SEPARATION AND COMMUNICATION — which is more Ex than Pt.
Maybe the split is:
- Authority (Au) covers Protection (Pt) — who can do what
- Boundary (Bn) covers Exchange (Ex) — how components communicate across separation
These are ALREADY separate in our primitive set. We just didn't map them to the abstract surface correctly.
4.4 Verdict
No split needed. Au = Protection, Bn = Exchange. Already covered, just mislabeled in the abstract mapping.
5. The revised primitive set
Adding Perception and Presentation as separate primitives:
| # | Primitive | Abstract role | Internal/External | What it does |
|---|---|---|---|---|
| 1 | Content (Ct) | Structure (St) | Internal | What the application operates on |
| 2 | Shape (Sh) | Organization (Or) | Internal | How content is structured |
| 3 | Access (Ac) | — | Internal | Finding internal content |
| 4 | Mutation (Mt) | — | Internal | Changing internal state |
| 5 | Propagation (Pg) | — | Internal | How internal changes spread |
| 6 | Coherence (Ch) | Regulation (Rg) | Internal | Consistency under concurrency |
| 7 | History (Hs) | — | Internal | Tracking changes [conditional] |
| 8 | Evaluation (Ev) | — | Internal | Computing derived values [conditional] |
| 9 | Perception (Pc) | Perception (Pr) | External | Receiving external input |
| 10 | Presentation (Pn) | Action (Ac) | External | Producing external output |
| 11 | Boundary (Bn) | Exchange (Ex) | External | Inter-system communication |
| 12 | Authority (Au) | Protection (Pt) | External | Controlling access |
12 primitives. 8 internal + 4 external. The internal/external split is clean.
5.1 Testing: is 12 too many?
Organism architecture: 9 primitives. Cognitive architecture: 9 primitives. Abstract surface: 7+2. Are 12 app architecture primitives too many?
The concern is legitimate. Let me check if any of the 12 should collapse.
Does Propagation (Pg) collapse into Mutation (Mt) + Perception (Pc)? Propagation = internal changes spreading. Is this just: Mutation happens → other parts of the system Perceive it? In one sense yes — propagation IS internal perception of internal mutations. But propagation has its own machinery (pub-sub, event buses, reactive frameworks) that's independent of both mutation and perception. Keep separate.
Does History (Hs) collapse into Mutation (Mt)? History = recording what mutations happened. But many systems mutate without recording history. And history has its own concerns (retention, reconstruction, provenance) beyond just "recording mutations." Keep separate (conditional).
Does Access (Ac) collapse into Perception (Pc)? Access = finding internal data. Perception = receiving external input. Both are "receiving information" but from different sources with different properties. Already tested above — they're independent.
Does Evaluation (Ev) collapse into Mutation (Mt)? Evaluation = computing derived values. Mutation = changing state. Evaluation produces NEW values from existing data without necessarily changing state (a derived view, a computed field). They're independent — you can evaluate without mutating (pure computation) and mutate without evaluating (direct write).
5.2 Can any of the 12 be FURTHER collapsed?
Propagation (Pg) + Presentation (Pn)? Propagation is internal spreading; Presentation is external output. Different directions. But sometimes they combine: a change propagates internally, then the resulting state is presented externally. They COMPOSE but don't COLLAPSE.
Access (Ac) + Perception (Pc)? If we think of "input" broadly — the app receives information from inside (Access) and outside (Perception) — these might be one primitive "Input" with an internal/external axis. But the qualitative differences (timing, reliability, control, semantics) suggest they're separate.
5.3 Assessment
12 primitives seems high but may be defensible. The app architecture surface spans a broader range of concerns than organism or cognitive architecture because software does MORE DIFFERENT THINGS than organisms or minds:
- Data management (Ct, Sh, Ac, Mt, Pg, Ch, Hs)
- Computation (Ev)
- External interaction (Pc, Pn)
- System architecture (Bn, Au)
If 12 doesn't survive 3/3b iteration, the most likely collapses are:
- Access + Perception → "Input" (receiving information, any source)
- Mutation + Presentation → "Output" (producing change, any target)
- These would give 10 primitives
But this loses the internal/external distinction, which is structurally important (different timing, reliability, semantics).
6. Dependencies for the 12-primitive set
Ct → (nothing; hub)
Sh → Ct (shape constrains content)
Ac → Ct (access finds content)
Mt → Ct (mutation changes content)
Pg → Mt (propagation triggered by mutation)
Ch → Mt (coherence coordinates mutation)
Hs → Mt (history tracks mutations)
Ev → Ct, Ac (evaluation derives from content via access)
Pc → (nothing; external input is independent of internal content)
Pn → Ct (presentation shows content — needs content to present)
Bn → Ct (boundary scopes content access)
Au → Bn (authority operates at boundaries)
Wait — Pc (Perception) has NO dependencies? External input can arrive regardless of internal state. A keyboard event doesn't depend on the app having content. This makes Pc an INDEPENDENT ROOT, like Cx (Context) in the SSA.
Actually this makes sense. The SSA has two independent roots: En (encoding) and Cx (context). App architecture might have two independent roots: Ct (content — internal) and Pc (perception — external input).
DAG:
Ct (internal hub) Pc (external root)
├── Sh │
├── Ac │ (Pc feeds into Mt and Pn through processing)
├── Mt → Pg, Ch, Hs │
├── Ev (needs Ct + Ac) │
├── Pn (needs Ct to present) │
├── Bn → Au │
└── (Pc connects through processing, not dependency)
Hmm, how does Pc connect? The app receives input (Pc) and then... processes it, which might involve Access (looking up relevant data), Mutation (changing state based on input), and Presentation (showing results).
Pc doesn't DEPEND on any internal primitive. But other primitives may depend on Pc:
- Mt might be TRIGGERED by Pc (user input causes mutation)
- Pn might be TRIGGERED by Pc (user input causes display update)
But these are TRIGGERS, not dependencies. Mutation can happen without perception (background jobs). Presentation can happen without perception (automated display updates).
So Pc is genuinely independent. It's a second root.
Revised DAG:
Ct (root 1) Pc (root 2)
├── Sh
├── Ac
├── Mt → Pg
│ ├── Ch
│ └── Hs
├── Ev
├── Pn
├── Bn → Au
Two independent roots, like the SSA's En and Cx. The internal side (Ct hub) and the external input (Pc root) are independently available.
7. What the two-root structure means
7.1 Parallel to SSA
SSA has En (encoding — internal information) and Cx (context — external conditions) as two independent roots. App architecture has Ct (content — internal data) and Pc (perception — external input) as two independent roots.
This is the SAME PATTERN at a different level. The surface recapitulates the topology's two-root structure.
7.2 The internal/external split is structural
The 12 primitives divide into:
- Internal (Ct-rooted): Ct, Sh, Ac, Mt, Pg, Ch, Hs, Ev — data management and computation
- External (independent or Ct-connected): Pc (independent root), Pn (needs Ct), Bn (needs Ct), Au (needs Bn)
Perception is the ONLY fully independent external primitive. Presentation needs content to present. Boundary needs content to scope. Authority needs boundary to control.
7.3 Apps without perception
A batch processing system has Ct, Sh, Ac, Mt, Pg, Ch, Hs, Ev — the full internal set — but Pc at level 0 (no external input during processing). It receives input through files or schedules, not real-time perception.
This is like an organism without sensing (Sn at 0) — a sessile organism that doesn't detect its environment. Structurally valid but environmentally limited.
7.4 Apps without presentation
An API backend has full internal primitives plus Bn (boundary) and Au (authority), but Pn at level 0 (no direct presentation to humans). It presents to OTHER SYSTEMS through Bn, but not to humans.
This is like an organism without response (Rs at 0) — exists but doesn't act on its environment. It processes internally but doesn't produce visible output.
7.5 The fully interactive app
A fully interactive application (Instagram, a game, a creative tool) has ALL 12 at moderate-to-high levels. Full internal data management, full external perception and presentation, full boundary and authority.
This is the organism architecture equivalent of a complex animal — full sensing, full response, full communication, full internal regulation.
8. Comparing surface primitive counts
| Surface | Primitives | Internal | External | Roots |
|---|---|---|---|---|
| Organism arch | 9 | 4 (Mo, Me, Dv, Ho) | 4 (Sn, Rs, Df, Cm) + Rp | 1 (Mo?) |
| Cognitive arch | 9 | 4 (Kw, Sk, Pl, Cr) | 4 (Dc, Jd, Si, Co) + Id | 1 (Kw?) |
| App arch (revised) | 12 | 8 (Ct, Sh, Ac, Mt, Pg, Ch, Hs, Ev) | 4 (Pc, Pn, Bn, Au) | 2 (Ct, Pc) |
| Abstract surface | 7+2 | ~3 (St, Or, Rg) | ~4 (Pr, Ac, Pt, Ex) + [Rs, Gn] | 1 (St) |
App architecture has MORE internal primitives than other surfaces (8 vs ~4). This might mean: (a) Software genuinely has more internal complexity (more distinct data management concerns) than organisms or minds, OR (b) We're over-counting — some of the 8 internal primitives should collapse
8.1 Why software might genuinely have more internal primitives
Organisms and minds handle data management IMPLICITLY — metabolism, homeostasis, memory are bundled with few distinct concerns. Software handles data management EXPLICITLY — every concern is a separate design decision because software is DESIGNED, not evolved.
The entity system's open evaluator means APPLICATION DEVELOPERS must make choices that biology makes ONCE (genetic code) and never revisits. Access strategy, mutation semantics, propagation model, coherence guarantees, history retention — each is a DESIGN CHOICE in software that's FIXED in biology.
More design choices → more primitives at the surface.
8.2 Or are we over-counting?
Potential collapses to retest:
Propagation (Pg) → aspect of Mutation? In biology, mutation events just propagate through signaling — there's no separate "propagation" primitive. In organism arch, what's equivalent to Propagation? Probably the nervous system aspect of Sensing/Response — changes detected and acted on. Propagation might be the MECHANISM by which Mutation connects to Perception/Presentation, not a separate primitive.
But: in software, you can have mutation without propagation (batch write, no notifications) and propagation without mutation (re-sending old events, subscription replay). They're independently variable.
Coherence (Ch) → aspect of Mutation? In biology, consistency is maintained by homeostasis (Ho). Coherence IS the app architecture's homeostasis — self-regulation under concurrent pressure. It maps to the abstract Regulation (Rg) role. Keep it.
History (Hs) → conditional, keep as noted.
Evaluation (Ev) → conditional based on substrate openness, keep as noted.
9. Working conclusion
12 primitives with two independent roots:
Root 1 — Content (Ct): internal hub for data management
- Sh (Shape), Ac (Access), Mt (Mutation), Pg (Propagation), Ch (Coherence), Hs (History), Ev (Evaluation)
Root 2 — Perception (Pc): external input, independent
Connected to both: Pn (Presentation — needs Ct to present, may be triggered by Pc), Bn (Boundary — scopes Ct, mediates external exchange), Au (Authority — controls Bn)
The abstract surface mapping is now complete:
- St → Ct ✓
- Or → Sh ✓
- Rg → Ch ✓
- Pr → Pc ✓ (was missing)
- Ac → Pn ✓ (was missing)
- Pt → Au ✓
- Ex → Bn ✓ (was partial)
All 7 abstract surface roles filled. Plus 5 additional primitives for software-specific internal concerns (Ac, Mt, Pg, Hs, Ev).
12 total = 7 (matching abstract surface) + 5 (software-specific internal). That's actually a clean decomposition.
Whether 12 survives full 3/3b iteration: uncertain. Propagation is the most likely to collapse. But the two-root structure and the internal/external split feel structurally right.