Entity System → Application Architecture Bridge: Canonical Analysis

Status: Canonical reference. Analyzing the substrate-bridge extensions as bridge primitives connecting entity system substrate {E,I,T,M,X,P} to application architecture surface {D,Sh,Ac,Mt,Pg,Ch,Pc,Pn,Bn,Au,Hs,Ev}. Source: v1_entity_domain_analysis/entity-system-extensions.md, SYSTEM-ARCHITECTURE.md v0.3, current v7.0 extension specs.

** revision summary.** Since the original authoring, the architecture team has restructured the extension layer into a five-tier classification (per SYSTEM-ARCHITECTURE.md §13). The bridge analysis below has been updated to: (1) restrict the bridge set to the substrate-bridge tier (Tier 1); (2) reflect the absorption of SYNC into REVISION; (3) add TYPE / QUERY / REVISION as substrate-bridge extensions; (4) move ROLE / NETWORK to the operational tier (no substrate-bridge edge); (5) acknowledge exploratory (DURABILITY) and first-pass-grounding (TRANSACTION) tiers explicitly as non-bridge categories. The structural framework — pair-bundles → surface primitives → bridge gaps at Pc/Pn — is unchanged from the original analysis.

1. The bridge structure

1.1 What the bridge does

The substrate-bridge extensions translate entity system substrate primitives into application architecture surface capabilities. Each extension exercises specific substrate pair-bundles and produces specific surface primitives. Only the substrate-bridge tier participates in this mapping; the operational, first-pass-grounding, and exploratory tiers play distinct roles (see §1.3).

1.2 The 11 substrate-bridge primitives

1.3 Extensions outside the bridge set

Three further extension categories exist in the L2.5 layer but do not produce substrate-bridge edges to the application-architecture surface in the structural sense above:

• Operational extensions (Tier 2 per SYSTEM-ARCHITECTURE §13). Provide operational semantics for deployed multi-peer systems:

  • Tier 2a user-identity: IDENTITY (peer identity, controllers, K-of-N quorums, rotation, certs), ATTESTATION (generic attestation graph), QUORUM (K-of-N primitive), ROLE (RBAC), GROUP (membership).
  • Tier 2b network: NETWORK (transport, peer connection, bootstrap conventions), Discovery (spec gap), Relay (spec gap).
  • Tier 2c management: GC (gap), Persistence (SDK-side partial), ENCRYPTION (sketch).

  These do not bridge substrate primitives to application-architecture surface primitives; they encode operational semantics that any deployment needs, alongside the substrate-bridge set.

• First-pass-grounding extensions (Tier 3): TRANSACTION (draft v0.1) — multi-binding atomic writes with observation boundary. Held loosely as anti-fragmentation work; the substrate-bridge edge story for transaction is not yet load-bearing.

• Exploratory extensions (Tier 4): DURABILITY (v0.1) — retracted from spec after scope-overreach review; preserved as reference design, not actively developed, not normative for any tier.

1.4 Note on SYNC's absorption

The version of this analysis listed SYNC as a distinct bridge primitive producing Ch (Coherence). SYNC has been absorbed into REVISION: EXTENSION-REVISION §1.1 explicitly covers the sync protocol (version negotiation, delta transfer, integration between peers). REVISION provides the Ch (Coherence) bridge edge plus the version-DAG semantics that the standalone SYNC did not. The §2 mapping below carries this absorption through.

2. Extension → Surface primitive mapping

The core question: which extensions produce which surface capabilities?

2.1 Surface primitives and their producing extensions

Flipping the view — which extensions feed each surface primitive:

Note (revision). §3-§11 have been rerun against the current 11-extension substrate-bridge set. Key shifts: SYNC absorbed into REVISION; NETWORK and ROLE moved to operational tier (no longer in the bridge set); QUERY added to the bridge set with three heavy pairs; independent-extension count rose from 4 to 7; the dependency DAG now has a shared predecessor (Inbox) and a join (Query needs Subscription AND Type). Major substantive finding: Query's addition lands application-architecture Ac3+ (indexed access) inside the substrate-bridge tier — the "Ac is partially covered" gap is closed.

