research: Project Xanadu deep dive (EDL/reference-not-copy, transclusion, addressing); UC-44/45/46

Xanadu studied as conceptual ancestor, not a candidate shard. Yield:
reference-not-copy EDL/xanadoc validates projection+overlay+union;
content-identity bidirectional transclusion; portable span-address
(tumbler) problem logged as adapter-contract architecture for
SHARD-WP-0002. Recorded design-bug boundaries: reject
single-global-docuverse, single-canonical-instance, baked-in economic
policy. Added UC-44/45/46; enriched UC-24/27/29/32.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

research/260614-xanadu-deep-dive/README.md

@@ -0,0 +1,47 @@
+# 260614 — Project Xanadu deep dive (the docuverse, the EDL, reference-not-copy)
+
+Date: 2026-06-14
+
+## What this is
+
+A focused study of **Project Xanadu** (Ted Nelson) read through shard-wiki's lens.
+Unlike the engine dives (`xwiki`, `twiki`, `foswiki`), Xanadu is **not a candidate
+shard backend** — it never shipped at scale and there is nothing to attach. It is
+studied as the **deepest conceptual ancestor** of shard-wiki's own model: several
+shard-wiki primitives turn out to be Xanadu mechanisms under different names.
+
+The distinctive material:
+- the **EDL / xanadoc** — a document that contains *no content*, only an ordered list
+  of **spans** (content references) plus **xanalinks** (separate link tables); the
+  client assembles the page by reference → this is shard-wiki **projection** + **union**
+- the storage substrate — **tumblers** (stable fine-grained addresses), **istream**
+  (invariant content pool), **enfilades / spanfilade** (virtual↔content mapping,
+  version comparison by span-set intersection)
+- **content-identity, bidirectional transclusion** — content "knowably in more than
+  one place" that remembers all its appearances → stronger than UC-32
+- **transcopyright / micropayment** — a baked-in rights policy shard-wiki must keep
+  *configurable*, not inherit
+
+Goes deliberately **underneath** the surface pattern table in
+`research/260608-federation-concepts/findings.md` §3.3, which it extends rather than
+repeats.
+
+## Contents
+
+| Path | Role |
+|------|------|
+| `findings.md` | EDL/xanadoc, addressing substrate, transclusion, versioning, rights, INTENT mapping (reinforcements + design-bug divergences), UC seeds, architecture notes, sources |
+
+## Status
+
+Initial deep dive complete. Three new use cases promoted to `spec/UseCaseCatalog.md`
+(UC-44 compose-by-reference, UC-45 reverse transclusion, UC-46 content-identity
+equivalence); UC-24/27/29/32 enriched. Span-addressing as an adapter capability,
+content identity, composition manifests, and reuse-terms metadata logged as
+architecture for `workplans/SHARD-WP-0002-federation-architecture.md`.
+
+Key boundary recorded: shard-wiki inherits Xanadu's **reference-not-copy** mechanisms
+but **rejects** the single-global-docuverse premise, the single-canonical-instance
+model, and the baked-in economic policy — those would violate shard sovereignty,
+parallel-version support (UC-27), and mechanism-over-policy.
+</content>

research/260614-xanadu-deep-dive/findings.md

