Public resource · verification terms
Verification glossary: the difference between documented, accepted, unavailable, blocked, and untested
Clear status language makes a checkout archive more useful: each label should describe an observed event, not a desired marketing outcome.
Documented and accepted
Documented means the site recorded a specific permitted cart-only event with an event time, method, code, visible response, and limitation note. Accepted means the storefront displayed a success response for the code in that observed cart context.
Neither term means that a customer completed payment, that every item is eligible, or that the result will repeat for all visitors. The cart event is the scope of the claim.
Unavailable, blocked, and untested
Unavailable describes a condition in which no suitable currently purchasable item or required cart element could be observed. Blocked describes a normal-path limitation such as a storefront control or protective measure that prevents the permitted test. Untested means no documented event was run for the claimed period.
These are not negative marketing labels. They are transparent states that prevent an archive from pretending every calendar date produced a successful check.
Manual review required
Manual review required means the visible outcome is ambiguous, the storefront has changed, or an automated process should not make a public status claim without a human assessing the source record. It is a safeguard against converting uncertainty into a green badge.
This glossary describes the site’s evidence language only. It does not make a checkout promise or instruct readers to bypass any merchant control.
Evidence labels have both a threshold and a limit
Every archive label should say two things: what evidence threshold was met and what the label does not establish. “Accepted,” for example, requires a documented cart context and visible discount, but it does not establish completed payment or universal eligibility. “Stock unavailable” identifies why no suitable test occurred, but it does not establish code rejection. These paired meanings stop the labels from being used as marketing shorthand.
The glossary also supports consistency over time. A later run should not receive an accepted status merely because the code name is familiar, and an ambiguous page should not be called blocked just because the result was inconvenient. Defining the threshold before the event makes it harder for a desirable outcome to change the classification after the fact.
Observed and inferred facts must stay in different columns
The archive’s vocabulary separates what the screen directly showed from what a reader might infer. A product name, subtotal, discount line, payment label, tax line, timestamp, and screenshot are observed fields. Eligibility, payment approval, fulfilment, future availability, and the reason behind an opaque storefront response are often inferred or unknown fields. The labels are designed to prevent those categories from merging.
This distinction has practical consequences. An accepted event can be published when its observed fields meet the stated threshold, even though many downstream facts remain unknown. Conversely, a tempting conclusion must be withheld when the core observation is incomplete. The glossary makes those decisions legible before an event is recorded.