Followup completed: §6.4 has been computed. 576 / 2048 = 28.125% valid coherent subsets over the new DAG. Notably tighter than the 42.2% — driven by Query's join (needs Sub AND Type) and Inbox's role as a shared predecessor. Programmatic enumeration confirms the hand-walked count (make enumerate-lattices, compute/scripts/enumerate_lattice_filters.py): bridge/substrate filter ratio is exactly 2.0000.

2.2 Gaps in the bridge

Two surface primitives are NOT well-covered by extensions:

Perception (Pc) — NO DEDICATED EXTENSION. The entity system doesn't have an extension for receiving external input. User actions, sensor data, external events — these enter the system through EXECUTE dispatch (X) and emit (M), but there's no structured bridge specifically for external input handling.

No extension handles external input. The path from external input to entity system operations isn't formalized in the extension set.

Presentation (Pn) — NO EXTENSION COVERS THIS. No extension handles external output production. The Content extension is about data aggregation (content manifests), not rendering or presentation. The bridge from entity system content to visible output is entirely unspecified.

3. How substrate primitives expand to surface

3.1 The expansion pathways

E (Entity) ──→ via Type, Tree ──→ D (Data), Sh (Shape)
   Encoding becomes structured typed content with schema.
   
I (Identity) ──→ via History, Revision ──→ Hs (History), Ch (Coherence)
   Content-addressing enables version comparison and convergence checking
   (Revision absorbs the former Sync extension's coherence role).
   
T (Tree) ──→ via Tree, Type ──→ Sh (Shape), Ac (Access)
   Namespace becomes structural hierarchy and path-based retrieval.
   
M (Emit) ──→ via Subscription, History ──→ Mt, Pg, Hs
   Observable mutation splits into: state change, change propagation, 
   and change tracking.
   M is the MOST EXPANSIVE substrate primitive — produces 3 surface concerns.
   
X (Execution) ──→ via Compute, Continuation ──→ Ev (Evaluation)
   Dispatch becomes application-level evaluation — derived values, reactive computation.
   X is also AMBIENT — general computation assumed by all surface concerns.
   
P (Peer) ──→ via Inbox ──→ Bn (Boundary)
   Substrate-bridge: Inbox handles cross-peer messaging.
   Operational tier (NETWORK, IDENTITY, ROLE) provides the operational
   Au (Authority) and broader Bn surface but lives outside the
   substrate-bridge set.

3.2 What's NOT bridged from the substrate

Pc (Perception) and Pn (Presentation) don't have clear substrate origins. They EMERGE at the surface from the system being USED by external entities. The entity system's primitives are about internal information processing — they don't inherently produce external I/O capabilities.

The fact that these two surface primitives lack substrate origins is structurally meaningful:

• In biology: Sensing (Sn) and Response (Rs) emerge through developmental mechanisms that connect biology to the PHYSICAL ENVIRONMENT
• In the entity system: Perception and Presentation need bridges to the HUMAN/PHYSICAL world — which is outside the entity system's scope

The bridge TOWARD humans (Pc, Pn) requires client-side implementation — SDKs, UI frameworks, device drivers. These are bridges the entity system doesn't fully specify because they cross into a different chain (the human chain).

3.3 The expansion factor

Entity system 6 substrate primitives → 12 surface primitives. Factor: 2×.

But of the 12 surface primitives:

• 10 are produced through the substrate-bridge extension set (11 extensions) from the 6 substrate primitives
• 2 (Pc, Pn) emerge from the system's relationship to its external environment, not from substrate expansion

So the substrate-to-surface expansion is really 6 → 10 through bridge mechanisms (via 11 substrate-bridge extensions), plus 2 environmental primitives. The bridge expansion (6→10, factor 1.67×) is closer to biology's expansion factor (~1.5×). The Au (Authority) primitive sits partly inside the substrate (capabilities on Peer) and partly in the operational tier (Identity, Role, Group, Attestation, Quorum) — it bridges the substrate but draws much of its surface from operational machinery that is not in the substrate-bridge set.

4. Bridge internal structure

4.1 Dependencies between extensions

Reconstructed from current Depends: headers in the v7.0 extension specs:

Tree (extended) ─────── (independent — depends on core tree handler only)
Type ────────────────── (independent — depends on ENTITY-NATIVE-TYPE-SYSTEM)
Content ─────────────── (independent — core ET/IT only)
Inbox ───────────────── (independent — core)
Compute ─────────────── (independent — core TMX/EX/IX only)
History ─────────────── (independent — core ITM)
Clock ───────────────── (independent — core TM only)

Subscription ──► Inbox  ──► (core XP)
Continuation ──► Inbox  ──► (core XP for cross-peer)
Query ──► Subscription, Type ──► Inbox
Revision ──► Tree-extended, History (optional)

Independent extensions (7 of 11): Tree, Type, Content, Inbox, Compute, History, Clock — depend only on core protocol or core-protocol-internal Tier-0 handlers. This is a notable shift from the original analysis (4 independent), driven by the absorption of SYNC and the removal of Network/Role from the bridge set.

Chain extensions (4 of 11): Subscription, Continuation, Query, Revision — form short dependency chains within the bridge layer.

4.2 Hub extensions

Inbox — Subscription, Continuation, and Query (transitively through Subscription) depend on it. Cross-peer messaging is foundational for distributed capabilities.

Tree (extended) and History — Revision depends on both. Tree-extended for snapshot/diff/merge primitives, History for path-level transition data when enriching versions.

Subscription — Query depends on it for tree-change event semantics. Promoted to hub status by Query's addition to the bridge set.

The hub pattern parallels biology's bridge structure (Code as the hub — everything depends on the genetic code); here, the substrate's content-addressed-tree-with-emit-events is the structural analog and Inbox/Tree/Subscription are the bridge-level hubs that propagate access to it.

4.3 Over-subscribed substrate surfaces

Updated for the current 11-bridge set:

TM (tree-emit) is the most over-subscribed — five bridge extensions compete for events when tree paths change. This is why L2 (System-Composition) exists: consumer ordering, cascade depth limits, convergence classes. The count rose from 4 to 5 because Revision (which absorbed Sync's coherence role) also consumes TM events for auto-versioning.

TX (tree-execution) is the second most subscribed at 4 — a new finding when Query is added to the bridge set, since Query's secondary indexes are tree-walk dispatch operations.

MX (emit-execution) is the reactive core — where emit triggers dispatch triggers further emit. Unchanged from the prior analysis.

4.4 Core triad of the bridge

{Compute, Subscription, Revision} — Evaluation bridge + Propagation bridge + Coherence bridge.

"What are the essential application bridges?" → The ability to COMPUTE within the entity system (Compute), PROPAGATE changes to interested parties (Subscription), and RECONCILE distributed state including its version history (Revision — which subsumes the former Sync extension's role).

The core triad's role is unchanged from the analysis; the third member's name changed from Sync to Revision when the architecture team absorbed sync semantics into the version-DAG-and-merge framework. The structural argument carries: all three exercise the TMX triangle (the reactive dispatch substrate surface) from different angles:

• Compute: T values evaluated by X through M triggers
• Subscription: T changes via M delivered through X
• Revision: T state reconciled across peers via M+X (with version DAG semantics on top of what bare sync provided)

4.5 Comparison to biology's bridge structure

The bridge structure replicates structurally even with the count shift. The 12 → 11 reduction is driven by architectural reclassification (Network/Role moved to operational tier) rather than by methodological inconsistency. Hub-and-spoke pattern, over-subscribed substrate surfaces, and a clean three-extension core triad all carry over.

5. Pair Enumeration and Load Classification

Pair count: C(11,2) = 55 pairs (was 66 with the 12-bridge set). The drop reflects Network/Role moving to operational tier; the substitution Sync→Revision keeps the same slot.

5.1 Heavy pairs (updated)

14 heavy pairs of 55 = 25.5% (was 12/66 = 18%; the bridge's structural density rose with Query's addition and Revision's three-axis role).

**Pairs removed since ** Inbox-Network and Network-Role (both Network/Role moved to operational tier; their pairs against bridge extensions live in a separate operational-coupling analysis, not in the substrate-bridge layer).

5.2 Medium pairs (updated)

5.3 Light pairs (updated)

Of the remaining 55 - 14 (heavy) - 15 (medium) = 26 light pairs in the 11-bridge set. Network/Role pairs from the enumeration are removed (those extensions are operational tier; their interactions with bridge extensions are tracked separately).

Representative light pairs:

5.4 Summary

14 heavy of 55 (25.5%). Notable rise from the 12/66 = 18% — driven by:

1. Query's three heavy dependencies (Subscription, Type, Tree) when added to the bridge set.
2. Revision's three heavy pair-bundles (Tree, History, Subscription) absorbing Sync's role plus the version-DAG semantics.
3. Removal of the 6 pairs involving Network/Role (which were medium/light in the original count) shrinking the denominator.

Heavy pairs cluster around three structural cores:

• Reactive core: Compute–Subscription–History, with Query joining as a fourth heavy participant.
• Distributed-versioning core: Revision–History, Revision–Subscription, Revision–Tree.
• Type-substrate core: Type–Tree, Type–Content, Compute–Type, Query–Type.

The distributed-networking core that existed in the framing (Inbox–Network, Network–Role) is gone from the bridge analysis — those interactions now live in the operational-tier analysis (TODO doc).

6. Coherent Sub-lattice

6.1 Dependencies restated

Tree → (independent)
Type → (independent)
Tree → (independent — depends on core tree handler only)
Type → (independent — depends on ENTITY-NATIVE-TYPE-SYSTEM, no other extensions)
Content → (independent — core ET/IT only)
Inbox → (independent — uses core XP)
Compute → (independent — core TMX/EX/IX only)
History → (independent — core ITM)
Clock → (independent — core TM only)
Subscription → Inbox (hard, per SUBSCRIPTION spec)
Continuation → Inbox (hard, for cross-peer XP)
Query → Subscription, Type (hard, per QUERY v1.7 Depends)
Revision → Tree (hard, per REVISION spec)

Hard extension-to-extension dependencies (used for sub-lattice enumeration):

• Subscription depends on Inbox
• Continuation depends on Inbox
• Query depends on Subscription AND Type
• Revision depends on Tree
• (Revision optionally depends on History per the spec, but optional deps don't trigger sub-lattice invalidity)

6.2 Enumeration

11 extensions. 5 hard dependencies (some transitive via Subscription).

Total subsets: $2^{11} = 2048$.

Invalid subsets (violate at least one hard dependency): those containing Subscription without Inbox, OR Continuation without Inbox, OR Query without (Subscription AND Type), OR Revision without Tree.

The dependency graph is no longer a simple set of independent chains (as it was in the 12-bridge picture); Query introduces a join (requires both Subscription and Type), and Subscription/Continuation share a common predecessor (Inbox). The clean inclusion-exclusion count of the analysis no longer applies directly; a coherence enumeration must walk the dependency DAG.

An approximate filter estimate by analogy with the walk (3 simple chains gave 42% coherent): the 11-extension set with one shared predecessor (Inbox) and one join (Query) is moderately tighter than the old chain-only structure — back-of-the-envelope estimate puts the coherent fraction in the 30-40% range, with the exact count pending a proper combinatorial enumeration (deferred — see §6.4).

6.3 What the moderately-tight filter means

Applications can still select extension sets fairly freely, but Query's join (needs both Subscription AND Type) and Inbox's role as a shared predecessor (for Subscription, Continuation, and transitively Query) introduce real coupling. Representative coherent configurations:

• Core only: minimal entity store
• Core + Tree + Type: typed content in namespace
• Core + Tree + Type + Compute: typed reactive content
• Core + Tree + Type + Inbox + Subscription: typed content with distributed notifications
• Core + Tree + Type + Inbox + Subscription + Query: typed content with indexed access
• Core + Tree + History + Revision: versioned content
• Core + full bridge: full platform

Selectable modularity remains the bridge's distinctive feature — you configure your bridge profile to your deployment's needs. Biology's bridge is not selectable (you get all developmental mechanisms or you're not an organism); the entity system's bridge is.

6.4 Exact combinatorial enumeration

Walking the 11-extension dependency DAG: 4 chain extensions (Subscription, Continuation, Query, Revision) × 7 independent extensions (Tree, Type, Content, Inbox, Compute, History, Clock).

Constraints (five hard dependencies):

• R1: Sub=1 → Inbox=1
• R2: Cont=1 → Inbox=1
• R3: Query=1 → Sub=1 (chain-to-chain)
• R4: Query=1 → Type=1
• R5: Rev=1 → Tree=1

Walk method. Enumerate the 16 chain combos (S, C, Q, R) ∈ {0,1}⁴. R3 eliminates the 4 combos with Q=1 and S=0, leaving 12 valid chain combos. For each valid chain combo, count the compatible independent-extension subsets: the count is a product of single-variable factors — 1 if the variable is forced to 1 by an active constraint, 2 otherwise. The four always-free independents (Content, Compute, History, Clock) contribute a uniform factor of 2⁴ = 16.

Total valid coherent subsets: 576 of 2048.

Filter: 576 / 2048 = 28.125%.

Sanity check: 576 valid + 960 invalidated by R1/R2/R4/R5 (within otherwise-valid chain combos) + 512 invalidated by R3 alone (the 4 Q=1 S=0 chain combos × 128 indep subsets each) = 2048. ✓

**Comparison to ** the prior 12-bridge analysis gave 1728/4096 = 42.2%. The new 28.125% is notably tighter, driven by:

1. Query's join constraint (Q=1 needs both Sub=1 and Type=1) — joins tighten more than parallel chains do.
2. Inbox's role as a shared predecessor (for Sub, Cont, and transitively Query) — concentrating dependency weight on one extension.
3. Smaller universe (2^11 vs 2^12) — but this alone would predict a similar percentage.

Comparison to substrate filter: the substrate has 9/64 = 14% coherent. The bridge at 28% is exactly 2× looser — consistent with the bridge being modular by design (selectable extension profiles) while the substrate is constitutively interlocked (primitives co-determine one another).

Programmatic verification: the per-chain-combo table above and the totals (576 valid, 9 substrate-coherent, 2× ratio) are reproduced by compute/scripts/enumerate_lattice_filters.py (make enumerate-lattices). The bridge/substrate filter ratio is exactly 2.0000.

7. Build-up Sequence (Hasse Walks)

7.1 Dependency structure for the 11-bridge set

The structure is no longer three independent chains; Inbox is a shared predecessor and Query is a join. The dependency DAG:

                Inbox ─→ Subscription ─→ Query
                  ↓        ↗ (join)
              Continuation
                          Type ─→ Query
                          Tree ─→ Revision
                          History ─→ (Revision optional)

Chain extensions (4): Subscription, Continuation, Query, Revision. Independent (7): Tree, Type, Content, Inbox, Compute, History, Clock.

7.2 Build-up paths

Because most extensions are independent, there are MANY valid monotone paths. Key paths:

Path α — Content-first:

{} → Tree → Type → Content → History → Subscription+Inbox → Sync → Compute → ...

Start with content organization and typing. Add versioning. Add notification. Add distributed consistency. Add computation. This builds a CONTENT MANAGEMENT system.

Path β — Reactive-first:

{} → Tree → Compute → Subscription+Inbox → Type → History → Sync → ...

Start with reactive computation. Add notifications. Add typing. Add versioning. Add sync. This builds a REACTIVE APPLICATION.

Path γ — Distribution-first:

{} → Tree → Inbox → Subscription → History → Revision → ...

Start with the messaging substrate. Add subscriptions. Add history. Add version-based reconciliation (sync now lives inside Revision). This builds a DISTRIBUTED SYSTEM at the substrate-bridge level; operational network connectivity (NETWORK extension, peer discovery) sits in Tier 2 and is composed on top.

Path δ — Minimal-operational:

{} → Tree → Type → Compute → Inbox → Subscription → History → Revision

The minimum path to a reactive, versioned, distributed typed system. 7 of 11 substrate-bridge extensions. This is the CORE OPERATIONAL SET.

Path ε — Indexed-data:

{} → Tree → Type → Inbox → Subscription → Query → ...

A new path enabled by Query's place in the bridge set: build indexed access by composing Subscription (for index maintenance) with Type (for typed index keys) and Query (the operation surface). Reaches application-architecture Ac3+ (indexed access) without leaving the bridge layer.

7.3 Phase transitions in the bridge

The most consequential: +Compute (entity tree → computation graph), +Inbox+Subscription (pull → push), and +Revision (per-peer state → reconcilable distributed state). Together they create the reactive distributed system — the entity system's primary surface capability.

8. Load-bearing Compositions

8.1 Triangles

Updated for the 11-bridge set:

8.2 Core triad confirmed

{Compute, Subscription, Revision} is the strongest — all three pairs are heavy through the reactive distributed core. The core triad {Compute, Subscription, Sync} is unchanged in structural role; the third member's name is now Revision (which absorbed Sync's coherence role into the version-DAG framework).

"What are the essential application bridges?" → COMPUTE within the system, PROPAGATE changes to interested parties, RECONCILE distributed state. These three together enable reactive, consistent, distributed computation.

8.3 Quad

{Compute, Subscription, Revision, History} — the operational quad. Reactive computation + distributed notification + version-based reconciliation + per-path transition tracking. Minimum for a fully operational distributed reactive system. The quad {Compute, Subscription, Sync, History} is the same up to Sync→Revision.

8.4 Higher / full set

{Tree, Type, Content, Inbox, Subscription, Continuation, Compute, Query, Revision, History, Clock} — the complete 11-extension substrate-bridge set. The full application-architecture bridge configuration; peaks at the full-spec target. Consistent with the entity-system complete-substrate composition, plus operational extensions composed on top for deployment (not part of the substrate-bridge story).

9. Emergent Properties

Updated for the 11-bridge set:

Operational tier (peer discovery, identity management, role-based authority, etc.) sits alongside; it provides deployment operability and is not part of the substrate-to-application-architecture bridge mapping above.

9.1 Activation thresholds

The bridge has specific activation thresholds where qualitative capability changes:

1. +Tree+Type: Content becomes structurally organized and type-checked. Data integrity.
2. +Compute at reactive level: The tree becomes a live computation graph. Derived values.
3. +Inbox+Subscription: The system becomes push-based. Real-time.
4. +Query (with Subscription+Type already active): The system gains indexed access. Application-architecture Ac3+ lands inside the bridge.
5. +History+Revision: The system becomes versioned and convergent across peers. Distributed consistency with merge semantics.
6. +Continuation: The system supports durable, cross-peer workflows.

Each threshold enables a class of applications that wasn't possible before.

10. Manifestation Landscape

10.1 Extension profiles of real implementations

Updated for the 11-bridge set (substrate-bridge tier only; operational-tier columns dropped from this table — they belong in a separate operational profile if/when authored). Note: column header "Rev" = Revision; "Query" added.

The Sync→Revision absorption means the old Sync column folds into the Revision column with comparable values (Git had Sync=2 → Revision=2 since Git's pull/push is a version-DAG operation; CouchDB had Sync=3 → Revision=3 since its replication protocol is conceptually a version-DAG reconciliation).

10.2 What the landscape shows

Go implementation is progressing through the build-up — Tree, Type, Subscription, Compute, Query, Revision, History all at moderate levels. This is broader bridge coverage than the snapshot showed (Query and Revision now present).

Git has extreme History (Full) and Tree (Full) plus moderate Revision (the version-DAG semantics map). Nothing in the reactive cluster — it's a versioned content store, not a reactive system.

Kafka has extreme Subscription (Full) and moderate Revision (its log-as-version-stream). Notification-first, weakly versioned.

React+Redux has moderate Compute and Subscription plus light Query (component lookup). Reactive-first frontend.

CouchDB has moderate Revision (its replication protocol is version-DAG-shaped) and moderate Query (its view machinery). Document-store-with-replication shape.

The extension profile IS a fingerprint that differentiates architecturally distinct systems — and Query's addition to the bridge gives the fingerprint another discriminating axis (Kafka, CouchDB, React+Redux differ sharply on Query coverage).

11. The full connection traced

11.1 End-to-end: substrate → bridge → surface

Updated for the current 11-bridge set:

11.2 What the entity system spec covers vs what's left to implementation

Updated to reflect Query's addition to the bridge set (which lands Ac3+ indexed access inside the substrate-bridge tier) and Sync→Revision absorption:

Fully specified by the substrate-bridge extensions:

• D, Sh (via Type + Tree + Content) — structured typed content with manifests
• Ac (via Tree paths + Query indexed access) — both structural path access and indexed access now covered (Query was not in the bridge set in)
• Mt (via core Emit) — state change mechanics
• Pg (via Subscription + Inbox + Continuation) — change propagation, local and cross-peer, durable
• Ch (via Revision + Clock) — distributed coherence via version-DAG reconciliation plus causal ordering
• Hs (via History + Revision) — per-path transition tracking plus per-version recording
• Ev (via Compute + Continuation) — entity-native evaluation, durable evaluation
• Bn (via Inbox) — cross-boundary messaging at the substrate-bridge slice
• Au (substrate-level via core Capabilities) — base capability system on Peer

Specified by operational tier (Tier 2, not substrate-bridge):

• Au at the deployment level — via IDENTITY, ATTESTATION, QUORUM, ROLE, GROUP
• Bn at the network level — via NETWORK plus discovery/relay gaps

Left to client-side implementation:

• Pc — how external input enters the system. Client SDK responsibility (no substrate-bridge extension covers this; gap flagged in §2.2).
• Pn at rendering level — how content becomes visible. UI framework responsibility (gap flagged in §2.2).

5.3 What this means for entity system development

Strong bridges (well-specified, ready): D, Sh, Mt, Pg, Ch, Hs, Ev, Bn, Au — 9 of 12 surface primitives are well-served by extensions.

Well-covered through core + extensions (10/12): D, Sh, Mt, Pg, Ch, Hs, Ev, Bn, Au through extensions. Pc and Pn through core EXECUTE dispatch — external input arrives as EXECUTE calls, external output is produced by handlers dispatched through X. Compute and Subscription support Pn (computing what to show, pushing updates).

Partial (1/12): Ac at path level only (tree paths). Property-based queries, full-text search, semantic access (Ac3+) not covered by any extension.

Gap (1/12): Ac at query level — the only surface primitive without a clear bridge path. Applications needing property-based retrieval must build query infrastructure beyond the tree extension.

6. The codes at the bridge

Each extension carries a specific code (Ke+Kd) — an encoding/decoding protocol:

All extensions are Kd4 (deterministic). The bridge is uniformly deterministic — same inputs always produce same outputs across implementations. Any evaluator variability occurs OUTSIDE the bridge, in the cross-chain interaction with humans (how users interpret content), not within the bridge itself.

Summary

Referenced by the model

Cited as a source by 1 model record (browse the model census):

• entity-to-app-bridge — bridge entity/sc1