research: write up wiki-engines landscape scan; send IAM demand to netkingdom

- Add README.md + findings.md to research/260608-wikiengines-overview/ to match sibling research convention (was a bare Perplexity dump). findings.md synthesizes the engine landscape into adapter-contract implications and maps to INTENT (capability heterogeneity, L0->L4 ladder, backend-neutrality). - Mark the netkingdom integration demand as sent: capability request 3136a9e2 (auto-routed to netkingdom) + inbox message 46c60f17. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-13 18:18:45 +02:00
parent 81cfce10d2
commit 7d1fb97968
4 changed files with 580 additions and 2 deletions
--- a/demand/260608-netkingdom-integration-requirements.md
+++ b/demand/260608-netkingdom-integration-requirements.md
@@ -82,8 +82,10 @@ shard-wiki authorizes; it never authenticates or stores identity. Everything bel
 ## Next actions
- [ ] Send this as a **capability request / interface negotiation** to the netkingdom domain
+- [x] Send this as a **capability request / interface negotiation** to the netkingdom domain
-      (user-engine + net-kingdom owners) via the state hub.
+      (user-engine + net-kingdom owners) via the state hub. — *sent 2026-06-13, capability
      request `3136a9e2-0c1a-4b3f-8a02-ef47b27071fe` (auto-routed to `netkingdom`), inbox
      message `46c60f17`.*
 - [ ] Lock the **token claim contract** (A2–A4) and the **membership read API** (B1–B5) first
      — they gate everything L2+.
 - [ ] Define shard-wiki's **audit event schema** (C1) against user-engine's existing audit model.
