Resource Architecture: Full Domain Analysis

Status: Full 12-step analysis. The domain of how systems organize resources for consumption — naming, isolation, lifecycle, composition, authority, dispatch. Discovered through the SDK/namespace review, now analyzed formally to determine what it IS and where it fits. Domain kind (R1): Unknown at start. Could be: substrate, surface, bridge, abstract framework, or a new kind. The analysis will determine. Builds on: exploration-is-this-a-domain.md (candidate primitives identified), SDK-SYNTHESIS.md, NAMESPACE-AND-PEER-MODEL.md, TREE-NAMESPACE-REVIEW.md (source material) Key question: Is this an independent domain, a view of the entity system primitives, a bridge domain, or an abstract framework that configures multiple concrete domains?

Step 1 — Information Gathering

1.1 What we're analyzing

The structural concerns that recur whenever a system organizes resources (files, entities, services, processes, data) for access by consumers (users, applications, other systems). This is the "how things are organized" question that appears in operating systems, distributed systems, databases, the entity system, and biological cells.

1.2 Literature and precedent

Operating systems:

• Plan 9: per-process namespace composition, everything is a file server, /srv as discovery
• Unix: FHS hierarchy, permission model, process isolation, mount points
• Multics: rings, segments, capability-based addressing — the original resource architecture

Distributed systems:

• DNS: hierarchical naming with delegation
• LDAP: directory-based naming with schema and access control
• Kubernetes: namespaces + RBAC + label-based dispatch + lifecycle controllers
• Service mesh (Istio/Envoy): naming (service discovery) + isolation (mTLS) + dispatch (routing) + authority (policy)

Databases:

• SQL: schema (naming) + privileges (authority) + transactions (lifecycle/isolation) + views (composition)
• Content-addressed stores: naming by hash, immutable lifecycle, structural composition

The entity system:

• Tree paths (naming), peers (isolation), extensions (composition), capabilities (authority), handlers (dispatch), persistent/session/ephemeral (lifecycle)

Biology (cellular level):

• Membrane addressing (naming), membrane compartments (isolation), protein lifecycle, organelle composition, signaling pathways (dispatch), molecular recognition (authority)

1.3 What recurs

Every system above deals with the same six concerns. The vocabulary differs but the structural roles are the same.

Step 2 — Landscape Analysis

2.1 Instances positioned by how they handle each concern

2.2 What the landscape reveals

Every system has ALL SIX concerns. No system omits any. Even the simplest (Git) has naming (refs), isolation (branches), lifecycle (immutable objects), composition (merge), authority (repo access), and dispatch (plumbing).

Systems differ in WHICH concerns they emphasize. Plan 9 emphasizes naming and composition (namespace composition IS the system). Kubernetes emphasizes lifecycle and isolation (pod management IS the system). SQL emphasizes authority and composition (views + privileges). The entity system emphasizes naming and dispatch (tree + handler dispatch).

The six concerns are independently variable. Plan 9 has sophisticated naming but primitive authority. Unix has sophisticated authority but primitive composition. Kubernetes has sophisticated lifecycle but relies on DNS for naming. Each system advances different concerns to different levels.

This is the signature of a domain: independently variable dimensions that compose.

Step 3/3b — Primitives and Partial Levels

3.1 The six primitives

1. Naming (Nm) — How resources are addressed and located. The system's coordinate system.

Phase transition: Nm2→Nm3. Below: names are mutable pointers. Above: names are derived from content. This changes everything — deduplication, integrity verification, and concurrent modification all become structural properties rather than engineering challenges. The entity system's I-Full IS Nm3+.

2. Isolation (Is) — The boundary that separates different contexts. What can't see each other.

Phase transition: Is2→Is3. Below: isolation enforced by the OS/runtime — trust the platform. Above: isolation verified cryptographically — trust mathematics. The entity system's P (peer) IS Is3+.

3. Lifecycle (Lc) — How long resources exist and how they change over time.