@@ -0,0 +1,322 @@
+# Findings — Project Xanadu: the docuverse, the EDL, and reference-not-copy
+
+Date: 2026-06-14
+Source kind: **conceptual / architectural prior art** (not a deployable engine, not a
+candidate shard backend)
+Lens: shard-wiki orchestration — projection, overlay, transclusion, provenance,
+addressing, coordination journal
+
+> Reading guide. Every previous deep dive (`xwiki`, `twiki`, `foswiki`) studied a
+> *shippable engine* as a candidate **shard**. Xanadu is different: it is the
+> **deepest conceptual ancestor** of shard-wiki's own model and is *not* a backend
+> we would ever attach. It is studied here for its **mechanisms** —
+> reference-not-copy documents, separated link tables, content-identity transclusion,
+> stable fine-grained addressing — several of which shard-wiki already reinvents
+> under different names (projection, overlay, union BackLinks, coordination journal).
+> The job of this file is to (a) name what shard-wiki inherits, (b) flag what would
+> be a **design bug** to inherit, and (c) extract use cases that are genuinely new
+> versus the federation track already in the catalog.
+
+Pairs with — and deliberately extends, does not repeat —
+`research/260608-federation-concepts/findings.md` §3.3, which treats Xanadu only as a
+six-row pattern table and (correctly) labels it "speculative design / pattern
+language, not deployable federation." This dive goes underneath those patterns into
+the actual data architecture (EDL, istream, enfilades, tumblers) because *that* is
+where the resonance with shard-wiki's storage-neutral page model lives.
+
+---
+
+## 1. Origin and status
+
+Project Xanadu (Ted Nelson, 1960– ; the term *hypertext* and *transclusion* are his)
+is the original electronic-literature system: a global **docuverse** of permanent,
+addressable documents joined by visible, two-way links. It famously never shipped at
+scale; partial artifacts exist — **Udanax Green / Udanax Gold** (source released 1999
+to establish prior art against patents), **XanaduSpace**, and **OpenXanadu** (2014, a
+small working browser demo built on the EDL format). Treat all of these as
+*reference designs*, not running software to integrate.
+
+Why it matters to shard-wiki: Nelson's critique of the Web — **"one-way,
+ever-breaking links and no management of version or contents"** — is precisely the
+gap shard-wiki addresses for wikis. shard-wiki is, in effect, a *pragmatic, federated,
+Git-backed, heterogeneous-backend* descendant of the Xanadu idea, scoped to
+Markdown wiki pages and explicitly **refusing** Xanadu's one-global-store premise.
+
+---
+
+## 2. The headline insight — a document is a manifest of spans, not content
+
+The single most shard-wiki-relevant Xanadu artifact is the **EDL (Edit Decision
+List)**, also called a **xanadoc**:
+
+- A xanadoc is a *connected document that contains no original content*. It is a file
+  listing (a) **spans** — "portions of content to bring in" addressed in remote
+  sources — and (b) **xanalinks** — tables saying what to connect to what.
+- The client reads the EDL, **fetches each span from its source**, and **assembles**
+  the document locally per the xanalinks. Content is referenced, never embedded.
+- Structure is strictly separated: **spans first** (content references), **xanalinks
+  after** (relationships). Content and link structure live apart.
+
+This is *the same move* shard-wiki makes:
+
+| Xanadu (xanadoc / EDL) | shard-wiki concept |
+|------------------------|--------------------|
+| Document = ordered list of span references, no embedded content | **Projection** — lazy, cache-like view assembled from shard storage, not a copy |
+| Spans pulled from multiple remote sources at view time | **Union of pages** across heterogeneous shards |
+| Xanalinks stored separately from content | **Overlay** — non-destructive edits/annotations as separate objects, "overlay before mutation" |
+| "All media should be permanized and addressable" | **Coordination journal** + Git content-addressable storage |
+
+shard-wiki's INTENT lines — *"prefer lazy projection over eager copying"* and *"union
+without erasure"* — are the xanadoc principle restated for wikis.
+
+---
+
+## 3. Addressing and the storage substrate
+
+Xanadu's machinery underneath the EDL:
+
+- **Tumblers** (Miller / Gregory): a transfinite-number addressing scheme where one
+  address simultaneously encodes **machine, author, document version, byte span, and
+  links**. A single tumbler is a stable, fine-grained, hierarchical pointer into the
+  whole docuverse.
+- **istream (invariant stream):** a growing pool of *shareable content pieces*.
+  Documents do not store text; they reference istream content by virtual address. A
+  family of **enfilades** (tree structures using *dsps* = relative displacements and
+  *wids* = ranges) maps **virtual addresses ↔ istream addresses** bidirectionally.
+- **Spanfilade:** indexes which istream spans each document uses. Other filades:
+  **granfilade** (storage across disks/network), **POOMfilade** (permutation-of-order
+  matrix mapping document position → istream location).
+- Implicit substrate: content pieces are **invariant** (append-only, never rewritten);
+  versions are new arrangements of shared, permanent pieces. Nothing is deleted, so
+  references never break.
+
+shard-wiki mapping:
+
+- **istream + invariance ≈ Git's content-addressable, immutable blob store**, and the
+  **coordination journal** as the append-only record. shard-wiki gets "references
+  never break" *for Git-native shards for free*; for non-Git shards it must
+  approximate via the journal/projection cache.
+- **Tumbler ≈ the still-open question of a portable, stable, fine-grained span
+  address** that survives projection, overlay, and versioning across heterogeneous
+  backends. shard-wiki has no such addressing scheme yet; this is the hardest part
+  Xanadu solved on paper and the part that never shipped. (See §10, §11.)
+
+---
+
+## 4. Links and transclusion — separate, two-way, content-identity
+
+- **Links are first-class objects stored apart from content** (the xanalinks tables),
+  and are **visible and followable from all endpoints** (rule 7) — i.e. inherently
+  **bidirectional**. Backlinks are not derived after the fact; they are the same
+  object seen from the other end.
+- **Transclusion** = Nelson's "the same content *knowably* in more than one place."
+  The content piece **remembers its identity and can trace back to all its
+  appearances**. This is the crucial delta from every weak modern form (server-side
+  includes, HTML embeds, Roam block-refs): those *copy or cache*; Xanadu keeps one
+  permanent instance that is **aware of where it is reused**.
+
+shard-wiki mapping:
+
+- **Separate link tables ≈ overlays and union BackLinks as first-class.** An overlay
+  is shard-wiki's xanalink: a non-destructive object spanning content it does not own.
+- **Content-identity, bidirectional transclusion** is *stronger* than UC-32 as
+  currently written (which is path/span fetch with freshness). Xanadu says the
+  *content itself* knows its appearances → enables **reverse transclusion** ("where is
+  this paragraph used across all shards?") and **content-identity equivalence** ("these
+  two pages in different shards are versions of the same content"). These are new
+  capabilities, surfaced as UC-45 and UC-46 below.
+
+---
+
+## 5. Versioning and comparison — by span-set intersection
+
+Because a document is a set of spans over an invariant pool, **comparing two documents
+or two versions = intersecting their span-sets** (the spanfilade operation). Shared
+spans are literally shared subtrees; differences fall out of the set arithmetic. The
+same operation surfaces links between documents.
+
+shard-wiki mapping: this is a **content-identity diff/merge** model. shard-wiki's
+diff/merge capability (an adapter capability in the contract) is today implicitly
+path/title- and text-based. Xanadu shows a path-independent alternative: detect that
+page A in shard X and page B in shard Y are *the same or derived content* by span
+overlap, **without relying on matching titles or paths**. This directly serves UC-27
+(view parallel versions of equivalent pages) by giving an *equivalence-detection
+mechanism* rather than assuming naming conventions align across sovereign shards.
+
+---
+
+## 6. Rights and economics — transcopyright, micropayment, implicit permission
+
+Three of the 17 rules are an economic/rights layer:
+
+- Rule 8: **publication grants implicit permission to link/transclude.**
+- Rule 9: **granular royalty / micropayment** on any accessed portion.
+- **Transcopyright:** pre-granted permission for virtual republication *by reference*,
+  with the attribution chain to origin preserved automatically because the content is
+  transcluded, not copied.
+
+shard-wiki mapping — handle with the **mechanism-over-policy** rule:
+
+- The *mechanism* shard-wiki should provide: a reference (overlay/transclusion) that
+  **carries provenance and reuse terms with it**, so attribution and permission travel
+  with the span. This strengthens UC-29 (remix with portable attribution).
+- The *policy* (whether reuse requires permission, whether anything is metered) must
+  **not be hard-coded**. Xanadu baked one global economic policy into the substrate;
+  shard-wiki keeps editorial/economic policy configurable. Baking in a payments or
+  permission model would be a design-bug per INTENT.
+- This intersects the **settled authz-in-core / authn-delegated decision**
+  ([[shard-wiki-auth-in-core-decision]]): "publication grants implicit linking
+  permission" is exactly a *policy* that an information space might or might not adopt
+  on its L0→L4 ladder. shard-wiki must be able to *represent* the permission on a
+  transclusion; it must not *assume* Xanadu's answer.
+
+---
+
+## 7. Xanadu through shard-wiki's lens — it is architecture, not a shard
+
+Unlike the engine dives, there is **no capability profile to fill in** — Xanadu is not
+a backend you attach. The useful framing is the inverse: *which shard-wiki primitives
+are Xanadu mechanisms in disguise?*
+
+| shard-wiki primitive | Xanadu mechanism | Inheritance verdict |
+|----------------------|------------------|---------------------|
+| Projection (lazy view, no copy) | xanadoc / EDL span assembly | **Inherit** — same idea, scope to wiki pages |
+| Overlay (non-destructive edit) | xanalinks as separate objects | **Inherit** — overlays are xanalinks |
+| Union BackLinks | two-way links visible from all endpoints | **Inherit** — generalize to sub-page spans |
+| Transclusion (UC-32) | content-identity, content-aware reuse | **Inherit, strengthen** — add reverse + equivalence |
+| Coordination journal | invariant istream / permanent storage | **Inherit** (Git gives this for Git-native shards) |
+| Stable span address | tumblers | **Aspire** — hard, partly unshippable; degrade gracefully |
+| Editorial/economic policy | transcopyright + micropayment | **Reject as substrate** — keep configurable |
+| One global docuverse | the docuverse premise | **Reject** — see §8.2 |
+
+---
+
+## 8. Mapping to shard-wiki INTENT (compare, do not equate)
+
+### 8.1 Reinforcements
+
+- **Reference-not-copy** is the core of both. Xanadu validates shard-wiki's
+  "lazy projection over eager copying" and "union without erasure" as a coherent,
+  decades-deep design lineage, not an ad-hoc preference.
+- **Provenance is structural, not decorative.** In Xanadu, knowing where content came
+  from and where it is reused is *built into the storage model*. shard-wiki's "never
+  hide authorship, conflicts, freshness, backend limits" is the same commitment.
+- **Links/edits as separate objects** validates overlays-before-mutation and
+  first-class BackLinks.
+
+### 8.2 Deliberate divergences (design bugs if conflated)
+
+1. **No single docuverse / no universal address space.** Xanadu requires one global
+   permanent store, universal addressing, and its own published client–server
+   protocol (rules 12, 17). shard-wiki's whole reason to exist is the opposite:
+   **federate heterogeneous, sovereign backends** (Git repos, Gitea, Obsidian,
+   WebDAV, Coulomb), each keeping its own storage, history, identity, and limits.
+   Adopting Xanadu's universality would violate **shard sovereignty** and **graceful
+   degradation**. shard-wiki's addressing must tolerate backends that *cannot* offer
+   stable span addresses, treating fine-grained addressing as an **adapter
+   capability**, not a precondition.
+2. **One canonical content instance vs. parallel divergent versions.** Xanadu
+   transclusion centers a *single source of truth*. shard-wiki must support
+   **equivalent-but-divergent** pages across shards with conflicts *visible* (UC-27),
+   not collapsed into one instance. Content-identity is a *detection* tool here, not a
+   mandate to unify.
+3. **Baked-in economic/permission policy.** See §6 — reject as substrate, keep as
+   configurable policy.
+4. **Permanence as a hard requirement.** Xanadu forbids deletion globally. shard-wiki
+   cannot impose that on sovereign shards; permanence holds for the **coordination
+   journal** and Git-native shards, and is *approximated* (cache/projection/snapshot)
+   for backends that delete. This is graceful degradation, not a weaker promise.
+
+### 8.3 What Xanadu teaches that shard-wiki should not lose
+
+- A page view can legitimately be a **composition manifest** (a list of references),
+  not a file. Build the page model so a page *can* be authored as references into
+  other shards (UC-44), even if the common case is a plain Markdown file.
+- **Content identity** (not path/title) is the durable basis for transclusion,
+  equivalence, and reverse lookup across sovereign shards (UC-45, UC-46). Lean on
+  Git blob hashes where available; define a content-fingerprint fallback elsewhere.
+- Getting **stable fine-grained addressing** right is the hard, valuable, historically
+  *unshippable* part. Scope it as an adapter capability with explicit degradation
+  rather than promising tumbler-grade universality.
+
+---
+
+## 9. Use-case seeds → catalog (promoted 2026-06-14)
+
+Last existing UC is **UC-43**. New UCs **UC-44–UC-46** added; several existing UCs
+enriched (no new scenario, stronger mechanism/notes).
+
+| Seed | Catalog action |
+|------|----------------|
+| **Compose-by-reference page** — author a page whose body is an ordered list of spans pulled from multiple shards, stored as a manifest (xanadoc/EDL), not a copy | **UC-44 (new)** |
+| **Reverse transclusion** — find every page/shard where a given span (paragraph/section) appears or is transcluded | **UC-45 (new)** |
+| **Content-identity equivalence** — detect that two pages in different shards are the same or derived content via span/content overlap, without matching titles or paths | **UC-46 (new)** |
+| Content-identity, content-aware (bidirectional) transclusion | **enriches UC-32** |
+| Equivalence detection mechanism for parallel versions | **enriches UC-27** |
+| Reference carries provenance + reuse terms (transcopyright as representable policy) | **enriches UC-29**; links [[shard-wiki-auth-in-core-decision]] |
+| Provenance: content remembers its appearances | **enriches UC-24** |
+
+---
+
+## 10. Adapter-contract / architecture notes for SHARD-WP-0002
+
+Logged as architecture (no UC):
+
+- **Fine-grained span addressing is an adapter capability**, not a core assumption.
+  The shard adapter contract should model whether a shard can mint a *stable address
+  for a sub-page span* that survives edits/versions (tumbler-grade), down through
+  whole-page-only, down to path-only. Transclusion/overlay capabilities depend on it.
+- **Content identity** should be a contract-level concept: a shard advertises how it
+  fingerprints content (Git blob hash, normalized-text hash, none). UC-45/UC-46 and
+  cross-shard diff/merge consume it.
+- **Composition manifests** (UC-44) imply the wiki page model must permit a page whose
+  canonical form is a reference list. This is an INTENT-level page-model decision —
+  flag for the page-model spec, not just the adapter contract.
+- Reuse-terms metadata on a reference (UC-29 / §6) is **policy data the core carries
+  but does not interpret** — consistent with mechanism-over-policy and the L0→L4
+  authz ladder.
+
+---
+
+## 11. Open questions (for spec / workplans)
+
+1. What is shard-wiki's **portable span address**? Git blob+range works for Git-native
+   shards; what is the fallback for Obsidian/WebDAV/Gitea-wiki, and how does it
+   survive a shard's storage swap (cf. UC-43 Foswiki RCS↔PlainFile)?
+2. Is **compose-by-reference (UC-44)** core orchestrator, adapter-provided, or
+   reference-UI — and is it MVP or deferred with UC-32?
+3. Does **content-identity equivalence (UC-46)** belong in core (cross-shard union
+   logic) or as an adapter-provided index? How expensive is span-set intersection at
+   wiki scale without enfilades?
+4. How far do we take **reverse transclusion (UC-45)** — exact span identity only, or
+   fuzzy/derived-content tracking? The latter is research-grade.
+5. Where does **reuse-terms/transcopyright metadata** sit on the L0→L4 ladder, and
+   does any tier ever *enforce* it, or is it always advisory provenance?
+
+---
+
+## 12. Sources
+
+| Source | Used for |
+|--------|----------|
+| Wikipedia — Project Xanadu (https://en.wikipedia.org/wiki/Project_Xanadu) | 17 rules, tumblers, history, Web critique |
+| xanadu.com — The Edit Decision List / Xanadoc File (https://xanadu.com/xuEDL.html) | EDL/xanadoc structure: spans + xanalinks, client assembly |
+| Wikipedia — Enfilade (Xanadu) (https://en.wikipedia.org/wiki/Enfilade_(Xanadu)) | istream, enfilades (dsp/wid), spanfilade, granfilade, POOMfilade, version comparison by span-set intersection |
+| Wikipedia — Transclusion (https://en.wikipedia.org/wiki/Transclusion) | "same content knowably in more than one place," content-aware reuse, transcopyright, micropayment vs. weak modern forms |
+| Maggie Appleton — Xanadu Patterns (https://maggieappleton.com/xanadu-patterns) | pattern naming: visible links, parallel documents, transpointing windows, modular blocks, stable addresses, annotation |
+
+Cross-references: `research/260608-federation-concepts/findings.md` §3.3 (prior
+surface treatment), `spec/UseCaseCatalog.md` (UC-24, UC-27, UC-29, UC-32),
+`workplans/SHARD-WP-0002-federation-architecture.md` (adapter contract).
+
+---
+
+## 13. Traceability
+
+- New UCs: **UC-44, UC-45, UC-46** → `spec/UseCaseCatalog.md` (section F, federation).
+- Enriched UCs: **UC-24, UC-27, UC-29, UC-32**.
+- Architecture (no UC): span-addressing capability, content-identity, composition
+  manifest, reuse-terms metadata → `SHARD-WP-0002`.
+- Decision link: transcopyright-as-policy → [[shard-wiki-auth-in-core-decision]].
+</content>
+</invoke>

research/README.md

@@ -14,3 +14,7 @@ when multiple files or sources are involved. Findings here inform `spec/` and
 | 2026-06-08 | `260608-c2-wiki-origins/` | Ward Cunningham & WikiWikiWeb origins; terms and use cases |
 | 2026-06-08 | `260608-federation-concepts/` | Federated Wiki, git/ActivityPub/Xanadu federation models |
 | 2026-06-08 | `260608-wikiengines-overview/` | Wiki engine landscape survey (Perplexity-assisted) |
+| 2026-06-13 | `260613-xwiki-deep-dive/` | XWiki impl, extension interfaces, ecosystem; UC-38/39 |
+| 2026-06-13 | `260613-twiki-deep-dive/` | TWiki impl, plugin API, ecosystem; UC-40/41 |
+| 2026-06-13 | `260613-foswiki-deep-dive/` | Foswiki store abstraction, extension API; UC-42/43 |
+| 2026-06-14 | `260614-xanadu-deep-dive/` | Project Xanadu — EDL/reference-not-copy, transclusion, addressing; UC-44/45/46 |

spec/UseCaseCatalog.md

@@ -1,11 +1,12 @@
 # UseCaseCatalog
 
-Status: **draft** · Date: 2026-06-08 · Updated: 2026-06-13
+Status: **draft** · Date: 2026-06-08 · Updated: 2026-06-14
 
 Promoted from `research/260608-c2-wiki-origins/`,
 `research/260608-yawex-prior-art/`, `research/260608-federation-concepts/`,
 `research/260608-wikiengines-overview/`, `research/260613-xwiki-deep-dive/`,
-`research/260613-twiki-deep-dive/`, and `research/260613-foswiki-deep-dive/`.
+`research/260613-twiki-deep-dive/`, `research/260613-foswiki-deep-dive/`, and
+`research/260614-xanadu-deep-dive/`.
 See InfoTechPrimers on coulomb.social for use-case catalog conventions.
 
 ## Conventions
@@ -116,7 +117,10 @@ and UC-03 (projection only). Fork vs overlay vs import decided in
 authors without collapsing them into one canonical page.  
 **Source:** federation, intent  
 **Notes:** Fedwiki "chorus of voices"; INTENT union without erasure. Equivalent-
-page identity model TBD (`SHARD-WP-0002`). Links UC-07 divergence detection.  
+page identity model TBD (`SHARD-WP-0002`) — Xanadu deep dive offers a path-independent
+detection mechanism via content-identity / span-set intersection (UC-46,
+`research/260614-xanadu-deep-dive/findings.md` §5, §8.2). Links UC-07 divergence
+detection.  
 **Priority:** Later
 
 ### UC-28 — Carry forward pages from closed or archived shard
@@ -134,9 +138,13 @@ lifecycle policy. Complements UC-02 attach and UC-26 fork at scale.
 **Actor:** Author  
 **Goal:** Reuse content across shards or spaces with attribution and edit
 history intact, without manual copy-paste.  
-**Source:** federation, intent  
+**Source:** federation, intent, xanadu  
 **Notes:** Fedwiki journal travels with page; shard-wiki coordination journal +
-per-shard history. Frictionless reuse principle (~15s not ~15min).  
+per-shard history. Frictionless reuse principle (~15s not ~15min). Xanadu
+**transcopyright**: a reference carries provenance *and reuse terms* with it, so
+attribution/permission travel with the span — but reuse policy stays configurable, not
+baked into the substrate (`research/260614-xanadu-deep-dive/findings.md` §6); links the
+authz-in-core L0→L4 ladder decision.  
 **Priority:** Later
 
 ### UC-30 — Time-bounded collaboration space
@@ -169,7 +177,11 @@ concrete push transport: an engine event bus (`ObservationManager`
 refreshable content.  
 **Source:** federation, intent  
 **Notes:** Xanadu transclusion pattern; stronger than UC-03 whole-page
-projection. Provenance and staleness must be explicit.  
+projection. Provenance and staleness must be explicit. Xanadu deep dive sharpens this:
+transclusion should be **content-identity based and bidirectional** (content is "knowably
+in more than one place" and aware of its appearances), not a one-way path fetch —
+enables UC-45 reverse lookup (`research/260614-xanadu-deep-dive/findings.md` §4). See
+UC-44 for the whole-page composition-manifest form.  
 **Priority:** Later
 
 ### UC-33 — Git-branch an information space
@@ -342,6 +354,49 @@ Relates to UC-40 (attach path) and UC-41 (history import) but is about *change u
 live attachment*, not initial attach.  
 **Priority:** Later
 
+### UC-44 — Compose a page by reference (xanadoc / EDL manifest)
+
+**Actor:** Author  
+**Goal:** Author a page whose canonical body is an ordered list of spans pulled by
+reference from one or more shards, stored as a composition manifest rather than a copy.  
+**Source:** xanadu, intent  
+**Notes:** Xanadu EDL/xanadoc — a document that contains no content, only span
+references plus link tables, assembled by the client
+(`research/260614-xanadu-deep-dive/findings.md` §2). The reference-not-copy embodiment
+of INTENT "lazy projection over eager copying" and "union without erasure". Stronger
+than UC-32 (single inline span): the *whole page* is a manifest. Requires the wiki page
+model to admit a reference-list canonical form — flag for page-model spec. Open:
+core vs. adapter vs. reference-UI; MVP vs. deferred with UC-32 (findings §11 Q2).  
+**Priority:** Later
+
+### UC-45 — Reverse transclusion: find all appearances of a span
+
+**Actor:** Reader or maintainer  
+**Goal:** Given a span (paragraph/section/page), find every page and shard where that
+content appears or is transcluded.  
+**Source:** xanadu, intent  
+**Notes:** Xanadu content "remembers its identity and traces back to all its
+appearances" (`research/260614-xanadu-deep-dive/findings.md` §4). Union BackLinks
+generalized from page links to sub-page content identity. Depends on a content-identity
+mechanism (UC-46) and on span addressing as an adapter capability (`SHARD-WP-0002`).
+Open: exact-identity only vs. fuzzy/derived tracking (findings §11 Q4).  
+**Priority:** Later
+
+### UC-46 — Detect content-identity equivalence across shards
+
+**Actor:** Reader or orchestrator  
+**Goal:** Determine that two pages in different shards are the same or derived content
+by content/span overlap, without relying on matching titles or paths.  
+**Source:** xanadu, intent  
+**Notes:** Xanadu compares documents by **span-set intersection** over an invariant
+content pool (`research/260614-xanadu-deep-dive/findings.md` §5). Supplies the
+equivalent-page identity model left open in UC-27 with a *path-independent* detection
+mechanism — equivalence is detected, not enforced (parallel versions stay visible per
+UC-27, not collapsed). Adapter advertises its content fingerprint (Git blob hash,
+normalized-text hash, none). Open: core vs. adapter-index; cost at wiki scale without
+enfilades (findings §11 Q3).  
+**Priority:** Later
+
 ---
 
 ## B. Knowledge work and collaboration
@@ -520,7 +575,10 @@ CommonMark wikilink + red-link extension.
 edit count, and whether the page has local overlays or diverges elsewhere.  
 **Source:** yawex, c2, intent  
 **Notes:** yawex `Page::info`; c2 optional `UserName` signing. INTENT explicit
-provenance principle.  
+provenance principle. Xanadu deep dive: provenance is *structural*, not decorative —
+content remembers where it came from and where it is reused (UC-45), built into the
+storage model rather than added after the fact
+(`research/260614-xanadu-deep-dive/findings.md` §4, §8.1).  
 **Priority:** Later
 
 ### UC-25 — Collaborative glossary and precise naming
@@ -564,6 +622,9 @@ CamelCase and `[[free links]]`. Markdown-first link semantics TBD.
 | UC-41 | | | | ✓ | ✓ |
 | UC-42 | | | | ✓ | ✓ |
 | UC-43 | | | | ✓ | ✓ |
+| UC-44 | | | ✓† | | ✓ |
+| UC-45 | | | ✓† | | ✓ |
+| UC-46 | | | ✓† | | ✓ |
 | UC-08 | ✓ | | |
 | UC-09 | ✓ | | |
 | UC-10 | ✓ | | |
@@ -654,6 +715,34 @@ which also enriched UC-39 (MetaDataPlugin multi-record), UC-40 (PlainFile store)
 logged the `Foswiki::Store` versioned interface as **adapter-contract prior art** for
 `SHARD-WP-0002` (no UC — architecture).
 
+### xanadu mapping
+
+(† UC-44–UC-46 are placed in the **federation** matrix column as the nearest existing
+source; their true lineage is the **Xanadu deep dive**,
+`research/260614-xanadu-deep-dive/findings.md`.)
+
+| Xanadu mechanism (findings §) | Catalog UC |
+|-------------------------------|------------|
+| EDL/xanadoc — document as a manifest of span references, not content (§2) | UC-44 |
+| Content "knowably in more than one place," remembers its appearances (§4) | UC-45 |
+| Version/document comparison by span-set intersection, content identity (§5) | UC-46 |
+| Content-identity, bidirectional transclusion (§4) | UC-32 (enriched) |
+| Path-independent equivalence detection for parallel versions (§5) | UC-27 (enriched) |
+| Transcopyright — reuse terms travel with the reference (§6) | UC-29 (enriched) |
+| Structural provenance — content remembers origin and reuse (§4, §8.1) | UC-24 (enriched) |
+
+Note: Xanadu is **conceptual prior art, not a candidate shard backend** — it never
+shipped at scale and there is nothing to attach. Its yield is *mechanism*:
+**reference-not-copy** documents (validating projection + overlay + union),
+content-identity transclusion, and the still-open **portable span-address** problem
+(tumblers), logged as adapter-contract architecture for `SHARD-WP-0002` (span
+addressing as an adapter capability; content fingerprint; composition manifests;
+reuse-terms metadata — `research/260614-xanadu-deep-dive/findings.md` §10). The dive
+also recorded **design-bug boundaries**: shard-wiki **rejects** Xanadu's
+single-global-docuverse premise, single-canonical-instance model, and baked-in economic
+policy (findings §8.2), as these violate shard sovereignty, parallel-version support
+(UC-27), and mechanism-over-policy.
+
 ---
 
 ## Open questions