Liminal Wiki

The problem

Wikis rarely become stale because people cannot write. They become stale because maintenance is endless: finding the canonical page, preserving links, adding evidence, reconciling newer information, handling concurrent changes, and keeping history intact. This burden is especially costly for small research, product, policy, and engineering teams whose knowledge must remain sourced, connected, and auditable.

Document chatbots can answer questions, but their result stays in a chat. AI features inside editors can draft prose, but people still have to maintain the source of truth. Visual browser agents can operate editing controls, but they must infer live state and may act outside the context a person intended.

What Liminal Wiki does

Liminal Wiki changes the primary interaction. The human-facing workspace is for reading and judgment, not direct page editing. A person opens the wiki, reads a page, and selects Request change. They describe what should be different instead of editing Markdown, moving files, repairing links, placing sources, or resolving a save conflict.

The Site turns that intent into a structured handoff containing the exact wiki and target, current version, permalink, request type, user instructions, and authorized scope. It does not copy the page body or create a second request database. The agent reads the live wiki through the tools of the open page.

The result lives in the wiki—not in another chat transcript. Applied changes appear in the same Documents and Explore topics views with stable page IDs, linked sources, claim-level evidence, immutable revisions, and an audit trail.

Why WebMCP is essential

The safe action depends on live product state: the active wiki, open page, signed-in role, current revision, evidence graph, and operational mode. Page-scoped WebMCP lets the Site expose precise, session-aware actions instead of making an agent scrape the DOM or use a separate automation identity.

Before writing, the agent reads the workspace context and operating contract, searches for an existing canonical page, and inspects relevant pages, links, claims, sources, and topic insight. Grounded research is first captured in an immutable plan. Application requires the same plan hash, a current version, and a retry-safe operation ID. Every server API independently rechecks the wiki boundary and permission.

What people and agents do together

People remain responsible for intent, judgment, and scope. Agents handle the maintenance work required to turn that intent into durable knowledge: search before creating, reuse stable IDs, connect exact evidence, preserve uncertainty, avoid stale writes, and record revisions. The agent stops when the target is ambiguous, a warning expands the impact, the version changes, or the evidence does not support the requested conclusion.

Complete product

Each signed-in account receives an isolated private wiki with persistent storage. The product includes multilingual reading and request interfaces, folder and topic exploration, full-text search, connections, evidence-backed insights, revisions, recoverable page deletion, roles and sharing, portable and full backups, operational read-only mode, and a separate recovery Site.

People directly manage membership, ownership, backups, operational settings, and wiki deletion. Authorized sessions may also expose wiki creation through WebMCP without granting membership or bypassing owner controls.

What was built during the challenge

The repository history begins during the challenge window. During that period we built the production Site and its page-scoped WebMCP integration, then redesigned the normal knowledge-change workflow around structured human requests. Challenge work includes session-aware tool registration, capability-based discovery, the Request change handoff, live context and policy inspection, search-before-create behavior, plan/apply workflows for grounded changes and topic insights, version and idempotency safeguards, provenance and revision verification, bounded observability, deployment, backup, and recovery. Third-party and adapted components are identified in the repository's provenance and notice files.