CueCrux Whitepaper - Answers as Infrastructure

Version: 1.0
Date: 5 January 2026
Contact: contact@cuecrux.com

Executive summary

AI systems can generate fluent answers faster than organisations can verify them. That mismatch creates a new integration risk: you can plug an AI into your product in a day, and spend the next year explaining why it hallucinated in public.

CueCrux is built to change the default contract of AI outputs from "trust me" to "verify this". It does that by making evidence-first answers the primary product and producing a cryptographically verifiable receipt for those answers, including the minimal evidence set required to support atomic claims.

CueCrux is intentionally open where it matters: contracts, proofs, and receipts are designed to be verifiable and integratable across organisations. It is intentionally controlled where it must be: provenance, security, and cost envelopes are enforced so that trust does not degrade under scale, incentives, or attack.

For partners and AI companies, CueCrux provides:

A stable API and SDK experience oriented around proofs, not just payloads (typed DTOs, receipt verification, trust indicators).
A formalised notion of modes that trade latency for verification depth, including deterministic replay and signed receipts in audit mode.
An extension framework that allows new evidence types and validators without breaking proof chains, and without leaking secrets to browsers.

CueCrux is not a new model that demands belief. It is an evidence system that earns it.

1. The problem: integration without proof creates narrative debt

When an answer is produced without defensible evidence lineage, every downstream consumer becomes responsible for:

checking sources,
explaining what the model "meant",
managing drift (model, retrieval, or corpus changes),
and responding to manipulation.

At small scale, this is annoying. At platform scale, it is existential. The narrative debt will always be paid, and it is usually paid in public.

CueCrux is a response to this trust gap: it makes verifiability, provenance, and replay a first-class output of the system, not a post-hoc apology.

2. Design principles

CueCrux is designed around four principles that partners can plan around.

2.1 Proof over opinion

Every trust claim must be anchored to evidence lineage and a receipt that can be checked independently.

2.2 Minimal sufficient evidence, not maximal citation dumping

CueCrux aims to cite the smallest non-redundant set of evidence that supports atomic claims, not the longest list of links. This is formalised as MiSES (Minimal Sufficient Evidence Sets).

The benefit is not "fewer citations". The benefit is that you can see what the answer truly depends on.

2.3 Separation of powers by architecture

Authentication and entitlements live at the BFF boundary; the core engine focuses on evidence and receipts. Browsers do not receive engine secrets or tokens.

This reduces the blast radius of compromise and simplifies partner integration patterns.

2.4 Bounded cost and bounded risk

CueCrux treats verification depth as an explicit dial with budget envelopes (C3: Cost-Conditioned Cascades). This enables reliable integration: partners can choose verified or audit behaviours without runaway spend or unpredictable latency spirals.

3. Core primitives

This section defines CueCrux's protocol primitives. These names are not marketing. They are contract surfaces.

3.1 CROWN receipts

CROWN (Canonical Witnessed Output with Replayable Narrative) is a cryptographically signed receipt for an answer. The receipt anchors:

the canonical answer payload,
the evidence set used (MiSES),
retrieval and model parameters,
and verification metadata required for replay and auditing.

A CROWN receipt is designed so a verifier can:

recompute the canonical hash of the receipt payload, and
verify the signature using the published public key set.

3.2 MiSES evidence sets

MiSES is the system’s mechanism for selecting and persisting the minimal non-redundant evidence set supporting all atomic claims in an answer.

3.3 Modes: light, verified, audit

CueCrux exposes modes that trade speed for depth:

light: fastest path, minimal checks
verified: full provenance signals and higher evidence expectations
audit: deterministic replay, signed receipts, and counterfactual checking

This is not quality theatre. Modes are designed to control real costs and real verification work, and to make those differences visible to integrators and users.

3.4 Trust indicators

CueCrux exposes trust indicators such as domain diversity, recency, contradiction rate, and reputation signals. These enable UIs to show why-trust panels and allow integrators to set policies (for example: "only show answers with 2+ independent domains when available").

4. System architecture at partner level

CueCrux is a platform of cooperating services with clear boundaries.

4.1 Engine and BFF boundary

The platform is designed with separation of powers: the engine focuses on core evidence and receipt creation; the BFF owns authentication and entitlements. This is both a security and an integration feature, because it makes "who can call what" explicit and testable.

4.2 Independent oversight via WatchCrux

WatchCrux is an always-on operator that supervises services, runs deterministic audits, and reports health even if an API server fails. It remains lifecycle-independent so test and audit loops persist through outages and drift.

For partners, this means claims about verification are not self-certified. There is a designed place in the system where independent checks live.

4.3 Artefacts and retrieval pipeline

CueCrux’s retrieval and evidence pipeline is designed for very large scale and policy-aware operation, with clear separation between:

artefacts and metadata,
vector search,
raw content storage,
analytics and telemetry,
receipts and evidence sets.

This separation enables strict retention and licensing controls while still allowing reproducible evidence tracking.

5. Protocol requirements

This is a normative section intended for integrators and auditors.

5.1 Receipt creation requirements

A CueCrux answer in verified or audit mode must produce a replayable receipt stored with the answer and suitable for independent verification.

