Skip to content
Myles Bryning
2026-01-09

CueCrux Whitepaper - Integration Without Abdication

How to integrate AI systems without surrendering trust.

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

Executive summary

AI companies and product teams want integrations because integrations create distribution. The problem is that most integrations also create narrative debt: the answer travels, but the evidence and accountability do not.

CueCrux exists to prevent that failure mode.

CueCrux is not a model and not a “trust badge”. CueCrux is a verification substrate: it turns answers into proof-carrying artefacts through atomic claims, minimal sufficient evidence sets (MiSES), signed receipts (CROWN), and operational trust signals (coverage, fragility, contradiction, and time).

This whitepaper defines a practical integration stance:

Integrations are welcome. Bypasses are not.

CueCrux is designed to integrate with:

  • AI model providers,
  • agent toolchains (including MCP-style tool calling),
  • enterprise stacks,
  • and downstream verification services,

while preserving three invariants:

  1. Receipts remain verifiable (even outside CueCrux).
  2. Evidence lineage remains inspectable (even after reuse).
  3. Costs and risk remain bounded (even under automation).

If you are an AI company integrating CueCrux, this document is your map of what you can extend, what you must preserve, and what will break trust if you do not.

1. Why integrations break trust

Integrations rarely fail because the API was down. They fail because the trust contract was diluted, and nobody noticed until it mattered.

Common failure patterns:

1.1 The answer travels, the proof does not

An answer is copied into a ticket, policy note, internal wiki, or agent plan. The receipt and evidence set are dropped “for convenience”. Convenience is then promoted to precedent.

1.2 Self-certification replaces verification

A vendor says “verified” but cannot produce receipts, replay, or a stable explanation of what changed. Downstream teams treat it as verified anyway, because the UI looked calm.

1.3 The integration strips uncertainty to look decisive

Coverage, contradiction, and fragility signals are removed because they look messy. The product becomes easier to sell and harder to defend.

1.4 Agent pipelines turn outputs into actions without preserving checks

An agent uses the answer as a tool result, then triggers actions downstream. If the agent cannot carry verification metadata, every step becomes overconfident by default.

CueCrux is designed to make these patterns difficult, and to make the remaining risk explicit.

2. CueCrux integration stance

CueCrux aims to be:

  • open where it matters: contracts, proofs, receipts, and verification flows are designed to be implementable outside CueCrux;
  • controlled where it must be: provenance, key management, policy, and cost envelopes are enforced to keep trust stable under pressure.

CueCrux makes one demand of integrators:

If you integrate CueCrux, you preserve the proof chain.

This is not bureaucracy. It is the minimum condition for interoperable trust.

3. Roles in a CueCrux integration

CueCrux assumes an ecosystem with distinct roles. The confusion begins when one actor tries to play all of them at once.

3.1 Model provider

Produces raw language output and may contribute tool calls. A model provider is not assumed to be a verifier of its own outputs.

3.2 Evidence provider

Supplies artefacts (documents, datasets, transcripts) into an ingestion pipeline, under licence and policy constraints.

3.3 CueCrux Engine

Constructs answers from evidence, selects MiSES evidence sets, and mints signed receipts.

3.4 Consumer product

Displays answers, enforces policy, stores receipts, and routes risk (for example by escalating to audit mode).

3.5 Independent verifier and operator

Verifies receipts, detects drift, and reports integrity status. This may be internal or external.

Separation of powers is not a philosophical preference. It is how you stop “trust” becoming a marketing adjective.

4. Integration primitives you must preserve

CueCrux integrations should treat these objects as first-class artefacts, not optional extras.

4.1 Answer object

An answer includes:

  • human-readable text,
  • atomic claims,
  • evidence set references,
  • trust signals,
  • coverage and fragility summaries,
  • and pointers to receipts and snapshots.

4.2 MiSES evidence sets

MiSES shows what each claim depends on. If you drop evidence sets, you are no longer integrating verification. You are integrating vibes.

4.3 CROWN receipts

