A tender freshness assessment is a time-bounded decision about a derived listing, not a verdict on the procurement itself. It fixes the record, official procedure and lot identity, intended downstream use and assessment time; separates the source publication, source modification, observation, ingestion, normalization and last-verification clocks; checks for newer official notices, changed documents, deadline conflicts and broken provenance; and returns fresh_for_discovery, fresh_for_triage, revalidation_required, superseding_event_found, identity_unresolved or source_unavailable. The result states what the copied record may support, when it expires and which official check comes next. It never silently changes the record or translates a stale signal into open, closed, cancelled or replaced.
A listing can look current because it was scraped five minutes ago while still carrying an initial notice published three weeks earlier. Another can be six months old and remain an accurate historical award record. Age alone does not establish staleness. The decisive question is whether the evidence remains adequate for the proposed use. A title and buyer name may be enough to create a discovery lead, but not to start pricing, download the controlling pack or rely on a deadline. Search indexes, alert emails and aggregators often preserve the original card after the authority publishes a change notice, result, cancellation or replacement. If a system overwrites the old value without recording the event, it also destroys the evidence needed to explain why a bid decision changed.
Treat freshness as a relationship between evidence, time and action. Preserve the derived record exactly as observed, then reopen the official publication route using stable identifiers. Compare notice and procedure identities before comparing values. A later official event is stronger than a recent aggregator timestamp. An HTTP ETag or Last-Modified value can show whether one web representation changed, but it does not certify the procurement state or every linked document. An agent may retrieve public sources, issue conditional GET requests, compare versions and content fingerprints, and recommend revalidation. It must not edit the pipeline record, stop a pursuit, contact the buyer, accept portal terms or change submission data without the appropriate authority.
Direct answer
A tender listing is stale when its evidence no longer supports the next decision
Do not start with a universal age limit. Start with the action. A copied title, buyer and official identifier can remain useful as a discovery lead long after its response window. The same record is unfit for mobilization if nobody has checked the current notice, deadline and document route. Freshness therefore belongs to a use, not to the row in isolation.
Use revalidation_required when age, missing provenance or a material mismatch prevents the proposed use but no newer official event has yet been proved. Use superseding_event_found only after a later official notice or portal event has been connected to the same procedure and relevant scope. That state still does not say what the event means. Route an extended deadline to the open-status and time-zone checks, a change notice to amendment review, and a cancellation or successor candidate to disposition review.
A record can be fresh_for_discovery while barred from triage. It can be fresh_for_triage yet require another check before submission. Make that boundary machine-readable. “Verified recently” is too vague for an agent and too weak for an audit.
| State | Evidence | Permitted use | Next step |
|---|---|---|---|
| fresh_for_discovery | Identity and official locator are credible | Create or retain a labelled lead | Open the official source before qualification |
| fresh_for_triage | Current official identity and core fields agree through checked_at | Run initial opportunity assessment | Recheck before a material or time-critical action |
| revalidation_required | Fitness for the named use is not supported | Preserve only as an unverified lead | Retrieve the defined official evidence |
| superseding_event_found | Later official event matches procedure and scope | Do not rely on the earlier field operationally | Classify the event in the specialist workflow |
| identity_unresolved | Record and candidate source cannot be safely connected | No merge or current-state claim | Run tender identity resolution |
| source_unavailable | Required official evidence cannot be inspected | No material reliance | Assign access and retry ownership |
Time model
A recent timestamp may describe the copy rather than the tender
Keep at least three layers of time. Event time describes when the authority dispatched, published or changed a notice. Observation time says when your system retrieved a representation. Processing time covers ingestion and normalization. Verification time marks the last moment when a defined official comparison passed. These clocks answer different questions and should never share one “updated” field.
The current eForms model demonstrates the distinction. Notice metadata includes the notice identifier, version, procedure identifier, dispatch date and OJ S publication date. The submission deadline is a separate business term at lot level. A crawler that fetched the notice today has not changed any of those facts. It has only created a new observation.
Derive record age from the relevant clock and retain the calculation rule. Source age can help schedule a check. Verification age determines whether a prior comparison still meets your operating policy. Deadline distance changes the cost of being wrong. None of those calculations can replace a search for a later event.
| Field | Meaning | Common error |
|---|---|---|
| source_published_at | Official event publication time | Replacing it with scrape time |
| source_modified_at | Publisher-declared change time when available | Assuming every semantic change updates it |
| observed_at | Time one representation was retrieved | Calling the underlying facts current |
| ingested_at | Time the copy entered the system | Displaying it as buyer update time |
| normalized_at | Time a transformation ran | Treating processing as verification |
| last_verified_at | Time the named comparison last passed | Omitting the sources and checks used |
| valid_until | Policy boundary for a named use | Presenting it as a buyer deadline |
Source comparison
Search the official history before comparing visible fields
Begin with stable identity. Procedure, notice, notice version, publication identifier, lot and buyer reference are stronger connectors than title similarity. A later record for the same buyer and subject can be another lot, a recurring procurement or a separate procedure. If identity remains uncertain, return identity_unresolved and preserve both candidates.
eForms Change Notices are consolidated reproductions of the parent notice. They receive their own notice identifier and use BT-758 to reference the notice and version being changed. That structure lets an agent prove that a later publication belongs to the earlier notice instead of inferring the relationship from dates. The change section can also say that procurement documents changed, which matters even when the copied headline fields are identical.
OCDS makes the same temporal principle explicit through another model. Releases are immutable events. A record indexes all releases, while compiledRelease represents the latest values at the time the record was published. Tags distinguish tender updates, amendments and cancellations. An agent reading one old release should not treat it as a current snapshot, and an agent reading a compiled release should retain the releases that explain how the value changed.
Compare material fields only after the relationship is proved: deadline, lot scope, submission route, document version, value, procedure stage and status. Record each difference as a candidate change with its source and observed time. Do not patch the aggregator row during the assessment.
Technical evidence
ETag and Last-Modified validate a representation, not the whole procurement
HTTP conditional requests are useful. Store ETag and Last-Modified with the URL and representation. A later request can use If-None-Match or If-Modified-Since, and a 304 response can avoid downloading an unchanged representation. RFC 9110 defines those fields as validators for the selected representation. That scope is important.
A notice page can remain byte-for-byte unchanged while a linked document, Q&A area or separate change notice is published. A dynamic page may change without sending a reliable validator. Content negotiation can also produce several representations of one resource. Treat the validator as one observation in the evidence graph, not as the freshness decision.
When validators are absent, a normalized content fingerprint can show that selected material fields changed. Store the extraction version and the fields included in the fingerprint. A matching hash proves only that the hashed content is equal to the earlier observation. It does not prove that the official history contains no later event.
An agent-friendly record should expose source URLs, typed relationships, all relevant timestamps, raw and normalized values, the extraction method and an explicit list of checks not performed. This lets another agent decide whether to reuse the observation or revalidate it without guessing what “synced” meant.
Worked example
A recently fetched card can still lag behind a change notice
A fictional alert service records a city cybersecurity tender on 4 October. Its card says active and gives 14 October at 12:00 as the deadline. The service fetches the same card again on 10 October, so ingested_at is recent. Its source event and deadline have not changed, and the card does not expose a notice version.
The official publication search returns version 01 from 3 October and a Change Notice published on 9 October. BT-758 connects the change to version 01. The consolidated notice moves the lot deadline to 21 October at 12:00 and states that the procurement documents changed. The procedure and lot identifiers match the card.
The assessment preserves the 14 October claim with its alert-service observation. It adds the later official event and returns superseding_event_found for deadline and document-pack use. It does not rewrite the card to 21 October, declare the tender open, or claim that every amendment has been collected.
The next actions are typed. The deadline goes to the dated open-status check, including time-zone review where needed. The changed-document signal goes to the amendment completeness register. The opportunity can remain a discovery lead, but the copied deadline is prohibited from planning or submission.
| Evidence | Observed fact | Assessment effect |
|---|---|---|
| Alert card | Fetched 10 October; deadline 14 October | Recent copy of an older claim |
| Official version 01 | Published 3 October | Identity anchor for the original |
| Change Notice | Published 9 October; references version 01 | Proved later event |
| Consolidated deadline | 21 October at 12:00 for the same lot | Copied deadline cannot be reused |
| Document-change indicator | Procurement documents changed | Run amendment completeness review |
| Freshness state | superseding_event_found | Preserve lead; block material reliance |
Agent contract
Return fitness for use, evidence age and the next official check
An inspectable output contains assessment_id, record_id, intended_use, assessed_at, source_role, source_url, source_record_id, procedure_id, notice_id, notice_version, lot_ids, source_published_at, source_modified_at, observed_at, ingested_at, normalized_at, last_verified_at, representation_etag, representation_last_modified, content_fingerprint, advertised_deadline_raw, candidate_events, material_differences, freshness_state, allowed_uses, prohibited_uses, valid_until, confidence, review_owner and recheck_trigger.
The agent may retrieve anonymous public sources, use documented APIs, follow official references, compare machine-readable fields, issue conditional requests and generate a diff. It stops when official identity is unresolved, a required source needs credentials, robot or rate limits prevent inspection, the source relationship is ambiguous, or the proposed action requires a specialist current-state decision.
Updating a CRM record, deleting a listing, ending bid work, accepting access terms, using credentials, contacting the buyer or submitting a response requires separate authorization. The freshness output supplies evidence to those workflows. It does not execute them.
What good looks like
Useful outcomes from stale tender listing
- Every freshness claim names the record, procedure, lot, intended use and assessment instant.
- Publication, modification, observation, ingestion and verification times remain separate.
- A recent scrape no longer disguises an old or superseded source event.
- Official notice identifiers and versions control comparisons instead of similar titles.
- Later change, result and cancellation candidates are preserved as events for specialist checks.
- Deadline conflicts trigger revalidation without automatically changing opportunity status.
- HTTP validators and content fingerprints are used as transport evidence, not legal conclusions.
- Each result carries allowed uses, prohibited uses, an owner and a next-check trigger.
- Derived records remain auditable instead of being silently corrected in place.
Operating model
How to run the work
- 01
Fix the record and intended use
Capture the listing exactly as observed, identify the decision it is meant to support and record the assessment time with an offset.
- 02
Separate the clocks
Record source publication and modification times, your observation time, ingestion time, transformation time and last verified time without substituting one for another.
- 03
Resolve official identity
Match procedure, notice, version, buyer and lot identifiers before treating any newer publication as part of the same procurement.
- 04
Search for defeating evidence
Check the official notice history, operational portal and linked records for later versions, changed documents, results, cancellation signals or deadline differences.
- 05
Classify fitness for use
Return the narrowest supported freshness state and state exactly which downstream uses remain permitted or require another official check.
- 06
Preserve and schedule
Keep the original observation and candidate events, name the review owner and set a recheck trigger based on source change, decision risk and deadline proximity.
Evaluation
Questions that change the decision
- Which observed record and exact fields are being assessed?
- What decision or action is the record expected to support?
- Which procedure, notice version and lot does the record claim to describe?
- When did the authority publish or modify the underlying information?
- When was the source observed, ingested, normalized and last verified?
- Does the official source expose a later version or related lifecycle event?
- Do deadline, document, status or scope fields disagree materially?
- Does a content fingerprint or HTTP validator show a representation change?
- Is the remaining evidence adequate for discovery, triage or neither?
- Which dedicated verification must run before the next material bid action?
Failure modes
Where teams lose control
A current ingestion timestamp is mistaken for a current notice.
An old but accurate historical record is marked stale solely because of age.
A similar title causes an unrelated notice to be treated as an update.
A passed copied deadline is converted to closed without checking for an extension.
A later award or change notice is ignored because the original competition page still resolves.
A portal redirect or temporary error is treated as withdrawal.
A 304 Not Modified response is read as proof that no procurement fact changed elsewhere.
A changed attachment keeps its filename and escapes a URL-only comparison.
An agent overwrites the observed record and removes the evidence of source lag.
A discovery-grade record reaches pricing or submission without a stronger check.
Measurement
Measure the finished job
Measure the completed workflow, including review effort and exceptions. Output volume on its own is not evidence of a better process.
- freshness assessments with named downstream use and assessed-at time
- observations carrying distinct source, ingestion and verification clocks
- records matched through procedure, notice, version and lot identifiers
- superseding candidates preserved with typed relationship and official source
- material field conflicts routed before bid work begins
- freshness states with allowed uses, expiry and next-check trigger
- conditional requests paired with semantic source checks
- silent record overwrites prevented by append-only observations
Questions
Common questions
How old can a tender listing be before it is stale?
There is no reliable universal age. Judge whether the record’s evidence still supports the named use. A historical award can remain accurate for years, while a competition card can become stale minutes after an official change.
Does a recent scrape mean the tender data is current?
No. It proves when the copy was retrieved. Check the underlying event, notice version, official history and material fields before describing the procurement information as current.
Is a passed deadline proof that the listing is stale?
It is a strong revalidation trigger, not a complete status decision. The buyer may have extended the deadline, the field may refer to another stage or lot, or a later notice may have changed the procedure.
Can an agent replace an old deadline with the official one?
Not silently. Preserve the old observation, attach the later official event and route the controlled record update through the authorized workflow. Keep the source and change history auditable.
Does HTTP 304 Not Modified prove nothing changed?
It says the selected representation validated against the stored HTTP condition. It does not cover separate notices, linked documents, private portal messages or facts omitted from that representation.
What is the difference between stale and closed?
Stale describes whether a copied record is fit for a use. Closed describes the procurement response state after a dedicated official check. A stale active card might point to an extended deadline, a closed procedure or another event.
Should an aggregator record be deleted when a later event appears?
No automatic deletion follows from the freshness assessment. Retain the observation as provenance, connect the later event and let the authorized data-retention and pipeline workflow decide presentation.
When must the listing be checked again?
Set the trigger from the next use, source volatility and deadline distance. Always revalidate before relying on a copied deadline, controlling document, status or submission route for a material action.
Sources
Primary references
- OCDS guidance on releases and records Open Contracting Partnership
- OCDS release and tender-status codelists Open Contracting Partnership
- OCDS guidance on updates and amendments Open Contracting Partnership
- TED eForms notice metadata and identifiers Publications Office of the European Union
- TED eForms Change Notice structure Publications Office of the European Union
- TED Search API for published procurement notices Publications Office of the European Union
- RFC 9110 on HTTP representation validators RFC Editor
About the author
Tony Kim
Tony writes about applied AI, dependable product engineering and the systems that turn complex response work into controlled delivery.
Zelius
Managed tender intelligence and bid execution for teams that want the commercial outcome.
Suppliers, founders and commercial teams pursuing public or private opportunities. Start with the workflow, constraints and evidence you already have.