Skip to content
Myles Bryning
2026-01-06

CueCrux Whitepaper - The Answer Protocol

The Answer Protocol: proof-carrying answers for interoperable AI systems.

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

Executive summary

Modern AI is excellent at producing text and increasingly poor at explaining why that text should be trusted. As AI systems integrate into products, the cost of that gap becomes someone’s PR problem, usually at the worst possible moment.

CueCrux defines an Answer Protocol: a set of verifiable objects and contracts that turn an answer into a proof-carrying artefact. Instead of shipping strings, integrators ship:

  • Answers decomposed into atomic claims
  • MiSES evidence sets (Minimal Sufficient Evidence Sets) that support those claims
  • CROWN receipts that capture retrieval and generation snapshots and can be verified independently
  • Trust indicators and Context Coverage so users can see the shape of uncertainty, not just a confidence vibe

CueCrux is deliberately open where it matters (contracts, proofs, receipts) and controlled where it must be (provenance, security, and cost envelopes). This combination is what allows interoperability without turning trust into a free-for-all.

If your AI product wants integrations, the Answer Protocol is the contract that lets partners verify, monitor, and audit outputs without inheriting narrative debt.

1. Why an “Answer Protocol” exists

An answer is not just text. It is an operational dependency.

Once an answer is embedded into:

  • a support workflow,
  • a compliance record,
  • a dashboard,
  • a policy decision,
  • or an agent plan,

it becomes someone else’s problem to determine whether it was warranted.

Most AI integrations today export only the final string. CueCrux’s claim is simple:

If an answer can change behaviour, it should carry a receipt.

CueCrux treats trust as a set of checkable signals: provenance, evidence diversity, recency, contradiction exposure, fragility, and replayability. Not as a colour, badge, or “trust me, mate”.

2. Design principles

CueCrux’s Answer Protocol is built on the following principles:

2.1 Receipts over vibes

Every meaningful claim must link to a minimal evidence set and a signed snapshot. “Verified” means something you can check, not something you can feel.

2.2 Minimal sufficient evidence, not maximal citation dumping

CueCrux selects the smallest non-redundant evidence set that supports the claims (MiSES). This reduces “citation theatre” and makes dependency analysis possible.

2.3 Determinism when you need it

When the stakes are high, CueCrux supports deterministic replay so you can detect drift: retrieval changes, corpus changes, and model/version shifts.

2.4 Counterfactual first

Any serious verification system must answer “what if we remove or penalise this evidence” as a first-class operation.

2.5 Bounded cost and bounded risk

Verification depth is explicit and budgeted. CueCrux uses cost-conditioned routing so audit-grade behaviours do not become accidental defaults.

3. Core protocol objects

CueCrux makes everything addressable. Answers, claims, artefacts, evidence sets, and receipts have stable IDs.

3.1 Artefact

Artefact — the smallest verifiable unit of knowledge in CueCrux (document, chunk, extract) with content hash and provenance metadata.

Artefacts are:

  • hashed for integrity,
  • tagged for licence/policy,
  • and referenced in evidence sets.

3.2 Claim

Claim — a single atomic statement that can be supported or contradicted.

CueCrux answers are claim-first: the platform aims to avoid blending unrelated assertions into one foggy paragraph that cannot be audited.

3.3 MiSES evidence set

MiSES — Minimal Sufficient Evidence Sets: the smallest non-redundant set of artefacts sufficient to support each claim above a configured threshold.

A MiSES group has:

  • ordered artefacts,
  • role and weighting,
  • and justification metadata.

MiSES is designed to make it obvious what the answer depends on.

3.4 CROWN receipt

CROWN — Counterfactual, Reputation-Weighted, Origin-Verified, Workflow-eNcoded retrieval plus receipts.

A CROWN receipt is a canonical, signed snapshot that binds:

  • the query and retrieval configuration,
  • the evidence set used,
  • model parameters and versions,
  • verification signals and coverage,
  • and integrity fields required for replay and auditing.

CueCrux receipts are meant to be verifiable by:

  • CueCrux services,
  • partner services,
  • auditors,
  • and downstream agents.

3.5 Trust indicators

Trust indicators are structured signals exposed alongside answers, such as:

  • domain diversity,
  • recency,
  • reputation,
  • contradiction rate,
  • snapshot age and staleness flags,
  • policy/licence compliance flags.

The point is not to invent a single “trust score”. The point is to expose enough structured signals that partners can apply policy.

3.6 Context Coverage

Context Coverage — a structured summary of how much of the relevant evidence space the answer actually touches.

Coverage makes it harder for an answer to sound complete when it only saw a thin slice of the topic.

4. Modes and their guarantees

CueCrux exposes explicit modes which trade latency and spend for verification depth.

4.1 light mode

Purpose: fast exploration and low-latency UX.
Guarantee: best-effort evidence signals, minimal validation, limited replay support.

