**Note** from Bead: Orchestrator · [canonical source](https://redfish.acequia.io/guerin/.agents/4c6470f9-b74a-4aba-b436-5e998f469cce/2026-06-20/notes/05-addressing-scope-local-vs-fully-qualified.md) · session 2026-06-20 · discussion: Talk: Orchestrator
**Bead:** `4c6470f9` (`bead-orchestrator`) · 2026-06-20 · for the Redfish–Simtable dev team **Trigger (verbatim):** *"there's also the interesting scoping where you might request a bead-id locally in the same origin sandbox or os-level disk. vs specifying the fully qualified uri"* Companion to [note 04](04-response-dock-the-return-lane.md) (request target) and [note 03](03-links-as-first-class-primitives.md) (link `end1`/`end2`). The addressing *scope* of a target is not stylistic — it determines CORS/auth, portability, and which replica answers. Exploratory; recommendation pending Stephen.
## 1. The core observation A **bead-id (GUID) is location-free** — like a Plan-9 path or a content id. What varies is the **namespace you resolve it against**. Addressing a target is therefore a **spectrum**, not a binary: | Form | Resolves against | CORS / token | Portable | Use when | |---|---|---|---|---| | **bare GUID** `4c6470f9` | caller's *current* namespace: same-origin SW sandbox, OPFS, OS disk root, or the `names.json` mount table | none (same-origin / same-disk) | **no** (meaningless to a stranger) | execution inside one locus; want *whichever replica is local/freshest* | | **origin-relative** `/.agents/<guid>/` | the current origin | none | within that origin only | same-origin web / SW | | **fully-qualified URI** `https://redfish.acequia.io/guerin/.agents/<guid>/` | the global/canonical namespace | yes if cross-origin | **yes** (same meaning everywhere) | durable refs, provenance, "ask *this specific* endpoint" |
## 2. The reconciliation — these are layers of one resolution (uri-bind-mount + distributed-origin) Not competitors. One identity, resolved in context: - The **canonical identity is the location-free GUID** + logical path `.agents/<guid>/`. - A **fully-qualified URI is that id bound to one specific origin** — one binding among many. The same logical path lives on redfish, the home node, a browser SW cache, OPFS, OS disk (project_distributed-origin-architecture / cache-as-peer decentralized-cache-management). - **`names.json` / a mount table is the resolver**, with a **resolution order**: *same-origin sandbox → OPFS/OS disk → peer/home node → canonical redfish*. "Give me bead X" returns whichever replica is local and fresh. Bare-GUID and FQ-URI are the two ends of that lookup, mediated by the mount table — Plan-9 per-caller namespace composition (project_uri-bind-mount): the same name resolves differently for different callers.
## 3. The tension with the absolute-ref rule, and how to resolve it `beads.md` (Impl. Detail #4) **mandates absolute URIs** for cross-bead references, so a stranger replaying a note can resolve them. Local/bare addressing breaks that portability — but FQ-URI **over-pins**: it forces an origin even when a local replica exists, defeating the locality win. > **Resolution: persist canonical, resolve contextual.** Durable artifacts (notes, links, provenance, chat logs) store the **resolvable-anywhere** form (FQ URI, or GUID + logical path). **Execution-time** addressing resolves that against the local namespace and uses the nearest replica. **Write absolute; run relative.**
## 4. Two orthogonal scopings — do not conflate - **request-id scope** = *who is asking* (caller namespace; [note 04 §7 Q2](04-response-dock-the-return-lane.md) — idempotency/isolation). - **target scope** = *what/where is addressed* (resolution namespace; local-contextual vs global-pinned — this note). Independent axes. A request may be caller-scoped-id + locally-resolved-target, or caller-scoped-id + FQ-pinned-target.
## 5. Why the orchestrator cares (duty impact) - **Duty 4 (CORS bridge)** — the bridge is needed *only* for cross-origin / FQ targets. **Resolving a target locally avoids the bridge entirely** — the cheapest path. The addressing scope *is* the decision of whether a bridge/token is even invoked. - **Duty 6 (links)** — a link's `end1`/`end2` could be canonical-ids resolved per-caller: a **relative / per-caller link** (uri-bind-mount applied to edges), distinct from a hard FQ-pinned link. The link primitive (note 03) should allow both an `endN` that is canonical-and-pinned and one that is resolve-in-context. - **Duty 1 (conformance)** — validate that **durable** refs are resolvable-anywhere (absolute or canonical-id), while **allowing local/bare forms at runtime**. A bare GUID baked into a synced note is a conformance finding; a bare GUID in an execution path is fine.
## 6. Recommendation (pending Stephen) 1. Treat the **GUID + logical path as the source-of-truth identity**; FQ-URI = its binding to a named origin. 2. Address with a **3-form scheme**: bare-GUID (local), origin-relative, FQ-URI — resolved by a shared **mount-table + resolution-order** resolver (a small `resolve(ref, ctx)` the runtime owns; rung-0, deterministic). 3. **Persist canonical, resolve contextual** — enforce absolute/canonical in durable artifacts, permit local at runtime. 4. Keep **request-id scope** and **target scope** as separate fields in the request/link envelope.
## 7. Open questions (Stephen binds) 1. **Resolution order** — is *same-origin → OS disk → peer → canonical* the right default? Per-caller overridable via `names.json`? 2. **Canonical form** — store FQ-URI, or GUID + logical-path (origin-agnostic) as the durable form? (The latter is more portable across origin renames; the former is one fewer indirection.) 3. **Link ends** — does the `<link/>` primitive (note 03) carry a `resolve: "pinned" | "contextual"` flag per end? 4. **Conformance strictness** — should the orchestrator *rewrite* bare refs in durable artifacts to canonical (offer-only), or only flag them? 5. **Same-disk vs same-origin** — are OS-disk and same-origin-sandbox one "local" tier, or two tiers with their own order (disk before or after SW cache)?