Receipts bind an answer to a signed snapshot:

  • retrieval configuration,
  • model/version parameters,
  • evidence links,
  • time constraints,
  • and integrity metadata.

Receipts are designed to be verified independently by partners.

4.4 Time and drift fields

Integrations must carry time semantics such as:

  • as_of,
  • time_window,
  • snapshot age and staleness flags.

If an integration cannot carry time, it cannot be trusted to reuse answers safely.

4.5 Coverage, fragility, and contradiction signals

These are not UI ornamentation. They are routing inputs for automation and policy.

5. Integration patterns that keep trust intact

5.1 Product integration via server-side BFF

The safest pattern is:

  1. Your product server requests an answer (mode: verified by default).
  2. Your server verifies the receipt.
  3. Your server stores the answer ID and receipt ID with the business record.
  4. Your UI renders the answer with a Why Trust drawer.

This keeps secrets off the client and makes trust enforceable.

5.2 Agent tool integration (MCP-style)

CueCrux can be exposed as an agent tool where tool outputs are proof-carrying:

  • Tool returns: answer text + structured trust payload + receipt ID
  • Agent must carry: receipt ID, coverage label, staleness flags
  • Downstream actions must require: verified receipt status for policy-critical steps

If you only return text to the agent, the agent will behave as if it was certain. Agents are great at planning and terrible at spontaneous humility.

5.3 Model-agnostic verification layer

A model provider can call CueCrux for verification and evidence binding without ceding model choice.

Typical use:

  • Model generates a draft.
  • CueCrux binds claims to evidence and produces receipts.
  • Consumer displays the CueCrux-traceable answer as the reliable artefact.

This keeps model vendors free to innovate while keeping trust checkable.

5.4 “Bring your own corpus” evidence integration

Enterprise partners often need their own evidence base.

CueCrux supports this pattern when evidence providers:

  • respect licensing and policy constraints,
  • provide stable artefact identifiers,
  • allow provenance capture (observed time, source URL, licence bucket),
  • accept that artefacts are hashed and referenced, not hand-waved.

The integration contract is: you can bring content, but you cannot bring ambiguity.

5.5 Independent verification service

Partners can run a verifier that:

  • fetches receipts,
  • canonicalises payloads,
  • recomputes hashes,
  • verifies signatures via published public keys and key IDs,
  • flags drift and supersession.

This is how you prevent “trust” being trapped inside one vendor boundary.

6. Guardrails for safe integrations

Integrations that do not respect guardrails will produce outputs that look plausible and behave dangerously.

6.1 Receipts cannot be optional in verified or audit paths

If the mode implies verification, the integration must store and verify receipts. No receipt, no verification.

6.2 Verification must be server-side

Receipt verification (hash + signature) belongs in trusted server code. If you do it in the browser, you have invented a new sport called “trust by JavaScript”.

6.3 Integrations must carry uncertainty through pipelines

If you pass answers between services or agents, you must carry:

  • coverage label,
  • fragility score (or at least a high/low indicator),
  • contradiction status,
  • staleness flags,
  • receipt ID.

If you strip those, you are not simplifying. You are hiding risk in the plumbing.

6.4 Extensions must not bypass provenance and policy

Extensions may add:

  • ingest adaptors,
  • validators,
  • domain planners,
  • rerankers,

but they must not bypass:

  • licence gates,
  • provenance recording,
  • receipt discipline,
  • budget and entitlement constraints.

Payment buys compute, not a censorship bypass.

6.5 Compatibility and drift must be observable

Partners need build and compatibility signalling so they can pin behaviour and detect drift:

  • build identity and API compatibility fields,
  • SDK version expectations,
  • deprecation windows and compatibility policies.

The polite version is “versioning”. The honest version is “stopping silent change”.

7. Compatibility contract: how to avoid integration rot

An integration is not “done”. It is “done until the first quiet upgrade”.

CueCrux recommends a compatibility contract with:

7.1 Stable canonical schemas

Answer and receipt schemas must be versioned and backwards verifiable. Receipt canonicalisation rules must not change silently.

7.2 Explicit key IDs and rotation

