Knowledge wiki leapfrog architecture

app-mediakit-knowledge is the PointSav knowledge platform engine, a Rust binary that serves three wiki instances — documentation.pointsav.com, projects.woodfinegroup.com, and corporate.woodfinegroup.com — from flat Markdown files stored in git repositories. The engine renders content with Wikipedia-shaped chrome: sticky table of contents, wikilink resolution with red-link signalling, category pages, edit history, and full-text search. A reader comparing this wiki to Wikipedia feature-by-feature will find most of the reading experience already matches — the two clearly missing pieces are the infobox and the navbox, the two highest-impact elements of Wikipedia's visual muscle memory. A planned multi-sprint roadmap is intended to close that gap before adding a Leapfrog 2030 differentiation layer that goes beyond what Wikipedia offers.

Why it matters: a reader arrives already knowing how to use this wiki, because the reading and editing patterns are the ones two decades of Wikipedia use have already taught them.

Why Topics, not pages

The engine's Wikipedia-shaped chrome serves a specific content model: an article is a Topic — a self-contained unit with its own table of contents — not a page in a larger document, and not an email thread. Reaching for a wiki at all is a response to a concrete, recognisable failure mode: distributing knowledge as a growing set of standalone documents, each updated ad hoc and re-sent to whoever asks, eventually collapses under its own volume. Every recipient ends up with a different, dated copy; nobody can tell which version is current without asking.

Three older library-science concepts describe what a Topic-based wiki restores. A library offers information services — someone or something that helps a reader find what they need, rather than a folder of files.¹ An encyclopedia divides knowledge into topics rather than chapters, each independently findable and cross-linked.² A repository adds version control and access discipline on top — a document's current state and its history are both first-class, not just its current state.³ A knowledge platform that is only one of the three is incomplete: a pure library with no topic structure sprawls; a pure encyclopedia with no version discipline loses its history; a pure repository with no topic structure is a file server with better auditing.

This is why the engine's baseline target is Wikipedia's reading and editing muscle memory specifically, rather than a generic content-management system: Wikipedia is the clearest existing example of a platform that is a library, an encyclopedia, and a repository at once, at a scale that proves the model holds.

Why it matters: a reader never has to ask "is this the current version, and is there a better copy somewhere else" — every Topic has exactly one home, one history, and one answer to "what does this say right now."

Why not port MediaWiki

MediaWiki is the software that runs Wikipedia. Porting it to Rust would not serve the platform's goals.

MediaWiki was designed in 2003 for a PHP-and-MySQL stack. Its parser — the component that converts wikitext into HTML — was described by its original author Tim Starling as "a huge pile of regular expressions."⁴ The Parsoid project, MediaWiki's attempt to replace that parser with a clean bidirectional HTML↔wikitext converter, took ten years to ship and is still completing its rollout as of 2025.⁵

The wikitext template system is the core of MediaWiki's content richness — infoboxes, navboxes, citation templates, and geographic coordinate templates are all implemented as wiki pages in the Template: namespace, processed by a recursive macro expansion interpreter that calls back into the database during parsing. This design couples the parser to the database, complicates caching, and makes the system difficult to run without MySQL.

Same reader experience, different stack

The architectural goal of app-mediakit-knowledge is not to replicate this design but to achieve the same reader experience through a fundamentally different stack. The content format is Markdown with YAML frontmatter, not wikitext. Version control is git, not a MySQL revision table. The search backend is Tantivy — embedded, zero operational overhead — not an Elasticsearch-backed cluster. Template transclusion is replaced by six native block types that cover approximately 95 percent of what templates are actually used for on Wikipedia.⁶

Why it matters: the reader gets the same familiar page; the operator gets a system that runs as one binary with no database server, no PHP runtime, and no separate search cluster to keep alive.

MediaWiki architecture, understood

MediaWiki's namespace system defines 30 namespaces in two axes: subject pages (Article, User, File, Template, Category, Help, Module, Draft) paired with Talk pages. Special pages form a separate class of software-generated pages with no talk equivalent.

The Vector 2022 skin divides every page into: a sticky header (logo, search, language switcher, personal tools), a left sidebar (navigation menu and table of contents), an article header (namespace tabs, view tabs, title, short description, hatnotes), the article body (infobox floated right, body text, tables, images, footnote superscripts), an appendix (See also, References, External links), navboxes, category strip, and a footer (last-edited timestamp, licence, legal links).⁶

Cite extension and reader muscle memory

