Exploration: Is Implementation Architecture a Domain?

Status: Exploration. Testing whether the implementation architecture space (namespaces, peer models, SDK levels, resource organization) has its own irreducible primitives, or whether it decomposes into existing domains. Source material: SDK-SYNTHESIS.md, NAMESPACE-AND-PEER-MODEL.md, TREE-NAMESPACE-REVIEW.md (egui-entity-core-rust/docs/architecture/reviews/sdk-review/) Context: The SDK review used ad-hoc architectural analysis and arrived at peer type dimensions, namespace conventions, and SDK levels. The question: would a formal domain analysis have found these? Does the methodology add clarity here, or is this outside its effective range?

1. What the SDK Review Already Found (Without the Methodology)

The review work independently discovered structural dimensions:

Peer type dimensions (4):

• Lifecycle (persistent → session → ephemeral)
• Autonomy (autonomous → managed → embedded)
• Visibility (transparent → abstracted → invisible)
• Role (device, service, management, application, session, worker)

SDK levels (5):

• L0 wire protocol → L1 tree operations → L2 typed entities → L3 extension operations → L4 composition patterns

Namespace concerns (recurrent across all precedent systems):

• What syncs vs what stays local
• How multiple applications coexist
• How system infrastructure separates from user content
• How identity scopes access
• Where state lives by lifecycle (persistent/session/ephemeral)

Convergent evidence: Three implementations in three languages independently arrived at the same operations. Five UI projects arrived at the same views. Three CLIs demonstrate the same command surface.

This is EXACTLY what the methodology looks for in Step 2 (landscape analysis): recurrent patterns across independent instances suggesting underlying structural primitives.

2. Candidate Primitives — What Recurs Across ALL Systems

Looking across Plan 9, Unix FHS, XDG, mobile (Android/iOS), Git, and the entity system — what concerns recur in EVERY system's resource organization?

Candidate 1: Naming (Nm) — How things are addressed and located. Paths, URIs, keys.

• Every system has naming. Plan 9 paths, Unix FHS hierarchy, Git refs, entity tree paths.
• Removing naming: nothing can be found. ✓ minimal
• Naming + Isolation = scoped names (per-process in Plan 9, per-peer in entity). ✓ productive
• ✓ recurrent

Candidate 2: Isolation (Is) — What boundary separates different contexts. The unit of "can't see each other."

• Plan 9: per-process namespaces. Unix: users/groups. Mobile: app sandboxes. Entity: peers.
• Removing isolation: everything is global. No security, no composition, no multi-user. ✓ minimal
• Isolation + Authority = capability-scoped access. ✓ productive
• ✓ recurrent

Candidate 3: Lifecycle (Lc) — How long does state persist? Permanent, session, ephemeral.

• Unix FHS: /usr (static) vs /var (variable) vs /tmp (ephemeral). XDG: config/data/state/cache/runtime. Git: objects (permanent) vs index (session) vs working tree (ephemeral). Entity: system/ (persistent) vs workspace/ (session) vs temp/ (ephemeral).
• Removing lifecycle: can't reason about what persists, what syncs, what's disposable. ✓ minimal
• Lifecycle + Naming = path conventions by lifecycle (storage/ vs temp/). ✓ productive
• ✓ recurrent

Candidate 4: Composition (Co) — How pieces combine. Mount, union, linking, extension.

• Plan 9: bind/mount namespace composition. Unix: mount, symlinks. Entity: extensions compose on tree, peers compose through sync.
• Removing composition: everything is monolithic, no reuse, no assembly. ✓ minimal
• Composition + Isolation = composable isolated units. ✓ productive
• ✓ recurrent

Candidate 5: Authority (Au) — Who can do what. Capabilities, permissions, delegation.

• Plan 9: capabilities. Unix: rwx permissions. Mobile: entitlements. Entity: capability grants.
• Removing authority: no access control. ✓ minimal
• Authority + Isolation = security boundary. Authority + Naming = path-scoped access. ✓ productive
• ✓ recurrent

Candidate 6: Dispatch (Dp) — How requests reach the right handler. Routing, matching, resolution.

• Plan 9: 9P protocol dispatch. Unix: system calls. Entity: handler dispatch via longest-prefix match.
• Removing dispatch: you can name things but can't operate on them. ✓ minimal
• Dispatch + Naming = handler pattern matching. Dispatch + Authority = authorized operations. ✓ productive
• ✓ recurrent

Six candidates. All pass the three tests. Let me check if any should merge or split.

3. The 3/3b Iteration

Should any merge?