Phase transition: Lc2→Lc3. Below: resources change in place, old state lost. Above: every change preserved, previous states accessible. This enables undo, audit, and temporal queries — structural capabilities that emerge from versioned lifecycle.

4. Composition (Co) — How separate pieces combine into larger wholes.

Phase transition: Co2→Co3. Below: composition is about code/data linking. Above: composition is about NAMESPACE — what you can see is what you can use. Plan 9's insight: the namespace IS the composition mechanism. Entity system: extensions compose by operating on the shared tree.

5. Authority (Au) — Who can do what. How access is controlled and delegated.

Phase transition: Au2→Au3. Below: authority checked by querying an access control list. Above: authority carried BY the requester as an unforgeable token. This inverts the control flow — no central authority server needed. The entity system's capability model IS Au3+.

6. Dispatch (Dp) — How requests reach the right handler. The routing mechanism.

Phase transition: Dp2→Dp3. Below: routing determined by path/destination. Above: routing determined by WHAT the content is. This enables type-driven processing — the same path can dispatch to different handlers based on entity type.

3.2 The 3/3b iteration loop

Check: do the partial levels stabilize?

Each primitive has a clear progression from absent to self-describing/self-managing. The "Full" level for each is where the concern becomes SELF-REFERENTIAL — naming names itself, isolation isolates itself, lifecycle manages its own lifecycle, etc. This self-referential pattern is consistent across all six.

Check: does anything split?

Lifecycle (Lc) — the potential Lifecycle/Mobility split from the exploration. At Lc3+ (versioned), mobility becomes possible: versioned resources can be transferred because they have integrity (previous versions are preserved, content-addressed). Mobility IS a consequence of Lifecycle + Naming (content-addressed) + Isolation (cross-boundary). It's a three-way composition, not an independent primitive. Keep Lifecycle unified.

Check: does anything merge?

Naming and Dispatch both involve "finding things." But they serve different structural roles: Naming says WHERE things are (passive — the coordinate system). Dispatch says HOW operations reach them (active — the routing). You can name without dispatching (a read-only filesystem) and dispatch without hierarchical naming (RPC with numeric IDs). Distinct.

Primitive set stable at 6: {Nm, Is, Lc, Co, Au, Dp}.

Step 4 — Dependencies

What does each primitive presuppose?

• Nm requires nothing. You can name things without any of the others.
• Is requires Nm (at Is2+). To isolate, you need distinguishable resources — naming provides identity.
• Lc requires Nm. Lifecycle management applies to named resources.
• Co requires Nm + Is. Composition combines isolated named things.
• Au requires Is. Authority controls crossing isolation boundaries. Without boundaries, authority is meaningless.
• Dp requires Nm. Dispatch routes to named handlers/resources.

Nm → Is → Au
  → Lc     → Co
  → Dp

Wait — does Composition really require Isolation? You can compose things that aren't isolated (static linking composes libraries that share the same address space). Co at Co0-Co1 doesn't need Is. But Co at Co3+ (namespace composition) requires Is (you need boundaries to compose across).

Revised: Composition depends on Naming (you compose named things). At Co3+, it also depends on Isolation. But at primitive-presence level, Co only depends on Nm.

Nm → Is → Au
  ↘      ↗
   → Co (depends on Nm; at Co3+ also depends on Is)
  → Lc
  → Dp

Simplified (primitive-presence dependencies only):

Nm → Is → Au
Nm → Co
Nm → Lc
Nm → Dp

Nm is the hub. Everything depends on it. Is enables Au. The rest are independent branches from Nm.

Filter calculation

2^6 = 64 total subsets. Coherent: if Is → Nm, if Au → Is → Nm, if Co → Nm, if Lc → Nm, if Dp → Nm.

Without Nm: only {} is coherent (nothing else can exist without Nm... wait, Nm has no prereqs, so {} alone is a subset without Nm. But can Is exist without Nm? No — Is requires Nm. Can Lc? No. So only {}: coherent.)

Actually, Nm can stand alone. {Nm} is coherent. Then anything that depends on Nm can be added if Nm is present.

