Module verify 

context/verify — pull-based revalidation of frames a host already holds (docs/context-reuse.md §4).

Deterministic composition (§1) makes reusing context cheap: an unchanged frame set renders byte-identically and rides the provider’s prompt cache. But cheap reuse is only safe if the frames are still true. Without a way to ask, a host faces a bad pair of choices at every turn boundary: re-query everything (paying tokens and latency, and destroying the very prefix stability §1 bought) or reuse silently and risk citing evidence that changed underneath it.

A verify exchange is the cheap third option. The host sends a batch of FrameIds — (provider id, frame id, content digest) — and the provider answers one Verdict per frame. No frame body travels in either direction. That is the whole economic point: verification costs bytes, not tokens, so a host can afford to do it every turn on frames it would otherwise have re-queried in full.

The digest is the ground truth. A provider compares the digest the host presents against the digest its source has now: equal ⇒ Valid, different ⇒ Stale, source gone ⇒ Gone, can’t tell ⇒ Unknown. Because the digest is provider-declared and opaque (§1), the provider is the only party that can answer — which is exactly why §4’s conformance case exists to hold it honest.

Verify is the pull counterpart to subscribe (#6), not a replacement. A provider that can watch its sources pushes invalidations; one that cannot — a stateless HTTP endpoint, a batch-rebuilt index — can still answer a question asked of it. Both are capability-gated, and a host that has neither falls back to re-querying.

Structs

FrameVerdict

One frame’s verdict, paired with the identity it answers (docs/context-reuse.md §4).

VerifyRequest

A host’s request to revalidate frames it already holds (docs/context-reuse.md §4).

VerifyResponse

A provider’s answer to a VerifyRequest (docs/context-reuse.md §4).

Enums

Verdict

A provider’s answer for one frame (docs/context-reuse.md §4).