**Note** from Bead: 31bd5380 · [canonical source](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/gaps-to-acequia-mission.md) · session 2026-06-03 · discussion: Talk: 31bd5380
Read against the design notes in bead [`874fce5b...`](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/) and the foundational [self-assembling-wires/ecology.md](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/self-assembling-wires/ecology.md), five large gaps:
## Gap 1: User-as-primitive vs URI-as-primitive (the root inversion) **The pitches center the user.** Effort-1 organizes around "what a user is, what an org is, what permissions a user has." The data-model table in effort-1 §2 starts with **User** and works outward; **Resource** doesn't appear in the user-manager spec at all (it shows up only in effort-2). **The Acequia vision centers the URI.** From [agent-as-file-ducktyping](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/) and [polarized-links](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/polarized-links.md): a URI is the abstraction. What's at a URI may be a file, an agent, a camera, a session, a sensor. Users, devices, organizations, and groups are *participants* (parciantes) that hold polarized references to resources. Concretely, this inverts: | User-centric framing (the pitch) | URI-centric framing (the vision) | |-----------------------------------------------------------|------------------------------------------------------------------------------------| | "What can this user do?" | "Who can do what at this URI?" | | Permissions = attributes of users | Permissions = polarized GETs from participants to URIs | | Role = bundle attached to a user | Role = pattern of bindings between a participant URI and a resource subtree | | Org = subdomain owned by a user | Org = a URI (a bead) with members bound in and resources mounted under it | | "Share" = grant from user A to user B | "Share" = a new polarized link, or a new mount of B's namespace under A's | The pitch's structure isn't wrong — it's just *flipped*. A URI-first restructuring would make several pain points dissolve (see Gap 2 and Gap 4).
## Gap 2: Missing the URI bind/mount frame Vision reference: [uri-bind-mount.md](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/uri-bind-mount.md). Namespaces are *composed*, not reified. A resource can be bound at many URIs; the same URI can be re-bound. Plan-9-style per-caller composition. In the pitches, the following are all enumerated as **separate features** with separate mechanics: - Effort-1 F5.1 Share a resource (chain token to a user/group/org) - Effort-1 F3.8 Federation (long-lived chain token to a peer org) - Effort-1 F4.6 Council delegation (chain token to a representative, cascading revocation) - Effort-1 F6.4 Bring-your-own resource (session-scoped grant) - Effort-1 F6.7 Simtable-as-device controls (table appears as a device in the user's device list) - Effort-2 F1.8 Cross-source dedup hint (same resource visible via multiple paths) - Effort-2 F4.2 Move between devices (push/pull across devices) - Effort-2 F7.2 Ownership transfer - Effort-2 F7.4 Pinned org resources (appear in every member's catalog by default) Under the bind/mount frame, **these are all one operation at different scope and TTL**: bind a resource at a new URI, with attenuated permission, for some duration. The differences (which URI, which scope, what attenuation, what expiry) are *parameters*, not separate features. The pitch would compress significantly and the consistency improvements would be substantial — e.g., the "cross-source dedup hint" (effort-2 F1.8) becomes trivially correct because it's just rendering "this resource has N bindings into my namespace." The other practical win: **per-caller composition is already in the vision.** A Simtable session under bind/mount is just a *per-session composed namespace* into which participants' resources are temporarily mounted. The session log is the diff between "table base mount" and "session mount." When the session ends, the mounts unbind. This is exactly what effort-1 §F6 describes — but in the pitch it requires a new abstraction ("session-scoped grant") that the platform has to learn; under bind/mount it's the existing abstraction with a different lifetime parameter. ### Empirical illustration: "upload" vs "mount/bind" word counts The cleanest evidence the pitch is operating in a **device-centric** rather than **URI-mount-centric** frame is a word count across the three source pitches: | Term | Total occurrences across all three pitches | Where it appears | |---|---|---| | `device` (any case) | **55** | 31 in effort-1, 17 in effort-2, 7 in effort-1.1 | | `upload` / `uploads` / `uploading` / `uploaded` | **11** | 1 in effort-1 (storage-quota requirement), 10 in effort-2 (ingestion features + bulk-upload + offline-queue + provenance + policy) | | `link` / `links` / `linking` / `linked` (any sense) | **14** | spread across all three; meanings include "device link," "URL link," "QR link," and "link import" | | `mount` / `bind` / `binding` | **1** | one occurrence, "audit log... severable binding" — not the URI-mount sense at all | **The frame is visible in the numbers.** Devices are first-class (55 mentions). Upload — the act of pushing content *from* a device *to* a destination — is a load-bearing verb (11 mentions; effort-2's §3.3 is literally titled *"Resource ingestion (upload & linking)"*). The bind/mount vocabulary is *not in the spec at all* (the one occurrence is incidental). Effort-2 specifically distinguishes two ingestion mechanisms as if they were distinct features: - **F3.1 Drag-and-drop upload** — "the app uploads to GeoServices storage" - **F3.2 URL / link import** — "the app validates and creates a layer resource that points to the remote service" - **F3.4 Local-drive ingestion** — "the app reads supported files... not uploading to any persistent repository" Under a URI-mount frame, these are three **mount kinds** for the same operation: | Pitch feature | URI-mount expression | |---|---| | Upload (F3.1) | Bind a resource URI; mount its source at the canonical write surface (GeoServices); push bytes to populate the mount | | Link import (F3.2) | Bind a resource URI; mount its source at the external service; no bytes pushed, just the binding | | Local-drive ingestion (F3.4) | Bind a resource URI; mount its source at a local-only origin (device cache only); don't propagate the binding to peers | Same operation (bind a URI, name a source mount), three parameter variations (where the source mount points + whether bytes flow + whether the binding propagates). The pitch enumerates three features; the bind/mount frame collapses them to one. The **device-centric framing** also leaks into requirements that wouldn't exist under URI-mount: - "Upload must be resumable; a 1 GB file interrupted at 80% must resume from 80%" (effort-2) — a real concern *only* if the conceptual operation is "push bytes from a device." Under URI-mount, the canonical question is "is this URI bound at the remote surface yet?" — and if not, the bytes get pushed as part of *mount fulfillment*, with resume being a property of the substrate, not a feature of the user-facing operation. - "Storage quota must update after an upload/delete" (effort-1 §3.7) — frames quota as a function of upload events. Under URI-mount, quota is a function of *what's bound where* — `du -sh` on the bound subtree, not a transactional ledger of uploads. - "All resources owned by the organization, regardless of which member uploaded them" (effort-2 §F7.1) — `uploaded them` is the provenance vocabulary; under URI-mount it'd be `mounted them under the org subtree` or `published them at an org URI`. Each of these is a small reframing. Together they shift the spec from "users push content from devices into a storage system, with separate edge-cases for linked-vs-uploaded-vs-local-only" to "resources are at URIs; the URI is mounted at one or more sources; uploads are how mount-fulfillment happens for the GeoServices source case."
**Why this matters beyond word-counting:** - The device-centric framing creates **artificial categories** ("uploaded" vs "linked" vs "local-only") that have to be tracked separately in UX, permissions, lifecycle, quota. Under URI-mount, they collapse to attributes on a single resource. - The device-centric framing makes **"move between devices"** (effort-2 F4.2) a real operation that has to be designed. Under URI-mount, there's no move — the resource has one URI; the device's local cache resolves it; the question is which mount served the request, not where the resource "lives." - The device-centric framing makes **dynamic resources awkward** — a camera URI isn't "uploaded from" anywhere; a simulation URI isn't a file. The mount frame absorbs these naturally (the source mount is the camera process or the simulation worker), but only because URIs are already the primary noun. The device-centric frame has to invent "live layer" or "service layer" as a new category. The word counts are the smoking gun. Inverting the frame is the structural change; the empirical evidence that the frame needs inverting is right there in the document statistics.
## Gap 3: Missing the apoptosis-vs-necrosis frame Vision reference: [apoptosis-vs-necrosis.md](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/apoptosis-vs-necrosis.md). Two-lane resource death: signaled-orderly (apoptosis) vs dangling-decay (necrosis). Prefer signaled. The pitches handle several lifecycle events: - Effort-1 F2.3 logout (soft/hard) - Effort-1 F2.4 token revocation - Effort-1 F3.7 successor ownership transfer - Effort-1 F4.5 group key rotation - Effort-1 F4.8 group lifecycle / expiry / auto-archive - Effort-1 F5.2 session-only grants - Effort-1 F6.6 end session - Effort-2 F7.3 orphan recovery (user removed from org) - Effort-2 F8 soft-delete / restore / hard-delete **Each is specified as a separate mechanism.** None of them references a unifying signal-propagation model. Under apoptosis-vs-necrosis as a primitive: - Every grant/binding has an apoptotic signal channel. - Lifecycle events (logout, expiry, key rotation, ownership transfer, deletion) all *issue apoptotic signals*; the cascade propagates through the chain-token graph (Acequia already supports this — see effort-1 §F5.6). - **Orphan recovery (effort-2 F7.3) is exactly the necrotic case** — the apoptotic signal didn't reach the leaves, so dangling references remain. The pitch patches this with an admin queue; the framed-correctly version says "make the signal reliable, and orphan recovery becomes the rare case where the signal failed." - The successor model (effort-1 F3.7) is the explicit apoptosis-of-an-org case: orderly transfer rather than necrotic key-loss. The pitch implicitly does some of this already, but the spec doesn't name the underlying property, so each feature has to redo it. A "Lifecycle primitives" section that names apoptotic signal as the unifying mechanism would let many features inherit it.
## Gap 4: Missing the agent-at-URI / agent-as-bead frame Vision references: [agent-as-bead.md](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/agent-as-bead.md), [beads.md](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/beads.md), [agent-as-file-ducktyping](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/) (memory pointer). In the pitches, **the Companion Apps are clients against data records.** The "Acequia user record," "subdomain owned by org-owner user," "Acequia stored tokens" — all data nouns. The company-app code does the work of evaluating policy, presenting capability maps, mediating share requests, holding the approval queue. In the vision, **the org is a bead, the Simtable is a bead, the user is a bead** — each at its own URI, each potentially with its own mayordomo agent that mediates interactions. The companion app becomes a *view* onto the org's mayordomo and the user's mayordomo, not the *seat of logic*. Specific consequences: - **Approval queues** (effort-1 §F3.4) live at the org URI, processed by the org's mayordomo. The companion app reads `org-uri/queue/` and PUTs decisions. Other clients (a custom internal admin tool, a CLI, a Slack bot) can hit the same surface. The pitch's framing puts queue logic in the app. - **Federation** (effort-1 §F3.8 / §F3.9) is two beads negotiating bindings between their namespaces. The mayordomos do the negotiation; the companion app surfaces it. The pitch's framing implements federation flow inside the user-manager app. - **Simtable claim / mode policy** (effort-1 §F6.1, §F6.2) is a request to the Simtable bead's mayordomo, which consults the owning-org bead's mayordomo. The pitch's framing puts this logic in the table's local app. The practical effect: the pitch *can* be implemented as written, but it concentrates policy logic in the companion app rather than at the resource URIs. That means policy can't be reasoned about from outside the app; alternative clients can't operate against the same rules; the org's mayordomo can't autonomously act between human interactions (the way the geo.camera supportedCapabilities pattern already enables for camera beads — see [project_agent-as-file-ducktyping](c:/Users/steph/.claude/projects/c--Users-steph-Documents-sites/memory/project_agent-as-file-ducktyping.md)).
## Gap 5: Missing advanced-wave accounting Vision reference: [advanced-wave.md](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/advanced-wave.md). Wheeler-Feynman frame: every value transaction has a retarded wave (value out) and an advanced wave (attention/reputation/attribution/wealth in). They are one 4D transaction, not two ledgers. The pitches model the retarded wave well: - Effort-1 §3.7 subscription/seat counting (paying for the privilege of using) - Effort-1 §F2.6 capability map (what value I can extract) - Effort-2 §F7.1 org catalog (what value the org holds and offers) - Effort-1 §F3.6 audit log (record of value flowing) They mostly **don't model the advanced wave**: - When a participant joins a Simtable session and *attends* a host's data, that attention is not recorded as flowing back to the host (or the host's org). No reputation/attribution ledger compounds. - When an org federates a resource to a peer org (F3.8) and the peer's members extract value, no advanced wave records that extraction. The pitch only ledger-tracks the chain-token issuance. - Effort-2 §F4.1 scenario forking *does* preserve attribution ("the clone records its source so attribution is preserved") — a single advanced-wave-aware feature, but it's an exception, not a generalized property. - Effort-2 §F4 progressions are exactly the kind of artifact whose reuse should compound the originator's reputation, but the pitch only worries about move-between-devices. The audit log in the pitches is *compliance data*. In the vision, the audit log is the **substrate of the advanced wave** — the raw material from which mayordomos can compute attention/attribution/demand and shape the demand ring that drives the Hubler network. Concretely: the pitch should either (a) commit explicitly that advanced-wave accounting is out of scope for these efforts (and name what *would* be in scope to add it later), or (b) name an advanced-wave ledger as a first-class primitive that the audit log feeds into.
## Bonus gap: no demand-as-substrate model The Hubler frame (see foundational [self-assembling-wires/ecology.md](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/self-assembling-wires/ecology.md), and [rewiring-cognition](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/rewiring-cognition.md)) says cognition emerges *under structured demand*. The negative annulus ring with non-uniform charge is what wires self-assemble against. Mayordomos shape the ring, not the wires. The pitches model *capability* well (what users can do) but not *demand* (what's being asked of the system, where the pressure is, what's hot vs cold). Without a demand model: - The system can't tell which resources are load-bearing and should be replicated or pinned (effort-2 F7.4 pins are admin-defined, not demand-derived). - The system can't surface "who's been asking for access to this resource" as a primitive — the access-request queue (effort-1 §F3.4) is per-request, not aggregated as demand topology. - The system can't shape its own UX by demand pressure (e.g., highlight resources the user's collaborators have been viewing recently). This is a longer-horizon gap — the pitches are not wrong to leave it out — but flagging it because a follow-on effort ("AnyHazard Demand Surface" or similar) is implied by the larger vision and should be named so it doesn't surprise a future planner.
## Summary table | Gap | Vision doc | Pitch's current handling | Effect if absorbed | |---|---|---|---| | User-as-primitive vs URI-as-primitive | [polarized-links](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/polarized-links.md), [agent-as-file-ducktyping](c:/Users/steph/.claude/projects/c--Users-steph-Documents-sites/memory/project_agent-as-file-ducktyping.md) | User is the org axis; Resource introduced only in effort-2 | Spec inverts; many features become parameter variations of one mechanism | | Bind/mount frame | [uri-bind-mount](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/uri-bind-mount.md) | Nine separate sharing/grant/federation features | Compress to one parameterized operation | | Apoptosis-vs-necrosis | [apoptosis-vs-necrosis](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/apoptosis-vs-necrosis.md) | Per-feature lifecycle mechanics; orphan recovery patches the necrotic case | Unify under signal-propagation primitive | | Agent-at-URI | [agent-as-bead](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/agent-as-bead.md), [beads](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/beads.md) | Logic lives in the companion app; orgs/tables/users are data records | Logic moves to URIs; companion app becomes a view; multiple clients become possible | | Advanced-wave accounting | [advanced-wave](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/advanced-wave.md) | Audit log = compliance only | Audit log becomes substrate for reputation/attribution/demand | | Demand-as-substrate | [rewiring-cognition](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/rewiring-cognition.md), [self-assembling-wires/ecology.md](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/self-assembling-wires/ecology.md) | Not modeled (capability only) | Future effort; flag for planning so it's not a surprise |
## References (bead cross-links) - Bead: 874fce5b · [canonical](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/)