Coherent subsets:

• {} = 1
• {Nm} = 1
• {Nm, X} for X in {Is, Co, Lc, Dp} = 4
• {Nm, Is, Au} = 1 (Au requires Is)
• {Nm, Is, X} for X in {Co, Lc, Dp} = 3
• {Nm, Co, Lc}, {Nm, Co, Dp}, {Nm, Lc, Dp} = 3
• {Nm, Is, Au, X} for X in {Co, Lc, Dp} = 3
• {Nm, Is, Co, Lc}, {Nm, Is, Co, Dp}, {Nm, Is, Lc, Dp} = 3
• {Nm, Co, Lc, Dp} = 1
• {Nm, Is, Au, Co, Lc}, {Nm, Is, Au, Co, Dp}, {Nm, Is, Au, Lc, Dp} = 3
• {Nm, Is, Co, Lc, Dp} = 1
• {Nm, Is, Au, Co, Lc, Dp} = 1

Also three-element without Au: already counted above.

Let me count systematically. Nm must be present (except for {}). Au requires Is.

Subsets containing Nm, without Is (so without Au): Any combination of {Co, Lc, Dp} with Nm = 2^3 = 8 subsets ({Nm}, {Nm,Co}, {Nm,Lc}, {Nm,Dp}, {Nm,Co,Lc}, {Nm,Co,Dp}, {Nm,Lc,Dp}, {Nm,Co,Lc,Dp})

Subsets containing Nm+Is, without Au: {Nm,Is} + any combination of {Co, Lc, Dp} = 2^3 = 8 subsets

Subsets containing Nm+Is+Au: {Nm,Is,Au} + any combination of {Co, Lc, Dp} = 2^3 = 8 subsets

Plus {}: 1

Total: 1 + 8 + 8 + 8 = 25

(R2) Filter: 25/64 = 39.1%

39.1% — surface-like looseness. In the range 25-40% typical of surface domains. If this IS a bridge domain, it's at the looser end, which makes sense: bridge domains connect to surfaces and need to accommodate surface-level variability.

Step 5 — Pair Enumeration

C(6,2) = 15 pairs.

Step 6 — Load Classification

Summary:

• Heavy: 5 (Nm-Is, Nm-Lc, Nm-Co, Nm-Dp, Is-Au)
• Medium: 8 (Nm-Au, Is-Lc, Is-Co, Is-Dp, Lc-Co, Co-Au, Co-Dp, Au-Dp)
• Light: 2 (Lc-Au, Lc-Dp)

Hubs:

• Nm: 4 heavy (Nm-Is, Nm-Lc, Nm-Co, Nm-Dp) — strongest hub by far
• Is: 2 heavy (Nm-Is, Is-Au) + 3 medium
• Co: 1 heavy (Nm-Co) + 3 medium

Hub: Nm (Naming). Naming participates in 4 of the 5 heavy pairs. It's the hub everything else relates to.

Anchor pair: Nm-Is (naming + isolation). How you name things AND how you separate them — this IS the namespace architecture question.

Step 7 — Coherent Sub-Lattice

25 coherent subsets out of 64 = 39.1%. See Step 4.

Step 8 — Hasse Diagram Walks

Path α — Plan 9 Path (Naming and Composition First)

{} → {Nm} → {Nm,Co} → {Nm,Co,Dp} → {Nm,Is,Co,Dp} → {Nm,Is,Au,Co,Dp} → Full

"Start with naming. Add composition (bind/mount). Add dispatch (9P). Then isolation (per-process). Then authority. Lifecycle last."

Plan 9's historical development follows this path. Naming and composition were the core insight. Isolation came from the namespace model. Authority was implicit (if you can see it, you can use it).

Path β — Unix Path (Naming and Authority First)

{} → {Nm} → {Nm,Is} → {Nm,Is,Au} → {Nm,Is,Au,Dp} → {Nm,Is,Au,Co,Dp} → Full

