Skip to content
Myles Bryning
2026-01-08

CueCrux Whitepaper - Time Is a First-Class Dependency

Drift-aware answers that remain auditable as the world changes.

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

Executive summary

Most AI systems treat time as decoration: a timestamp on the output, a vague "recently updated" note, a quiet hope that yesterday's answer still fits today.

In practice, time is one of the most common reasons answers fail.

Even when nothing is "wrong", an answer can become fragile because:

  • the evidence aged,
  • the environment changed,
  • sources were superseded,
  • an assumption drifted,
  • automation reused the answer outside its original context,
  • the system quietly updated behaviour without leaving a trail.

CueCrux takes a different position:

If an answer can be relied on, it must declare the time conditions under which it holds and provide receipts that survive change.

CueCrux makes time explicit and operational by combining:

  • atomic claims (so you can see what is being asserted),
  • MiSES evidence sets (Minimal Sufficient Evidence Sets),
  • CROWN receipts (signed snapshots suitable for verification and replay),
  • Context Coverage and freshness signals (so you can see what was covered and how old it is),
  • drift detection and revalidation triggers (so the system revisits the right things before they become embarrassing).

This whitepaper defines why time breaks answers, what a time-aware answer contract looks like, and how integrators can use CueCrux to keep answers maintainable instead of merely convincing.

1. The time problem: answers rot faster than dashboards notice

Organisations rarely fail because they used an obviously false claim. They fail because they kept using a claim after its conditions stopped being true.

Time introduces failure modes that are quiet at first and expensive later:

1.1 Staleness

Evidence that was strong becomes stale. A policy changes. A dataset is updated. A vendor revises terms. The answer still reads well, which is exactly why it is dangerous.

1.2 Drift

The underlying system changes:

  • models are upgraded,
  • retrieval policies change,
  • embedding lanes change,
  • corpora expand or contract,
  • rankings shift due to new data.

If the system cannot replay and explain these changes, the organisation inherits narrative debt.

1.3 Misapplied reuse

A correct answer in one time window becomes wrong in another. A claim that holds "this quarter" is reused as if it holds "forever". Automation makes this faster, because it applies answers consistently without asking whether the world still fits.

1.4 Silent supersession

A source is updated, corrected, retracted, or superseded, but the old answer continues to circulate because nothing forces a revisit.

CueCrux treats these as protocol problems, not user problems.

2. CueCrux stance: time must be part of the answer contract

CueCrux does not aim for timeless answers. Timelessness is a sales pitch, not a capability.

CueCrux aims for answers that remain:

  • auditable (you can prove what they depended on),
  • replayable (you can detect drift),
  • maintainable (the system knows what to revisit and why),
  • policyable (integrators can enforce freshness rules by domain and risk).

This requires time to be a first-class field, not an afterthought.

3. The time-aware answer contract

CueCrux answers carry time in three distinct ways.

3.1 Evidence time (when the world was observed)

Each artefact referenced by an answer must carry:

  • an observed timestamp (when it was captured or last validated),
  • a provenance footprint (where it came from),
  • and a stable identifier (so later audits can refer to the same object).

3.2 Retrieval time (when the system searched)

Answers record:

  • the retrieval timestamp,
  • the time window applied (explicit or implied),
  • and any freshness weights used in ranking.

This matters because retrieval is not neutral. Freshness is a policy decision.

3.3 Answer time (when the output was produced)

A CueCrux answer includes:

  • generation time,
  • receipt time,
  • and mode (light, verified, audit).

This establishes which verification behaviours were purchased and which were not.

4. Key protocol primitives for time

CueCrux treats the following as stable contract surfaces.

4.1 as_of

An answer may be requested "as of" a specific date or time. This makes the question falsifiable and helps reduce ambiguity in regulated contexts.

4.2 time_window

A defined window used during retrieval and evidence weighting, such as:

  • last 30 days,
  • last 12 months,
  • 2019 to 2021,
  • "since the most recent policy change".

4.3 snapshot_id and receipt_id

A CROWN receipt binds a specific snapshot of:

  • retrieval config,
  • evidence set selection,
  • model parameters and versions,
  • and integrity metadata.

If the world changes, the receipt does not pretend it never happened.

4.4 superseded_by

Artefacts can be linked to newer versions or replacements. CueCrux treats supersession as a first-class event in provenance and trust indicators.

4.5 staleness and obsolescence signals

CueCrux exposes structured freshness signals such as:

  • median evidence age,
  • max evidence age,
  • staleness flags,
  • and domain-specific freshness thresholds.

The aim is not to pick one universal threshold. The aim is to let integrators define policy.

5. Freshness is not one rule: it is domain and risk dependent

A single "freshness score" is another leaky abstraction.

Different domains behave differently:

  • regulation and compliance can change overnight,
  • scientific consensus changes slower but still shifts,
  • operational policies drift continuously,
  • product documentation becomes wrong the moment a release ships.

