Docs: cached page re-verification — PRD-0014 amendment + ADR-0019#123
Docs: cached page re-verification — PRD-0014 amendment + ADR-0019#123tieguy wants to merge 1 commit into
Conversation
…ADR-0019 Design docs (no code) for evolving Re-verify from "re-check one finding in place" into "refresh the whole page to the current revision, cheaply", resolving the mixed-revision display seam review flagged on #109. - PRD-0014 amendment (2026-07-09): Re-verify's operator-facing contract becomes a cached page refresh — header, links, sections, and every card end up consistently as-of the current revision. The one-finding fold-and-regroup stays the interim implementation, with the mixed-revision display a known limitation. - ADR-0019 (Cached page re-verification): activate ADR-0009's dormant content-addressed verdict cache (keyed by snapshot_hash + claim) as a read-through in ADR-0011's pipeline; in-memory/process-scoped, no panel fingerprint (panel fixed in-session), re-fetch the article but reuse session-cached source bodies, and no force-refresh bypass (a second-opinion re-roll is a separate future control). Stacked on the #109 branch (PRD-0014 lives there, not yet on main). Proposed, docs-only, for review. Link + doc-consistency gates pass. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MT5gvrNTp77JJqRTC5bKov
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7818cd2853
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| - **A verdict is content-addressable.** It is a function of the **source content** | ||
| and the **claim sentence** (and the model panel). **ADR-0009** already defines a | ||
| content-addressed verdict record keyed by `(snapshot_hash, claim)` |
There was a problem hiding this comment.
When an edit changes only the surrounding article context, this cache will still hit because it keys only (snapshot_hash, claim). The page verifier passes Some(&us.context) into verify_citation_use_site (crates/sp42-citation/src/citation/page.rs:264-270), and the prompt builder renders that context and metadata into the model prompt (crates/sp42-citation/src/citation/prompts.rs:59-74), so the verdict is not solely a function of source bytes and the claim sentence. A re-verify after changing a pronoun antecedent or preceding sentence could incorrectly reuse the old verdict unless the key includes the prompt/context inputs that affect inference.
Useful? React with 👍 / 👎.
| Re-verify does **not** offer a "re-run this one regardless" bypass. Every case | ||
| that warrants fresh inference busts the content-addressed cache on its own: | ||
|
|
||
| - operator edited the claim → new `claim` → miss → fresh; | ||
| - source content changed → new `snapshot_hash` → miss → fresh; |
There was a problem hiding this comment.
For sources already in the promoted session body cache, Re-verify explicitly does not refetch the source, so a mid-session source change cannot produce a new snapshot_hash; it will keep using the cached body/verdict until a new load/session. This makes the no-force-refresh rationale too broad: the source content changed → new snapshot_hash → miss path only applies when the source is fetched again or was not cached, not for the normal session-cached Re-verify path described above.
Useful? React with 👍 / 👎.
2 participants
Summary
Design docs (no code) evolving Re-verify from "re-check one finding in place" into "refresh the whole page to the current revision, cheaply." This resolves the mixed-revision display seam review flagged on #109: folding an N+1 re-verify verdict into a report loaded at revision N leaves the card's verdict fresh while the report header, raw report, and "show citation in article" link still read N.
(snapshot_hash, claim)) as a read-through in ADR-0011's pipeline. Decisions: in-memory/process-scoped (§2); no panel fingerprint since the panel is session-fixed (§3); re-fetch the article but reuse session-cached source bodies (§4); no force-refresh bypass — a second-opinion re-roll is a separate future control (§5). Builds on ADR-0009, extends ADR-0011.Type
Validation Required
Docs-only. Ran the doc gates:
Risk
Docs-only; adds ADR-0019 and amends PRD-0014. No code or runtime behavior changes.
Notes For Reviewers
citation-repair-browser-surfacebranch (not yet onmain), so this PR bases on that branch. Merge after Add citation repair/insertion action row to the Citations tab (PRD-0014) #109, or retarget tomainonce Add citation repair/insertion action row to the Citations tab (PRD-0014) #109 lands.verdict_storage_key/store_verdict/load_verdictinstorage.rs, currently dormant); the "Decision" section is where the real choices live (in-memory scope, no panel fingerprint, no bypass, the fetch model).🤖 Generated with Claude Code
Generated by Claude Code