"Start with naming (FHS). Add isolation (users). Add authority (rwx). Add dispatch (system calls). Add composition (mount). Lifecycle last."

Unix's development: the FHS hierarchy first, then users and permissions, then system calls, then mount for composition. Lifecycle management (FHS static/variable distinction) came later.

Path γ — Entity System Path (Naming and Dispatch First)

{} → {Nm} → {Nm,Dp} → {Nm,Is,Dp} → {Nm,Is,Lc,Dp} → {Nm,Is,Au,Lc,Dp} → Full

"Start with tree paths (naming). Add handler dispatch. Add peer isolation. Add lifecycle (persistent/session/ephemeral). Add capabilities (authority). Composition last."

The entity system's development: tree paths were first (naming). Handler dispatch was core protocol. Peer isolation came with multi-peer. Lifecycle categories emerged from the namespace review. Capability authority is specified but partially implemented. Full composition (cross-peer, extension-based) is the frontier.

Path δ — Kubernetes Path (Lifecycle First)

{} → {Nm} → {Nm,Lc} → {Nm,Is,Lc} → {Nm,Is,Lc,Dp} → {Nm,Is,Au,Lc,Dp} → Full

"Labels for naming. Pod lifecycle controllers. Namespace isolation. Service routing (dispatch). RBAC (authority). Composition through operators."

K8s: lifecycle management (pod controllers) was the core innovation over raw Docker. Naming (labels, DNS), isolation (namespaces), dispatch (service routing), and authority (RBAC) built around the lifecycle core.

Walk observation

Different systems take different paths through the same lattice, emphasizing different primitives first. The entry point corresponds to the system's core insight:

• Plan 9: naming IS composition
• Unix: naming + authority = security
• Entity system: naming + dispatch = protocol
• Kubernetes: naming + lifecycle = orchestration

But they all arrive at the same full set: every mature system has all six.

Step 9 — Load-Bearing Compositions

Core triad candidates

{Nm, Is, Au} — Security Triangle

Nm-Is heavy, Is-Au heavy, Nm-Au medium. Two heavy + one medium. Close to core but Nm-Au isn't quite heavy enough on its own (authority works through isolation more than directly through naming).

{Nm, Is, Co} — Namespace Architecture Triangle

Nm-Is heavy, Nm-Co heavy, Is-Co medium. Two heavy + one medium. Same pattern — Co works through naming more than directly through isolation.

{Nm, Co, Dp} — Service Architecture Triangle

Nm-Co heavy, Nm-Dp heavy, Co-Dp medium. Two heavy + one medium. Close — composition and dispatch interact (routing through composed namespaces) but the pair is medium.

No perfect core triad with ALL three pairs heavy. The heaviest triangle is:

{Nm, Is, Co} or {Nm, Lc, Dp} — let me check Nm-Lc and Nm-Dp...

Actually, looking at the heavy pairs: Nm-Is, Nm-Lc, Nm-Co, Nm-Dp, Is-Au.

ALL four Nm-X pairs are heavy. But no non-Nm pair is heavy except Is-Au. This means Naming is SO dominant that it makes every pair it's in heavy, but the non-Naming pairs are all medium or light.

This is a hub-dominated domain. The core isn't a triad — it's a HUB with radiating heavy pairs. Naming is the center; everything else relates TO naming more than to each other.

This is similar to how Entity (E) dominates the entity system — the hub primitive that everything depends on.

The structural signature: star topology

        Lc
        |
  Co —— Nm —— Is —— Au
        |
        Dp

Naming at the center, four heavy arms radiating to Isolation, Lifecycle, Composition, and Dispatch. Authority hangs off Isolation. The pairs BETWEEN the arms are medium (they interact but primarily through Naming).

Load-bearing compositions

{Nm, Is, Co} — Namespace Composition. How you name + how you isolate + how you compose = the namespace architecture. Plan 9's entire innovation. Entity system's tree + peers + extensions. Medium-to-heavy triangle.

{Nm, Is, Au} — Access Model. How you name + how you isolate + who can access = the security model. Unix permissions. Entity capabilities. Medium-to-heavy triangle.

