Operational-Tier Coupling — Exploration
The question
The entity-to-app bridge analysis treated all then-current extensions as substrate-bridge extensions producing application-architecture surface primitives. The architecture restructuring split the extension layer into 5 tiers (per SYSTEM-ARCHITECTURE §13):
- Tier 1: substrate-bridge (analyzed in
analysis-entity-to-app-bridge.md) - Tier 2: operational — IDENTITY, ATTESTATION, QUORUM, ROLE, GROUP, NETWORK + Discovery/Relay gaps, GC/Persistence/ENCRYPTION
- Tier 3: extras / first-pass-grounding — TRANSACTION
- Tier 4: exploratory — DURABILITY (retracted)
The bridge analysis explicitly excludes Tier 2 from its substrate-to-surface mapping. Open question: does Tier 2 deserve its own analytical companion doc, and what would it produce?
What Tier 2 actually does structurally
Tier 2 extensions don't produce application-architecture surface primitives (D, Sh, Ac, Mt, Pg, Ch, Hs, Ev, Pc, Pn, Bn, Au). They provide operational semantics — the deployment-level instantiation of capabilities the substrate already implies:
| Operational extension | What it thickens / instantiates | Substrate primitive it operationalizes |
|---|---|---|
| IDENTITY (Stable v3.7) | Peer identity (controllers, K-of-N quorum at root, certs, rotation, recovery) | P at deployment |
| ATTESTATION (Stable v1.2) | Generic attestation graph (consumed by IDENTITY/QUORUM/ROLE/GROUP) | P + I — content-addressed attestation |
| QUORUM (Stable v1.2) | K-of-N node primitive (multisig, group authorization) | P + I + cap-system |
| ROLE (Draft v2.0) | RBAC patterns over capability templates | P + capabilities |
| GROUP (Stable v1.4) | Membership / registries | P + Tree |
| NETWORK (Draft v1.3) | Peer transport, connection, bootstrap conventions | P + XP, with transport detail |
| Discovery (spec gap) | Peer discovery beyond ad-hoc connection | P + XP |
| Relay (spec gap) | Multi-hop routing through intermediaries | P + XP |
| GC (spec gap) | Garbage collection / storage management | T + I — storage operability |
| Persistence (partial, SDK-side) | Local-storage substrate | T + I |
| ENCRYPTION (sketch) | At-rest / wire encryption | I (content-derived) + E (typed encrypted data) |
The pattern: Tier 2 operationalizes P (and storage aspects of T/I). The substrate-bridge tier operationalizes the rest of the substrate (E, I, T, M, X) into application-architecture surface. The two tiers together cover the substrate but at different abstraction layers:
- Substrate-bridge tier: substrate primitives → application-architecture surface (how the system behaves to the application developer)
- Operational tier: P-aspects of the substrate → deployment operability (how the system is deployed, secured, run)
What an operational-coupling analysis would produce
Three plausible scopes for such an analysis:
Scope A — Operational tier as bridge to security architecture
Map operational extensions to security/authority surface primitives. This is essentially Paper 10's domain (Security Architecture). The methodology corpus does not yet have a full security-architecture analysis to bridge to. Doing the bridge analysis would require also doing the security-architecture target analysis.
Verdict: Substantial work; tied to Paper 10's authoring.
Scope B — Operational tier as instantiation of P
Document how the operational extensions thicken the substrate's Peer primitive into deployable reality:
- Substrate P provides: identity + capabilities + connection (definition)
- IDENTITY + ATTESTATION + QUORUM provide: identity management at scale
- ROLE + GROUP provide: authority management at scale
- NETWORK + Discovery + Relay provide: connection management at scale
- ENCRYPTION + GC + Persistence provide: data-substrate operability
This is more an instantiation analysis than a bridge analysis. It documents the dependency on substrate primitives but doesn't produce a new surface. Useful as a reference but doesn't have the same "two domains, bridge between" structure as the substrate-bridge analysis.
Verdict: Modest analytical contribution; mostly catalogues what each operational extension does. Useful as a deployment guide; less useful as a methodology output.
Scope C — Operational tier as pre-bridge to "deployment domain"
Treat "deployment operability" as a domain in its own right with its own primitives (e.g., DeploymentTopology, IdentityScheme, TrustModel, TransportProfile, etc.) and analyze operational extensions as bridges to that surface. This would require first authoring a deployment-domain analysis at methodology Layer 1.
Verdict: Substantial new analytical work; would create a new deployment-domain analysis as a sibling to application-architecture.
Recommendation
Defer all three scopes. The substrate-bridge analysis is now current
(per update); the operational tier is documented at the
catalog level in architecture-catchup.md §1.3. That
catalog-level documentation is probably enough for the paper team's
current needs.
Paper 10 (Security Architecture, outline only) is the natural home for Scope A-shaped content. When Paper 10 gets drafted, the operational-tier analysis can be authored alongside it — at that point, the security-architecture surface will be specified by the paper, and the methodology bridge can be drawn properly.
Paper 7 (DEOS, outline only) is the natural home for Scope C-shaped content. The deployment-domain analysis would parallel "application-architecture" for DEOS's framing of the system as an OS.
What we don't lose by deferring: the substrate-bridge analysis is analytically clean as-is; the operational tier is named and classified in the architecture catch-up doc; both can be cited from any paper that needs them. The deferred work is the formal bridge analysis pairing operational extensions with a target surface, and that's gated on the target surface being specified.
What this leaves on the table
If at any point the project wants to:
- Draft Paper 10 → trigger Scope A authoring
- Draft Paper 7 → trigger Scope C authoring
- Make precise structural claims about Identity / Network / Role at the paper level → may trigger a lighter Scope B documentation pass first
None of these is blocking the current resync; all are flagged for when the relevant paper work starts.