Exploration: How Do Other Domains Handle Cross-Domain Interaction?

Status: Exploration. Testing whether an intermediate "interface domain" makes sense by looking at how interaction works everywhere else.

1. The test: do other domains have intermediate interface domains?

1.1 Organism ↔ Environment

An organism interacts with its physical environment — detecting temperature, avoiding predators, finding food.

Is there an "Organism-Environment Interface" domain? NO.

The organism has SURFACE PRIMITIVES that handle the interaction:

• Sn (Sensing) — detecting environmental state
• Rs (Response) — acting on the environment
• Cm (Communication) — exchanging signals with other organisms

The environment is just... the environment. The organism's surface handles the interaction through its own primitives. No intermediate domain.

1.2 Organism ↔ Organism

Two organisms interact — predator/prey, mating, communication.

Is there an "Organism-Organism Interface" domain? NO.

Both organisms have Cm (Communication), Sn (Sensing), Rs (Response). The interaction happens through BOTH surfaces' existing primitives. No intermediate domain.

1.3 Cognitive agent ↔ Cognitive agent

Two humans interacting — conversation, collaboration, conflict.

Is there a "Cognitive-Cognitive Interface" domain? NO.

Both cognitive architectures have:

• Si (Social intelligence) — perceiving the other
• Co (Communication) — exchanging with the other
• Jd (Judgment) — evaluating the interaction

The interaction happens through existing surface primitives on BOTH sides.

1.4 Application ↔ Application

Two software systems interacting — API calls, data exchange.

Is there an "App-App Interface" domain? NO.

Both apps have Bn (Boundary) and potentially Pg (Propagation). The interaction goes through existing surface primitives. REST API, gRPC, message queues — these are MECHANISMS (bridge-like), not separate domains.

1.5 Cat ↔ Keyboard

A cat jumps on a keyboard.

Is there a Cat-Computer Interface domain? Obviously not.

The cat's paw is a physical object. The keyboard is a physical sensor. Physics handles the interaction. The computer processes the keystroke through existing input handling. No special domain.

1.6 Pattern

In EVERY case of cross-domain interaction we've analyzed, the interaction is handled by SURFACE PRIMITIVES on each side. No intermediate domain needed. The surfaces face each other and interact through their own capabilities.

2. What this means for human ↔ software

2.1 Applying the pattern

If the pattern holds, human ↔ software interaction should be handled by:

• Human side: organism arch Sn (sensing the screen), Rs (pressing keys), and cognitive arch Si, Dc, Co (perceiving meaning, making decisions, communicating intent)
• Software side: app architecture's external-facing primitives (????)

The problem: app architecture's current primitives are mostly INTERNAL (data-facing). The external-facing dimension — how the app interacts with things OUTSIDE itself — might be underrepresented.

2.2 What organism architecture has that app architecture doesn't

Organism architecture has BOTH internal and external primitives:

The external primitives (Sn, Rs, Cm) are how organisms interact with their world. They're SURFACE primitives, not a separate domain.

App architecture's current primitives:

2.3 The gap: external-facing primitives

App architecture is missing the equivalent of Sn (sensing) and Rs (response) — the primitives for perceiving and acting on the EXTERNAL world (users, other systems, physical environment).

Boundary (Bn) partially covers this for system-to-system interaction. But the USER-FACING external interaction isn't there.

What would the missing primitives be?

Candidate: Perception (Pc) — the app's ability to receive and interpret external input. User actions, sensor data, external events, environmental state. Organism arch's Sn equivalent.

Candidate: Presentation (Pn) — the app's ability to produce external output. Display, audio, actuation, API responses. Organism arch's Rs equivalent.

These are NOT an intermediate domain. They're surface primitives of app architecture — the external-facing ones we missed because we were focused on data management.

2.4 But wait — aren't these just Access and Mutation?

Access (Ac) = finding data internally. Perception (Pc) = receiving input externally. Different direction — inward vs outward.

Mutation (Mt) = changing internal state. Presentation (Pn) = producing external output. Different direction — inward vs outward.

They're NOT the same primitives. You can access data without any external perception (batch processing). You can mutate state without any external presentation (background service). They're independently variable.

Test: Can Perception exist without Access? YES — an app can receive user input without querying a database. A game controller sends events the app processes without any data retrieval.

Can Access exist without Perception? YES — a background service queries a database without any external input channel.

Independent. They might be separate primitives.

2.5 Or are they partial levels of existing primitives?

Maybe Access at high partial levels INCLUDES external input:

• Ac0: no access
• Ac1: direct address (internal paths)
• Ac2: indexed access (internal queries)
• Ac3: query language (internal declarative)
• Ac4: external input (user actions, sensor data, API calls received)
• ...