Receipt signing must be performed with centralised signing and auditable key rotation, with no private keys stored on disk in production deployments.

5.2 Evidence lineage requirements

Evidence items used in answers must carry sufficient metadata to support provenance and compliance signals (hashes, observed time, licence and domain signals). Receipts must reference the evidence set produced by MiSES.

5.3 Deterministic audit requirements

Audit mode is expected to support deterministic replay checks on samples, with verification status observable by an independent operator service.

5.4 Compatibility and drift requirements

CueCrux services expose health and compatibility information so integrators can pin behaviour:

/healthz includes build info and compatibility data, including SDK version expectations.
Drift alerts surface when contracts skew, with independent monitoring support.

6. Verification workflow for partners

CueCrux is designed to be integrated as a verifiable component inside other AI products.

6.1 Typical integration pattern

A partner application does:

Send a query to CueCrux with a selected mode.
Receive an answer plus CROWN receipt ID and trust indicators.
Verify the receipt locally or via a verifier service.
Display the answer with a why-trust panel and a receipt link.

6.2 TypeScript example

import { Answers, Receipts, trustBadge } from '@cuecrux/sdk';

const res = await Answers.ask({
  q: 'How did this regulation change over time?',
  mode: 'verified',
  k: 10,
});

const ok = await Receipts.verify(res.crown.receiptId);
const badge = trustBadge(res.trust);

if (!ok) throw new Error('Receipt failed verification');
console.log(badge);

7. Manipulation resistance without censorship

CueCrux assumes adversarial pressure from the beginning: bots, collusion, citation cartels, manipulated sources, and prompt injection embedded in content.

7.1 Weight down, do not ban

CueCrux’s approach to manipulation is to reduce the influence of low-quality or coordinated evidence while maintaining visibility, and to record reasons transparently. The aim is to avoid viewpoint bans by focusing on independence and evidence quality rather than ideology.

7.2 Counterfactual and contradiction as first-class signals

CueCrux uses counterfactual checking and treats contradiction rate as a first-class metric. When sources are weak or contradictory, the system should label that status rather than manufacture certainty.

7.3 Retractions, venue risk, and policy-aware ingestion

The system integrates retraction awareness and venue reputation signals, and supports policy-aware ingestion gates (licence and robots handling, PII discipline) so evidence quality is enforceable, not aspirational.

8. Privacy, compliance, and enterprise deployment

CueCrux is designed to support commercial-grade analytics and evidence provenance without leaking private content or personal data by default.

Key practices include:

policy-aware intake with licence and robots gates,
conservative handling of PII and takedown cascades,
retention policies enforced via metadata,
enterprise "private stack" patterns where content can remain in-region while proofs can still be verified via hashes and metadata federation.

9. Extensibility and MCP-style ecosystems

AI companies will increasingly integrate via agent and tool protocols. CueCrux is designed to be compatible with this world because its core output is not "a string", but a verifiable artefact:

a receipt ID,
a signed payload,
and a structured evidence set.

CueCrux’s Extension API exists to add evidence types, validators, or agent hooks while preserving receipt discipline and keeping secrets server-side only.

This makes CueCrux naturally fit into MCP-style tool chains: treat CueCrux as a tool whose output is a proof-carrying answer, with receipts that can be verified by any downstream agent or service.

10. Crux credits are not a token

CueCrux includes a credits mechanism used to account for compute, storage, and contributions. This exists to align incentives with evidence quality and reuse, and to keep verification work economically bounded.

Crux credits are internal utilities: non-transferable, with no cash value outside the service, and not representing ownership or investment interest.

This matters because trust infrastructure collapses if people think it is secretly a casino.

11. What CueCrux stands for

CueCrux stands for four commitments:

Receipts over rhetoric
If we cannot show evidence lineage and verification metadata, we do not claim trust.
Minimal sufficient evidence
We do not reward citation spam. We reward the smallest defensible set.
Safety in depth
Security, privacy, and cost constraints are built into the architecture and operational discipline, not bolted on later.
Integration without narrative debt
Partners should be able to integrate CueCrux and inherit a trust story that is verifiable, monitorable, and resilient to drift.

12. What CueCrux is not

CueCrux is not:

a replacement for domain expertise,
an oracle that eliminates uncertainty,
a censorship system,
or a marketing badge that bypasses scrutiny.

CueCrux is a verification substrate that makes uncertainty and disputes visible, and makes trust claims checkable.

13. Call to action

If you build AI systems that answer questions, summarise evidence, or support high-stakes decisions, you need receipts.

CueCrux invites:

AI companies to integrate proof-carrying answers via SDKCrux and stable contracts,
publishers and data owners to provide licence-aware corpora,
independent verifiers to validate receipts and surface drift.

Because the future of AI is not just better outputs. It is better accountability for outputs.

Appendix A: Minimal receipt verification checklist (partner-facing)

Verify receipt signature using published key(s).
Recompute canonical hash from canonical JSON and confirm it matches the receipt ID.
Validate evidence set exists and evidence items have required provenance metadata.
Check snapshot age and freshness signals match your policy.
If high-stakes or disputed: request audit mode and require deterministic replay verification status.

Your lawyer will still be busy. Just less busy than if you shipped "trust me, bro" to production.