CueCrux supports domain-aware policy routing so integrators can define rules such as:

  • "financial and legal domains require evidence newer than 90 days unless the claim is explicitly historical",
  • "product operational decisions require the latest versioned source",
  • "news queries require an as_of constraint and visible time window".

CueCrux does not decide your policy. CueCrux makes policy enforceable.

6. Drift and replay: keeping answers maintainable

Time-aware systems must support one simple capability:

When questioned later, the system can show what changed.

CueCrux supports this through receipts, replay, and operator oversight.

6.1 Deterministic replay in audit mode

Audit mode is designed to allow deterministic replay checks so that drift is measurable, not anecdotal.

Replay can detect:

  • retrieval drift (candidate sets changed),
  • model drift (outputs changed under the same snapshot),
  • corpus drift (sources changed or disappeared),
  • policy drift (licence, filtering, and weighting rules changed).

6.2 Counterfactual replay

Counterfactual replay answers practical questions like:

  • "What if we exclude this domain?"
  • "What if we require primary sources?"
  • "What if we apply a stricter recency window?"
  • "What if we down-weight a venue due to a retraction event?"

This turns time and uncertainty into something you can test, not argue about.

6.3 Revalidation triggers

CueCrux supports explicit triggers that force revisits, such as:

  • evidence older than a threshold,
  • contradiction rate rising in a domain,
  • artefact supersession,
  • policy changes that alter admissible evidence,
  • sustained user dissatisfaction or repeated follow-ups.

Triggers are the difference between maintainable answers and institutional amnesia.

7. UI patterns for time-aware trust

Time should be visible without becoming noisy.

CueCrux recommends a few product patterns that preserve accuracy:

7.1 "As of" labelling

Every answer should surface the effective as_of time. If the user did not specify it, the system should state what it assumed.

7.2 Freshness and coverage panel

A compact panel should show:

  • median evidence age,
  • time window used,
  • staleness flags,
  • and context coverage breakdown.

7.3 Supersession alerts

If key sources were superseded since the receipt was minted, the UI should show a gentle warning:

  • "One key source has been updated since this answer was produced."
  • "Recheck recommended."

This is cheaper than the alternative: surprise.

7.4 Drift comparison views

For high-stakes teams, CueCrux should support side-by-side comparisons:

  • the previous receipt,
  • the rechecked receipt,
  • what evidence changed,
  • what claims moved.

It makes revisiting decisions less political and more procedural.

8. Integration guidance for AI companies

If AI companies integrate with CueCrux, time-aware behaviour should be treated as part of the integration contract.

8.1 Store receipts with time metadata

Do not store only the answer text. Store:

  • receipt_id,
  • snapshot_id,
  • as_of,
  • time_window,
  • freshness summary (median age, staleness flags),
  • verification status.

That is the difference between "we had an answer" and "we had a defendable answer".

8.2 Verify receipts server-side

Receipt verification (hash + signature) should happen in server-side code. Browsers are wonderful, but they are also where good ideas go to get nicked.

8.3 Carry time signals through agent pipelines

If your agents plan actions, they must carry:

  • snapshot age,
  • time window,
  • staleness flags,
  • coverage and fragility.

Without these, every agent becomes overconfident by default.

9. A practical TypeScript example: time-aware policy routing

Below is a policy pattern that turns time signals into behaviour. Thresholds are illustrative. The pattern is the point.

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

const res = await Answers.ask({
  q: "What has changed in this regulation and what does it mean for our product?",
  mode: "verified",
  asOf: "2026-01-10",
  timeWindow: { from: "2024-01-01", to: "2026-01-10" },
  k: 20
});

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

// Time-aware routing
const medianAgeDays = res.trust?.recency?.medianAgeDays ?? 9999;
const stale = res.trust?.recency?.stale ?? true;
const coverage = res.contextCoverage?.label ?? "low";

if (stale || medianAgeDays > 90 || coverage === "low") {
  // Escalate to audit mode and refresh evidence
  const audited = await Answers.ask({
    q: "Re-check with a stricter recency window and include counterevidence if present.",
    mode: "audit",
    asOf: "2026-01-10",
    timeWindow: { from: "2025-01-10", to: "2026-01-10" },
    k: 30
  });

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

  return audited;
}

return res;

10. What we are not claiming

CueCrux is not claiming:

  • that every answer can be made forever valid,
  • that freshness is one universal threshold,
  • that receipts guarantee correctness,
  • that time-aware systems remove disagreement,
  • that uncertainty should block decisions.

CueCrux makes time visible, actionable, and auditable so decisions can be revisited without chaos.

Call to action

If your AI system will be used tomorrow, you need to design for time today.

CueCrux provides:

  • proof-carrying answers,
  • time-aware receipts,
  • replay and counterfactuals,
  • and drift detection tooling.

Integrate time into your answer contract now. It is cheaper than integrating surprise later.