Tool attestations and freshness

2 min readReferenceUpdated 2026-05-21

What you'll find here

Two related contracts that bound the trust on observed tool results and the recency of knowledge — craik.tool_result_attestation and craik.knowledge_freshness_probe.

Recency, not truth.

Freshness probes only record whether the expected source was observed recently enough for the caller's freshness policy. They do not prove the underlying claim is true.

Contracts

Contract

Records

Fields

craik.tool_result_attestation

tool output

Tool name & identity · command when available · observed output summary · output hash · trust class · evidence/receipt links · capture time · optional expiry · local HMAC integrity metadata.

craik.knowledge_freshness_probe

recency

Links a target (GitHub state · documentation · memory facts · tool results · external state · instruction sources) to freshness status and stale-risk warning text.

Stale-risk surfaces

Surface expiring / expired / missing probes.

Before a handoff or memory promotion relies on a piece of knowledge, expiring, expired, and missing probes must surface as stale-risk warnings.

Expiration evaluation

Attested evidence is evaluated before reuse:

Status

Meaning

Operator action

unexpired

reusable

The attestation has an expiry and it is still in the future.

expired

blocked

Refresh the source or provide an explicit override rationale.

overridden

explicit

The evidence is expired but the caller recorded why reuse is acceptable.

missing_expiration

warning

The evidence may be usable, but it cannot silently carry recency authority.

What's next

ReferenceKnown trapsHow freshness interacts with active traps.ReferenceSchema referenceFull attestation and probe shapes.GuideAgent onboardingWhere stale-risk warnings appear at run start.