coulomb/shard-wiki
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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>
This commit is contained in:
Bernd Worsch
2026-06-14 01:24:45 +02:00
parent 316fdeedc2
commit 60e1aa661c
4 changed files with 470 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

47
research/260614-xanadu-deep-dive/README.md Normal file
View File

@@ -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>

322
research/260614-xanadu-deep-dive/findings.md Normal file
View File

@@ -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>

6
research/README.md
View File

@@ -13,4 +13,8 @@ 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 |

103
spec/UseCaseCatalog.md
View File

@@ -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