The Cite extension handles footnotes: <ref>citation text</ref> in the article body inserts a numbered superscript; <references/> at the section bottom renders the numbered list. Reference Tooltips — a JavaScript gadget — shows citation text on hover without requiring the reader to scroll.⁷

These elements constitute the muscle memory that Wikipedia readers have developed over two decades. A wiki missing the infobox, the sticky TOC, the [1][2][3] footnote superscripts, or the navboxes does not feel like Wikipedia regardless of how good its content is.

Why it matters: these are the specific, nameable elements a reader unconsciously checks for — closing this exact list, not a vague "make it feel more like Wikipedia," is what actually closes the gap.

Current feature state

As of May 2026, app-mediakit-knowledge implements approximately 78 percent of the full Wikipedia muscle-memory surface. The following elements are fully operational:

Wikilinks with blue/red distinction (existing articles link blue; missing articles link red)
Sticky collapsible table of contents, Vector 2022 pattern
Read / Edit / View History tabs and per-section edit pencils
Article/Talk tabs (Article tab functional; Talk tab is a functional stub)
Full-text search via Tantivy BM25
Edit history, blame, and unified diff via git
CodeMirror 6 editor with citation autocomplete and SAA squiggle linting
Quality badges (complete / core / stub) and stub notice
Category pages and category strip at article bottom
Home page with 3×3 category grid, featured article pin, and leapfrog facts panel
Atom 1.0 and JSON Feed 1.1 syndication
Hover card page previews
Glossary auto-linker with tooltips
Authentication and edit review queue (Phase 5)
Read-only git remote (smart-HTTP protocol)
MCP server (JSON-RPC 2.0) for agent integration
Notify-based incremental search reindex (no restart required on file changes)
Mobile hamburger navigation

Why it matters: a reader today already gets working search, working edit history, and working category navigation — the remaining gap is specific and named below, not a sign the whole engine is unfinished.

Missing elements ranked by impact

The following elements are stubbed or absent today, ranked by muscle-memory impact:

Missing feature	Impact	Notes
Infobox (structured right-column summary)	9/10	Most recognisable Wikipedia element; absent entirely
Navbox (bottom navigation template)	8/10	Creates topic clusters; absent entirely
Citation `[1][2][3]` CSS rendering	8/10	Footnotes parse correctly; CSS unstyled
Citation hover tooltip	8/10	JavaScript gadget not yet written
Two-column word-level diff	7/10	Unified diff exists; two-column Wikipedia style absent
Talk/Discussion pages	7/10	Tab renders as disabled; no backend
Redirects	6/10	No `redirect_to` frontmatter processing
Disambiguation pages	6/10	No page type flag or chrome
Special:RecentChanges	6/10	Git log data exists; HTML page absent
Special:AllPages	5/10	Article list endpoint absent
`/random` article	5/10	Absent
Edit summary field	5/10	Git commit message populated from author and time only
Definition lists	4/10	comrak extension disabled; one-line fix

Why it matters: ranking the gaps by impact rather than listing them alphabetically tells a reader exactly which two elements — the infobox and the navbox — would move the needle most, rather than leaving them to guess which of thirteen items to care about.

The native block types approach

Rather than implementing a wikitext macro expansion engine, app-mediakit-knowledge is designed to use six native block types as fenced code blocks parsed during the comrak AST walk. These are intended to cover the vast majority of what Wikipedia templates are actually used for.

Infobox — a YAML-body fenced block intended to render as a <table class="infobox"> floated at the right margin of the article. The author writes:

```infobox
name: PointSav Digital Systems
founded: 2024
jurisdiction: British Columbia, Canada
sector: Enterprise software
```

The engine walks the comrak AST, matches CodeBlock nodes with info = "infobox", parses the YAML body, and replaces the node with an HtmlInline table. No template database, no macro expansion, no Lua interpreter.

Navbox — a similar fenced block intended to render a collapsible horizontal table at the article bottom, grouping related article links under a shared title. JavaScript collapses navboxes when two or more appear on the same page, matching Wikipedia's autocollapse behaviour.

Cite block — inline citation syntax ([^id] with [^id]: text at article bottom) that the comrak footnotes extension already parses. The remaining work is CSS styling matching [1][2][3] superscript form and a JavaScript hover tooltip.⁷ The citations.yaml registry used by the editor's autocomplete system extends naturally into citation rendering.

comrak upgrade path

