Price and Stock Freshness: Defining a Trust Window

A price or a stock level is only reliable if you know when it was produced, when it was collected, and whether the collection was complete. Define separate trust windows by supplier, field type, and use case: automatic purchasing, a manual alert, or simple historical analysis. There is no universal duration. Stock can change faster than product specifications, and an old price can still be contractually valid. Beyond the chosen window, don't replace the value with zero: mark it "to confirm" or "stale," block actions incompatible with that level of proof, and require a recent observation before ordering.

Three timestamps instead of a vague "last updated"

Freshness is often reduced to the script's execution date. That is not enough. A successful 10 a.m. collection can download a file produced the day before, itself based on a business system updated at an unknown cadence. Keep, as far as possible, three distinct points in time:

• source_generated_at: the date declared by the supplier for the data or file;
• observed_at: the moment your system received the response;
• validated_at: the moment the content passed controls and became usable.

If the first timestamp doesn't exist, don't replace it with the download time. Explicitly note source_generated_at=unknown. The HTTP ETag and Last-Modified validators, described by RFC 9110, can help determine whether a representation has changed when the server provides them correctly. They do not, however, alone prove when the business-level price or stock was actually refreshed.

Treat each data family separately

A product sheet combines elements that don't change at the same speed. Brand, title, or GTIN are generally used as identity data; price, availability, lead time, and discounts are offer data. A single global date masks these differences.

The InStock status deserves special attention. Schema.org defines it as an indication that the item is in stock, but this convention provides neither a quantity nor a timestamp. The age of the observation therefore remains essential. The distinction between boolean stock and exact quantity must be kept in addition to freshness.

Building a trust policy without inventing a standard

Start with the risk of the action. A search page viewed by a human can display older data with a clear warning. An order triggered without verification requires more recent proof and stronger contractual guarantees. Then define an internal window for each source × field × use case combination, and document who approved it.

Here is an entirely hypothetical example meant to show the structure, not recommended durations. A team might decide that stock observed less than two hours ago is "fresh" for an alert, that between two and eight hours it is "to confirm," and that beyond that it is "stale." For a monthly contractual price, it might apply a different rule. These numbers come from no standard: they must be replaced with thresholds derived from your observed cadence, your contract, and your risk tolerance.

The calibration procedure matters more than the initial number:

1. Log every collection as successful, partial, or failed. 2. Measure the intervals between actually observed changes, field by field. 3. Track rejected orders, price discrepancies, and stockouts after observation. 4. Choose a cautious, explicit initial threshold for the studied use case. 5. Show the date and status to the user, not just a score. 6. Revise the threshold based on incidents and new evidence.

A policy should never declare a value fresh just because the job started. It depends on a valid, complete response attributable to the right source.

Handling partial collections and silences

A smaller-than-usual file can be a genuine catalog reduction or an interrupted export. An API can respond 200 OK while returning an empty page because of a mishandled cursor. Freshness must therefore include a completeness check: expected volume as an observed range, page count, presence of critical fields, and identifier stability.

If the check fails, keep the last validated value with its old timestamp. Do not attach the failure time to the retained data. Log last_attempt_at, last_success_at, and the exact reason separately. This is what lets you tell a silent source apart from a genuinely out-of-stock product.

The choice of CSV, XML, API, or FTP feed format influences the recovery strategy, but not the fundamental rule: a data point's timestamp only moves forward when a relevant, validated observation justifies it.

Presenting uncertainty without a misleading score

An overall score can help sort things, provided it stays explainable. Display real age, the available timestamp, the stock type, and recent incidents next to any color code. A green gauge with no detail turns an internal choice into an implicit promise.

Prefer three operational states: usable_for_analysis, confirmation_required, and blocked_for_action. The rules leading to these states should be readable. A supplier reliability score can incorporate freshness, but must never erase a critical failure or a missing field.

Freshness checklist

• ☐ Source, observation, and validation dates are kept separate.
• ☐ Price and stock have their own statuses.
• ☐ A missing timestamp is marked unknown.
• ☐ An ETag is not presented as a business date.
• ☐ Thresholds are internal, approved, and revisable.
• ☐ Completeness is checked before declaring the collection successful.
• ☐ An error does not refresh the last valid value.
• ☐ The real age remains visible next to the score.
• ☐ A recent confirmation is required before ordering.
• ☐ Incidents feed into the policy's revision.

What ArbitragePro+ can automate / what the seller must verify

The proposed score-fraicheur specification could calculate the age of observations, apply configured thresholds, flag partial collections, and block the use of a stale value. It should always expose the timestamps and the rule that produced the status.

The seller must define the windows suited to their contract and risk, confirm price and availability before purchase, and then decide how to handle cases where the source offers no business timestamp.

Monitor source health

View source health to review the collection information and alerts currently available.

Official sources

• IETF, RFC 9110, «HTTP Semantics», https://www.rfc-editor.org/rfc/rfc9110.html — accessed 2026-08-17.
• Schema.org, «ItemAvailability», https://schema.org/ItemAvailability — accessed 2026-08-17.
• Schema.org, «InStock», https://schema.org/InStock — accessed 2026-08-17.