{Nm, Dp, Lc} — Service Lifecycle. How you name + how you dispatch + how long things live = the service model. Kubernetes services. Entity handler lifecycle. Medium triangle.

{Nm, Is, Co, Au} — Full Resource Model (quad). The four-way composition: named resources in isolated contexts, composed across boundaries with authorized access. This IS what every resource architecture provides.

Step 10 — Emergent Properties

From Naming hub + each arm:

Nm + Is → Scoped namespace: resources visible only within their isolation boundary. Emergent: per-user views, multi-tenant safety, peer-local state.

Nm + Lc → Lifecycle-categorized namespace: different persistence policies at different paths. Emergent: the FHS, XDG categories, entity system/storage/temp split.

Nm + Co → Composed namespace: multiple sources visible through one namespace. Emergent: Plan 9 union directories, entity extension composition, mount points.

Nm + Dp → Named dispatch: operations routed by name pattern. Emergent: URL routing, handler matching, service discovery.

Is + Au → Security boundary: isolation enforced by authority model. Emergent: capability-based security, sandboxing, multi-user access control.

From the full set:

Self-describing resource architecture: when ALL six are at their "Full" level, the system's naming, isolation, lifecycle, composition, authority, and dispatch are ALL described as resources within the system itself. Entity types define naming. Peers provide isolation. History manages lifecycle. Extensions compose. Capabilities authorize. Handlers dispatch. AND all of these are entities in the tree — the system describes its own architecture.

This self-description IS the entity system at full elaboration. The entity system achieves it because its primitives (E, I, T, M, X, P) map to these resource architecture concerns at high levels.

Step 11 — Structural Patterns

Pattern 1: Hub-dominated star topology

Naming dominates with 4/5 heavy pairs involving it. No heavy pair between non-Naming primitives (except Is-Au). This is a STAR, not a triangle-based structure.

Compare to other hub-dominated domains:

• Entity system substrate: E is hub with 3-4 heavy pairs
• Layer 4 applied analysis: Mn is hub with 5 heavy pairs
• This domain: Nm is hub with 4 heavy pairs

Hub-dominated structures appear when one primitive is the MEDIUM through which all others operate. Naming IS the medium — isolation, lifecycle, composition, authority, and dispatch all operate ON named things.

Pattern 2: Self-referential at Full levels

Every primitive's "Full" level is self-referential — the concern manages itself through the same mechanism. This is the entity system's self-description pattern: types describe types, handlers handle handlers, capabilities authorize capabilities.

