While Wikantik is a modern platform built for the agent era, its roots go back to one of the oldest Java-based wiki engines: Apache JSPWiki. Understanding this evolution explains several of the platform's architectural continuities and its unique hybrid nature.
In early 2026, the project began as a radical experiment to see if a legacy enterprise wiki could be transformed into an agentic knowledge base — a system where AI agents are first-class citizens alongside human editors.
The initial modernization was exceptionally compressed, taking place over two months. Key milestones:
/.policy_grants table, manageable via admin UI). JAAS-based SSO (OIDC + SAML via pac4j) was added.kg_* tables and pgvector-backed embeddings introduced the Knowledge Graph and hybrid search./wikantik-admin-mcp (26 write/analytics tools) and /knowledge-mcp (read-only retrieval).After the initial fork, the platform continued to grow substantially:
type: runbook pages, page verification metadata, the get_page_for_agent token-budgeted projection, and nightly retrieval-quality CI.canonical_id (rename-stable page identifiers), cluster: hub membership, and the list_clusters/list_tags/list_pages_by_filter structural query tools. The relations: frontmatter block was removed at this point — edges are now KG-extracted or wikilink-derived, not YAML-declared./scim/v2/* — IdP-driven user and group onboarding/offboarding.wikantik-ontology module added a queryable wikantik: T-Box (9 entity + 5 content classes, 21 KG predicates), a SHACL write-time gate, Postgres→RDF projectors, a public SPARQL endpoint at /sparql, dereferenceable IRIs at /id/{type}/{id}, and RDF dumps at /export/. SEO JSON-LD @type is now re-sourced from the ontology.GET /api/bundle?q=, assemble_bundle MCP tool) assembles ranked, de-duplicated, version-pinned-cited sections — the wiki acts as a knowledge base that any agent or pipeline can query for grounded retrieval, without answer synthesis. Derived pages (Apache Tika 3.3.0 ingest via POST /api/ingest) allow documents to be ingested and machine-reflowed from source attachments.Despite the overhaul, several JSPWiki components remain as load-bearing foundations:
VersioningFileProvider) still follow the provider interfaces established by JSPWiki, though these are now behind the PageProvider abstraction in wikantik-api.Plugin and PageFilter interfaces. Most have been modernized or replaced by agent-grade variants; the [{Plugin}]() syntax is auto-normalized for the Flexmark renderer.MarkdownRenderer) is Wikantik-built but retains the pre-JSPWiki-era plugin embedding model.Note: the jspwiki.* property key namespace was progressively renamed to wikantik.* during the rebrand. Modern deployments use wikantik-custom.properties with wikantik.* keys.
| Era | Primary User | Primary Goal | Storage |
|---|---|---|---|
| JSPWiki Era | Human editors | Documenting for humans | Files + XML |
| Wikantik Era | Humans + AI agents | Knowledge synthesis + agent retrieval | Files + PostgreSQL + pgvector + RDF |
JSPWiki provided a battle-tested core for page management, attachment handling, versioning, and basic wiki semantics. This allowed Wikantik to focus engineering energy on the high-value AI integration, hybrid retrieval, Knowledge Graph, and ontology layers rather than reinventing content management.
Today, Wikantik is effectively a "Ship of Theseus" — nearly every visible surface has been replaced, but the page provider foundations and Lucene core remain.