Dimensional Completeness: Validating Protocol Design Through Irreducible Primitives

1. Introduction

A protocol that changes after release imposes migration costs on every implementation and deployment. If specific design choices can be validated before release — if the type system can be shown to cover the structural primitives of data description, and the capability system can be shown to cover the structural primitives of authorization — then the protocol resists the kind of post-release changes that are most expensive: structural ones.

This paper applies a design validation procedure to two design spaces within The Entity Core Protocol: the type system and the capability system. The procedure is the same in both cases: survey existing systems in the design space, identify the irreducible primitives that any system in the space must address, decompose each primitive into partial levels, categorize any gaps, and test whether the protocol covers the space.

The entity core protocol is built from six substrate primitives — Entity, Identity, Tree, Emit, Execution, and Peer — described in The Entity System. These substrate primitives and the fifteen pair-relationships they produce determine what properties the protocol has. But the substrate primitives alone do not tell you whether the type system’s field vocabulary is sufficient, or whether the capability grant’s four fields are the right four. Those are specific design choices that require specific validation against the primitives of the relevant surface design space.

Two independent analyses — one examining type systems, the other examining capability and authorization systems — each find eight irreducible primitives. Each primitive decomposes into 3–6 partial levels. The analyses were conducted by examining existing systems, not by deriving from the entity substrate primitives. The results map back: each surface primitive requires specific pair-coverage among the substrate primitives. The type primitives require pairs within the EIT (self-description) triangle; the capability primitives span the EIT, TMX (reactive dispatch), and IXP (cryptographic capability) triangles. This convergence between bottom-up analysis of an existing design space and top-down structure from the substrate primitives provides confidence that the protocol’s design choices cover what they need to.

A third validation — the cross-compilation partition — examines what happens when programming language features are translated to entity computation. The partition into three categories is uniform across five languages with radically different type systems, suggesting the entity type system captures a natural level of abstraction.

A note on this paper’s history. This paper was first authored before the structural methodology of A Structural Methodology for Information System Domains crystallized. The early work captured the right intuition — survey the landscape, extract the primitives, ground them in the substrate — but using coarser vocabulary (“dimensions”), implicit irreducibility tests, and no formal partial-level decomposition. The methodology, later formalized and applied across roughly twenty domains, was applied back to this paper’s two design spaces under formal procedure. The result: minor refinements for the type system (one additional primitive, three renames) and substantive refinements for the capability system (two additional primitives, including the Authority primitive that the protocol spec independently arrived at by debugging cross-peer capability bugs — §5.2 “three slots”). The appendix records the reconciliation in detail.

The primitive combinatorial analysis — partial levels, pair-coverage scoring, attractor states, and landscape positioning across the entity substrate itself — is developed in the companion paper on Convergent Evolution. The full methodology of structural domain analysis is in A Structural Methodology for Information System Domains. This paper focuses on validating specific protocol design choices through primitive coverage within two surface design spaces, using pair-relationships as the analytical layer that connects surface primitives to substrate primitives.

Companion papers. The six substrate primitives, fifteen pair-relationships, and five named structural triangles are in The Entity System. The protocol specification is in The Entity Core Protocol. The computational architecture and two-level type architecture are in The Entity Church Architecture. The full landscape analysis with pair-coverage scoring across the substrate is in Convergent Evolution. The structural methodology in full generality is in A Structural Methodology for Information System Domains.

2. Type System Design Validation

2.1. The Question