--- a/research/260608-wikiengines-overview/260608-perplexity-wikiengines-research.md
+++ b/research/260608-wikiengines-overview/260608-perplexity-wikiengines-research.md
@@ -0,0 +1,397 @@
 # Perplexity Research Wiki Engines
 Source: https://www.perplexity.ai/search/9b76560e-31b7-4465-87a4-01a9df9cdbbe#1
 ## What are the most technically interesting wiki engines out there?
 Below is an expanded, more technical map of the wiki landscape, including your additions: C2, Federated Wiki, TWiki, Confluence, Semantic MediaWiki, TiddlyWiki, Fossil, and the Tcl-based option I found. I’ve kept the focus on what each system is *for*, what makes it distinct, and what kind of adoption it seems to have had. [c2](http://c2.com/cgi/wiki?TopTenWikiEngines)
 ## Wiki.js
 Wiki.js is a modern, extensible, self-hosted wiki aimed at polished documentation and flexible deployment. It feels like the “modern web app” interpretation of a wiki. [js](https://js.wiki)
 **USPs**
 - Modern UI and authoring experience.
 - Extensible architecture.
 - Self-hosted and open source. [wikimatrix](https://www.wikimatrix.org/compare/wiki-js+dokuwiki+xwiki+mediawiki+tiki-wiki-cms-groupware+tiddlywiki)
 **Strengths**
 - Strong for documentation teams that want low-friction editing.
 - Good fit when you want a contemporary stack and a clean UX.
 - Broadly positioned as “powerful and extensible.” [js](https://js.wiki)
 **Weaknesses**
 - Less historically proven than MediaWiki or TWiki in huge legacy enterprise environments.
 - Smaller ecosystem than the oldest wiki engines.
 - Not as “structured application platform” oriented as Foswiki/XWiki. [wikimatrix](https://www.wikimatrix.org/compare/wiki-js+dokuwiki+xwiki+mediawiki+tiki-wiki-cms-groupware+tiddlywiki)
 **Characteristic use cases**
 - Internal docs.
 - Product documentation.
 - Team knowledge bases.
 - Self-hosted alternative to SaaS doc tools. [js](https://js.wiki)
 **Userbase estimate**
 - Likely **tens of thousands of active deployments/users**, but public numbers are not well standardized. That makes it a strong product choice, but not a giant legacy ecosystem like MediaWiki or TWiki. [wikimatrix](https://www.wikimatrix.org/compare/wiki-js+dokuwiki+xwiki+mediawiki+tiki-wiki-cms-groupware+tiddlywiki)
 ## XWiki
 XWiki is a programmable wiki platform that blurs the line between wiki and lightweight application platform. It is technically interesting because it supports scripts, macros, and application-style pages. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
 **USPs**
 - Scriptable pages and apps.
 - Strong extension model.
 - Syntax compatibility with other wiki styles. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
 **Strengths**
 - Great for building structured internal tools.
 - More “platform-like” than plain wiki software.
 - Good fit for teams that need dynamic content and forms. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
 **Weaknesses**
 - More complexity than simpler wikis.
 - Can feel heavyweight if you only want plain documentation.
 - Requires more governance and administration. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
 **Characteristic use cases**
 - Enterprise knowledge bases.
 - Internal business applications.
 - Structured reporting and collaborative workflows.
 - Documentation that needs embedded logic. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
 **Userbase estimate**
 - Probably **tens of thousands to low hundreds of thousands** of users across deployments, but public install counts are not clearly disclosed. [wikimatrix](https://www.wikimatrix.org/compare/wiki-js+dokuwiki+xwiki+mediawiki+tiki-wiki-cms-groupware+tiddlywiki)
 ## MediaWiki
 MediaWiki is the canonical large-scale wiki engine: boring in the best possible way, because it works at enormous scale and has an enormous extension ecosystem. It remains technically important because it set the pattern for high-volume collaborative editing. [herothemes](https://herothemes.com/blog/wiki-software/)
 **USPs**
 - Proven at internet scale.
 - Huge extension ecosystem.
 - Strong revision/history and collaboration model. [herothemes](https://herothemes.com/blog/wiki-software/)
 **Strengths**
 - Best-in-class for public, high-traffic, multi-author wikis.
 - Extremely mature.
 - Broad tooling and community support. [herothemes](https://herothemes.com/blog/wiki-software/)
 **Weaknesses**
 - Can be operationally heavy.
 - Editing experience is not the smoothest by default.
 - Often overkill for small internal knowledge bases. [herothemes](https://herothemes.com/blog/wiki-software/)
 **Characteristic use cases**
 - Wikipedia-style public encyclopedias.
 - Community knowledge bases.
 - Large multilingual collaborative sites.
 - Semantic layering via extensions. [herothemes](https://herothemes.com/blog/wiki-software/)
 **Userbase estimate**
 - By far the largest in this group; think **millions of contributors and readers across many thousands of sites**. [c2](http://c2.com/cgi/wiki?TopTenWikiEngines)
 ## Semantic MediaWiki
 Semantic MediaWiki is technically interesting because it turns wiki pages into queryable knowledge objects. It is less “just a wiki” and more a semantic knowledge base on top of MediaWiki. [en.wikipedia](https://en.wikipedia.org/wiki/Foswiki)
 **USPs**
 - Semantic annotations.
 - Queryable structured content.
 - Strong fit for knowledge management with ontology-like behavior. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
 **Strengths**
 - Very powerful for structured knowledge capture.
 - Supports reporting and retrieval beyond full-text search.
 - Bridges freeform wiki editing and data-driven retrieval. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
 **Weaknesses**
 - Steeper learning curve.
 - Requires discipline in content modeling.
 - More complex than plain wiki editing. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
 **Characteristic use cases**
 - Research knowledge bases.
 - Reference systems with structured facts.
 - Enterprise knowledge graphs and catalogs.
 - Areas where pages should behave like data records. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
 **Userbase estimate**
 - Smaller than MediaWiki, but meaningful in specialist knowledge-management circles: likely **thousands of sites, not millions**. [en.wikipedia](https://en.wikipedia.org/wiki/Foswiki)
 ## DokuWiki
 DokuWiki is the classic lightweight, file-based wiki: simple, pragmatic, and still technically elegant because it avoids a database. It is a workhorse for teams that want low operational overhead. [medevel](https://medevel.com/os-wiki-engines-for-2021/)
 **USPs**
 - No database required.
 - Simple deployment.
 - Large plugin ecosystem. [medevel](https://medevel.com/os-wiki-engines-for-2021/)
 **Strengths**
 - Easy to run and back up.
 - Good text/wiki syntax experience.
 - Reliable for small-to-medium teams. [medevel](https://medevel.com/os-wiki-engines-for-2021/)
 **Weaknesses**
 - Less suited to highly structured app-like workflows.
 - Not the strongest choice for huge public communities.
 - Interface feels older than modern doc platforms. [medevel](https://medevel.com/os-wiki-engines-for-2021/)
 **Characteristic use cases**
 - Internal docs.
 - Departmental knowledge bases.
 - Small team collaboration.
 - Simple intranets and technical notes. [medevel](https://medevel.com/os-wiki-engines-for-2021/)
 **Userbase estimate**
 - Likely **tens of thousands of installations**; broad but not dominant. [medevel](https://medevel.com/os-wiki-engines-for-2021/)
 ## TiddlyWiki
 TiddlyWiki is one of the most technically unusual wiki engines because it is often a single self-contained HTML file that acts like a personal knowledge system. That makes it deeply portable and hackable. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
 **USPs**
 - Single-file architecture.
 - Highly personal and portable.
 - Strong customization via plugins/macros/themes. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
 **Strengths**
 - Great for personal knowledge management.
 - Easy to carry around and version-control.
 - Extremely flexible for power users. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
 **Weaknesses**
 - Not a conventional multi-user server wiki.
 - Collaboration and permissions are not its core strength.
 - Can become messy without personal discipline. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
 **Characteristic use cases**
 - Personal notes.
 - Research notebooks.
 - Offline-first knowledge bases.
 - Individual knowledge workflows. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
 **Userbase estimate**
 - Probably **tens of thousands to a few hundred thousand users**, with a strong enthusiast niche. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
 ## TWiki
 TWiki is a structured enterprise wiki that emerged from enterprise demand rather than minimalist wiki ideals. It is interesting because it became a platform for forms, workflows, and application-like pages. [junauza](https://www.junauza.com/2008/05/five-of-best-freeopen-source-wiki.html)
 **USPs**
 - Enterprise collaboration platform.
 - Strong extensibility, with hundreds of extensions.
 - Structured content and application building. [sourceforge](https://sourceforge.net/projects/twiki/)
 **Strengths**
 - Proven in corporate environments.
 - Great for structured team workflows.
 - Strong fit for intranets and process-heavy use. [sourceforge](https://sourceforge.net/projects/twiki/)
 **Weaknesses**
 - Older design philosophy.
 - Can feel complex and procedural.
 - Less attractive for lightweight modern docs. [sourceforge](https://sourceforge.net/projects/twiki/)
 **Characteristic use cases**
 - Corporate intranets.
 - Team collaboration.
 - Project tracking.
 - Enterprise knowledge management. [junauza](https://www.junauza.com/2008/05/five-of-best-freeopen-source-wiki.html)
 **Userbase estimate**
 - SourceForge’s description claims **50,000 small businesses, many Fortune 500 companies, and millions of people** use TWiki, though that should be treated as a vendor-style estimate rather than audited usage data. [sourceforge](https://sourceforge.net/projects/twiki/)
 ## Foswiki
 Foswiki is the continuation of the structured enterprise-wiki tradition, with strong emphasis on collaboration, plugins, and business use. It is technically interesting because it treats the wiki as an application platform with macros, forms, and reporting. [sourceforge](https://sourceforge.net/projects/foswiki/)
 **USPs**
 - Enterprise wiki and collaboration platform.
 - Application-building via markup and macros.
 - Fine-grained access control and auditability. [sourceforge](https://sourceforge.net/projects/foswiki/)
 **Strengths**
 - Strong fit for controlled enterprise environments.
 - Very flexible for internal business applications.
 - Deep extension model and workflow-style usage. [en.wikipedia](https://en.wikipedia.org/wiki/Foswiki)
 **Weaknesses**
 - Heavier and more specialized than lightweight wikis.
 - UX is functional rather than modern-first.
 - Best when governance and structure matter more than simplicity. [sourceforge](https://sourceforge.net/projects/foswiki/)
 **Characteristic use cases**
 - Knowledge bases.
 - Team collaboration portals.
 - Workflow and project tracking.
 - Document management and structured reporting. [hpcsupport.utsa](http://hpcsupport.utsa.edu/foswiki/bin/view/System/WikiCulture)
 **Userbase estimate**
 - Likely **thousands to tens of thousands of active users/deployments**, with a strong enterprise niche rather than mass-market scale. [en.wikipedia](https://en.wikipedia.org/wiki/Foswiki)
 ## Confluence
 Confluence is the enterprise commercial benchmark for team wikis, but technically it is more a knowledge collaboration platform than a pure wiki engine. It matters because many organizations chose it as the default workplace knowledge layer. [herothemes](https://herothemes.com/blog/wiki-software/)
 **USPs**
 - Tight enterprise integration.
 - Mature permissions and collaboration.
 - Large marketplace ecosystem. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
 **Strengths**
 - Strong adoption in enterprises.
 - Good for cross-team documentation and workflows.
 - Familiar to many business users. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
 **Weaknesses**
 - Commercial lock-in.
 - Less transparent/inspectable than open-source engines.
 - Can become sprawling and hard to govern at scale. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
 **Characteristic use cases**
 - Enterprise documentation.
 - Project spaces.
 - Meeting notes and cross-functional knowledge sharing.
 - Regulated orgs that need access control and audit trails. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
 **Userbase estimate**
 - Very large enterprise footprint, plausibly **millions of users** across customers, but exact counts are not public. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
 ## C2
 C2 is historically important because it sits close to the origin story of wiki culture and especially “wiki engine as a social process,” not merely software. It is less a mainstream product choice today and more a foundational technical-cultural reference point. [wiki.c2](https://wiki.c2.com/?WikiEngines)
 **USPs**
 - Foundational wiki culture.
 - Minimalist and historically influential.
 - Strong association with Ward Cunningham’s original ideas. [wiki.c2](https://wiki.c2.com/?WikiEngines)
 **Strengths**
 - Very important conceptually.
 - Captures the original wiki ethos.
 - Useful as a reference model for design thinking. [c2](http://c2.com/cgi/wiki?TopTenWikiEngines)
 **Weaknesses**
 - Not a modern enterprise product.
 - Limited contemporary ecosystem.
 - Not typically chosen for new production deployments. [wiki.c2](https://wiki.c2.com/?WikiEngines)
 **Characteristic use cases**
 - Early collaborative documentation.
 - Idea exploration.
 - Community knowledge sharing.
 - Historical origin of wiki practice. [c2](http://c2.com/cgi/wiki?TopTenWikiEngines)
 **Userbase estimate**
 - Modern active userbase is likely **very small**, mostly historical and enthusiast usage. [wiki.c2](https://wiki.c2.com/?WikiEngines)
 ## Federated Wiki
 Federated Wiki is one of the most intellectually interesting designs because Ward Cunningham pushed the idea beyond a central shared wiki toward a network of interoperating personal sites. It is a reaction against the assumptions of centralized knowledge ownership. [wiki.c2](https://wiki.c2.com/?WikiEngines)
 **USPs**
 - Federated, distributed model.
 - Personal control with sharing across sites.
 - Strong conceptual innovation. [wiki.c2](https://wiki.c2.com/?WikiEngines)
 **Strengths**
 - Excellent for decentralization-minded users.
 - Encourages personal ownership of notes and pages.
 - Very distinctive architecture. [wiki.c2](https://wiki.c2.com/?WikiEngines)
 **Weaknesses**
 - Smaller ecosystem.
 - Less mainstream operational tooling.
 - Can be harder for teams expecting centralized permissions and governance. [wiki.c2](https://wiki.c2.com/?WikiEngines)
 **Characteristic use cases**
 - Personal knowledge networks.
 - Distributed collaboration.
 - Experimental knowledge sharing.
 - Communities interested in networked authorship. [wiki.c2](https://wiki.c2.com/?WikiEngines)
 **Userbase estimate**
 - Probably **small niche adoption**, more influential than widely deployed. [wiki.c2](https://wiki.c2.com/?WikiEngines)
 ## TiddlyWiki
 TiddlyWiki is already covered above as one of the core additions, but it deserves emphasis: it is the most “personal-computing” oriented wiki in this list. Its architecture is a big reason it remains technically admired. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
 **USPs**
 - Portable single-file personal wiki.
 - Deep customization.
 - Offline-friendly. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
 **Strengths**
 - Great for individual workflows.
 - Easy to archive and transport.
 - Powerful for note structuring and metadata. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
 **Weaknesses**
 - Not a natural fit for large teams.
 - Sync/conflict handling is user-managed.
 - Can be too freeform for rigid organizations. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
 **Characteristic use cases**
 - Zettelkasten-like note systems.
 - Research and personal PKM.
 - Portable offline notes.
 - Solo technical planning. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
 **Userbase estimate**
 - Niche but durable: **tens of thousands to low hundreds of thousands**. [wikiwand](https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software)
 ## Fossil
 Fossil is technically interesting because it bundles version control, bug tracking, and wiki/documentation into one system. Its wiki is part of a developer workflow, not a standalone knowledge product. [en.wikipedia](https://en.wikipedia.org/wiki/Fossil_(software))
 **USPs**
 - Integrated VCS, issue tracker, and wiki.
 - Single-tool developer workflow.
 - Simple, self-contained project hosting. [en.wikipedia](https://en.wikipedia.org/wiki/Fossil_(software))
 **Strengths**
 - Excellent for small to medium software projects.
 - Tight coupling between code, tickets, and docs.
 - Strong for maintaining project history. [en.wikipedia](https://en.wikipedia.org/wiki/Fossil_(software))
 **Weaknesses**
 - Not a general-purpose wiki platform.
 - Smaller ecosystem than GitHub/GitLab-style stacks.
 - More dev-centric than business-user-centric. [en.wikipedia](https://en.wikipedia.org/wiki/Fossil_(software))
 **Characteristic use cases**
 - Software project documentation.
 - Developer-run issue tracking and wiki pages.
 - Integrated team repositories.
 - Small tooling-centric open-source projects. [en.wikipedia](https://en.wikipedia.org/wiki/Fossil_(software))
 **Userbase estimate**
 - Likely **tens of thousands of users**, mostly among developers and small project teams. [en.wikipedia](https://en.wikipedia.org/wiki/Fossil_(software))
 ## Tcl wiki option
 The Tcl ecosystem does have a wiki presence, but the result I found is mainly **Tcler's Wiki**, which is a wiki for the Tcl community rather than clear evidence of a widely used Tcl-native standalone engine. So I would not confidently label it as a major separate engine without more evidence. [wiki.tcl-lang](https://wiki.tcl-lang.org/page/Fossil)
 **USPs**
 - Community knowledge base for Tcl.
 - Demonstrates Tcl community use of wiki patterns. [wiki.tcl-lang](https://wiki.tcl-lang.org/page/Fossil)
 **Strengths**
 - Niche relevance for Tcl users.
 - Good example of a community-maintained knowledge base. [wiki.tcl-lang](https://wiki.tcl-lang.org/page/Fossil)
 **Weaknesses**
 - Not clearly a mainstream, distinct wiki engine product.
 - Limited evidence of broad adoption beyond the Tcl community. [wiki.tcl-lang](https://wiki.tcl-lang.org/page/Fossil)
 **Characteristic use cases**
 - Tcl community documentation.
 - Shared project knowledge.
 - Language-specific community support. [wiki.tcl-lang](https://wiki.tcl-lang.org/page/Fossil)
 **Userbase estimate**
 - Very small, niche community usage. [wiki.tcl-lang](https://wiki.tcl-lang.org/page/Fossil)
 ## What stands out most
 If you want the most technically distinctive group, I’d rank them this way: **Federated Wiki** for distributed architecture, **TiddlyWiki** for single-file personal knowledge, **Semantic MediaWiki** for queryable structure, **Fossil** for integrated dev workflow, and **Foswiki/TWiki** for enterprise wiki-as-application platforms. [en.wikipedia](https://en.wikipedia.org/wiki/Foswiki)
 The older engines are still interesting because they reflect different answers to the same design question: should a wiki be a simple page editor, a structured app platform, or a knowledge graph with a browser front end? [c2](http://c2.com/cgi/wiki?TopTenWikiEngines)
 # Possible Follow Ups
 - How do the underlying data architectures of these wiki engines impact long-term knowledge curation and data longeevity?
 - How does TiddlyWiki manage non-linear storage in a single file?
 - How do Semantic MediaWiki graph capabilities compare to modern graph DBs?
 - What architectural challenges led to the creation of Federated Wiki?
 - How does Fossil provide version control and wiki in one binary?
--- a/research/260608-wikiengines-overview/README.md
+++ b/research/260608-wikiengines-overview/README.md
@@ -0,0 +1,32 @@
 # 260608 — Wiki engines overview (landscape scan)
 Date: 2026-06-08
 ## What this is
 A breadth-first **landscape scan of notable wiki engines** — Wiki.js, XWiki,
 MediaWiki, Semantic MediaWiki, DokuWiki, TiddlyWiki, TWiki, Foswiki, Confluence,
 C2, Federated Wiki, Fossil — captured to understand the design space
 `shard-wiki` orchestrates over (and deliberately does **not** re-implement).
 Complements the deeper-dive research:
 - `research/260608-c2-wiki-origins/` — pre-federation wiki culture
 - `research/260608-federation-concepts/` — Federated Wiki, git/AP federation models
 - `research/260608-yawex-prior-art/` — the specific Perl engine being superseded
 Focus: what each engine is *for*, its storage/permission model, and what its
 existence implies for shard-wiki's **adapter contract** — not engine selection.
 ## Contents
 | Path | Role |
 |------|------|
 | `findings.md` | Synthesis: storage/permission axes, shard-wiki mapping, adapter implications, open questions |
 | `260608-perplexity-wikiengines-research.md` | Raw source dump (Perplexity), kept as provenance |
 ## Status
 Initial scan complete. Reinforces the INTENT stance that shard-wiki is an
 **orchestrator, not an engine**: the heterogeneity below is the problem space,
 not a menu to pick from. Adapter-contract implications feed
 `workplans/SHARD-WP-0002-federation-architecture.md`.
--- a/research/260608-wikiengines-overview/findings.md
+++ b/research/260608-wikiengines-overview/findings.md
@@ -0,0 +1,147 @@
 # Findings — Wiki engine landscape and what it implies for shard-wiki
 Date: 2026-06-08 · Status: research draft
 Scope: a breadth-first scan of notable wiki engines, read through one question —
 **what does this engine's storage and permission model demand of a shard adapter,
 and what must shard-wiki therefore NOT assume is uniform?** This is landscape, not
 selection: shard-wiki orchestrates over these, it does not pick one.
 **Complements:** `research/260608-federation-concepts/` (federation mechanics) and
 `research/260608-c2-wiki-origins/` (origin culture). Raw source kept alongside as
 `260608-perplexity-wikiengines-research.md`.
 ---
 ## 1. The engines, by what they actually are
 The "wiki" label spans at least four distinct system shapes. Conflating them is
 exactly the mistake shard-wiki's adapter contract exists to prevent.
 | Shape | Engines | Storage | Permission model | Page format |
 |-------|---------|---------|------------------|-------------|
 | **Simple page editor** | C2 (origin), DokuWiki | flat files (DokuWiki: no DB) | open / htaccess / ACL plugin | wiki markup |
 | **App platform** | XWiki, TWiki, Foswiki | DB + structured objects | fine-grained, per-space, forms/workflow | macro markup |
 | **Internet-scale collaborative** | MediaWiki, Semantic MediaWiki | DB + revision tables | role/group, extension-driven | wikitext (+ semantic annotations) |
 | **Personal / single-file** | TiddlyWiki, (Obsidian) | one HTML file / local vault | user-managed, not multi-user | tiddlers / Markdown |
 | **Federated / distributed** | Federated Wiki, Fossil, ikiwiki | per-site JSON / repo | per-site sovereignty / VCS auth | JSON story+journal / files |
 | **Commercial benchmark** | Confluence | proprietary store | mature enterprise ACL + SSO | proprietary |
 The same word, six storage substrates and at least five permission philosophies.
 ## 2. The two axes that matter for orchestration
 Stripping the marketing, engines differ on two axes shard-wiki must model
 explicitly rather than flatten:
 1. **Storage substrate** — flat files (DokuWiki, Fossil), single file (TiddlyWiki),
   relational DB + revision tables (MediaWiki, XWiki, Confluence), per-site JSON
   journals (Federated Wiki), git repo (Fossil, ikiwiki, Gitea wikis).
 2. **Permission philosophy** — open-by-default (C2), file/htaccess gating
   (DokuWiki, yawex), per-space/per-page enterprise ACL (Foswiki, XWiki,
   Confluence), VCS-level auth (Fossil), or *none / user-managed* (TiddlyWiki).
 These map directly onto two INTENT concepts:
 - Storage substrate → the **shard adapter contract** must not assume one backend.
 - Permission philosophy → validates the **L0→L4 access ladder**: real engines
  already span "open C2" to "enterprise ACL + SSO". shard-wiki's ladder is not
  invented; it's the union of where these engines actually sit.
 ## 3. Capability heterogeneity (why "capability-aware" is non-negotiable)
 The scan concretely demonstrates the INTENT principle *capability-aware adapters*:
 | Operation | Always available? | Counter-example |
 |-----------|-------------------|-----------------|
 | Read | ~yes | Confluence behind SSO: not without auth |
 | Write | no | C2 today is read-only/archival; MediaWiki dumps are read-only |
 | Structured diff/merge | no | DB-backed engines expose revisions but not git-style 3-way merge |
 | Semantic query | rarely | only Semantic MediaWiki / XWiki |
 | Single-file atomicity | special | TiddlyWiki is whole-file, not per-page, writes |
 | Native VCS history | sometimes | Fossil/ikiwiki yes; Confluence no (internal only) |
 No adapter can assume a peer supports its own operation set — the capability
 profile per shard is load-bearing, not decorative.
 ## 4. Mapping to shard-wiki INTENT (compare, do not equate)
 ### 4.1 Reinforcements (engines confirm an INTENT stance)
 | Observation | INTENT principle confirmed |
 |-------------|----------------------------|
 | Six storage substrates under one word | Markdown-first, **backend-neutral**; adapter contract |
 | Permission philosophies span open→enterprise | **Open by default, progressively governed** (L0→L4) |
 | DB engines expose revisions but not portable history | **Git-addressable coordination** adds the missing portable journal |
 | TiddlyWiki/Obsidian = sovereign personal stores | **Local-first usefulness**; shards, not replacements |
 | Federated Wiki = union composed from many origins | **Union without erasure** |
 | Confluence/Foswiki = mature ACL but lock-in | shard-wiki **delegates** IAM, never owns identity |
 ### 4.2 Deliberate divergences (design bugs if conflated)
 | Engine assumption | shard-wiki correction |
 |-------------------|----------------------|
 | "Pick the one engine for your team" | shard-wiki attaches *many* as shards; not a single choice |
 | App-platform macros define the page | **Markdown-first**; engine-specific render stays out of core |
 | Permissions live in the engine's DB | **Authorization in core**, identity delegated — uniform across shards |
 | History = the engine's revision table | **Coordination journal** is space-level, git-backed, portable |
 | Federation = everyone runs the same engine | Adapter contract spans heterogeneous, non-git, capability-limited backends |
 ### 4.3 What the landscape teaches that shard-wiki should not lose
 1. **Don't homogenize** — the heterogeneity is the user's reality, not a defect to fix.
 2. **Openness and governance are a spectrum, not a toggle** — engines live at every
   point C2→Confluence; the ladder must too.
 3. **Structured/semantic pages exist** (Semantic MediaWiki, XWiki) — Markdown-first
   must degrade gracefully when a shard carries structure shard-wiki can't model yet.
 4. **Single-file/whole-vault write granularity** (TiddlyWiki) breaks per-page write
   assumptions — the capability profile must express write granularity.
 ## 5. Implications for the adapter contract (carry to SHARD-WP-0002)
 1. **Capability profile must encode write granularity** (per-page vs whole-file vs
   whole-space) — TiddlyWiki and DB engines differ here.
 2. **History portability is an adapter concern** — engines with internal-only
   revisions (Confluence, MediaWiki) need the coordination journal to supply the
   git-addressable layer they lack.
 3. **Structured/semantic payloads need a passthrough/provenance escape hatch** so
   Semantic MediaWiki / XWiki content isn't silently flattened to lossy Markdown.
 4. **Permission model is never trusted from the shard** — even engines with rich
   internal ACLs are authorized through shard-wiki's core, not their DB.
 ## 6. Open questions (for spec / workplans)
 1. How does shard-wiki represent **structured/semantic** pages (Semantic MediaWiki,
   XWiki objects) — lossy Markdown projection, sidecar metadata, or opaque blob?
 2. **Write granularity** in the capability profile — what's the vocabulary
   (per-page / per-file / per-space / append-only)?
 3. For engines with **internal-only history** (Confluence), is the git coordination
   journal authoritative, or a mirror with reconciliation back?
 4. Which of these engines get **first-class adapters** vs are reachable only via a
   generic file/WebDAV adapter?
 ## 7. Sources
 | Source | URL |
 |--------|-----|
 | Perplexity — wiki engines scan (raw, this dir) | `260608-perplexity-wikiengines-research.md` |
 | C2 — Top Ten Wiki Engines | http://c2.com/cgi/wiki?TopTenWikiEngines |
 | C2 — WikiEngines | https://wiki.c2.com/?WikiEngines |
 | Comparison of wiki software | https://www.wikiwand.com/en/articles/Comparison%20of%20wiki%20software |
 | WikiMatrix engine comparison | https://www.wikimatrix.org/ |
 | Wiki.js | https://js.wiki |
 | Foswiki | https://en.wikipedia.org/wiki/Foswiki |
 | Fossil (software) | https://en.wikipedia.org/wiki/Fossil_(software) |
 | shard-wiki — federation concepts | `research/260608-federation-concepts/findings.md` |
 | shard-wiki — INTENT | `INTENT.md` |
 ---
 ## 8. Traceability
 | This document section | Informs (future) |
 |-----------------------|------------------|
 | §2 two axes | Access ladder (INTENT) + adapter contract guardrails |
 | §3 capability heterogeneity | Adapter capability profile design |
 | §4 INTENT mapping | Architecture blueprint guardrails |
 | §5 adapter implications | `workplans/SHARD-WP-0002-federation-architecture.md` |
 | §6 open questions | spec — page model for structured/semantic content |