As a platform born from a rapid modernization of Apache JSPWiki, Wikantik has unique strengths but also carries genuine technical debt. This page provides a candid assessment of the system as of 2.0.x and where it must go next.
Agent-Centric Architecture: Wikantik ships two production MCP servers — /wikantik-admin-mcp (26 write/analytics tools) and /knowledge-mcp (19–20 read-only retrieval + ontology tools) — plus an OpenAPI 3.1 tool server at /tools/* for non-MCP clients. No other self-hosted wiki ships an agent surface at this depth.
Hybrid Retrieval: BM25 (Lucene) + dense vector (Lucene HNSW in-process or pgvector) fused via Reciprocal Rank Fusion (k=60), with fail-closed BM25 fallback when Ollama is unavailable. Section recall@12 improved from 0.60 to 0.74 after chunker heading-fidelity fixes and contextual document embeddings.
RAG-as-a-Service Context Bundle: GET /api/bundle?q= and the assemble_bundle MCP tool assemble ranked, de-duplicated, version-pinned-cited sections from the corpus. The wiki acts as a retrievable knowledge base for any agent — without answer synthesis (ADR-0001).
Structured Knowledge + Ontology: Frontmatter drives search, SEO, the Page Graph, and the Knowledge Graph. The wikantik: RDF/OWL ontology (9 entity + 5 content classes, 21 KG predicates) is queryable via public SPARQL at /sparql, dereferenceable IRIs at /id/{type}/{id}, and RDF dumps. A SHACL write-time gate enforces schema conformance on KG edges at both write chokepoints.
Apache 2.0 License: Unlike MediaWiki (GPLv2) and Wiki.js (AGPL), Wikantik lets organizations fork, embed, and relicense their derivatives without copyleft restrictions.
SCIM 2.0 Provisioning: IdP-driven user and group onboarding/offboarding at /scim/v2/*. Most competing self-hosted wikis lack SCIM support.
Performance: Measured at 480 RPS sustained (p95 1.25 s) on a 16-core host under a search-heavy workload; degrades gracefully under overload via BackpressureFilter (503 + Retry-After: 1).
wikantik-main is a God Module: It handles Markdown rendering, JAAS auth, hybrid search, entity extraction, the math parser, derived-page ingestion, and legacy page providers. Further decomposition is needed — e.g. extracting a wikantik-renderer module.
Metadata Maintenance Burden: The richness of the Knowledge Graph depends on frontmatter completeness. The structured frontmatter editor with live validation helps, but keeping large corpora fully tagged requires sustained curator effort or expensive extraction runs.
Single-Host Deployment Model: Production runs on a single Docker host (all services co-located). Horizontal app-tier scale requires splitting PostgreSQL first; there is no hosted/SaaS option.
KG Rerank Ceiling: Measured recall lift from Knowledge Graph-aware reranking was near zero (even with a strong KG), because section relevance is not well-predicted by entity-proximity in a co-mention graph. The reranker is left dormant (boost=0) — not removed, but not contributing.
Ollama Dependency for Extraction: LLM-based entity extraction requires a running Ollama instance (model gemma4-graph:12b). Extraction is an offline batch process (wikantik-extract-cli), so the wiki serves fine without it, but KG enrichment stalls if Ollama is absent.
wikantik-main: Move the rendering pipeline to wikantik-renderer and potentially split the auth providers. This would reduce the module's test surface and improve build times.| Capability | Wikantik | BookStack | Outline | Wiki.js | MediaWiki | Confluence | Notion |
|---|---|---|---|---|---|---|---|
| License | Apache 2.0 | MIT | BSL → Apache | AGPL | GPLv2 | Proprietary | Proprietary |
| Self-host | Yes | Yes | Yes | Yes | Yes | Yes (paid DC) | No |
| MCP servers for agents | 2 dedicated (admin + read-only) | No | No | No | No | No | No |
| OpenAPI tool surface | Yes (/tools/*) | No | No | No | No | No | No |
| Hybrid retrieval (BM25 + dense) | Yes — Lucene HNSW + pgvector + Ollama | No | No | No | No | Partial | Yes |
| SPARQL / RDF ontology | Yes — public /sparql + JSON-LD + dumps | No | No | No | Semantic MW (complex) | No | No |
| SCIM 2.0 provisioning | Yes | No | No | No | No | Yes | Yes |
| RAG context bundle | Yes — GET /api/bundle, assemble_bundle | No | No | No | No | No | No |
| LLM-extracted Knowledge Graph | Yes (with reviewer queue) | No | No | No | No | Partial | Partial |
| Page Graph viewer | Yes — Cytoscape, filterable | No | No | No | No | No | No |
| Markdown-native | Yes | Partial | Yes | Yes | No | No | No |
| Stack | Java 25 / Tomcat 11 / PostgreSQL + pgvector / React | PHP / Laravel | Node.js | Node.js | PHP | JVM | Proprietary |
Wikantik is the only project in this table that ships two production MCP servers plus an OpenAPI tool server as first-class, authenticated, documented surfaces — not plugins or afterthoughts. The retrieval stack was designed for hybrid BM25 + dense + KG from the outset, rather than retrofitted.
Compared to Confluence: Wikantik is open-source (Apache 2.0) and protocol-open (MCP, OpenAPI). Where Confluence locks AI integrations into Atlassian Intelligence, Wikantik works with any agent that speaks MCP or OpenAPI.
Compared to MediaWiki: Wikantik is modern-stack (Java 25, React, PostgreSQL) and developer-friendly. Semantic MediaWiki is a powerful but complex and fragile add-on; Wikantik's ontology is built in from the start.
Wikantik occupies a distinct niche: an open-source, self-hosted knowledge base that is genuinely agent-grade. Its main competitive risk is the single-maintainer development pace and the operational complexity of the stack (Tomcat + PostgreSQL + pgvector + Ollama). Its main strength is that no other self-hosted wiki today ships MCP servers, a public SPARQL ontology, a RAG context bundle endpoint, and SCIM provisioning as a coherent whole.