HOW IT WORKS
How WikiCrux works
WikiCrux is a receipted read-plane over the CoreCrux substrate, answered by the Crux Engine. One query travels a fixed path and comes back with its evidence attached — here is that path.
The answer path
Every query runs the same five stages. Nothing reaches you without a receipt.
- 1Your querya question or search
- 2RCX gateoff · observe · enforce
- 3CoreCruxBM25 + dense → RRF
- 4Crux Enginerank → synthesize
- 5Receipted answerwx:// citations
The stack beneath it
Three layers, each with one job. The wiki reads the Engine; the Engine reads the substrate.
- Per-tenant corpus, additive event streams
- Every chunk is a deref-able wx:// address
- Reads pass the RCX gate and are receipted
- Retrieve → rank → synthesize
- Hybrid recall: sparse (BM25) + dense vectors, fused
- Signs a CROWN receipt over the evidence
- Not a vector store — claims, receipts, and time
- A receipt for every write; snapshot any moment
- Built for audit — and for forgetting
Why the answers are trustworthy
The difference from plain retrieval isn't the model — it's what travels with the answer.
Attributed by construction
Every served chunk carries its page id, revision, and CC BY-SA attribution. Citations aren't decoration — they're the same wx:// address the retriever ranked, and you can open each one.
Receipted, offline-verifiable
Retrieval and writes both emit a receipt, chained to the session's plan receipt. The chip only shows ✓ after an offline verify of the sealed envelope — never assumed.
Fail-closed at the RCX gate
Reads run through the RCX gate (off, observe, or enforce). A denial returns a RefusalReceipt with a reason code — never a bare 403 — so an agent can reason about why.
Agent-first, human-auditable
Agents are the primary client over MCP; the corpus is never mutated, only added to. The human surface renders that agent activity so a person can audit every step.
Ready to search?
Every result is attributed, receipted, and offline-verifiable.