Skip to content
Myles Bryning
2026-01-10

CueCrux Whitepaper - Who Decides When an Answer Changes

Governance for living knowledge in AI systems.

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

Executive summary

Most organisations treat answers as if they are static objects: once accepted, they become policy, configuration, training data, or automation defaults. When the world changes, answers often do not. The result is predictable:

  • decisions become brittle,
  • drift becomes invisible,
  • failures become personal,
  • and “we didn’t see it coming” becomes institutional folklore.

CueCrux is built on a different premise:

If answers can influence systems, they must be governed as living artefacts.

CueCrux does not ask humans to remember every caveat. CueCrux makes caveats, assumptions, and revision triggers first-class fields.

This whitepaper defines:

  • why answer governance is inevitable,
  • what counts as a legitimate reason to change an answer,
  • how to prevent “truth” becoming politics or bottlenecks,
  • how receipts, provenance, and replay enable fair revision,
  • and how partners and AI companies can integrate governance without rewriting what CueCrux stands for.

Governance here does not mean committees. It means rules that make changes inspectable and auditable.

1. The governance problem: answers become defaults

Answers do not remain in their original place.

They travel:

  • from a report to a deck,
  • from a deck to an email,
  • from an email to a policy,
  • from a policy to a script,
  • from a script to an agent.

Repetition becomes mistaken for verification. And once an answer becomes default, changing it becomes expensive.

This is why governance is not optional: the cost of revision rises over time, so revision needs structure.

2. CueCrux stance: governance should be procedural, not personal

When answers change without procedure, organisations fall into two traps:

2.1 Authority trap

A senior voice decides what is “true”, often based on urgency, narrative comfort, or incentives.

2.2 Chaos trap

Anyone can change “the truth”, creating version wars, confusion, and mistrust.

CueCrux aims to avoid both traps by defining:

  • what can change,
  • who can propose change,
  • what evidence is required to approve change,
  • and how changes propagate.

The core idea is simple:

Changes are triggered by observable events, not by opinions.

3. What counts as a legitimate reason to change an answer

CueCrux uses the idea of revision triggers. A trigger is an event that forces a revisit.

Examples of legitimate triggers:

3.1 Evidence supersession

A key artefact was updated, corrected, retracted, or replaced.

3.2 Assumption drift

A named assumption moved:

  • thresholds changed,
  • input distributions shifted,
  • operational constraints changed,
  • incentives changed.

3.3 Contradiction emergence

New contradictory evidence appears with sufficient weight and independence.

3.4 Time expiry

The answer has exceeded its freshness window for the domain or risk level.

3.5 Policy change

Compliance requirements or admissible evidence policies changed.

3.6 Incident feedback

Operational incidents, user disputes, or repeated follow-ups reveal fragility or misfit.

A governance system that cannot name triggers will revert to politics.

4. The CueCrux governance primitives

CueCrux is designed so governance is implemented using stable artefacts and contracts.

4.1 Answer cards

An answer is not just text. It is a card with:

  • claims,
  • evidence sets,
  • time semantics,
  • coverage and fragility,
  • and receipts.

4.2 Receipts and snapshots

Receipts bind answers to verifiable snapshots. Snapshots provide replay anchors so debates can be about what changed, not about who remembers what.

4.3 Provenance ledger

Provenance is append-only. Artefacts are hashed and signed. This makes tampering detectable and makes change history inspectable.

4.4 Modes as governance levers

Modes are not just latency dials. They are governance tools:

  • light mode for exploration,
  • verified mode for operational reliance,
  • audit mode for disputes and regulated contexts.

4.5 Trust signals as revision inputs

Coverage, fragility, contradiction, and staleness signals are used to route revision work. They help avoid “review everything” paralysis.

5. A practical governance workflow

CueCrux governance is designed to be boring and repeatable.

5.1 Propose

A change proposal includes:

  • the answer ID and receipt ID,
  • the trigger event,
  • evidence showing what moved,
  • the proposed new status (for example: confidence down, disputed, superseded).

5.2 Verify

The verifier checks:

  • receipt integrity,
  • evidence lineage,
  • trigger validity,
  • replay results (where required),
  • counterfactual sensitivity (fragility).

5.3 Decide