And Mutation at high partial levels INCLUDES external output:

• Mt0: no mutation
• Mt1: internal overwrite
• Mt2: structured internal mutation
• Mt3: transactional
• Mt4: external output (display updates, API responses, actuation)
• ...

This would absorb the external dimension into existing primitives rather than adding new ones. The distinction would be partial levels (internal-only vs external-facing) rather than separate primitives.

Problem: This conflates structurally different things. Internal data access and external user input are qualitatively different operations — different latency, different reliability, different semantics. Putting them on the same gradient feels forced.

3. Looking at this from the abstract surface

The abstract surface has 7 universal primitives: {St, Or, Rg, Pr, Ac, Pt, Ex}

• Pr (Perception) — detecting external state
• Ac (Action) — directed output
• Ex (Exchange) — inter-system communication

These three ARE the external-facing primitives. Every surface has them. Our app architecture maps:

Three abstract surface roles are unfilled or partially filled. These are exactly the external-facing roles.

The app architecture's current primitives fill the INTERNAL abstract roles (Structure, Organization, Regulation, Protection) but NOT the EXTERNAL ones (Perception, Action, Exchange).

3.1 What this tells us

The app architecture as currently defined IS a partial surface — it covers the data management side but not the environmental interaction side. This is why something felt missing when we tested against real applications.

To be a COMPLETE surface (like organism architecture), app architecture needs:

• Something for Perception (Pr) → receiving external input
• Something for Action (Ac) → producing external output
• Something better for Exchange (Ex) → inter-system communication (Bn is partial)

Plus our existing primitives covering the internal roles:

• Ct → St, Sh → Or, Ch → Rg, Au → Pt
• Mt, Pg, Hs, Ev → additional internal concerns that the abstract surface doesn't have explicit parallels for

4. Revised thinking: no intermediate domain, just complete the surface

The pattern from ALL other domains: no intermediate interface domain. Surfaces handle their own external interaction through their own primitives.

App architecture needs to COMPLETE its surface by adding the external-facing primitives that organism architecture, cognitive architecture, and the abstract surface all have.

What the full app architecture surface might look like:

Internal-facing:

1. Content (Ct) → St
2. Shape (Sh) → Or
3. Access (Ac) → internal data retrieval
4. Mutation (Mt) → internal state change
5. Propagation (Pg) → internal change spreading
6. Coherence (Ch) → Rg
7. History (Hs) → conditional

External-facing: 8. Perception (Pc) → Pr — receiving external input (user actions, sensor data, external events) 9. Presentation (Pn) → Ac — producing external output (display, audio, API responses) 10. Boundary (Bn) → Pt + Ex — boundary protection + inter-system communication

Evaluation: 11. Evaluation (Ev) → computing derived values (substrate-dependent)

That's 11. But some might collapse under 3/3b iteration. Perception and Access might collapse (both are about "receiving information," just from different sources). Presentation and Mutation might collapse (both are about "producing change," just directed differently).

5. What we DON'T know yet

1. Do Perception and Access really separate? Or are they the same primitive (receiving information) from different sources (internal vs external)?

2. Do Presentation and Mutation really separate? Or are they the same primitive (producing change) directed differently (internal vs external)?

3. Is Boundary one primitive or two? Protection (Pt) and Exchange (Ex) are separate in the abstract surface. Bn currently bundles them.

4. Is there structure in the "external" primitives that constitutes the v1 UI analysis? The v1 UI primitives {E,S,V,L,C,Σ} might describe the INTERNAL STRUCTURE of how apps implement Perception + Presentation — like how organism Sensing (Sn) has internal structure (retina, cochlea, etc.) that could be analyzed as its own domain at a finer resolution.

5. How does the cat test work? Cat presses key → hardware registers keystroke → OS generates event → app receives through... Perception? Access? If the cat's keystroke and a human's keystroke are structurally identical from the app's perspective, then Perception doesn't depend on WHO/WHAT provides the input. It's just "external input received." This is correct — the app doesn't need to know it's a cat.

6. Where we are

• No intermediate HCI domain needed — follows the pattern from all other domains
• App architecture surface is INCOMPLETE — missing external-facing primitives
• The abstract surface tells us what's missing: Perception, Action, Exchange
• These would be SURFACE PRIMITIVES of app architecture, not a separate domain
• The v1 UI analysis might describe the INTERNAL STRUCTURE of how apps implement these external-facing primitives (finer resolution analysis)
• Exact primitive count and boundaries need 3/3b iteration
• The codes (Ke+Kd) at each bridge are still relevant — they describe HOW the external-facing primitives connect to the human world through hardware