Not all domains have this. Biology's primitives at Full levels aren't self-referential (a fully elaborated genome doesn't encode its own encoding scheme — the genetic code is fixed). The entity system and resource architecture BOTH have it, suggesting they share structural DNA.

Pattern 3: Path-dependent but convergent

Different systems enter the lattice at different primitives (Plan 9: composition. Unix: authority. K8s: lifecycle. Entity: dispatch) but all mature systems converge to high levels on all six. The paths differ; the destination is the same.

This is the attractor pattern from the methodology: the full resource architecture is an attractor position. Systems approach it from different directions depending on their entry concern.

Step 12 — Literature Alignment and Cross-Domain Mapping

12.1 Mapping to entity system primitives

Observation: The 6 resource architecture primitives map to the 6 entity system primitives, but NOT 1:1. Naming requires THREE entity primitives (E+I+T). Dispatch uses TWO (X+M). Lifecycle is only partially mapped to M.

This means resource architecture is NOT just "the entity system viewed differently." It's a HIGHER-LEVEL ABSTRACTION that the entity system's primitives implement. The entity system has finer granularity — 6 primitives that produce 6 resource architecture concerns through composition.

12.2 Mapping to the entity→app bridge

Each resource primitive maps to 2-3 bridge mechanisms. The bridge mechanisms ARE the resource architecture's implementation in the entity system.

12.3 Mapping to application architecture surface

12.4 What IS this domain?

Three possible interpretations, all partially right:

Interpretation A: Abstract bridge domain. Resource architecture describes the STRUCTURAL CONCERNS of any substrate→surface bridge. The entity system bridge is one instance. The biology cell→organism bridge might be another. This would make resource architecture an abstract framework that concrete bridges configure.

Evidence for: the same 6 concerns appear in Unix, Plan 9, K8s, SQL, Git, entity system, AND biology. That's cross-domain recurrence at the abstract level.

Interpretation B: The entity system's design space viewed from the application level. Resource architecture is what the entity system LOOKS LIKE from the perspective of someone building applications. The 6 primitives are the SDK designer's concerns.

Evidence for: the SDK review arrived at exactly these concerns without knowing the methodology. The peer type dimensions map to resource architecture positions.

Interpretation C: A domain between bridge and surface — the "platform" level. Not the raw bridge (12 specific mechanisms) and not the surface (12 application primitives), but the structural middle layer where bridge mechanisms are organized into platform services.

Evidence for: resource architecture concerns are MORE abstract than specific bridge mechanisms (handler dispatch is one mechanism; Dispatch as a resource architecture primitive covers ALL routing patterns) but LESS abstract than application primitives (application Data doesn't care HOW naming works).

Most likely: Interpretation A (abstract bridge domain) with C as the concrete instance. Resource architecture is the abstract framework for how ANY system organizes resources for consumption. The entity system's SDK/platform layer is one instantiation. Unix, Plan 9, K8s are others. They all sit at the same abstract position but with different primitive levels.

This makes resource architecture analogous to the info-comp core — an abstract framework that multiple concrete domains configure. The edge from resource architecture to the entity system platform would be a CONFIGURATION edge (the entity system at specific resource architecture settings).

12.5 The biology comparison

If resource architecture is truly abstract (Interpretation A), it should appear in biology. The cell-to-organism bridge handles the same concerns:

This maps. The cell organizes its resources using the same six concerns, implemented through molecular machinery rather than software mechanisms.

The mapping is not perfect — biology's "authority" (molecular specificity) is structural rather than delegatable, and biology's "composition" (organelle assembly) is physical rather than logical. But the six concerns recur.

If confirmed with a full analysis, this would make resource architecture a genuine abstract domain — the third confirmed instance (entity system, biology, + one more from Unix/Plan 9/K8s) needed for the Layer 3 genesis transition.

Summary

Six primitives

Structural signature

• Hub: Naming (Nm, 4 heavy pairs) — star topology
• Anchor pair: Nm-Is (naming + isolation = namespace architecture)
• Heavy pairs: 5/15 (33%) — Nm-Is, Nm-Lc, Nm-Co, Nm-Dp, Is-Au
• No core triad with all-heavy — hub-dominated star rather than triad-based
• Filter: 39.1% (25/64) — surface-like looseness
• Dependencies: Nm → {Is, Lc, Co, Dp}. Is → Au.
• Phase transitions: Nm2→3 (mutable→content-addressed), Is2→3 (platform→cryptographic), Lc2→3 (in-place→versioned), Co2→3 (linking→namespace), Au2→3 (role→capability)

Domain classification

Abstract bridge domain — the structural framework for how any system organizes resources for consumption. Concrete instances: entity system platform (SDK/namespace layer), Unix, Plan 9, Kubernetes, SQL databases. Biology's cell-to-organism bridge may be another instance. Connected to entity system through a configuration edge (entity system at specific resource architecture settings).

What this means for the SDK decisions

The SDK review's findings are STRUCTURALLY GROUNDED. The namespace conventions follow Nm-Lc composition (naming categories by lifecycle). The peer types are positions in the resource architecture lattice (each peer type at different Nm/Is/Lc/Co/Au/Dp levels). The SDK levels are a Hasse walk (adding primitives in dependency order).

The practical decisions (specific paths, specific API shapes) are Sc2 — beyond structural analysis. But the methodology confirms WHY the converged answers are right and provides vocabulary for reasoning about future architectural decisions.