research: ZigZag/zzstructure deep dive (information space as orthogonal dimensions); UC-47/48/49

Evaluated modelling a wiki information space as a zzstructure: a page is
a cell at the intersection of many co-equal dimensions (namespace tree,
created-from genealogy, version, shard, equivalence, links).
Recommendation: adopt zzstructure as a navigation/visualization/indexing
LENS (a derived dimensional projection over the union), not as the
storage substrate — Git and sovereign shards stay canonical, and the
many-to-many link graph does not fit the one-neighbour-per-dimension rank
rule. Clone <-> transclusion convergence with the Xanadu dive. Added
UC-47/48/49; enriched UC-05/22/26/29; dimensional projection layer +
genealogy-edges-in-journal logged as architecture for SHARD-WP-0002.

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

SCOPE.md

@@ -19,9 +19,9 @@ Learnings update both SCOPE and INTENT where necessary.
 |-------|-------|
 | Code | Python package scaffold (`src/shard_wiki/`, smoke tests only) |
 | Intent | `INTENT.md` established; authorization-in-core amendments drafted |
-| Research | yawex prior art; c2 origins; federation concepts; wikiengines overview (`research/260608-*/`) |
+| Research | yawex prior art; c2 origins; federation concepts; wikiengines overview (`research/260608-*/`); XWiki/TWiki/Foswiki deep dives (`research/260613-*/`); Xanadu + ZigZag deep dives (`research/260614-*/`) |
 | Demand | NetKingdom integration asks captured, not yet negotiated |
-| Spec | Architecture blueprint drafted; UseCaseCatalog 25 UCs from research; PRD/TSD scaffolds |
+| Spec | Architecture blueprint drafted; UseCaseCatalog 49 UCs from research; PRD/TSD scaffolds |
 | Work | `SHARD-WP-0001` active (6 tasks); `SHARD-WP-0002` active (10 tasks) |
 
 ## In Scope (today)

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/260614-zigzag-deep-dive/README.md

@@ -0,0 +1,43 @@
+# 260614 — ZigZag / zzstructure deep dive (an information space as orthogonal dimensions)
+
+Date: 2026-06-14
+
+## What this is
+
+A focused study of **Ted Nelson's ZigZag** and its data model **zzstructure**, asked
+through a specific shard-wiki question: a wiki page is linked in many independent ways
+at once — a **namespace** tree, a **created-from / genealogy** lineage, **hyperlinks**,
+plus shard-wiki's own **shard / overlay / version / transclusion / equivalence**
+relations. Could the information space be modelled as a zzstructure, where each
+relationship is a first-class **dimension** and none is privileged?
+
+Distinctive material:
+- the zzstructure model — **cells**, **dimensions** (edge colours), **ranks**,
+  **posward/negward**, and the one rule that defines it: *at most one posward and one
+  negward neighbour per dimension per cell* (a directed coloured multigraph)
+- **views** — I-view (one dimension), **H-view** (pivot two dimensions into a cross),
+  raster-vs-view
+- trees/lists/tables as *spent dimensions*; many-to-many graphs as the hard case
+  (handled by **clones**)
+- **clone ↔ transclusion** convergence with the Xanadu dive
+
+## Contents
+
+| Path | Role |
+|------|------|
+| `findings.md` | zzstructure model, views, fit analysis, a proposed dimension map for a shard-wiki space, recommendation (lens not store), INTENT mapping, UC seeds, architecture notes, sources |
+
+## Status
+
+Initial deep dive complete. Three new use cases promoted to `spec/UseCaseCatalog.md`
+(UC-47 navigate-by-dimension, UC-48 H-view pivot/cross-tab, UC-49 genealogy
+dimension); UC-05/17–22/26/29 enriched. A **dimensional projection layer** is logged
+as architecture for `workplans/SHARD-WP-0002-federation-architecture.md`.
+
+**Recommendation recorded:** adopt zzstructure as a **navigation / visualization /
+indexing lens** (a derived dimensional projection over the union), **not** as the
+storage substrate — Git and sovereign shards remain canonical (INTENT Stability Note).
+The many-to-many hyperlink graph does not fit zzstructure's rank constraint and stays a
+separate graph index. Pairs with `research/260614-xanadu-deep-dive/` (clone ↔
+transclusion).
+</content>

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