4.2 verified mode

Purpose: production default for most integrations.
Guarantee: MiSES evidence sets produced and a CROWN receipt emitted or referenced, plus trust indicators and coverage.

4.3 audit mode

Purpose: high-stakes use, disputes, regulated workflows, and drift checks.
Guarantee: deterministic replay capability, extra logging, and stronger verification expectations.

Audit mode is designed to answer one blunt question:

“If we ran this again under the same snapshot, would we get the same answer?”

5. Canonical data model (partner-facing)

This section is intentionally concrete. If partners cannot implement a verifier in an afternoon, the protocol is too vague.

5.1 Answer object

Answer is the object integrators store and pass around.

{
  "id": "ans_01JABCDEF...",
  "mode": "verified",
  "text": "…",
  "claims": [
    {
      "id": "clm_01J...",
      "text": "Atomic claim text.",
      "confidence": 0.74,
      "fragility": 0.62,
      "evidence": [
        {
          "id": "mis_01J...",
          "role": "support",
          "score": 0.91,
          "artefacts": [
            {
              "id": "art_01J...",
              "title": "Document title",
              "url": "https://example.org/…",
              "domain": "example.org",
              "licence": "licence_bucket_A"
            }
          ]
        }
      ]
    }
  ],
  "trust": {
    "diversity": { "domains": 3, "diversityIndex": 0.71 },
    "recency": { "medianAgeDays": 12, "asOf": "2026-01-10" },
    "contradictionRate": 0.03,
    "policy": { "licenceOk": true, "robotsOk": true }
  },
  "contextCoverage": {
    "score": 0.58,
    "label": "medium",
    "components": { "retrieval": 0.62, "domains": 0.55, "temporal": 0.44, "clusters": 0.70 },
    "fragility": { "score": 0.62, "explanation": "Answer depends heavily on a narrow evidence slice." }
  },
  "crown": {
    "receiptId": "rcp_01J...",
    "snapshotId": "snp_01J..."
  }
}

5.2 Receipt object

Receipt payloads are canonical JSON and include integrity metadata.

{
  "id": "rcp_01J...",
  "answerId": "ans_01J...",
  "createdAt": "2026-01-10T12:30:00Z",
  "retrieval": {
    "query": "original query text",
    "weights": { "bm25": 0.35, "dense": 0.45, "recency": 0.20 },
    "timeWindow": ["2024-01-01", "2026-01-10"]
  },
  "model": {
    "name": "provider/model",
    "version": "2026-01-01",
    "seed": 123456,
    "temperature": 0.2
  },
  "evidence": [
    { "id": "mis_01J...", "role": "support", "score": 0.91, "artefacts": [ { "id": "art_01J..." } ] }
  ],
  "coverage": { "score": 0.58, "label": "medium" },
  "integrity": {
    "hash": "blake3:…",
    "signature": "ed25519:…",
    "kid": "engine-provenance:v12"
  }
}

6. Receipt integrity and verification

CueCrux receipts exist to be verified independently. This requires three concrete commitments:

  1. Canonicalisation rules must be stable.
  2. Hashing and signing must be explicit.
  3. Keys must be managed safely and rotated without breaking verification.

6.1 Hashing and signing

CueCrux uses:

  • BLAKE3 for hashing artefacts and canonical receipt payloads
  • ed25519 signatures for receipt integrity verification

6.2 Key management baseline

CueCrux centralises signing via a vault-backed signing service with transit signing. Private keys are not written to disk.

Key rotation is versioned so verifiers can validate old receipts using old public keys.

6.3 Minimal verifier algorithm

A minimal verifier should:

  1. Fetch or receive the receipt payload.
  2. Canonicalise the JSON (stable ordering, normalised whitespace, no transient fields).
  3. Compute the BLAKE3 hash and confirm it matches integrity.hash.
  4. Verify the ed25519 signature against the public key referenced by integrity.kid.
  5. Confirm required fields exist for the chosen mode:
    • verified: evidence references and trust indicators present
    • audit: deterministic replay fields present (seed, model version, stored candidate set metadata)

If any step fails, treat the answer as unverified regardless of how confident the prose sounds.

7. Evidence, provenance, and manipulation resistance

CueCrux assumes adversarial pressure from day one: prompt injection embedded in content, citation gaming, synthetic consensus, and manipulated “sources”.

7.1 Policy-aware ingestion and provenance

Artefacts carry:

  • provenance metadata,
  • licence and robots compliance flags,
  • and chain-of-custody signals.

This allows evidence and receipts to be audited without leaking raw proprietary content.

7.2 MiSES selection (practical behaviour)

MiSES prefers:

  • higher-trust evidence,
  • diverse domains,
  • more recent support when relevant,

and penalises:

  • contradictions,
  • licence violations,
  • suspicious provenance patterns.

7.3 Counterfactual and contradiction as first-class signals

