Wikantik is a Semantic Agentic Wiki explicitly designed as a high-signal research substrate where humans and AI agents collaborate seamlessly to build, maintain, and verify a dense knowledge base. It represents a fundamental evolution from traditional wiki software, transforming passive, human-only documentation silos into a machine-readable, programmatically-accessible "Long-Term Memory" engine specifically tuned for Large Language Model (LLM) systems.
In the modern enterprise, standard knowledge management tools fail because they treat text as inert strings. Wikantik treats knowledge as an active graph, combining the historical reliability of a versioned file system with the bleeding-edge capabilities of semantic vector search and the Model Context Protocol (MCP). The result is a self-healing, agent-curated, and human-verified repository that effectively eliminates the "LLM Slop" hallucination problem by grounding generative AI in a mathematically verifiable context.
Building internal knowledge bases the traditional way is prohibitively expensive and highly inefficient. A mid-sized enterprise might easily spend upwards of $1.2M annually on knowledge management silos, duplicated research, and lost productivity due to unsearchable documentation. Furthermore, attempting to retrofit standard documentation systems for modern AI workflows introduces immense infrastructure costs.
Naive Retrieval-Augmented Generation (RAG) setups that rely on massive, unoptimized standalone vector databases often generate continuous cloud overhead, costing organizations between $50K and $150K per year purely in infrastructure and API transit costs, let alone engineering time. By utilizing a highly optimized, single-tenant hybrid retrieval model integrated directly alongside the data store—and by enforcing optimistic concurrency over complex locking mechanisms—Wikantik drastically reduces these operational costs. Enterprises can deploy an agent-grade memory substrate for under $15K per year in operational expenditure, while providing vastly superior signal-to-noise ratios and enabling deterministic auditing of every agent action.
The primary mission of Wikantik is to solve the catastrophic "LLM Slop" problem through a rigorous, tiered research and curation model. The system does not assume that AI output is inherently correct; rather, it uses agents for scale and humans for precision.
Consider a research team at a pharmaceutical company utilizing Wikantik to ingest and synthesize clinical trial data. Instead of human researchers spending weeks reading thousands of trial reports, an orchestrated fleet of agents ingests the PDFs, extracts the core methodologies and outcomes, and drafts hundreds of structured Wikantik pages. The agents link adverse effects to chemical compounds within the knowledge graph. The human researchers then review these synthesized pages, correcting any hallucinations and applying the "Verified" stamp. The company saves tens of thousands of dollars in research time and maintains a mathematically precise, agent-queryable database of clinical outcomes.
At its core, Wikantik relies on a highly sophisticated hybrid retrieval engine that combines the exact-match precision of Lexical Search with the contextual understanding of Semantic Search.
For lexical matching, Wikantik utilizes Apache Lucene implementing the standard Okapi BM25 algorithm. BM25 is highly effective for keyword-heavy queries (e.g., searching for a specific product ID or exact chemical name). The BM25 scoring function for a document D and a query Q (containing terms q_i) is defined as:
Where:
For semantic matching, Wikantik uses dense vector embeddings stored via pgvector. Text chunks are embedded into a high-dimensional space (e.g., d=768 or d=1536), and relevance is calculated using Cosine Similarity:
To yield the best possible retrieval for the AI agents, Wikantik merges these two scores using a normalized hybrid scoring function or Reciprocal Rank Fusion (RRF). If using a convex combination, the final relevance score is:
This ensures that an agent querying for "How do I configure the $50K caching tier?" will find the exact page mentioning the exact price and the exact term "caching tier," even if it uses synonymous phrasing in its request.
Wikantik is built on a modern Java 25 / Jakarta EE 10 stack, prioritizing decoupled, provider-based architecture. However, its most powerful architectural feature is its native support for the Model Context Protocol (MCP).
MCP acts as a universal "USB-C port" for AI integration, allowing standard agents to interact with the wiki without needing fragile, custom web scrapers. Wikantik exposes two primary MCP surfaces:
/knowledge-mcp (The Retrieval Surface)Optimized strictly for read-only retrieval and knowledge graph traversal.
retrieve_context — Executes the hybrid BM25 + Semantic search math described above.get_page_by_id — Stable, immutable retrieval using the Canonical ULID.traverse — Allows agents to walk the Knowledge Graph (nodes and edges) to discover related entities programmatically.discover_schema — Introspects the LLM-extracted relationship types dynamically./wikantik-admin-mcp (The Write Surface)The authoritative management interface for content mutation.
update_page — Enables agents to edit pages safely using Optimistic Concurrency (via expectedContentHash). If a human and an agent edit simultaneously, the system prevents silent overwrites.write_pages — Batch-creates articles with strict schema validation against the Structural Spine.propose_knowledge — Agents can propose new Graph edges (e.g., Compound_X -> TREATS -> Disease_Y) for human approval.mark_page_verified — Allows elevated agents to stamp content under specific, programmatic conditions.An organization can deploy a scheduled background agent that wakes up nightly, connects via MCP, and audits the entire wiki for broken links, stale data, or policy compliance. If the agent finds an outdated API endpoint, it uses update_page to submit a corrected draft. The company effectively gains an indefatigable, zero-cost janitor that ensures the knowledge base never rots, saving thousands of dollars in maintenance overhead.
Content in Wikantik is fiercely guarded by the Structural Spine. A page is not merely a string of text; it is a node in a structured graph. The required YAML frontmatter dictates taxonomy, access control, and edge relations.
A critical component of this semantic integrity is the Vector Centroid Engine. When a large article is ingested, it is chunked into smaller paragraphs, and each chunk is embedded into vector space (v_i). To represent the entire document for macro-level clustering without losing granularity, Wikantik computes the geometric centroid of the document's chunks:
This centroid vector V_{\text{centroid}} represents the "average semantic meaning" of the entire page. By comparing the centroids of different pages, Wikantik can automatically generate highly accurate "Similar Pages" recommendations, entirely bypassing the need for humans to manually curate related links.
While Wikantik represents the bleeding edge of agent-first systems, it is deeply rooted in the pragmatic, battle-tested heritage of Apache JSPWiki. It retains the robust security and extensibility patterns that made JSPWiki a staple of the enterprise Java ecosystem for over two decades.
Wikantik is more than just a wiki; it is a collaborative workspace where human intuition and agentic scale meet. By enforcing strict structural contracts, leveraging advanced hybrid retrieval mathematics, and exposing native MCP endpoints, Wikantik transforms disparate, rotting documentation into a living, verifiable, and highly lucrative organizational asset. It is the definitive knowledge engine for the AI era.