@@ -0,0 +1,294 @@
+# Findings — ZigZag / zzstructure: an information space as orthogonal dimensions
+
+Date: 2026-06-14
+Source kind: **conceptual / data-model prior art** (a data model + visualization
+paradigm, not a deployable wiki engine, not a candidate shard backend)
+Lens: shard-wiki — modelling a wiki information space where a page participates in
+*many* relationship structures at once (namespace, genealogy, links, versions, shards)
+
+> Motivating question (from the user). A wiki page is linked in several independent
+> ways at once: a **primary namespace** association giving a tree-like hierarchy; a
+> **created-from / genealogy** association (fork/derivation lineage); **hyperlinks**
+> to other pages; and — in shard-wiki — *which shard* it lives in, its **overlays**,
+> its **versions**, its **transclusions**, and its **equivalents** elsewhere. Could
+> the information space be modelled as Ted Nelson's **ZigZag / zzstructure**, where
+> each kind of relationship is a separate, first-class **dimension** and no single
+> relationship is privileged as *the* structure?
+>
+> Short answer: **yes as a navigation / visualization / indexing lens; no as the
+> storage substrate.** zzstructure is an unusually good *conceptual* match for
+> shard-wiki's "union without erasure" thesis — it makes every relationship
+> co-equal and separately navigable — but its one-neighbour-per-direction
+> constraint makes it a poor *direct* encoding of the many-to-many hyperlink graph,
+> and Git/heterogeneous shards must remain the canonical store. Details below.
+
+Companion to the Xanadu dive (`research/260614-xanadu-deep-dive/`): ZigZag is
+Nelson's *other* lifelong project, the structural/visual counterpart to Xanadu's
+literary/addressing one. Where Xanadu gives shard-wiki **reference-not-copy**, ZigZag
+gives it **many co-equal structures over the same cells**.
+
+---
+
+## 1. What ZigZag / zzstructure is
+
+ZigZag (Ted Nelson, conceived 1981 at Datapoint; first Perl prototype by Andrew Pam,
+1997; the **GZigZag / Gzz** Java project 2000–2003; US patent 6,262,736, expired
+2019) is **"a data model that deconstructs the spreadsheet to allow irregular
+relations, generalizing the idea to multiple dimensions."** The generic, vendor-free
+name for the data model is **zzstructure**.
+
+Core vocabulary:
+
+- **Cell (zzcell)** — an atom of data (a value, a record, a page). Cells are the only
+  content; everything else is connection.
+- **Dimension** — a *named kind of connection* (an edge colour). Dimensions are
+  **first-class** — in ZigZag, dimensions are themselves cells.
+- **Link (zzlink)** — a connection between two cells *along one dimension*, with a
+  **posward** (positive) and **negward** (negative) direction.
+- **Rank** — the maximal chain of cells along one dimension (a path, or a cycle). A
+  rank is ZigZag's equivalent of "a row" / "a list" — but it exists only along one
+  named dimension.
+- **Cursor** — the current focus cell from which views are drawn.
+- **Clone** — a copy of a cell that shares identity with its head cell (along a
+  special clone dimension), used to let one logical item appear in several places /
+  participate in many-to-one relations.
+
+---
+
+## 2. The one rule that defines everything
+
+Formally (McGuffin & schraefel, HT2004; McGuffin's graph-theoretic intro), a
+zzstructure is:
+
+> a **directed multigraph whose edges are coloured (typed)**, subject to the
+> restriction that **each node has at most one incoming edge of each colour and at
+> most one outgoing edge of each colour.**
+
+Equivalently: **along any single dimension, a cell has at most one posward and one
+negward neighbour.** That single constraint is the whole design:
+
+- Each dimension decomposes the cell set into disjoint **ranks** (paths and cycles) —
+  never a branching tree, never a fan-out, *within one dimension*.
+- Many dimensions coexist over the **same** cells, each imposing its own independent
+  rank structure. A cell sits at the intersection of as many dimensions as it
+  participates in.
+- There is **no inherent hierarchy.** A tree is not the substrate; it is *one
+  possible dimension* (encoded left-child/right-sibling — see §4).
+
+This is the property that matters for shard-wiki: **the same set of pages can carry
+many orthogonal structures simultaneously, with none privileged.**
+
+---
+
+## 3. Views — how multiple dimensions are seen
+
+Because no screen can show all dimensions, ZigZag *rotates* two into view at a time:
+
+- **I-view** — cells along **one** dimension from the cursor, drawn as a line.
+- **H-view** — a 2-D cross: **two** dimensions through the cursor, one drawn
+  horizontally and one vertically; only cells actually connected to the cursor along
+  those two dimensions appear (empty spreadsheet cells simply do not exist).
+- **I+/H+ (augmented) views** — fill remaining space with further neighbours.
+- **Raster vs. view (terminology)** — a *raster* selects which cells to take from the
+  structure; a *view* places them on screen. "Pivoting" rotates a different dimension
+  into the horizontal or vertical slot.
+
+The H-view "pivot" is the genuinely interesting UX idea for a *federated* wiki: put
+**pages of a namespace** on one axis and **shards** (or **versions across shards**)
+on the other, then rotate to re-cross-tabulate the same union by a different pair of
+relationships.
+
+---
+
+## 4. Trees, lists, tables, graphs — what fits and what does not
+
+zzstructure subsumes simpler structures by spending dimensions:
+
+- **List** = one rank along one dimension.
+- **Table** = two dimensions (rows / columns), shown as an H-view.
+- **Tree** = encoded as a zzstructure "analogous to the left-child, right-sibling
+  pointer implementation" — i.e. a *parent→firstchild* dimension plus a
+  *sibling→sibling* dimension. So a hierarchy is **two dimensions**, not a primitive.
+- **Many-to-one / many-to-many** = NOT directly expressible (the one-edge-per-colour
+  rule forbids fan-out). It is simulated with **clones**: the head cell links to many
+  clone cells along the clone dimension, and each clone participates in a different
+  rank.
+
+**This is the critical caveat for wikis.** A namespace hierarchy (each page has *one*
+parent) and a created-from genealogy (each page has *one* origin) fit zzstructure
+*natively* and beautifully. But a wiki's **hyperlink graph is many-to-many** (a page
+links to many pages and is linked from many) — it is *not* a rank and cannot be one
+dimension. Representing links/backlinks in zzstructure requires cloning or treating
+the link set as data, which is awkward. zzstructure is excellent for the
+**functional/sequential/hierarchical** relationships and weak for the **arbitrary
+graph** ones.
+
+---
+
+## 5. Mapping a shard-wiki information space onto dimensions
+
+Taking the user's framing literally — model the union of pages as cells, and each
+relationship as a dimension:
+
+| Dimension (proposed) | Rank meaning | Fits zzstructure? | shard-wiki source |
+|----------------------|--------------|-------------------|-------------------|
+| `d.namespace-child` + `d.namespace-sibling` | namespace tree (left-child/right-sibling) | **Yes** (2 dims) | UC-22, yawex topics |
+| `d.genealogy` | created-from / fork lineage (each page one origin) | **Yes** (functional) | UC-26 fork, UC-29 remix |
+| `d.version` | revision order of a page | **Yes** (a rank = a history) | coordination journal |
+| `d.shard` | pages grouped by owning shard | **Yes** | shard sovereignty |
+| `d.overlay` | page → its overlays | **Yes** (or clones) | overlay model |
+| `d.equivalence` | parallel versions of the same topic across shards | **Yes** (a rank of equivalents) | UC-27, UC-46 |
+| `d.recent` | temporal order of changes | **Yes** | UC-17 RecentChanges |
+| `d.alphabetical` | AllPages ordering | **Yes** | UC-19 |
+| `d.links` / `d.backlinks` | hyperlink graph | **No** (many-to-many) — needs clones / stays a graph index | UC-05, UC-18 |
+| `d.transclusion` | content reused in many places | **No** as rank — but maps to **clones** (= "same content in many places") | UC-32, UC-44/45 |
+
+Observation: shard-wiki's existing **derived views** (UC-05, UC-17–UC-20) are, in
+zzstructure terms, *dimensions + rasters*: RecentChanges is a raster along `d.recent`,
+AllPages along `d.alphabetical`, SiteMap is an H-view over the two namespace
+dimensions. zzstructure offers a **single unifying vocabulary** for what shard-wiki
+currently treats as a grab-bag of separate derived views.
+
+Observation 2: ZigZag **clones** are conceptually the same move as Xanadu
+transclusion ("the same content knowably in more than one place") — the two Nelson
+projects converge here. A transcluded span / equivalent page is a clone that
+participates in multiple ranks.
+
+---
+
+## 6. Is zzstructure the right model for shard-wiki? (recommendation)
+
+**Adopt as a lens, not a substrate.**
+
+- **As a navigation & visualization model: promising.** Letting a reader pick which
+  *dimension* to traverse (namespace vs. genealogy vs. version vs. shard) and pivot
+  two dimensions into an H-view is a real, differentiated UX for a federated,
+  provenance-preserving wiki. It operationalizes "union without erasure": every
+  relationship is co-equal and visible, none hidden. (UC-47, UC-48.)
+- **As a conceptual model for the page graph: useful and clarifying.** Reframing the
+  scattered derived views as *dimensions over one cell set* is a clean mental model
+  and a candidate internal index/API shape. It also de-privileges the namespace tree
+  (UC-49) — consistent with **mechanism over policy** (the hierarchy is one
+  configurable dimension, not the canonical structure).
+- **As the storage substrate: reject.** Git and heterogeneous sovereign shards remain
+  canonical (per INTENT Stability Note — Git's role is architectural). A zzstructure
+  is a **derived, projected index** computed over the union, like BackLinks today —
+  not a database that replaces the shards. The many-to-many hyperlink graph does not
+  fit the rank constraint, and forcing the wiki into a zz-DB would violate shard
+  sovereignty and the orchestrator-not-engine boundary.
+
+Net: zzstructure is a strong answer to *"how do we present a page's many
+simultaneous relationships without picking a winner?"* — a **dimensional projection**
+layer over the existing union, not a new store.
+
+---
+
+## 7. Mapping to shard-wiki INTENT (compare, do not equate)
+
+### 7.1 Reinforcements
+
+- **Union without erasure ↔ co-equal dimensions.** zzstructure's refusal to privilege
+  any one structure is the data-model expression of shard-wiki's refusal to hide
+  provenance, conflicts, or alternative arrangements.
+- **Mechanism over policy ↔ hierarchy-as-just-a-dimension.** The namespace tree being
+  one dimension among many is exactly "do not hard-code one canonical structure."
+- **Provenance ↔ genealogy dimension.** Created-from lineage as a navigable rank makes
+  provenance a first-class traversal, not metadata buried in a footer.
+
+### 7.2 Deliberate divergences (design bugs if conflated)
+
+1. **zzstructure as store.** Replacing Git/shards with a zz-database would break the
+   Stability-Note boundary on Git's role and on orchestrator-vs-engine. zzstructure is
+   a projection, full stop.
+2. **Forcing the hyperlink graph into ranks.** The link/backlink graph is many-to-many
+   and must stay a graph index; do not contort it into a single dimension. Use clones
+   or keep it as a separate graph projection.
+3. **One global zz-space.** Like Xanadu's docuverse, a single universal zz-space would
+   fight shard sovereignty. Each information space gets its *own* dimensional
+   projection over *its* attached shards.
+
+### 7.3 What ZigZag teaches that shard-wiki should keep
+
+- A page is best understood as **a cell at the intersection of many independent
+  relationships**, not as a node in one tree. Build the page model and the navigation
+  API so *adding a new relationship is adding a dimension*, not special-casing a view.
+- **Pivoting two relationships** (H-view) is a powerful, under-used exploration
+  primitive for federation (namespace × shard, page × version, topic × equivalent).
+
+---
+
+## 8. Use-case seeds → catalog (promoted 2026-06-14)
+
+Last existing UC is **UC-46**. New UCs **UC-47–UC-49** added; existing UCs enriched.
+
+| Seed | Catalog action |
+|------|----------------|
+| **Navigate along a chosen relationship dimension** — pick namespace / genealogy / links / version / shard as the active traversal axis | **UC-47 (new)** |
+| **Pivot two dimensions as a cross-tab (H-view)** — e.g. namespace × shard, page × version-across-shards | **UC-48 (new)** |
+| **First-class created-from / fork genealogy dimension** — navigate derivation lineage as a rank | **UC-49 (new)** |
+| Namespace hierarchy is *one dimension among many*, not the privileged structure | **enriches UC-22** |
+| Derived views (RecentChanges, AllPages, SiteMap, BackLinks) reframed as dimensions + rasters | **enriches UC-05** (anchor for the UC-17–UC-20 view reframing) |
+| Fork/remix produce a genealogy edge consumed by UC-49 | **enriches UC-26, UC-29** |
+| Clone = "same content in many places" = transclusion convergence | links UC-32, UC-44/45 |
+
+---
+
+## 9. Architecture notes for SHARD-WP-0002 (no UC)
+
+- A **dimensional projection layer** over the union is a candidate internal model:
+  pages = cells; relationships (namespace, genealogy, version, shard, equivalence,
+  overlay, recent, alphabetical) = dimensions; existing derived views = rasters over
+  them. It is **derived/lazy**, never canonical store.
+- The **link/backlink graph stays a separate many-to-many index**; do not model it as
+  a rank. Reconcile with the dimensional model via clones or by keeping graph and
+  dimensional projections side by side.
+- **Genealogy** (created-from) should be recorded as an edge when fork/remix/import
+  happens (UC-26, UC-29) so the `d.genealogy` rank can be reconstructed — ties to the
+  coordination journal.
+- Whether the dimensional model is exposed in a **public navigation API** or stays an
+  internal organizing concept is open (see §10).
+
+---
+
+## 10. Open questions (for spec / workplans)
+
+1. Is the dimensional/zzstructure model a **public navigation API** and UI paradigm,
+   or only an *internal* organizing concept for the existing derived views?
+2. How is the **many-to-many link graph** reconciled with the rank-based dimensional
+   model — clones, a parallel graph index, or both?
+3. Which dimensions are **core** (namespace, version, shard, genealogy, recent) vs.
+   **adapter-provided** vs. **computed on demand** (equivalence, backlinks)?
+4. Is **H-view pivoting** worth a reference-UI investment, or is it research-only?
+5. Does the **clone = transclusion** convergence justify a single internal primitive
+   shared by UC-44/45 (transclusion) and UC-47/48 (dimensional navigation)?
+
+---
+
+## 11. Sources
+
+| Source | Used for |
+|--------|----------|
+| Wikipedia — ZigZag (software) (https://en.wikipedia.org/wiki/ZigZag_(software)) | History, spreadsheet-deconstruction framing, one-connection-per-dimension rule, pivoting |
+| Wikipedia — Zzstructure (https://en.wikipedia.org/wiki/Zzstructure) | Directed-coloured-multigraph definition, dimensions-are-cells, raster vs. view |
+| McGuffin & schraefel, "A Comparison of Hyperstructures: Zzstructures, mSpaces, and Polyarchies," ACM Hypertext 2004 (https://www.dgp.toronto.edu/papers/mmcguffin_HT2004.pdf) | Graph-theoretic formal definition; taxonomy vs. mSpaces/polyarchies |
+| McGuffin, "A Graph-Theoretic Introduction to Ted Nelson's Zzstructures" (https://www.dgp.toronto.edu/~mjmcguff/research/zigzag/) | Ranks, I-view/H-view/augmented views, clones, tree-as-left-child/right-sibling, "multiple arrangements coexist via dimensions" |
+| Moore & Brailsford, "Unified Hyperstructures for Bioinformatics," JoDI (https://jodi-ojs-tdl.tdl.org/jodi/article/download/jodi-138/127) | Applied zzstructure as a unifying model over heterogeneous structures |
+| Nelson, "A Cosmology for a Different Computer Universe" (zzstructure context) | Nelson's own framing of cells/dimensions/visualization |
+| Gzz — "A Gentle Introduction to Ted Nelson's ZigZag Structure" (https://www.nongnu.org/gzz/gi/gi.html) | Practical cell/dimension/rank examples (rate-limited; corroborated by above) |
+
+Cross-references: `research/260614-xanadu-deep-dive/findings.md` (clone↔transclusion
+convergence), `spec/UseCaseCatalog.md` (UC-05, UC-17–UC-22, UC-26, UC-27, UC-29,
+UC-32, UC-44/45/46), `workplans/SHARD-WP-0002-federation-architecture.md`.
+
+---
+
+## 12. Traceability
+
+- New UCs: **UC-47, UC-48, UC-49** → `spec/UseCaseCatalog.md`.
+- Enriched UCs: **UC-05** (anchors the UC-17–UC-20 derived-view reframing), **UC-22,
+  UC-26, UC-29**.
+- Architecture (no UC): dimensional projection layer; link-graph-stays-graph;
+  genealogy edges in the journal; clone↔transclusion primitive → `SHARD-WP-0002`.
+- Decision boundary recorded: zzstructure is a **derived lens, not the store**;
+  Git/shards remain canonical (INTENT Stability Note).
+</content>

research/README.md

@@ -13,4 +13,9 @@ when multiple files or sources are involved. Findings here inform `spec/` and
 | 2026-06-08 | `260608-yawex-prior-art/` | yawex 0.7.4 Perl wiki prior art; federation design seeds |
 | 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-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 |
+| 2026-06-14 | `260614-zigzag-deep-dive/` | ZigZag/zzstructure — information space as orthogonal dimensions; UC-47/48/49 |

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/`,
+`research/260614-xanadu-deep-dive/`, and `research/260614-zigzag-deep-dive/`.
 See InfoTechPrimers on coulomb.social for use-case catalog conventions.
 
 ## Conventions
@@ -71,7 +72,11 @@ all attached shards as a federated graph.
 **Source:** intent, c2, yawex  
 **Notes:** Present on both c2 (community nerve center) and yawex core pages.
 BackLinks over the union link-graph is the strongest core candidate; per-shard
-vs union scope remains open (see UC-19–UC-21).  
+vs union scope remains open (see UC-19–UC-21). ZigZag deep dive reframes these views
+under one vocabulary: each is a **dimension + raster** (RecentChanges along `d.recent`,
+AllPages along `d.alphabetical`, SiteMap as an H-view over the namespace dimensions),
+navigable via UC-47 (`research/260614-zigzag-deep-dive/findings.md` §5). Note: the
+many-to-many link/backlink graph stays a **separate graph index**, not a zz-rank.  
 **Priority:** Later
 
 ### UC-06 — Authenticated team wiki (L2+)
@@ -106,7 +111,9 @@ shard for independent editing, with provenance preserved.
 **Notes:** Fedwiki fork primitive. shard-wiki may realize as import, overlay
 seed, or writable copy per policy — distinct from UC-04 (overlay without copy)
 and UC-03 (projection only). Fork vs overlay vs import decided in
-`SHARD-WP-0002`.  
+`SHARD-WP-0002`. Should record a **created-from genealogy edge** in the coordination
+journal so the lineage is navigable as a dimension (UC-49,
+`research/260614-zigzag-deep-dive/findings.md` §9).  
 **Priority:** Later
 
 ### UC-27 — View multiple versions of equivalent page
@@ -116,7 +123,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 +144,14 @@ 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. Remix should also record a **genealogy edge**
+(UC-49) so reuse lineage is navigable, not just attributed.  
 **Priority:** Later
 
 ### UC-30 — Time-bounded collaboration space
@@ -169,7 +184,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 +361,88 @@ 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
+
+### UC-47 — Navigate the information space along a chosen relationship dimension
+
+**Actor:** Reader  
+**Goal:** Traverse pages along a *selected* relationship axis — namespace, created-from
+genealogy, version history, owning shard, equivalence, or recent-change order — rather
+than a single fixed hierarchy.  
+**Source:** zigzag, intent  
+**Notes:** ZigZag/zzstructure treats each relationship as a first-class **dimension**;
+a page is a cell at the intersection of many independent ranks
+(`research/260614-zigzag-deep-dive/findings.md` §2, §5). Reframes the existing derived
+views (UC-05, UC-17–UC-20) as *dimensions + rasters* under one vocabulary. Embodies
+union-without-erasure: every relationship co-equal, none privileged. Open: public
+navigation API vs. internal model (findings §10 Q1).  
+**Priority:** Later
+
+### UC-48 — Pivot two relationships into a cross-tab view (H-view)
+
+**Actor:** Reader  
+**Goal:** Cross-tabulate the union by two dimensions at once — e.g. namespace × shard,
+or page × versions-across-shards — and pivot to re-cross by a different pair.  
+**Source:** zigzag  
+**Notes:** ZigZag **H-view** shows two dimensions through a cursor, one horizontal one
+vertical, with only existing cells present (`research/260614-zigzag-deep-dive/findings.md`
+§3). A differentiated exploration primitive for federation/provenance. Open: reference-UI
+investment vs. research-only (findings §10 Q4).  
+**Priority:** Later
+
+### UC-49 — Navigate created-from / fork genealogy as a first-class dimension
+
+**Actor:** Reader or maintainer  
+**Goal:** Follow a page's derivation lineage — what it was forked/remixed/imported
+from, and what was derived from it — as a navigable rank.  
+**Source:** zigzag, federation, intent  
+**Notes:** Genealogy is a *functional* relation (one origin) that fits a zzstructure
+dimension natively (`research/260614-zigzag-deep-dive/findings.md` §4, §5). Requires a
+genealogy edge recorded at fork/remix/import time (UC-26, UC-29) in the coordination
+journal. Makes provenance a traversal, not a buried footer (complements UC-24).  
+**Priority:** Later
+
 ---
 
 ## B. Knowledge work and collaboration
@@ -495,7 +596,11 @@ adapter-provided indexing TBD.
 normalized paths within a topic hierarchy.  
 **Source:** yawex  
 **Notes:** yawex topics-as-directories; page-resolution state space is
-inspiration only for federation design (not inherited as API).  
+inspiration only for federation design (not inherited as API). ZigZag deep dive: treat
+the namespace hierarchy as **one dimension among many** (encoded left-child/right-sibling
+as two zz-dimensions), not the privileged structure — consistent with mechanism over
+policy; navigate it as one axis via UC-47 (`research/260614-zigzag-deep-dive/findings.md`
+§4, §7.1).  
 **Priority:** Later
 
 ### UC-23 — Soft topic creation via red link
@@ -520,7 +625,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 +672,12 @@ CamelCase and `[[free links]]`. Markdown-first link semantics TBD.
 | UC-41 | | | | ✓ | ✓ |
 | UC-42 | | | | ✓ | ✓ |
 | UC-43 | | | | ✓ | ✓ |
+| UC-44 | | | ✓† | | ✓ |
+| UC-45 | | | ✓† | | ✓ |
+| UC-46 | | | ✓† | | ✓ |
+| UC-47 | | | ‡ | | ✓ |
+| UC-48 | | | ‡ | | |
+| UC-49 | | | ‡ | | ✓ |
 | UC-08 | ✓ | | |
 | UC-09 | ✓ | | |
 | UC-10 | ✓ | | |
@@ -654,6 +768,61 @@ 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.
+
+### zigzag mapping
+
+(‡ UC-47–UC-49 are placed in the **federation** matrix column as the nearest existing
+source; their true lineage is the **ZigZag deep dive**,
+`research/260614-zigzag-deep-dive/findings.md`.)
+
+| ZigZag / zzstructure mechanism (findings §) | Catalog UC |
+|---------------------------------------------|------------|
+| Each relationship is a first-class **dimension**; a page is a cell at many ranks (§2, §5) | UC-47 |
+| **H-view** — pivot two dimensions into a cross-tab (§3) | UC-48 |
+| **Genealogy** as a functional dimension fitting a zz-rank (§4, §5) | UC-49 |
+| Hierarchy is **one dimension among many** (left-child/right-sibling) (§4, §7.1) | UC-22 (enriched) |
+| Derived views = **dimensions + rasters** under one vocabulary (§5) | UC-05 (enriched; anchors UC-17–UC-20) |
+| Fork/remix records a navigable genealogy edge (§9) | UC-26, UC-29 (enriched) |
+| **Clone** = "same content in many places" — converges with transclusion (§5) | links UC-32, UC-44/45 |
+
+Note: ZigZag is **a data model + visualization paradigm, not a candidate shard
+backend.** Recommendation recorded in the dive: adopt zzstructure as a **navigation /
+visualization / indexing lens** — a *derived dimensional projection* over the union,
+like BackLinks today — and **reject it as the storage substrate**
+(`research/260614-zigzag-deep-dive/findings.md` §6, §7.2). Git and sovereign shards
+remain canonical (INTENT Stability Note). The many-to-many hyperlink graph does **not**
+fit zzstructure's one-neighbour-per-dimension rule and stays a separate graph index.
+Architecture logged for `SHARD-WP-0002`: a dimensional projection layer; genealogy
+edges in the coordination journal; clone↔transclusion as a possible shared primitive
+(findings §9). Pairs with the Xanadu dive (clone ↔ transclusion convergence).
+
 ---
 
 ## Open questions
@@ -667,4 +836,8 @@ logged the `Foswiki::Store` versioned interface as **adapter-contract prior art*
    `ProductRequirementsDocument.md` as explicit product identity?
 5. Which federation UCs (UC-26–UC-33) are **MVP** vs deferred until
    `SHARD-WP-0002` architecture decisions land?
-6. Does UC-32 (transclusion) belong in core orchestrator or adapter/UI layer?
+6. Does UC-32 (transclusion) belong in core orchestrator or adapter/UI layer?
+7. Is the **dimensional/zzstructure model** (UC-47/48) a public navigation API and UI
+   paradigm, or only an internal organizing concept for the derived views?
+8. How is the **many-to-many link graph** reconciled with the rank-based dimensional
+   model — clones, a parallel graph index, or both? (ZigZag dive §10.)