Receipts include a key ID (kid) so old receipts remain verifiable after key rotation.

7.3 Mode guarantees as contracts

Mode names are meaningless unless their guarantees are stable. Partners should be able to depend on:

  • what verified includes,
  • what audit includes,
  • and what light explicitly does not guarantee.

7.4 Health and metrics as integration surfaces

Operational credibility depends on visible health and metrics, not promise decks. Partners should be able to monitor:

  • request timing,
  • verification pass rate,
  • contradiction trends,
  • drift checks,
  • and budget spend by mode.

8. Security posture for integrations

CueCrux integrations should assume adversaries, not just bugs:

  • prompt injection embedded in sources,
  • evidence manipulation,
  • spoofed receipts,
  • compromised clients,
  • and incentive-driven corner cutting.

Minimum integration security posture:

  • browsers do not hold engine secrets,
  • receipts are signed and verifiable,
  • private keys are not written to disk,
  • provenance is append-only,
  • operator verification is independent of the answer-serving path.

Security is not a feature. It is the cost of being believed by people who have been burned before.

9. Governance posture: weight down, do not ban

CueCrux aims to resist manipulation and synthetic consensus without becoming a secret moderation regime.

Integration-compatible governance looks like:

  • weighting and transparency over silent suppression,
  • provenance and independence signals over ideology,
  • recorded reasons for down-weighting and quarantine,
  • dispute surfacing where sources conflict.

Legitimacy comes from explainability and auditability, not from insisting you are neutral.

10. Minimal integration checklist

If you do nothing else, do this:

  1. Store receipt IDs with answers anywhere decisions might depend on them.
  2. Verify receipts server-side before showing “verified” to a user.
  3. Carry coverage, fragility, contradiction, and staleness flags through pipelines.
  4. Escalate to audit mode for disputes, high-stakes use, or stale evidence.
  5. Monitor drift and verification pass rates, not just latency and uptime.

This is the smallest set of behaviours that preserves narrative control.

11. Practical TypeScript examples

11.1 Verify-first integration

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

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

const ok = await Receipts.verify(res.crown.receiptId);
if (!ok) throw new Error("Receipt verification failed");

// Persist these with the business record
await db.answers.insert({
  answerId: res.id,
  receiptId: res.crown.receiptId,
  asOf: res.asOf,
  timeWindow: res.timeWindow,
  coverage: res.contextCoverage?.label,
  contradictionRate: res.trust?.contradictionRate ?? null
});

return res;

11.2 Policy routing for agent actions

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

const res = await Answers.ask({
  q: "Summarise the policy and recommend next steps",
  mode: "verified"
});

if (!(await Receipts.verify(res.crown.receiptId))) {
  throw new Error("Unverified answer");
}

// Example policy gates
const coverage = res.contextCoverage?.label ?? "low";
const stale = res.trust?.recency?.stale ?? true;
const contradiction = res.trust?.contradictionRate ?? 0;

const highRisk = stale || coverage === "low" || contradiction > 0.05;

if (highRisk) {
  // Do not auto-act; escalate to audit mode or human review
  const audited = await Answers.ask({
    q: "Re-check with counterevidence and stricter recency constraints",
    mode: "audit"
  });

  if (!(await Receipts.verify(audited.crown.receiptId))) {
    throw new Error("Audit receipt failed verification");
  }

  return { action: "review_required", answer: audited };
}

return { action: "safe_to_proceed", answer: res };

12. What we are not claiming

CueCrux is not claiming:

  • that integrations can eliminate uncertainty,
  • that receipts guarantee correctness,
  • that one “trust score” can replace judgement,
  • that governance can be apolitical.

CueCrux makes trust checkable and uncertainty actionable, so integrations remain maintainable as the world changes.

Call to action

If your AI system is integrating with other AI systems, you need a shared trust contract.

CueCrux offers a practical path:

  • proof-carrying answers,
  • verifiable receipts,
  • time-aware signals,
  • and integration guardrails that prevent trust from being diluted at the edges.

Integrate proofs now. It is cheaper than integrating apologies later, and far less awkward at board level.