The engine

Crux Engine

The reasoning runtime at the heart of the platform. It turns a question into a fully receipted, evidence-backed answer (retrieve, rank, synthesize) and signs a CROWN receipt proving exactly how that answer was built.

Retrieval economics

Lanes, fusion, and a budget that is a wall

Each lane is a different way of remembering: exact words, meaning, relationships, people, time, structure. The engine runs them in parallel, and Adaptive Manifest Routing decides per query which lanes earn their tokens, learning from outcomes rather than knobs. The exit is a hard token_budget enforced server-side; metadata travels first, and content is admitted only when it pays for itself.

This is a measurable claim, not a philosophy: budgets return substantially fewer tokens than naive top-K stuffing on the same corpus at equivalent answer quality — the exact margin depends on corpus and query mix, so we point you at the methodology rather than a headline percentage, and the daemon's numbers are regression-gated in CI against pinned baselines.

query

"what did we decide about invoice rounding?"

token_budget=2000

lexicalfusedBM25-class, microseconds on CPU
densefusedsemantic similarity, BYOE or managed
graphfusedentity links walked at query time
entityskippedwho/what-keyed dossiers
eventskippedtime-anchored recall
navigationalfusedsummary-tree descent for huge corpora

AMR fusion

routes per query, learns from outcomes, no knobs

budget gate

1,940 / 2,000 tokens · server-enforced

Lanes that do not earn their tokens are skipped for that query, not merely down-ranked: the budget is a hard ceiling, and metadata rides ahead of content. Skipped lanes stay warm; the next query may need exactly them.

evidencebenchmark methodologyscorecrux.comCRC-v1 schema

The answer path

Every query runs a multi-stage pipeline: understand the question, retrieve candidate evidence, re-rank it into a balanced set, synthesize an answer with explicit links back to each supporting chunk, and emit a receipt. The same real path the benchmark and IQ suites run: no shortcuts, no mock corpus.

Hybrid retrieval

Two lanes run in parallel: sparse keyword matching (BM25) and dense vector similarity. Recall holds up whether the user's words match the source or express the same idea in entirely different vocabulary. The ranked lists are merged with reciprocal-rank fusion, and the fusion weights are tunable per corpus class and query intent.

Re-ranking for a balanced evidence set

The goal is not the single best passage but a representative set. Candidates are re-ranked on relevance, recency, source authority, and coverage diversity, so the answer reflects the breadth of what's known, not just the loudest match.

Every answer is a CROWN receipt

The receipt captures the original query, the retrieved chunks with their ranking scores, the synthesis rationale, and a BLAKE3 content-hash chain, so anyone can verify the answer was produced from the claimed evidence, without access to your data.

Verify a live receipt →

Lane-aware indexing

Different parts of the corpus flow through different embedding tiers by importance and domain: a premium lane for a medical research corpus, a faster lane for general content. The lane metadata is written into every receipt, so retrieval conditions stay fully reproducible.

Deterministic replay

Because every retrieval decision is logged, an auditor can replay any past query against the historical corpus state and confirm the same inputs produce the same outputs, essential where answer provenance must withstand scrutiny.

Where it surfaces

  • Reads CoreCrux for evidence and writes receipts back to it.
  • Ships inside the Crux Daemon; hosted for fleets on cuecrux.com.
  • Powers the Ask, Proof, and Watch product surfaces.

Retrieval capabilities

Retrieval in practice