rag-contract question answering over a fixed corpus, with a measured contract

← the fixed question set

What distinguishes a strong validator from a weak validator?

q06 · grounded · HTTP 200 · index 0fc1763d6701

What survived the check — each claim with the passage that supports it

A strong validator is representation metadata that changes value whenever a change occurs to the representation data that would be observable in the content of a 200 (OK) response to GET.
rfc9110#8.8.1 — 100% of this claim's content words appear in that passage.
A weak validator is representation metadata that might not change for every change to the representation data.
rfc9110#8.8.1 — 100% of this claim's content words appear in that passage.
Strong validators are ideal for comparisons but can be very difficult, and occasionally impossible, to generate efficiently.
rfc9110#8.8.1 — 100% of this claim's content words appear in that passage.
Weak validators are easy to generate but are far less useful for comparisons.
rfc9110#8.8.1 — 100% of this claim's content words appear in that passage.
A strong validator is unique across all versions of all representations associated with a particular resource over time.
rfc9110#8.8.1 — 100% of this claim's content words appear in that passage.
A validator is weak if it is shared by two or more representations of a given resource at the same time, unless those representations have identical representation data.
rfc9110#8.8.1 — 100% of this claim's content words appear in that passage.
Strong validators are usable for all conditional requests, including cache validation, partial content ranges, and lost update avoidance.
rfc9110#8.8.1 — 100% of this claim's content words appear in that passage.
Weak validators are only usable when the client does not require exact equality with previously obtained representation data, such as when validating a cache entry or limiting a web traversal to recent changes.
rfc9110#8.8.1 — 100% of this claim's content words appear in that passage.

What was retrieved — the passages the drafter saw, and nothing else

ranksectionscore
1 RFC 9110 Section 8.8.1: Weak versus Strong 0.7414
5 RFC 9110 Section 8.8.2.2: Comparison 0.5362
6 RFC 9110 Section 17.14: Validator Retention 0.4961
7 RFC 9110 Section 8.8.3.2: Comparison 0.4484
8 RFC 9111 Section 4.3.4: Freshening Stored Responses upon Validation 0.4438
9 RFC 9111 Section 4.3.1: Sending a Validation Request 0.4198
10 RFC 9110 Section 8.8: Validator Fields 0.4130

What this request spent — against the deadline it was held to

7.61 ms of a 150.0 ms deadline: retrieval 0.413 ms, drafting 0.005 ms, grounding 6.966 ms. A request that spends the whole of it is abandoned rather than answered — a grounding check stopped part way through has not checked the remaining claims.

The same answer as JSON: /answer/q06.