The comrak upgrade this design depends on has already happened — the engine has run comrak 0.52 since before this article was last checked.⁸ That version adds the block_directive extension (:::infobox, :::navbox syntax), cleaner than fenced code blocks for multi-line Markdown content inside the block body. The upgrade itself was the easy part; the infobox and navbox rendering code that would use it has not been written yet. Having the newer comrak version in place removes one prerequisite for building these block types — it does not mean they are built.

Why it matters: no template database, macro interpreter, or Lua sandbox has to be built or operated to get the infobox and navbox on screen — the remaining work is rendering code against an author-friendly YAML block, not a new subsystem.

The Leapfrog 2030 layer

Wikipedia muscle memory is the floor, not the ceiling. Once app-mediakit-knowledge achieves full Wikipedia parity, three planned first-class primitives are intended to distinguish it from incumbent alternatives.

Citation Authority Ribbon — a planned per-article visual indicator of source verification status. Inline citations resolved against citations.yaml are intended to display a coloured ribbon: green for verified, amber for unverified, red for contested. Wikipedia has no equivalent; all citations are treated as equally reliable regardless of their actual verification state.

Research Trail Footer — every article declares five frontmatter fields (research method, depth, confidence, date, limitations) intended to be rendered as a collapsible footer section. This would make the provenance of every claim visible to readers, supporting NI 51-102 continuous-disclosure obligations for regulated issuers. Wikipedia has talk-page archives and edit history but no structured research provenance at the article level.

AI-integrated editor — the CodeMirror 6 editor includes a three-keystroke ladder: Tab (complete the current sentence), Ctrl+K (ask a question about the content), Alt+J (insert a citation). These affordances are planned to call app-orchestration-command via the Doorman proxy. They are currently stubbed as 501 endpoints, pending service-slm operationalisation. When activated, they are intended to provide author assistance that traditional wiki editing surfaces do not offer.

BCSC squiggle linting — the editor currently enforces seven deterministic SAA rules via coloured underlines. The planned complete set includes forward-looking statement detection, Do-Not-Use vocabulary flagging, Sovereign Data Foundation current-tense detection, competitive comparison flagging, and citation-required prompts. This is built into the editing surface rather than applied as a post-publication compliance check.

Why it matters: these three primitives are what the platform is intended to offer that no incumbent wiki does — Wikipedia parity closes the gap with existing readers' expectations, and this layer is meant to be the reason to choose this platform over an equally Wikipedia-shaped alternative.

Mobile-first and progressive enhancement

The wiki is designed mobile-first: the layout, navigation, and table of contents render correctly and usably at a 375 px viewport before any progressive enhancement for wider screens. Desktop users receive the full sidebar-plus-content layout as an enhancement; mobile users receive the complete reading and editing experience without a stripped-down alternative.

Touch targets and mobile parity

Touch target discipline follows WCAG 2.2 Success Criterion 2.5.8: all interactive elements — TOC entries, edit pencils, navigation links, toggle buttons — carry a minimum 44 px × 44 px touch target. Interactions do not rely on hover states; every feature accessible by hovering is equally accessible by tapping. Safe-area padding (env(safe-area-inset-*)) is applied to the shell chrome to accommodate notched and dynamic-island displays.

The muscle-memory goal extends to mobile. The Wikipedia app's navigation patterns inform the mobile layout — back-to-top, swipe-between-categories, bottom-rail search — not a stripped-down "mobile version" that reads like a fallback. This is the same leapfrog principle applied to form factor: reach full Wikipedia mobile parity first, then add the differentiation layer.

Why it matters: a reader on a phone gets the same complete reading and editing experience as a reader at a desk — mobile is never the degraded option.

Structural positioning

Incumbent wiki platforms built on hierarchical organisation models — books, chapters, spaces, folders — break the flat hyperlink graph that makes Wikipedia useful. A hierarchical wiki creates knowledge silos; a flat wiki with a category DAG creates a knowledge commons.

Platforms that impose hierarchical organisation typically lack redlinks (the signal that a page is missing and should be created), backlinks, navboxes, and the full Special pages framework. Several lack talk pages entirely.

app-mediakit-knowledge is designed as a Rust-native, git-backed, flat-file wiki engine targeting full Wikipedia muscle memory for regulated SMBs operating under continuous-disclosure obligations.

Why it matters: a flat, category-linked wiki keeps every article one hop from its neighbours — a reader never has to guess which folder or space a topic was filed under to find it.

Navigate

Topics

Guides

Resources

PointSav network