The entity core protocol defines a structural type system. Type definitions are entities — stored at system/type/* in the tree, subject to the same content addressing and dispatch as all other data (see The Entity System; The Entity Core Protocol). But what fields should a type definition have? What structural vocabulary is sufficient for describing data exchanged between peers?

These are not questions the primitives answer directly. The primitives establish that types are entities (E), types have content-derived identity (I), and types live at known paths (T). But the specific structural vocabulary — which fields, which composition mechanisms, which constraints — is a design choice. To validate it, we examine what existing type systems do.

2.2. Eight Primitives of Type Description

Analysis of 16 independent type systems — spanning schema systems, programming languages, and data description formats — reveals eight irreducible primitives that any type system addresses. (Earlier work, before the structural methodology of A Structural Methodology for Information System Domains crystallized, listed seven “dimensions”; the methodology’s formal procedure — explicit irreducibility tests on the landscape, plus partial-level decomposition — surfaces Naming as a separable primitive that the earlier survey took for granted, and clarifies three other primitives via partial-level analysis. See appendix.) Each primitive addresses a structural question that any system exchanging structured data must answer. Each also requires specific pair-coverage over the entity system’s substrate primitives — pairs of substrate primitives that must be in full expressiveness for the surface primitive to operate (see The Entity System).

Each primitive is irreducible: removing any one loses expressiveness that no combination of the others recovers.

Shape without constraint can describe structure but cannot validate values. Constraint without shape can validate values but has no structure to attach them to. Composition without naming can relate types only by inline embedding, which collapses into Shape. Equivalence without representation can compare by nominal labels but cannot establish cross-system agreement on canonical content. Representation without evolution can serialize data but cannot handle format changes. These are independent axes.

The derivation is forced by the nature of structured data exchange. Data has shape. Shape has fields. Fields have cardinality. Fields have value constraints. Types compose. Types need names. Types need equivalence rules. Types cross wire boundaries (representation). Types change (evolution). Each step follows from the previous. The structural vocabulary is not arbitrary — it is what any system must address when describing data for exchange.

All eight primitives require pairs within the EIT triangle (the self-description triangle from The Entity System). Composition requires the full triangle (all three pairs at full strength); other primitives require specific sub-pairs. The concentration of all eight type primitives within a single named substrate triangle is itself a structural finding: type description is the informational substrate at work, and the EIT triangle is precisely what activates when the informational substrate is complete. A system that does not reach the full EIT triangle will fail to support at least one type primitive; this is predictive and testable.

Partial levels

Each primitive decomposes into partial levels — a gradient from absent to fully elaborated (see A Structural Methodology for Information System Domains). Three excerpts illustrating the pattern (see the methodology domain analysis for the full eight-by-five table):

• Naming: Nm0 anonymous structural types only / Nm1 type aliases / Nm2 first-class named definitions / Nm3 namespaced names (packages, modules) / Nm4 globally addressable names (URI / hash / DID — the entity system’s level).
• Equivalence: Eq0 no equivalence rule / Eq1 nominal (same name) / Eq2 structural (same shape) / Eq3 content-derived (same canonical bytes / hash). Phase transition at Eq2→Eq3: requires the substrate’s Identity primitive at Full I.
• Representation: Rp0 in-memory only / Rp1 single encoding / Rp2 multiple encodings / Rp3 canonical encoding (deterministic single canonical bytes) / Rp4 self-describing encoding (decode without external schema).

The phase transitions matter for the entity system’s distinctive contribution: Eq3 requires Rp3 plus substrate-Identity, and this cascade is what makes type identity intrinsic across peers without coordination.

2.3. The 16-System Comparison

We compared 16 type systems across the eight primitives, scoring each system’s partial level per primitive. Two scoring views are reported: a per-primitive partial-level matrix (full detail in the methodology domain analysis) and an aggregate static-coverage figure for backward continuity with the original analysis.

The aggregate static coverage figures (percentage of the primitive space each system covers with its built-in mechanisms, ignoring type-level computation). These are not summed from the partial-level matrix; each is an analyst estimate of the share of that system’s type-description features that map directly onto the entity type system’s built-in mechanisms — features that need the compute extension or are fundamental gaps do not count. They are coarse by construction (rounded to the nearest 5%), reported here only for continuity with the original seven-dimension analysis; the per-primitive partial levels below are the load-bearing measure.

The pattern is similar to the earlier seven-dimension scoring, with one shift: the entity type system’s distinctive Eq3 (content-derived equivalence via canonical encoding) now shows as a partial-level peak rather than as a single binary dimension. Schema systems concentrate at Eq1 (nominal) regardless of how strong their other primitives are; IPLD is the only surveyed schema system reaching Eq3 in any form (via CID-keyed schemas, not content-derived equivalence of values). This sharpens the earlier seven-dimension “entity system exceeds most systems on Identity” claim — now grounded in a specific phase transition (Eq2→Eq3 requiring substrate-Identity at Full I).

Systems with highest aggregate coverage are schema and protocol systems — Avro, Protobuf, AT Protocol, Cap’n Proto, IPLD, CDDL. These systems focus on describing data structure for exchange. They are the entity type system’s closest relatives. In pair-coverage terms, these systems concentrate their coverage within the EIT triangle: strong EI (typed data with identity), strong ET (types at known paths or in known schemas), and strong IT to the extent their schemas are addressable. Gaps reflect incomplete triangle coverage rather than structural absence.

Programming languages score lower not because they are less capable, but because they invest type expressiveness in Composition (Cp4–5: generics, type classes, conditional types) and in type-level computation, rather than in the description primitives the protocol/schema cluster optimizes for. Haskell’s type classes, TypeScript’s conditional types, and Rust’s trait system are Composition mechanisms at Cp4–5. They extend beyond Shape description into program verification, which we treat as a scope-excluded primitive (see Gap Categorization below). When type computation is removed, the underlying description vocabulary is the same: Haskell’s data declarations describe the same Shape space as Protobuf messages. The pair-coverage pattern differs: programming languages activate EX (typed computation) and EI (types as language constructs) strongly but often do not settle on a shared wire-level ET, which is why translating a Rust type to a Protobuf message requires an explicit schema commitment.

2.4. Convergence Evidence

14 of 16 systems independently develop vocabulary for the same structural primitives:

No system achieves data shape description with a structurally different vocabulary. Systems that appear different — CUE’s lattice-based types, Haskell’s algebraic data types, SQL’s relational model — decompose to the same structural primitives when the type computation layer is removed. The structural convergence across 16 independently designed systems is strong evidence that the vocabulary is not arbitrary.

2.5. Gap Categorization

Every gap between the entity type system and any of the 16 systems falls into one of three categories:

Type computation (intersection types, conditional types, negation types, mapped types, higher-kinded types, information objects): computations over types that produce new types. These are expressiveness that belongs in the compute extension — they extend beyond structural description into type-level programming.

Encoding-specific (field tags and ordinals, zero-copy layout directives, CBOR-specific validation rules, multiple encoding rule sets): properties of particular wire formats. Excluded by design from an encoding-independent type system. ECF (Entity Canonical Form) deterministic encoding means the entity type system is deliberately encoding-independent — bridge handlers translate encoding-specific features when crossing the protocol boundary.

Domain-specific validation (format validators, uniqueness constraints, cross-field arithmetic constraints): domain rules that depend on application context. These belong in handler validation or the type extension’s value-level constraint mechanism, not in the structural type system.

This categorization means the entity type system is complete for structural type description. What it excludes is excluded by design, with a specific mechanism for where each category belongs: type computation in the compute extension, encoding specifics in bridge handlers, domain validation in handler logic.

2.6. Entity Type System Coverage

The entity type system covers all eight primitives, with the following partial-level positions:

• Naming: Nm4 (globally addressable). Types live at system/type/X paths in the tree; type-refs are paths; type identity is intrinsic to the path-and-content pair.
• Shape: Sh4–Full Sh. Records, sequences, maps, unions (via union_of), tuples. Self-describing types (system/type is itself an entity type).
• Cardinality: Ca2–3. Required, optional, repeated. Open types preserve unknown fields for forward compatibility. Richer cardinality (uniqueness, exactly-k) in the type extension.
• Constraint: Co2–3 in core, Co3 in the type extension. Pattern validation, range constraints, enumerations at core; cross-field arithmetic in the extension’s value-level constraint mechanism. Co4 (refinement / dependent constraint) is scope-excluded by design.
• Composition: Cp3–4. Single inheritance (extends), entity references via content hashes, generics, union types. Cp5 type-level computation is scope-excluded from the type system itself and lives in the compute extension.
• Equivalence: Eq3 (content-derived). Same canonical bytes hash to the same identity everywhere. The distinctive entity-system contribution; depends on Rp3 + substrate-Identity at Full I.
• Representation: Rp3 (canonical). ECF (Entity Canonical Form) gives encoding-independent structural description with deterministic canonical bytes. Self-describing types support an Rp4-like behavior (decoders can resolve type definitions via tree paths).
• Evolution: Ev2–3. Open types, compatibility rules, deprecation in core. Dynamic aspects (schema migration, live type evolution) distributed across extensions.

The two-level type architecture described in The Entity Church Architecture maps onto these primitives: Level 1 (structural types, core protocol) covers Naming, Shape, Cardinality, Composition, Equivalence, Representation, and Evolution. Level 2 (value constraints, type extension) covers Constraint. The separation reflects an observation: structure is universal (every system exchanging data needs to know field shapes), while value-level validation is domain-specific (what counts as valid varies by application).

3. Capability System Design Validation

3.1. The Question

The entity core protocol defines a capability system with four-dimensional grants (see The Entity Core Protocol). Each grant entry has fields for handler scope, resource scope, operation scope, and peer scope. Capability tokens carry these grants with cryptographic attenuation chains, temporal windows, and explicit revocation. The system has been refined across many spec revisions, including the normative addition of “three slots” for cross-peer capability provenance (see below).

But why these particular fields? Are they the right ones? Is the design space complete?

3.2. Eight Primitives of Authorization

Analysis of capability systems, access control models, and authorization frameworks reveals eight irreducible primitives. (Earlier work, before the structural methodology of A Structural Methodology for Information System Domains crystallized, listed seven “dimensions”; the methodology’s formal procedure surfaces two additional primitives — Authority as separate from Subject, and Revocation as separate from Time-expiry — both of which the protocol spec independently arrived at by debugging cross-peer flows. See appendix for the reconciliation.)

Each primitive corresponds to a structural aspect of authorization that any system must address. The primitives operate at three protocol layers (per-grant-entry scope, per-token scope, separate lifecycle mechanism); one primitive (Context) operates across both grant and token layers, giving the natural breakdown below.

Per-grant-entry scope primitives (one field per grant entry in a token’s grants array):

Per-token scope primitives (one field on the capability token itself):

Lifecycle mechanism (operates outside the token via separate entity):

Context (Cx) operates at both grant and token layers because the design space has both a spatial scoping axis (which peers) and a temporal scoping axis (which time window), and the methodology treats them as partial-level axes of one Context primitive rather than as two separate primitives. The architecture team’s choice to express the spatial axis per-grant (peers field) and the temporal axis per-token (expires_at, not_before) is a structural design choice within Context, not a difference in primitive identity.

An extensibility escape hatch — the constraints field — allows domain-specific coordinates without adding primitives.

Three primitives require Full I to activate (Sb, Au, At) because their supporting pairs (IP, IX) are phase-transition pairs: they do not operate at partial identity levels (see The Entity System). A system at I1 (assigned identity, not content-derived) cannot express these primitives in the entity-system sense, regardless of how many grant fields it has. This is the structural reason capability-based security in the entity system requires Full I and not merely some form of identity.

3.3. The Three-Slot Convergence (Spec ↔︎ Methodology)

The Subject/Authority/Attenuation distinction is the most consequential refinement in the eight-primitive analysis, and it has a notable provenance: the architecture team and the structural methodology arrived at the same three-slot decomposition by entirely independent routes.

The spec route was operational. §5.2 (“Cross-peer capability provenance — the three slots”, normative) was added after a recurring class of cross-peer capability bugs in which the local case of authorization (where the requester, the resource owner, and the in-chain granters collapse onto one identity) silently omitted two of the three slots. Cross-peer flows force the slots apart, and code paths reasoned about only the local case mis-attributed authority. The amendment names the three slots — and pins each to a different check point. In the spec’s own words:

A capability presented in an EXECUTE has three independent identity slots, each checked at a different point. […]

• Root — the peer that owns the resource being acted on. A chain can authorize action on peer X’s resource only if it roots at an authority X conferred. […]
• Grantee (of the leaf) — the wielder: the identity that authors the EXECUTE. […] The cap must be granted to whoever presents it.
• In-chain granters — every party that attenuated along the way, including any installer/minter that pre-mints a cap for later use. […] requires only that the writer appear as a granter somewhere in the chain — not that the chain roots at the writer.

— ENTITY-CORE-PROTOCOL §5.2

That the three slots are checked at three different points is the operational payoff: it is exactly the structure that the local case hides. §5.2 makes the slots an enforced invariant — any cross-peer capability-bearing operation must fill all three explicitly — and EXTENSION-SUBSCRIPTION §1.2 and EXTENSION-CONTINUATION §4.2 case 3 are now framed as instances of this one model, not as independent designs.

The methodology route was theoretical. The structural decomposition of capability-systems-as-a-domain (per A Structural Methodology for Information System Domains, the canonical analysis is under the project’s methodology directory) tests primitive candidates by irreducibility, compositional productivity, and empirical recurrence. The candidate primitive set for authorization includes Subject (the requester at request time) and Authority (the source of permission). They are independent: every delegated grant has a Subject distinct from its Authority, and the cap-systems literature (Dennis & Van Horn 1966; Miller 2006) treats them as separate concepts.

Both routes arrive at the same decomposition: Subject (grantee), Authority (chain root), Attenuation (in-chain granters). The convergence is structural evidence: the decomposition is not an artifact of either route. It is what the design space requires.

3.4. Why Each Primitive Is Irreducible

Removing any primitive loses authorization expressiveness:

• Without Subject: cannot distinguish who is acting. Every request is anonymous.
• Without Mechanism: cannot scope by handler. Authorization is mechanism-blind.
• Without Verb: cannot distinguish read from write from delete. All operations are equivalent within a mechanism.
• Without Object: cannot scope by data. Authorization is all-or-nothing on data access.
• Without Context: capabilities are unconditional — no time bounds, no spatial scoping, no environmental conditions.
• Without Authority: cannot answer whose permission is this exercising; every capability appears equally valid; cross-peer authorization collapses.
• Without Attenuation: capabilities cannot be safely delegated; every grant must come from root with full power.
• Without Revocation: capabilities are eternal — expiry without revocation handles only foreseeable cancellation, not compromise or policy change.

Each is an independent axis. Mechanism and Verb are distinct because the same verb (e.g., “read”) may be authorized on one mechanism but not another. Object and Context are distinct because the same object path may be accessible in some contexts but not others. Authority and Subject are distinct in any delegated grant (the holder of the capability is not its root). Attenuation and Revocation are distinct temporal modes: Attenuation is forward-narrowing at delegation time; Revocation is backward-cancellation after grant.

3.5. Capability as Region

A capability token is not a point in the eight-dimensional space — it is a region. Each grant entry defines a volume in the per-grant primitives: a set of mechanisms, a set of objects, a set of verbs. The token adds Subject, Context, Authority, and Attenuation constraints. Revocation can subsequently reduce the volume to zero.

Authorization is checking whether a point (the current request) falls within the region (the capability token) and the region has not been revoked. Attenuation is creating a sub-region — every attenuated capability is a smaller volume within the parent. The volume can only shrink, never grow. This is monotonic attenuation: delegation can restrict but never amplify. Revocation is a discrete event: the volume goes from positive to zero on a specific token.

3.6. The Four-Dimensional Grant Within an Eight-Primitive Structure

The entity system’s grant entry has one field per per-grant-entry primitive:

• handlers (Mechanism)
• operations (Verb)
• resources + exclude (Object)
• peers (Context, spatial axis)

This is the original “four-dimensional grant” framing of this paper. It remains accurate as a description of what varies per grant entry. The methodology refinement shows that the four-dimensional grant is one layer in a larger eight-primitive structure: four per-grant scopes inside a token that itself carries four additional primitives (Subject as grantee, Authority as granter, Attenuation via parent chain, Context-temporal via expires_at / not_before), with Revocation operating as a separate lifecycle mechanism (system/capability/revocation).

Counting the layers: 4 per-grant + 4 per-token (where Context appears at both layers as different partial-level axes) + 1 lifecycle = the 8 primitives. The earlier framing of this paper called the per-grant set “the four-dimensional grant” and treated the remainder as “Subject + Time + Delegation” — which collapsed Authority into Subject and bundled Revocation into Time. The methodology view separates these correctly and adds Revocation as a first-class lifecycle primitive.

The four-dimensional grant is therefore a principled and correct architectural choice for what varies per authorization scope; the methodology refinement is to the enumeration of what surrounds the grant, not to the grant itself.

3.7. Comparison to Existing Systems

Five capability and authorization systems illustrate different coverage patterns. Each system is scored at the partial-level of each of the eight primitives (per the methodology analysis).

The entity system reaches the highest partial level on six of eight primitives. UCAN matches Sb4 (both use content-addressed identity); CHERI matches At3 (sub-capability derivation in hardware); none of the surveyed systems reaches Ob5, Cx3-with-spatial-axis, or Au3-with-per-peer-root in combination.

The pair-coverage view explains the differences. Each system activates a subset of the capability-relevant substrate triangles:

• Zanzibar activates IP (subject) and TX (resource via relations), concentrated in a single-domain IP+TX cluster. Au1 (central authority) means the IXP triangle does not fully activate.
• UCAN activates IP (DID), EX (ability), and the IX aspect of IXP (proof chains) but not the full IXP triangle (no TP, no XP for topology). Revocation stays at Rv1.
• Macaroons activate IP (bearer), partial EX (caveat-encoded operations), and IM/TM (time caveats), but no TX for resource routing. At3 makes Macaroons attenuation-strong but Au1 limits provenance reasoning.
• Biscuit extends Macaroons’ caveat model with Datalog, reaching Vb3 and richer Cx, but stays at Au1, At3, Rv1.
• CHERI activates capability-as-machine-word with hardware enforcement. At3 (sub-capability derivation) is hardware-implemented. But Mc0 (memory-bound, not mechanism-aware) and Cx0 (no environmental conditions) limit its scope to the per-memory-access level.

The entity system activates the full IXP capability triangle plus TX (handler dispatch), TP (peer-namespaced objects), and IM/TM (temporal context). Authority at Au3 (per-peer roots) requires substrate-Identity at Full I; this is the cascade that lets the entity system reach the highest partial levels across the most primitives in one composition.

This also maps to classical access control theory (ABAC): Subject attributes map to Sb. Action attributes map to Mc + Vb. Resource attributes map to Ob. Environment attributes map to Cx. Meta/policy attributes map to Au + At. Lifecycle management (often outside ABAC’s frame) maps to Rv. The entity system provides finer granularity than ABAC by separating Action into Mechanism and Verb (distinct pair-coverages: TX vs EX), keeping Authority distinct from Subject (the cert-chain framework in Entity System Security Architecture operates on this distinction), and treating Revocation as a first-class lifecycle primitive.

4. Cross-Compilation Partition

4.1. The Partition

When translating any programming language to entity computation, language features partition into three categories (see The Entity Church Architecture):

Category A (maps directly): data types, functions, closures, generics, async, pattern matching, modules, interfaces. These map to entity types, handlers, compute expressions, type parameters, continuation chains, and tree structure.

Category B (erases): lifetimes, ownership, borrow checking, GC internals, access modifiers, stack layout, laziness strategy. Machine-level concerns that the content-addressed substrate handles structurally.

Category C (requires handler embedding): SIMD, inline assembly, memory-mapped I/O, raw pointer arithmetic, hardware register access. These need the actual machine and live inside native handlers, opaque to the entity model.

4.2. Uniformity Across Languages

The partition is uniform across five languages with radically different type systems and runtime models:

In every case: Category A represents what the language says about data and its transformation. Category B represents what the language says about the execution substrate — these erase because entity computation is a different substrate. Category C represents machine-level operations that the language exposes.

The entity type system abstracts away the same things across all languages. Rust’s lifetimes, Haskell’s laziness, TypeScript’s access modifiers, C’s pointer arithmetic, Python’s GC — all are Category B. All erase. What survives is the data transformation semantics, and those are universal.

4.3. Category B as Purity Boundary

Why does Category B erase? Consider Rust’s ownership model. It prevents use-after-free, double-free, and data races. In entity computation, none of these problems exist:

• Use-after-free: entities are content-addressed and immutable. Nothing is freed.
• Double-free: there is nothing to free. Content-addressed entities persist.
• Data races: entities are immutable. Path rebindings are serialized through the emit pathway.

Lifetimes compile to nothing. They erase completely. Not because entity computation cannot express them, but because the problems they solve do not exist in a content-addressed, immutable-entity, single-emit-pathway model. The entity computation substrate inherently provides the guarantees that lifetimes enforce in Rust.

The same pattern applies to every Category B feature across every language. Each Category B feature manages an aspect of the execution substrate — memory layout, evaluation strategy, access scope — that the content-addressed model handles structurally. Content addressing provides identity and lifetime semantics. The emit pathway serializes state changes. Open types handle forward compatibility.

4.4. Category C as Handler Boundary

Category C features require machine access. They cannot be expressed in content-addressed typed data because they need the physical machine: specific instruction sets, memory-mapped hardware, operating system interfaces. These live inside native handlers, which are opaque to the entity model — typed parameters in, typed result out, machine access inside.

Category C defines the machine boundary — where entity computation ends and physical computation begins. This boundary is examined in The Entity Machine Boundary.

4.5. Independent Validation

The cross-compilation partition validates the type system from a different direction than the 16-system comparison. The type comparison asks: does the structural vocabulary cover the description space? The cross-compilation partition asks: does the abstraction level capture the right things?

The uniformity of the partition across five languages — the same A/B/C split despite radically different type systems — suggests the entity type system sits at a natural level: above machine computation (Category B erases), below human-level intention (Category A maps), with a clean boundary to hardware (Category C embeds). Entity computation sits above machine computation but below human-level intention. It operates at the level of data transformation and coordination.

5. Connection to Substrate Primitives

The type primitives and capability primitives were identified by examining existing systems — bottom-up analysis within each design space. The six substrate primitives were identified by alternating construction and reduction of the protocol — top-down design (see The Entity System). That the two routes converge through pair-coverage provides independent validation.

5.1. The Four-Layer Analytical Framework

The grounding from substrate primitives to surface primitives is not a single step but passes through an intermediate layer. Four layers of analysis are available:

The surface-primitive analyses in this paper live at Layer 4. They were identified through formal methodology procedure (see A Structural Methodology for Information System Domains) applied to each design space independently; that they ground cleanly back through Layers 3, 2, and 1 is what “convergent validation” means here. Pair-relationships are the natural intermediate layer: they explain why particular surface primitives require particular substrate primitives, because each surface primitive requires specific pair-coverage to operate.

5.2. Type Primitives Ground in E+I+T via the Information Pair-Bundle

The eight type primitives map to informational substrate primitives, and more precisely to specific pair-coverage:

All eight type primitives require pairs within the EIT triangle (the self-description triangle from The Entity System). This is consistent with the observation that information precedes computation: the type system describes structure, which is informational. Constraint enforcement (checking values against constraints) requires computation (X), but the constraints themselves are structural descriptions over the EIT triangle.

5.3. Capability Primitives Ground in the Full Substrate via Multiple Pair-Bundles

The eight capability primitives ground in different substrate primitives and pair-bundles:

The capability primitives require all six substrate primitives and reach into multiple named triangles: EIT (types-as-tokens), TMX (dispatch + temporal scoping), IXP (capability cryptography), and the temporal axis IM/TM (lifecycle). Together, the 16 surface primitives (8 type + 8 capability) require all six substrate primitives and the five named structural triangles from The Entity System.

5.4. Phase-Transition Pairs Constrain Capability Completeness

Two of the 15 pair-relationships are phase-transition pairs (see The Entity System): they do not activate gradually but require Full I on their Identity endpoint.

• IX (convergence check): requires content-derived identity. Runtime equality of typed outputs depends on Full I.
• IP (content-addressed peer ID): requires Full I to derive a peer’s identifier from a key hash.

These phase transitions matter for capability completeness. Three capability primitives — Subject (via IP), Authority (via IP+IX), and Attenuation (via IX) — do not come in gradations at all; they require Full I to function. A system at I1 (assigned identity) cannot have capability-chain verification in the entity-system sense, even if it otherwise implements every grant field. This is the structural reason the entity system requires Full I: without it, the IXP capability triangle cannot activate, and three of the eight capability primitives degrade.

5.5. Convergence of Analyses

Three observations about this mapping.

First, the type primitives require only pairs within the EIT triangle, while the capability primitives span multiple triangles and require the full substrate. This reflects the 3+2+1 structure of the primitives described in The Entity System: information (E, I, T) is foundational; time (M, X) and space (P) build on it. Data description is an informational concern; authorization is a concern that spans all three domains.

Second, the two analyses were conducted by different procedures, and a third independent route reinforces them. The type analysis surveyed 16 existing type systems and found eight irreducible primitives by structural test. The capability analysis examined capability literature and surveyed five capability/access-control systems and found eight irreducible primitives. The protocol spec, refined operationally by debugging cross-peer capability bugs, arrived at the same Subject/Authority/Attenuation decomposition in §5.2. Three routes (methodology over types, methodology over capability, spec operational refinement) converge on consistent decompositions. None was derived from the substrate primitives or the pair-relationship framework. That all three map cleanly back through pair-coverage and substrate grounding is convergent evidence that the substrate primitive set spans these design spaces.

Third, the pair-relationship layer provides a more precise validation than substrate-level grounding alone. “Composition requires E+I+T” is true but coarse; “composition requires the full EIT triangle” is precise and testable. Systems that cover only part of the EIT triangle (Git has EI + IT but weak ET; Plan 9 has ET + (partial T) but weak EI) would not support composition in the entity-system sense. The pair-coverage view predicts this; the primitive-count view does not.

The full substrate combinatorial analysis — partial levels, internal dimensions, attractor states, and landscape scoring across existing systems — is developed in Convergent Evolution. The methodology that produces surface-primitive analyses of the kind in this paper is in A Structural Methodology for Information System Domains.

6. Discussion

6.1. Design Validation as Procedure

The procedure applied in this paper has general applicability. For any protocol design decision:

1. Declare the design space and its type (substrate / surface / bridge / ecosystem / context) (see A Structural Methodology for Information System Domains). The declaration predicts filter stringency and core triad function.
2. Survey the landscape: examine existing systems that address the same problem.
3. Extract irreducible primitives via three tests: structural minimality (removing forfeits expressiveness), compositional productivity (combinations yield new capabilities), empirical recurrence (shapes design decisions across instances).
4. Decompose each primitive into partial levels (typically 3–6 per primitive). Iterate steps 3 and 4 until both the primitive set and partial levels stabilize.
5. Identify dependencies, pair-relationships, and load-bearing compositions within the primitive set.
6. Categorize gaps: classify any features the protocol does not cover, and determine whether each gap is by design (excluded with a designated mechanism) or by omission.
7. Map back to substrate primitives via pair-coverage: verify that each surface primitive grounds in specific pair-relationships within the substrate primitive set. Surface primitives that require substrate pair-bundles the substrate cannot activate signal a missing substrate primitive or missing structural capability.

This is the structural methodology of A Structural Methodology for Information System Domains specialized to design validation. It is not specific to the entity system: any protocol with a type system could survey existing type systems for primitive coverage; any protocol with an authorization model could survey existing authorization systems. The procedure produces structured confidence, not proof — but structured confidence that specific primitives have been checked is more useful than informal intuition about completeness. The pair-coverage step adds precision: “does primitive X require pair-bundle Y?” is a testable question.

6.2. Two Independent Analyses Converging on Eight

Both the type analysis and the capability analysis found eight irreducible primitives. This is a coincidence of count, not of structure — the two sets are entirely different, addressing different design spaces. But the convergence is worth noting: in both cases, the dimensionality is low enough to be tractable (eight, not eighty) and high enough to capture meaningful distinctions (eight, not three).

The pair-coverage mapping shows why both counts land in this range. The type primitives all live within a single named substrate triangle (EIT); eight pair-sub-coverages within one triangle is a natural granularity for data description. The capability primitives span three named triangles (EIT for tokens-as-typed-data, TMX for reactive-dispatch + temporal, IXP for capability cryptography) plus the TX and TP pairs for routing and the IT+TM pair for revocation; eight distinct authorization-relevant coverages across this span is similarly natural. Neither number is an accident of measurement; both reflect the pair-coverage structure required.

The earlier seven-dimension framing in this paper missed one primitive in each design space — Naming for types (taken for granted because every surveyed system has it), and Revocation for capability (bundled into Time/expiry) — and bundled Authority into Subject for capability. The methodology surfaced all three. In the capability case, the protocol spec independently surfaced the Subject/Authority distinction by operational debugging (§5.2), reaching the same decomposition as the methodology by a separate route.

Both results sit as open invitations rather than proofs. A ninth type primitive independent of the eight — a question about data description that does not decompose into naming, shape, cardinality, constraint, composition, equivalence, representation, or evolution, and that does not reduce to pairs already covered within the EIT triangle — would refute the closure claim on type description. A ninth capability primitive independent of the eight — a request attribute or token-lifecycle property that is not subject, mechanism, verb, object, context, authority, attenuation, or revocation, and that requires pair-coverage outside the triangles already named — would do the same for authorization. None has been identified.

6.3. Protocol Stability

The practical outcome of primitive validation is protocol stability. The entity core protocol’s wire format has remained unchanged across many revisions (see The Entity Core Protocol). Entity structure has remained unchanged. The two-message model has remained unchanged. What has changed: type definitions, handler conventions, capability grant fields, and the operational sharpening that produced amendments like §5.2’s three-slot model (which clarified rather than restructured the underlying mechanism). Evolution occurs within the type system and extension architecture rather than requiring protocol changes.

The primitive analyses explain this stability. If the type system covers all eight description primitives (via full pair-coverage over the EIT triangle), there is no structural gap that would force a protocol change. If the capability system covers all eight authorization primitives (via pair-coverage across EIT, TMX, and IXP plus IT+TM for revocation), there is no authorization gap that would force a grant restructuring. Gaps are accommodated by the mechanisms already in place: type computation in the compute extension, encoding specifics in bridge handlers, domain validation in handler logic, additional authorization constraints in the constraints field, revocation in system/capability/revocation. In pair-coverage terms: the triangles are complete, so extensions can operate within them without requiring the core protocol to add new pair-relationships.

6.4. Limitations

Several limitations should be noted:

• Irreducibility is empirical. The arguments that each primitive is irreducible are structural and empirical, not mathematical proofs. A ninth primitive in either design space, or a demonstration that two of the eight reduce to each other, would refute the closure claim; none has been found.
• The 16-system type comparison is not exhaustive. Additional type systems (dependent-type systems, refinement-type systems, effect systems) could be included. We selected systems spanning schema formats, programming languages, and data description languages to cover the space broadly, but gaps in coverage are possible. Dependent-type systems would primarily exercise Cp5 (type-level computation), which is scope-excluded from the entity type system by design.
• Coverage scores are partial-level assessments. The per-primitive partial-level positions are analyst assessments, not measurements. Different evaluators might assign slightly different levels. The relative ordering is more reliable than the absolute levels.
• Capability system comparisons are structural. We compared primitive coverage at the partial-level resolution, not operational characteristics like latency, scalability, or deployment model. Zanzibar’s scalability advantages are real and are not captured by primitive analysis.
• The cross-compilation partition has been validated on five languages. Additional languages might reveal edge cases, though the structural argument (Category B erases because the content-addressed substrate provides equivalent guarantees) applies generally.
• Generated under prompt-and-review. This paper, like the rest of the corpus, the supporting implementations, and the architectural specifications, is LLM-generated under direction from the author. The author provides prompts, evaluates outputs, redirects, and approves — text, code, and design refinements are generated rather than directly authored. The methodology this enables is described in The Entity Core Protocol.

7. Related Work

Type system theory. Pierce (Pierce 2002) provides the foundational treatment of type systems and programming languages. Cardelli and Wegner (Cardelli and Wegner 1985) analyze types, data abstraction, and polymorphism. Our analysis differs in focus: we examine type systems as data description mechanisms for inter-system exchange rather than as program verification mechanisms, which explains why schema systems score higher than programming languages on our metric.

Capability systems. The object-capability model originates with Dennis and Van Horn (Dennis and Van Horn 1966). CHERI (Watson et al. 2015) implements hardware-level capabilities. Zanzibar (Pang et al. 2019) provides scalable relation-based authorization. UCAN (Zelenka et al. 2022) provides decentralized capability delegation. Macaroons (Birgisson et al. 2014) provide contextual caveat-based attenuation. Biscuit (Couprie et al. 2021) combines Macaroons-style attenuation with Datalog-based authorization logic. Our contribution is identifying eight irreducible primitives that span these systems and showing that each system covers a different subset, and noting that the Subject/Authority/Attenuation decomposition was independently arrived at by the protocol spec under operational refinement (§5.2).

Authorization models. RBAC (role-based access control), ABAC (attribute-based access control), and ReBAC (relationship-based access control) represent successive generalizations of authorization. The eight capability primitives map to ABAC’s attribute categories with finer granularity: ABAC’s Action attributes map to Mechanism + Verb (distinct pair-coverages), ABAC’s Environment attributes map to Context, ABAC’s policy attributes map to Authority + Attenuation. Lifecycle management (often outside ABAC’s frame) maps to Revocation.

Content-addressed systems. Git (Torvalds 2005), IPFS (Benet 2014), and Nix (Dolstra et al. 2004) occupy specific positions in the entity substrate primitive space (see The Entity System). Their type system limitations correspond to their positions in the type primitive space: Git’s four hardcoded object types cover Shape partially but lack Composition, Equivalence-for-types, Representation independence, and Evolution.

Schema systems. Avro, Protobuf (Varda 2013), CDDL (Bormann and Hoffman 2020), Cap’n Proto, and ASN.1 are the entity type system’s closest relatives. The convergence of these independently designed systems on the same structural vocabulary is evidence that the vocabulary is forced by the domain.

8. Conclusion

We have described a design validation procedure — declare the design space, survey the landscape, extract irreducible primitives with partial levels, categorize gaps, and map results back to substrate primitives via pair-coverage — and applied it to two design spaces within the entity core protocol.

In type description, eight irreducible primitives emerge from analysis of 16 independent type systems. The entity type system covers all eight at high partial levels. Gaps across all 16 systems fall into three categories (type computation, encoding-specific, domain-specific), each excluded by design with a designated mechanism. The convergence of 14 of 16 systems on the same structural vocabulary is evidence that the vocabulary is forced by the domain rather than chosen by convention.

In authorization, eight irreducible primitives emerge from analysis of capability and access control systems. The entity system covers all eight at high partial levels — the highest of any surveyed system in five-of-eight primitives, tied for highest in two more. Comparison to Zanzibar, UCAN, Macaroons, Biscuit, and CHERI shows that each covers a different subset; none covers all eight. The protocol spec’s §5.2 three-slot model, developed operationally to fix cross-peer capability bugs, independently arrives at the same Subject/Authority/Attenuation decomposition the methodology produces by structural test — a convergence between operational refinement and theoretical decomposition that strengthens both.

The cross-compilation partition provides a third independent validation: the same A/B/C split across five languages with radically different type systems suggests the entity type system captures a natural abstraction level.

All three analyses — type primitives, capability primitives, cross-compilation partition — were conducted independently of each other and independently of the substrate primitive analysis. That the type primitives ground in E+I+T, the capability primitives ground in the full set, and together the 16 surface primitives require all six substrate primitives is convergent evidence that the protocol’s design choices cover the relevant design spaces.

Open questions:

• Can the irreducibility of either set of eight primitives be formally proved?
• Are there design spaces within the entity system beyond type description and authorization that warrant primitive analysis (e.g., subscription, query, revision)?
• Can the procedure be applied to other protocols to identify primitive gaps before release?
• Is the coincidence of both analyses finding exactly eight primitives structurally significant, or is it coincidence?
• The convergence of methodology and spec on the three-slot (Sb/Au/At) decomposition is the load-bearing example; are there other places where the methodology and spec routes would be expected to converge and have not yet been checked?

9. Appendix: History and Methodology Reconciliation

This appendix records the reconciliation between this paper’s original framing (seven dimensions per design space) and the formal structural methodology of A Structural Methodology for Information System Domains (which surfaces eight primitives per design space). It is included for transparency about the paper’s evolution and as a worked example of methodology-applied-back to validate pre-methodology analytical work.

9.1. How this paper began

The first version of this paper was authored before the structural methodology of A Structural Methodology for Information System Domains had crystallized. The intuition was already operative — survey the landscape, find the irreducible axes, validate against the entity primitives — but the formal procedure was not. Steps that the mature methodology requires explicitly (domain-type declaration; partial-level decomposition; dependency graph among primitives; Hasse lattice; build-up sequence; load-bearing composition identification; emergent-property prediction map; cross-domain structural pattern observation) were either absent or implicit. The paper used “dimensions” rather than “primitives” — a choice that turned out to elide the distinction between Layer 1 (primitives) and Layer 4 (emergent surface properties) in the four-layer framework.

The paper produced two findings nonetheless: seven type description dimensions and seven authorization dimensions, with both grounded in entity-substrate pair-coverage. These findings were substantially correct — the seven dimensions in each design space all correspond to real structural axes — but the formal methodology, applied back to the same two design spaces, surfaced refinements:

9.2. Type-system reconciliation

The methodology applied to type-systems-as-a-domain produces eight primitives: Naming, Shape, Cardinality, Constraint, Composition, Equivalence, Representation, Evolution. The original seven dimensions map as follows:

The substrate-grounding finding (all type primitives ground in the EIT triangle) is preserved exactly: Naming grounds in ET, the other seven ground as in the original. The refinement is more accurate vocabulary, not a structural revision.

9.3. Capability-system reconciliation

The methodology applied to capability-systems-as-a-domain produces eight primitives: Subject, Mechanism, Verb, Object, Context, Authority, Attenuation, Revocation. The original seven dimensions map as follows:

The Context merge (Peer + Time → Context) is a methodology choice with a defensible alternative — splitting them back out, as the original did, is also reasonable for distributed systems. Both decompositions agree on the substrate pair-coverage requirements; the disagreement is at the surface-primitive level only.

The Authority and Revocation additions are the substantive refinements. Both are present in the spec and in the cap-systems literature, and both were missed in the original analysis. The reconciliation surfaces them, the comparison table now scores systems on both, and the entity system’s reach across all eight primitives is recorded.

9.4. What the reconciliation does not change

• The grounding of all surface primitives in substrate primitives via pair-coverage.
• The use of EIT, TMX, and IXP as the named structural triangles that surface primitives activate.
• The phase-transition pairs (IX, IP) requiring Full I for capability completeness.
• The cross-compilation partition.
• The “schema systems concentrate in EIT triangle” observation.
• The 4+4 architecture of the capability grant (the four per-grant primitives + four per-token/lifecycle primitives).

9.5. How the methodology was applied back

The methodology canonical analyses for type systems and capability systems are under the project’s methodology directory (methodology/type_systems_domain_analysis/ and methodology/capability_systems_domain_analysis/). They follow the 12-step procedure of A Structural Methodology for Information System Domains §2.1: information gathering, landscape analysis, primitive extraction with partial-level iteration, dependency specification, pair enumeration and load classification, coherent sub-lattice construction, build-up sequences, load-bearing composition identification, emergent-property prediction, cross-domain pattern observation, literature alignment.

The methodology-applied-back exercise is itself an example of methodology-on-methodology: applying the structural procedure to pre-methodology empirical work to test whether the empirical analysis would survive formalization. In this case, it largely did. The refinements are sharpening, not overturning. This is the kind of cross-validation that gives the methodology its claim to general applicability: the same procedure that surfaced primitives across roughly twenty other domains (see A Structural Methodology for Information System Domains) also reproduces and refines the pre-methodology findings of this paper.

9.6. Why this matters beyond this paper

Two practical consequences:

1. The protocol spec is already where the methodology says it should be. Authority is §5.2’s “root” / chain root slot. Revocation is the spec’s “Revocation model” section and the system/capability/revocation entity type. Naming is the system/type/X path convention. No spec amendments are implied by the methodology refinements above. The discrepancy was entirely between this paper and reality; the spec and reality agreed.

2. The convergence of operational refinement (the spec’s §5.2) with theoretical decomposition (methodology) is itself a finding. It suggests that the substrate primitive set is structurally complete for these design spaces in a sense neither route could have established alone. Two independent routes arriving at the same three-slot decomposition is the kind of evidence the paper’s whole design-validation thesis is about. The third route (cross-compilation partition) gives a fourth piece of consistent evidence within the type-system half of the analysis.