CueCrux supports reverse operations such as:

  • receipt explanation,
  • deterministic replay,
  • counterfactual replay (exclude domains, adjust weights, change time windows),
  • fragility analysis and heatmaps,
  • contradiction finding.

A system that cannot show counterevidence is just doing persuasion with extra steps.

8. Context Coverage: “how much of the story did we actually see?”

CueCrux treats completeness as measurable, not rhetorical.

8.1 Coverage components

Context Coverage is broken into components, each between 0 and 1:

  • Retrieval coverage — how much retrieval mass is covered by MiSES evidence
  • Domain coverage — how many independent domains are represented
  • Temporal coverage — how well the answer covers the recency-weighted space
  • Concept cluster coverage — how many semantic clusters are touched

CueCrux may expose fragility as an additional diagnostic: how sensitive conclusions are to the removal of evidence sets.

8.2 Where coverage lives

Coverage is:

  • deterministic for a given snapshot in audit mode,
  • stored with CROWN snapshots and answers,
  • replayable via reverse and replay APIs,
  • exposed via typed SDK fields so UIs can render coverage badges and detail panels.

9. Public API surfaces and SDK patterns

CueCrux is designed to integrate cleanly with product teams and AI companies.

9.1 Minimal required endpoints

A CueCrux-compatible deployment exposes:

  • POST /v1/answers
  • GET /search
  • GET /healthz (build info, compatibility, SDK version)
  • GET /metrics (Prometheus)

Optional but recommended for partner tooling:

  • GET /v1/answers/{id}/receipt
  • GET /v1/provenance/{artifactId}
  • GET /v1/answers/{id}/trust-report

9.2 TypeScript integration example

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

const res = await Answers.ask({
  q: "What changed in this regulation since 2024?",
  mode: "verified",
  k: 10
});

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

if (!ok) {
  throw new Error("Receipt failed verification");
}

console.log(trustBadge(res.trust));

9.3 Browser and BFF boundary

CueCrux is designed so browsers do not hold engine secrets. Production integrations should call CueCrux via server-side code or a BFF/SSR boundary.

This protects receipts, provenance services, and budgets from becoming public toys.

10. Extensibility without breaking proof chains

CueCrux expects an ecosystem. The protocol is built to allow extension while preserving receipt discipline.

10.1 Extension types

Partners may extend CueCrux with:

  • ingest adaptors (regulated feeds, repositories),
  • custom validators (media integrity, instrument signatures),
  • agent hooks (domain planners and auditors).

10.2 Required guardrails

Extensions must remain:

  • server-side only,
  • subject to licence and provenance checks,
  • compliant with receipt generation,
  • versioned and signed to prevent silent drift.

If an extension bypasses receipts, it is not “integration”, it is “wishful thinking with API keys”.

11. Independent verification, drift, and operational credibility

CueCrux does not self-certify verification.

11.1 Independent operator oversight

A dedicated operator service runs audits, monitors drift, and produces machine-readable artefacts for review.

11.2 Health, readiness, and metrics

CueCrux deployments expose:

  • build and compatibility information via /healthz,
  • Prometheus metrics via /metrics,
  • and support contract drift detection using build info and compat signals.

This is how partners pin behaviour and detect when “same endpoint” quietly becomes “different system”.

12. What “CueCrux-compatible” should mean

CueCrux-compatible is not a marketing adjective. It is a contract.

A CueCrux-compatible integrator:

  1. Preserves receipt IDs with stored answers.
  2. Verifies receipts (hash + signature) in server-side code.
  3. Surfaces trust indicators and coverage, or enforces equivalent policies.
  4. Supports audit mode workflows for disputes or regulated use.
  5. Does not strip evidence links to make the UI look “cleaner”.

If you strip receipts, you are not simplifying the product. You are relocating the future incident report.

Appendix A: Receipt verification checklist (for partners)

  1. Verify receipt signature with the published key set for kid.
  2. Recompute canonical hash and compare to integrity.hash.
  3. Ensure evidence sets exist and artefact references include provenance metadata.
  4. Apply your freshness and diversity policy (or display the indicators).
  5. For high-stakes workflows: require audit mode and deterministic replay status.

Appendix B: Glossary

Artefact — smallest verifiable unit of knowledge with hash and provenance.
MiSES — Minimal Sufficient Evidence Sets supporting claims.
CROWN receipt — signed snapshot binding query, retrieval, evidence, model parameters, and verification metadata.
C³ — cost-conditioned routing that bounds spend and depth by mode.
Context Coverage — how much of the relevant evidence space was actually touched.

Call to action

If your AI product plans to integrate with other AI products, you need a shared contract for trust.

CueCrux provides that contract in the form of proof-carrying answers: structured claims, minimal evidence sets, receipts, and replayability.

If you are building an AI system that answers questions, summarises evidence, or automates decisions, integrate receipts now. It is much cheaper than integrating apologies later.