Decision rules depend on domain and risk. Common policies include:

  • “audit mode required for high-stakes changes”,
  • “two independent domains required when available”,
  • “if contradiction persists, mark as disputed rather than forcing a single narrative”.

5.4 Publish

Publishing a change updates:

  • the canonical answer card,
  • the governance log,
  • the superseded-by links,
  • and any downstream consumers that subscribed to revision events.

5.5 Monitor

Watch for:

  • recurrence of drift,
  • repeated disputes,
  • suspicious manipulation patterns,
  • and governance bottlenecks.

6. Preventing bottlenecks and capture

Governance fails when:

  • it centralises all change authority,
  • it becomes slow,
  • or it becomes politicised.

CueCrux recommends:

6.1 Tiered governance

Not every change needs the same ceremony.

  • Low-risk updates can be automated with clear triggers.
  • Medium-risk changes require human review.
  • High-risk changes require audit mode and independent verification.

6.2 Separation of proposing and approving

The team that uses an answer can propose changes. Approval requires a different function or an independent verifier.

This prevents “grading your own homework” dynamics.

6.3 Transparent logs

Every change is recorded with:

  • trigger,
  • evidence links,
  • receipt IDs,
  • and justification.

Opaque change is where politics hides.

6.4 Appeal via evidence

Disagreements are resolved through:

  • additional evidence,
  • stronger counterfactual tests,
  • or explicit “disputed” status.

Not by shouting, not by seniority, and not by clever slide design.

7. Governance in partner and AI-company integrations

Integrations must not treat governance as a UI feature. It is a protocol layer.

7.1 What partners should store

Partners should store with any relied-on answer:

  • receipt ID,
  • snapshot ID,
  • as_of and time_window,
  • coverage and fragility summaries,
  • verification status,
  • last governance state (active, disputed, superseded).

7.2 Subscription to revision events

CueCrux-compatible integrations should support:

  • webhooks,
  • polling,
  • or event streams

that notify systems when answers they depend on are superseded or disputed.

7.3 Agent governance

If agents act on answers, they must:

  • carry governance status,
  • refuse to act on superseded or disputed answers without escalation,
  • request audit mode for high-stakes operations.

Agents should not become unofficial legislators.

8. A practical TypeScript governance sketch

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

const answer = await Answers.get("ans_01J...");
const receipt = await Answers.getReceipt(answer.crown.receiptId);

if (!(await Receipts.verify(receipt.id))) {
  throw new Error("Receipt failed verification");
}

// Trigger detection example
const stale = answer.trust?.recency?.stale ?? false;
const contradiction = (answer.trust?.contradictionRate ?? 0) > 0.05;

if (stale || contradiction) {
  const proposal = await Governance.proposeChange({
    answerId: answer.id,
    receiptId: receipt.id,
    trigger: stale ? "time_expiry" : "contradiction_emergence",
    proposedStatus: stale ? "recheck_required" : "disputed",
    notes: "Automatic trigger based on policy thresholds"
  });

  // In a real system, approval is handled by an independent function
  await Governance.requestAudit({
    proposalId: proposal.id,
    mode: "audit"
  });
}

The key is not the API surface. The key is the posture:

  • changes are triggered,
  • proposals are logged,
  • approvals are separable,
  • and outcomes are auditable.

9. Governance is not censorship

CueCrux governance is designed to support truth maintenance, not viewpoint enforcement.

Key distinctions:

  • Disputed does not mean suppressed.
  • Down-weighted means “less relied on”, not “unmentionable”.
  • Superseded means “a newer artefact exists”, not “history is deleted”.

Governance is a way to keep uncertainty attached to answers as they travel.

10. What we are not claiming

CueCrux is not claiming:

  • that governance removes disagreement,
  • that one governance model fits every domain,
  • that receipts guarantee correctness,
  • that policy decisions can be apolitical.

CueCrux makes changes inspectable, auditable, and less personal. It turns “truth maintenance” into a system property, not a heroic act.

Call to action

If answers are powering decisions in your organisation, you already have governance. It is just informal, inconsistent, and expensive.

CueCrux makes governance explicit:

  • triggers instead of opinions,
  • receipts instead of memories,
  • replay instead of narratives,
  • and logs instead of politics.

Govern your answers like they matter. Because they already do.