---
id: capability.wiki.shard-orchestration
name: Wiki Shard Orchestration
summary: Present a union of pages across heterogeneous wiki-shaped shards while preserving each shard's provenance, capabilities, and history.
owner: shard-wiki
status: draft
domain: helix_forge
tags: [wiki, federation, orchestration, union, shard-wiki]

maturity:
  discovery:
    current: D5
    target: D6
    confidence: high
    rationale: >
      Grounded in 84 documented use cases and a twice-reviewed whole-system
      architecture (CoreArchitectureBlueprint) derived from ~23 prior-art systems.
  availability:
    current: A2
    target: A5
    confidence: medium
    rationale: >
      InformationSpace orchestrator (attach -> resolve -> read, chorus on
      ambiguity) works as a Python source module; network API and incremental
      union are planned.

external_evidence:
  completeness:
    level: C2
    name: Partial
    confidence: medium
    basis: scope_vs_intent_and_consumer_expectations
    satisfied_expectations:
      - attach folder shards and read a union page with layered provenance
      - chorus presentation of equivalent-but-divergent pages (union without erasure)
    broken_expectations:
      - incremental union maintenance and equivalence index not yet built
      - write-through federation transports not yet built
    out_of_scope_expectations:
      - hosting or replacing the underlying wiki engines
  reliability:
    level: R1
    confidence: low
    basis: consumer_quality_signals
    known_reliability_risks:
      - early implementation; 64 tests but no production exposure

discovery:
  intent: >
    Let independently stored, differently implemented wikis behave as one
    coherent, versionable, inspectable information space without homogenizing them.
  includes:
    - union resolution across shards (identity-keyed)
    - chorus / designated-canonical presentation of equivalent pages
    - lazy replication projection of remote content with freshness
  excludes:
    - implementing a backend wiki engine (see capability.wiki.engine-typed-extensions)
    - silent remote mutation
  assumptions:
    - canonical truth lives in shards + a git coordination journal; the union is derived
  use_cases:
    - "shard-wiki UseCaseCatalog UC-01..UC-07, UC-26..UC-33 (information space, federation, coordination)"

availability:
  current_level: A2
  target_level: A5
  current_artifacts:
    - "shard-wiki/src/shard_wiki/union/"
    - "shard-wiki/src/shard_wiki/space.py"
  target_artifacts:
    - orchestrator network API
  consumption_modes:
    - source module

relations:
  depends_on:
    - capability.wiki.adapter-contract
    - capability.wiki.page-model
    - capability.wiki.coordination-journal
  supports:
    - capability.wiki.federation-models

evidence:
  documentation:
    - "shard-wiki/spec/CoreArchitectureBlueprint.md"
    - "shard-wiki/spec/FederationArchitecture.md"
  tests:
    - "shard-wiki/tests/test_union.py"
    - "shard-wiki/tests/test_integration.py"

consumer_guidance:
  recommended_for:
    - composing multiple Markdown/wiki stores into one provenance-preserving view
  not_recommended_for:
    - replacing a single wiki engine
  known_limitations:
    - resolution is recompute-on-read until the incremental tier lands
---

# Wiki Shard Orchestration

shard-wiki's core capability: orchestrate wiki-shaped content across heterogeneous *shards*
as a union of pages, preserving provenance, capabilities, and history per shard. Canonical
truth stays at the edges (shards + the git coordination journal); the union is a derived,
recomputable view (orchestrator, not engine).

## Assessment notes

### Discovery
Grounded by `UseCaseCatalog.md` (84 UCs) and the hardened `CoreArchitectureBlueprint.md`.

### Availability
`InformationSpace` provides attach/resolve/read today (source module); a network API is the
target availability step.