Naming and Dispatch — are these one thing? Naming says WHERE things are. Dispatch says HOW operations reach them. You can have naming without dispatch (a filesystem you can read but not execute operations on). You can have dispatch without naming (a function call that doesn't use paths). Distinct.

Isolation and Authority — are these one thing? Isolation says what's SEPARATED. Authority says who CROSSES the separation. Plan 9 has isolation (per-process namespace) without Authority (no capability system — if you can see it, you can use it). Unix has authority (rwx) without full isolation (shared filesystem). Distinct, but heavily interacting (heavy pair).

Should any split?

Lifecycle — does it bundle things? Lifecycle has two aspects: temporal (how long it exists) and mobility (does it transfer between contexts — sync, backup, share). Temporal lifecycle and mobility are different: a persistent entity might not sync (host/); a session entity might sync (workspace state transferring between devices).

Could split into: Lifecycle (temporal persistence) and Mobility (transferability). But mobility might just be Lifecycle + Composition interaction. Keep for now, flag as potential split.

Composition — does it bundle things? Composition includes: mounting (making remote visible locally), extending (adding capabilities), linking (connecting pieces). These might be distinct operations... but they all serve the same structural function (combining isolated pieces). Keep unified.

Is anything missing?

State/Content — the actual DATA being organized. But this might be ambient — it's what the system contains, not how it's organized. In the entity system analysis, Entity (E) is the content primitive. Here, content is WHAT gets named, isolated, composed, authorized, lifecycled, and dispatched. It's the medium, not a primitive of the organization.

But wait — different systems organize DIFFERENT KINDS of things. Plan 9 organizes file-like resources. Entity system organizes typed entities. Unix organizes files and processes. The NATURE of the content affects the organization. Is content-type a primitive?

Maybe not — content type might be a domain-specific property (what Layer 1 already captures for each specific domain). The resource architecture primitives describe HOW things are organized regardless of what they are.

Discovery — how do you find what's available? Handler discovery, service discovery, namespace browsing. But discovery might be Naming + Dispatch composition (name things, then look them up). Or it might be a primitive...

Test: removing discovery means you must know paths a priori. In Plan 9, ls /srv discovers services. In entity system, discover_handlers discovers operations. In Unix, ls /bin discovers commands.

Discovery = reading the namespace (Naming) via the dispatch mechanism (Dispatch). It's a COMPOSITION, not a new primitive. Keep at 6.

Stability check

Six candidates seem stable: {Naming, Isolation, Lifecycle, Composition, Authority, Dispatch}. The Lifecycle/Mobility potential split flagged but not forced.

4. How This Relates to Existing Domain Analyses

4.1 Is this a bridge domain?

The entity system arrangement has:

• Entity system substrate (6 primitives: E, I, T, M, X, P)
• Bridge to application architecture (12 extension mechanisms)
• Application architecture surface (12 primitives: D, Sh, Ac, Mt, Pg, Ch, Pc, Pn, Bn, Au, Hs, Ev)

Where does "resource architecture" sit?

The bridge! The 12 extension mechanisms bridge substrate to surface. Resource architecture describes the STRUCTURE of that bridge — how the substrate's primitives are organized for surface consumption.

Evidence: The SDK levels ARE the bridge levels:

• L0 (wire protocol) = encoding bridge (Enc, Hsh)
• L1 (tree operations) = protocol bridge (Prt, Prs)
• L2 (typed entities) = schema bridge (Sch)
• L3 (extension operations) = extension bridge mechanisms
• L4 (composition patterns) = high-level bridge patterns

The resource architecture primitives map to bridge concerns:

• Naming = how the tree addresses content (T primitive's organization)
• Isolation = how peers separate contexts (P primitive's boundaries)
• Lifecycle = how state persists across time (M primitive's emit lifecycle)
• Composition = how extensions combine (the extension composition model)
• Authority = how capabilities scope access (capability system)
• Dispatch = how operations reach handlers (X primitive's dispatch)

4.2 Is it a decomposition of the bridge?

The entity→app bridge has 12 mechanisms. The resource architecture has 6 primitives. Are the resource architecture primitives the STRUCTURAL CORE of the bridge, with the 12 mechanisms being the specific implementations?

Each resource primitive maps to 2-3 bridge mechanisms. The resource architecture IS the bridge viewed at a higher level of abstraction — the structural vocabulary for understanding what the 12 bridge mechanisms are doing.

4.3 The relationship to app architecture primitives

Each resource primitive ENABLES specific surface primitives. This confirms the bridge relationship: resource architecture sits between substrate and surface, translating substrate mechanisms into surface capabilities.

5. What This Means for the SDK Design Questions

5.1 The namespace question (Naming + Lifecycle + Isolation)

"What should the tree path convention be?" is a question about how Naming, Lifecycle, and Isolation COMPOSE:

• system/ = Naming(protocol-reserved) + Lifecycle(persistent) + Isolation(universal)
• host/ = Naming(hardware-bound) + Lifecycle(persistent) + Isolation(device-specific)
• app/{id}/workspace/ = Naming(app-scoped) + Lifecycle(session) + Isolation(per-app)
• storage/{identity}/ = Naming(identity-scoped) + Lifecycle(persistent) + Isolation(per-identity)
• temp/ = Naming(scratch) + Lifecycle(ephemeral) + Isolation(per-peer)

The namespace convention IS the composition of three resource primitives. The precedent analysis (Plan 9, Unix FHS, XDG) each found the same three: naming structure, lifecycle separation, isolation boundaries. They differ in specifics but share the same structural concerns.

This means: the namespace convention is NOT arbitrary. It's constrained by the resource architecture primitives. The specific paths are Sc2 design choices, but the STRUCTURE (separate by lifecycle, scope by isolation, address by naming) is Sc0 structural — it recurs across all precedent systems.

5.2 The peer type question (Isolation + Lifecycle + Dispatch)

"How should peers be classified?" The four dimensions from NAMESPACE-AND-PEER-MODEL.md map to resource primitives:

• Lifecycle dimension → Lifecycle (Lc)
• Autonomy dimension → Composition + Isolation (who composes this peer's lifecycle?)
• Visibility dimension → Naming (is this peer visible in the namespace?)
• Role dimension → Dispatch (what operations does this peer serve?)

The peer classification IS a multi-dimensional position in the resource architecture lattice. Different peer types occupy different positions:

Each peer type IS a position in the resource architecture lattice. The ad-hoc peer type analysis from the SDK review FOUND lattice positions without knowing they were lattice positions.

5.3 The SDK level question (Dispatch + Composition + Naming)

The five SDK levels are build-up levels of the resource architecture:

• L0: Dispatch at wire level (raw protocol)
• L1: Dispatch + Naming (tree operations at paths)
• L2: Dispatch + Naming + typing (typed entities at paths)
• L3: Dispatch + Naming + Composition (extension operations composing on tree)
• L4: Dispatch + Naming + Composition + cross-Isolation (cross-peer patterns)

The SDK levels ARE a Hasse walk through the resource architecture. L0 activates only Dispatch. L1 adds Naming. L2 adds typing (which is part of Naming). L3 adds Composition. L4 adds cross-Isolation.

5.4 What this tells us

The methodology DOES work for implementation architecture. The ad-hoc SDK review analysis FOUND structural dimensions that correspond to domain primitives. The formal domain analysis confirms what the review found and provides vocabulary to describe it.

The namespace convention is structurally constrained. The STRUCTURE (separate by lifecycle, scope by isolation, address by naming) is universal. The specific PATHS are design choices. This is the Sc0/Sc1 vs Sc2 distinction.

Peer types are lattice positions. The four dimensions are structural dimensions of the resource architecture. Different peer types sit at different positions.

SDK levels are a Hasse walk. The build-up from L0 to L4 activates primitives in dependency order.

6. Assessment: Domain Status

6.1 Is resource architecture a domain?

YES — 6 primitives pass the three-test criterion, show recurrence across diverse systems (Plan 9, Unix, mobile, Git, entity system), and compose productively.

6.2 Where does it sit in the methodology graph?

It's a BRIDGE-LEVEL domain — the structural vocabulary for the entity→application bridge. It sits between the entity system substrate (6 primitives) and the application architecture surface (12 primitives). The 12 extension bridge mechanisms ARE implementations of the resource architecture primitives.

Alternatively, it may be an abstract framework that CONFIGURES how any substrate organizes resources for surface consumption — not specific to the entity system. Plan 9, Unix, and mobile all have the same primitives at different partial levels. The entity system's resource architecture IS a specific position in this abstract domain's lattice.

6.3 What the methodology adds vs the ad-hoc analysis

The ad-hoc analysis found the RIGHT answers (peer types, namespace conventions, SDK levels). The methodology adds:

• Why it's right: the namespace convention works because it follows the resource architecture's structural constraints
• What else to check: pair analysis would reveal which primitive combinations are heavy (Naming-Isolation is probably the heaviest — namespace scoping)
• Prediction: other systems at similar positions should have similar namespace conventions (testable against more precedents)
• Navigation: what would happen if the entity system advanced one of these primitives? (e.g., advancing Composition from extension-based to full runtime composition)

6.4 What the methodology DOESN'T help with here

The specific path choices (workspace/ vs system/ui/) are Sc2 decisions. The methodology identifies the structural constraints (separate by lifecycle, scope by isolation) but can't choose the specific strings. That's prototyping and team convention.

The ad-hoc analysis already converged on the right answer for these (Go's workspace/ prefix won). The methodology would have gotten there too — but not faster. For Sc2 decisions with good precedent analysis, ad-hoc works fine.

7. Open Questions

1. Full 12-step analysis worthwhile? The exploration identified 6 candidate primitives and confirmed they map to the bridge layer. A full analysis (pair loads, core triad, Hasse walks, manifestation positions) would formalize this but might not change any practical decisions. Worth doing for the methodology's validation but not urgent for SDK work.

2. Lifecycle/Mobility split. Flagged in §3 — temporal persistence and transferability might be separate primitives. More instances needed.

3. Relationship to other bridge analyses. The biology→organism bridge also has structural primitives. Do they share the same abstract framework as the entity→app bridge? If resource architecture IS an abstract bridge domain, it should appear in biology too (and it plausibly does — cells have naming/addressing, isolation/membranes, lifecycle, composition, signaling/dispatch).

4. Is this the domain the user sensed was missing? The user noted implementation architecture decisions felt "ad hoc" and wondered if the methodology would help. The answer: YES, at Sc0-Sc1 (structural constraints are real and the methodology identifies them). NO, at Sc2 (specific design choices still need precedent analysis and team decisions). The methodology's value is confirming WHY the converged answers are right, not in finding the answers faster.