---
title: "How to verify a tender that an AI agent found"
description: "Preserve the agent answer as a lead, trace it to dated official evidence and verify each opportunity claim without hiding contradictions or broken links."
canonical: "https://zephior.com/insights/build-provenance-for-an-agent-found-tender"
last-updated: 2026-09-03
---

# How to verify a tender that an AI agent found

> Preserve the agent answer as a lead, trace it to dated official evidence and verify each opportunity claim without hiding contradictions or broken links.

By [Tony Kim](https://zephior.com/authors/tony-kim). Published 2026-09-03; updated 2026-09-03. 24 minute read.

## Definition

An opportunity provenance record is the chain of evidence between an agent-produced lead and the official public representations used to check it. The record preserves the agent output, the query or task that produced it when disclosure is allowed, displayed citations, redirect hops, retrieval activities, publisher and source roles, notice and procedure identifiers, observed representations, extraction steps and verification results. Each material claim has its own state: verified, contradicted, unresolved or not checked. The record also carries time, language, media type, version and a fingerprint for every captured representation. A fingerprint can show that two reviewers examined the same bytes. It cannot prove that the publisher was authorized or that the facts were correct. Provenance makes the reasoning inspectable; source authority and factual verification still require separate evidence.

## Problem

An AI agent can return a plausible tender in seconds, often with a title, buyer, deadline and link. That compact answer hides several transformations. The agent may have used a search snippet, an aggregator card, a cached translation, a structured feed or a previous crawl. Its displayed link may redirect to a search page, a changed notice, a login wall or a document whose relationship to the opportunity is unknown. A correct title can sit beside an expired deadline. An existing procedure can be attached to the wrong lot. A citation can support publication but not current open status. If a reviewer replaces the original answer with corrected values, the team loses the evidence needed to explain what the agent found and why the correction was made. If the reviewer accepts the answer unchanged, an unverified lead becomes a bid decision. Both failures come from collapsing discovery, lineage, authority and verification into one field.

## Point of view

Treat the agent answer as an observed lead, never as an official record and never as disposable scratch text. Freeze it before browsing. Resolve each cited or displayed locator, preserve the transformations, and reach a source whose publication role can be established. Then verify claims separately. Identity, deadline, lot, status, documents and submission route can reach different results because one representation rarely controls them all. Keep the agent claim and the official observation in separate fields. Record a contradiction instead of silently correcting it. Record an evidence gap instead of borrowing confidence from the rest of the notice. An agent may perform public retrieval, calculate fingerprints, compare identifiers and draft the provenance record. It may not enter a restricted account, accept terms, contact a buyer, infer a missing legal relationship, decide to bid or act on submission instructions without the required authorization.

## Keep the agent answer unchanged before checking it

Begin with a read-only copy of what the agent returned. Store the full answer, not only the sentence that looked useful. Include the title as displayed, buyer, deadline, amount, geography, lot, status, links and any language that indicates uncertainty. Record the observation time with an explicit offset. If the system exposes a run ID, model or tool version, retrieval mode and query, retain those fields when policy and confidentiality rules allow. If they cannot be retained, say so. “Query not retained under policy” is useful evidence. A blank field is not.

The lead layer must survive correction. Suppose the answer says that a tender closes at 17:00 on 14 October and the official notice says 12:00 on that date. The provenance record keeps both statements. The agent assertion becomes contradicted, while the official assertion carries its source and observation time. Replacing 17:00 with 12:00 inside the original text would make the final record look cleaner, but it would erase the failure that a reviewer or search maintainer needs to understand.

Preserve citations as they were displayed. A markdown link, numbered footnote, bare URL and search result card are different evidence objects. Keep the display text and target separately because the text may name one publisher while the URL reaches another. Do not copy session identifiers, bearer tokens, signed download parameters or private conversation text into a shareable record. Store a redacted locator and the reason for redaction when the original contains a secret. The public record should say that restricted evidence exists without disclosing it.

This first capture proves only that a system produced a lead at a certain time. It does not prove that the tender exists, that the cited page supported the answer or that the agent consulted the displayed citation. Those questions belong to the retrieval and verification layers.

**Lead capture fields that must not be rewritten after verification**

| Field | Recorded value | Reason |
| --- | --- | --- |
| lead_id | Locally unique immutable identifier | Lets later activities refer to the same observed answer |
| produced_by | System, agent or workflow name and disclosed version | Assigns responsibility without assuming accuracy |
| observed_at | RFC 3339 timestamp with offset | Anchors a changing answer and its citations |
| input_disclosure | Retained, redacted, unavailable or prohibited | Explains whether the search can be replayed |
| assertions | Exact claim text plus structured raw value | Prevents a later correction from replacing the claim |
| displayed_citations | Label and target exactly as rendered | Preserves what the recipient could inspect |

## Represent the path as entities, activities and responsible actors

A provenance record becomes easier to audit when it distinguishes things from actions. W3C PROV uses three useful starting concepts. An entity is a thing with fixed aspects, such as the frozen agent answer, an HTML response, an XML notice, a PDF or extracted text. An activity occurs over time and uses or generates entities, such as a search, HTTP retrieval, redirect resolution, download, OCR run, translation or field extraction. An agent bears responsibility for an entity or activity. Here that may be the AI system, the public publisher, the reviewing person or an approved translation service.

You do not need RDF to use the model. A table with stable local identifiers and typed edges is enough. Record that a retrieval activity used a displayed locator and generated a captured HTML representation. Record that an extraction activity used that HTML and generated a normalized assertion set. Record that the assertion set was derived from the representation, and name the system or person associated with the activity. The edges matter because a final fact can otherwise appear to come directly from an official XML file even when it passed through an unrecorded translation and summarizer.

Web resources change with time, language and request context. W3C PROV-AQ treats provenance for dynamic or context-dependent resources through constrained resources. In practice, capture the final URL, retrieval time, request language or accepted media type when relevant, response media type, declared language, publication or version identifier and digest. Keep every visible redirect hop. A generic landing-page URI and the English HTML representation reached on 3 September are related, but they are not interchangeable evidence objects.

Responsibility also needs a narrow meaning. The Publications Office can be responsible for a TED representation. The contracting authority is responsible for the procurement content it issued. A reviewer is responsible for the verification activity. The research agent is responsible for a captured extraction. None of those assignments implies that every actor endorses the downstream conclusion. Name the role beside the relationship.

**A small provenance vocabulary for tender verification**

| Object | Example | Relationship to preserve |
| --- | --- | --- |
| Entity | Frozen agent answer | Generated by the original agent run |
| Entity | Captured official XML notice | Generated by a dated retrieval |
| Activity | Redirect resolution | Used the displayed URL and generated a final locator |
| Activity | Field extraction | Used one representation and generated structured assertions |
| Activity | Human verification | Used assertions and official evidence to generate claim states |
| Agent | Public publisher | Attributed to the published representation |
| Agent | Research system | Associated with retrieval or extraction |
| Agent | Named reviewer | Associated with the verification decision |

## Trace the lead to an official representation without skipping the route

Open the citation in a clean browser or client with no inherited login state. Record the initial URL, each HTTP redirect that the client exposes and the final URL. If a search page requires a query, store the query and selected result. If content negotiation returns HTML for a browser and XML for a data client, capture the representation you used and its media type. A final official URL does not erase an aggregator or search engine from the chain. The secondary page remains the entity from which the lead was derived.

Next, establish the role of the official source. TED states that its Search API provides unauthenticated access to published procurement notices for analysis and reuse. TED Open Data also exposes official notice data in original XML, HTML, PDF and Linked Open Data. Those are useful official representations, but their format does not answer every operational question. Procurement documents, buyer messages and the submission route may live on a separate portal named by the notice. Record the TED evidence for the claims it supports and follow the designated source for the rest.

An official API response can still be a derivative view with a stated coverage limit. Preserve the endpoint documentation, request body or query, requested fields, page or cursor, response time and returned record identifier. If the endpoint returns only published notices, do not infer that absence proves a notice was never submitted or that a procedure does not exist elsewhere. If the response is a compiled record, keep the release history when the decision depends on change over time.

Source authority needs a separate investigation when the publication roles are unclear. The guide to identifying the official tender notice determines which publication controls a named fact. This provenance record consumes that decision and preserves its evidence in the chain. If authority remains unresolved, the claim cannot become verified here. The record says which source was examined, which relationship could not be proved and what review is still required.

**Source roles inside the provenance chain**

| Role | What it can prove here | What it cannot prove by itself |
| --- | --- | --- |
| Original agent citation | What the recipient was shown | That the target was consulted or authoritative |
| Secondary index | Discovery path and displayed secondary metadata | Current buyer instructions |
| Official publication representation | Fields published by that service in the captured version | Facts outside the service function or version scope |
| Designated operational portal | Documents or instructions within its buyer-designated role | Unrelated statutory publication facts |
| Retained representation | What bytes or rendered content the reviewer examined | That the publisher still serves the same content now |

## Bind the notice, procedure and lot before verifying any value

An agent can find the right procurement family and still cite the wrong object within it. TED eForms gives the notice its own identifier and version, while the procedure identifier names the wider procurement procedure. A change notice can refer to the notice version it changes. A lot has another scope. Preserve these identifiers separately, including the scheme and source that issued them. Joining on a title or buyer name is too weak for a verified chain.

Record the local identity claim made by the agent, then the identifiers observed in each official representation. State the match rule. A notice publication number can provide an exact retrieval key. A procedure UUID can connect competition, change and result notices without making them equivalent. A lot ID prevents a deadline or requirement from leaking from one lot to another. If the lead cites an award notice while describing an open competition, the procedure may be real but the opportunity claim is contradicted or unresolved.

OCDS makes the same distinction in another data model. Its OCID is globally unique for a contracting process. A release ID is unique within that process, and releases are immutable events. A record indexes releases and may provide a compiled view of current values plus versioned history. When an agent cites a compiled record, preserve the release or observation that supplied the checked value. The OCID alone cannot prove which historical value the agent used.

Stable-link recovery and duplicate detection have their own outputs. The stable-link guide creates a durable recovery route. The duplicate-notice guide determines whether records are duplicates or related objects. This provenance record stores the chosen identifiers, relationship result and evidence. It does not repeat those decisions when the relationship is uncertain.

## Give each material claim its own result

Break the agent answer into atomic assertions. “The Ministry is seeking maintenance services under a two-year contract, with bids due at noon on 14 October” contains at least four claims: buyer, scope, duration and deadline. The lot and open status may be implied and need separate rows. Keep the agent wording, a normalized value when safe, the source cited by the agent and the official observation used for review. A paragraph-level green check hides which part was confirmed.

Use a small state set. Verified means an authorized source directly supports the claim for the bound notice, version and lot at the observation time. Contradicted means authorized evidence states a materially incompatible value. Unresolved means the evidence is missing, ambiguous, inaccessible or in conflict. Not checked means the claim was deliberately outside this review. Do not turn an unresolved claim into a negative. Failure to find a value is not proof that the value is false.

The evidence reference should identify a field, table row, heading or short quoted passage, not only a homepage. Store the raw source value before normalizing dates, currencies, organization names or codes. If a deadline is checked, call the deadline and time-zone dossiers rather than hiding a guessed offset here. If open status, amendments or documents matter, attach the result from their dedicated review. The provenance record ties those decisions to the original lead and preserves their evidence.

A complete-looking answer can therefore end with mixed states. Buyer and procedure may be verified; deadline contradicted; lot unresolved; status not checked. That is a useful result. It tells a qualification reviewer exactly what can enter working data and what still needs attention.

**Claim verification ledger**

| Field | Required content | Rule |
| --- | --- | --- |
| claim_id | Stable local identifier | Never recycle it after correction |
| agent_assertion | Exact words and displayed value | Keep separate from normalized data |
| scope | Procedure, notice, version and lot | No inherited parent scope without evidence |
| official_observation | Raw value and exact evidence pointer | Do not paraphrase away qualifications |
| state | Verified, contradicted, unresolved or not checked | One state per atomic claim |
| reason | Short testable explanation | Name the mismatch or missing evidence |
| observed_at | Timestamp with offset | Never substitute publication date |
| reviewer | Responsible person or approved system | Name who made the comparison |
| expires_on | Event or maximum age | Force a new observation when it fires |

## Use fingerprints to identify evidence, not to certify truth

Calculate a cryptographic digest for every retained file or response body that supports a material conclusion. Name the algorithm and representation. A digest over the downloaded XML and a digest over text extracted from that XML cover different entities. If the evidence is an HTML page assembled dynamically, retain the response body or a documented capture as policy allows. A screenshot can preserve visible presentation, but it may omit links, hidden fields and machine-readable metadata. Record it as another derived entity.

HTTP validators have a narrower job. RFC 9110 defines ETag and Last-Modified as validators for a selected representation. They can support cache validation and later comparison. They do not establish the legal role of a publisher, connect a page to a procurement or certify that a deadline is correct. Keep the validator exactly as returned, including whether an ETag is weak. Pair it with the final URL, request context and observation time.

Transformations need their own outputs. OCR generates text from an image or PDF. Translation generates a language-specific rendering. Date parsing generates a normalized value from source text. Each activity should point to its input, output, responsible system, time and configuration that affects meaning. Keep the raw source beside the output. If the translated sentence changes a negation or the date parser lacks a time zone, mark the derived assertion unresolved even when the files have valid digests.

NIST describes content provenance metadata as potentially including the creator, creation time, location, modifications and sources. That is a useful checklist for the agent-produced lead and its transformations. NIST’s content-provenance discussion addresses origin and history of digital content; it does not turn an agent answer into an official tender source. State that boundary in the record.

## A TED citation can verify one claim and defeat another

Consider an illustrative lead returned on 3 September: a national transport buyer is seeking depot maintenance software; the agent names a competition, says bids close on 14 October at 17:00 and links to a translated search result. This is a fictional example, not a live opportunity. The reviewer freezes the complete answer and stores the displayed URL. A clean request follows the search link to an English HTML notice. The notice exposes a publication number, notice UUID, version and procedure UUID. Those identifiers become separate entities in the record.

The reviewer retrieves the same published notice through the TED Search API and retains the returned XML URL. The XML matches the buyer and procedure, so those two agent claims are verified. It places the described software in Lot 2, a detail the agent omitted. The deadline field for Lot 2 says 12:00 with an explicit zone, so the 17:00 assertion is contradicted. The reviewer does not edit the lead. The ledger links the contradiction to the exact XML field and records the HTML and XML as two official representations of the notice.

The agent also said the competition was open. The captured notice is a competition notice, but the provenance review does not assume that publication type proves current status. It calls the dedicated status check, which searches later related notices and the designated procurement source. Until that result returns, status stays not checked. The documents link leads to an operational portal that requires registration. The public notice proves the portal designation, but document completeness stays unresolved because the reviewer has no authority to create an account.

The handoff says: identity verified for the named procedure and Lot 2; buyer verified; agent deadline contradicted and official raw deadline preserved; current open status not checked; document completeness unresolved behind authorized access; no bid decision made. Another reviewer can reproduce every public step. The output is more useful than a single “verified” badge because it shows where the lead is strong and where it stops.

## Return the chain, the claim states and the stopping point

The top-level provenance state describes the chain, not the commercial attractiveness of the tender. Use complete_to_official_source when every material checked claim can be followed to an official representation and the source role is proved. Use complete_to_official_derivation when the chain ends in an official transformed dataset whose limits are adequate for the checked claims. Use broken_chain when a required transformation or locator is missing. Use source_unavailable when the identified source could not be observed. Use identity_conflict when the evidence does not bind the lead to one procurement scope.

Expose the record in a stable machine-readable form as well as readable prose. Include entities, activities, responsible actors, typed relationships, raw assertions, normalized values, evidence pointers, claim states and expiry conditions. W3C Data on the Web Best Practices recommends provenance information, version indicators, version history, persistent identifiers and machine-readable standardized formats. Those practices help another agent retrieve and interpret the record without depending on the visual page.

Do not publish private prompts, credentials, session URLs, buyer-confidential documents or personal data simply because a provenance schema has a field for them. Mark redactions and retention limits. If following a provenance link could disclose sensitive research interest to another service, require the appropriate permission. PROV-AQ specifically notes that provenance queries can reveal which resources a user is interested in.

The record expires when a later notice or version appears, a checked source changes, the deadline or status reaches its recheck threshold, the portal relationship changes or a reviewer discovers an identity conflict. Append the new observation and supersede the affected claim result. Keep the old entity and activity chain. History explains why the earlier result was reasonable at the time.

This record ends at a verified lead. The related guides separately establish source authority, current open status, the deadline and time zone, the latest amendment, a durable link, duplicate relationships and data freshness. Qualification, bid or no-bid, restricted access, buyer contact and submission remain separate authorized work.

**Top-level provenance states**

| State | Meaning | Permitted next use |
| --- | --- | --- |
| complete_to_official_source | Checked claims trace to an observed official representation | Use only the individual claim results within their expiry limits |
| complete_to_official_derivation | Checked claims trace to an official derived dataset with recorded limits | Use for claims inside the documented coverage |
| broken_chain | A required citation, redirect or transformation is missing | Research lead only |
| source_unavailable | The identified source could not be observed | Retry or obtain authorized access without promoting its claims |
| identity_conflict | The lead cannot be bound to one notice, procedure or lot | Quarantine until identity is resolved |

## Useful outcomes

- The original agent answer remains available with its wording, citations and observation time.
- Every redirect, retrieval and extraction that matters to the conclusion appears as a dated activity rather than an invisible transformation.
- Official, officially derived, secondary and unresolved sources remain distinct.
- Notice, version, procedure, buyer and lot identifiers retain their issuing scheme and scope.
- Each material opportunity claim receives its own evidence reference and verification state.
- Contradicted values remain visible beside the official observation that defeated them.
- Representation fingerprints support repeatable review without being misdescribed as proof of authority.
- Access limits, missing history and ambiguous relationships produce bounded unresolved states.
- The resulting lead can enter qualification without pretending that qualification or a bid decision has already happened.
- Another person or agent can repeat the public checks from the saved record.

## Workflow

1. **Freeze the lead.** Store the agent output exactly as received, its visible citations, task or query when policy permits, producing system, run identifier and observed time. Do not correct any value in this layer.
2. **Resolve every locator.** Open each public URL in a clean context, record redirects and content negotiation, and identify the final representation rather than saving only the first or last address.
3. **Classify the source role.** Establish who operates the source, what it publishes, whether the buyer designates it and whether the observed item is original, officially derived, secondary or unresolved.
4. **Bind the procurement identity.** Preserve notice, version, publication, procedure, buyer and lot identifiers with their schemes. Use explicit relationships and matching scope before joining records.
5. **Verify claims one by one.** Compare the claimed buyer, procedure, lot, deadline, status, documents and route with the source authorized for that fact. Cite the exact field or passage and keep the raw value.
6. **Record transformations and fingerprints.** Describe downloads, parsing, OCR, translation and normalization as activities. Store the observed media type, language, version, retrieval time and digest for each retained representation.
7. **Issue a bounded handoff.** Return the provenance state, claim states, unresolved checks, expiry triggers and the next authorized review. Keep bid qualification and portal action outside this record.

## Key decisions

- What exact output did the agent provide, and when was it observed?
- Can the originating query, tool, model or run identifier be retained under the applicable policy?
- Does each displayed URL resolve publicly, and what redirects or negotiated formats occur?
- Who publishes each representation, and what functional authority can be proved?
- Is a structured feed an official publication, an official derivation or a third-party transformation?
- Which identifiers name the notice, its version, the wider procedure, the buyer and the lot?
- Do the agent lead and official record concern the same procurement scope?
- Which source and passage support each claimed fact at the recorded time?
- Was any value translated, normalized, summarized, merged or inferred?
- Does the fingerprint cover the actual retained representation or only an extracted text file?
- Which claims are contradicted, unresolved or outside the review?
- What event or age makes the verification unsafe to reuse?

## Risks

- A convincing agent answer may be promoted directly into pipeline data.
- A search snippet may be mistaken for the page it summarizes.
- A redirect chain may end on a different notice, language or version than the displayed citation.
- An official domain may host a summary whose facts are controlled elsewhere.
- A machine-readable official feed may omit older releases or operational portal messages.
- One matching identifier may hide a wrong lot or notice version.
- A corrected value may overwrite the false claim and destroy the audit trail.
- A content digest may be presented as proof that the publisher or claim is trustworthy.
- OCR or translation may alter a date, unit, negation or qualification without a recorded activity.
- A public source may change after verification while the record continues to circulate.
- Private prompts, account tokens or restricted documents may leak into a shareable provenance record.
- A complete provenance chain may be mistaken for completed legal, commercial or bid qualification.

## Metrics

- agent leads preserved without post-verification edits
- displayed citations with a resolved public retrieval chain
- retained representations carrying retrieval time, media type, language and digest
- sources with an evidenced functional role
- records with separate notice, version, procedure, buyer and lot identifiers
- material claims linked to an exact official field or passage
- claims classified as verified, contradicted, unresolved or not checked
- translations, OCR runs and normalizations recorded as activities
- contradictions retained rather than overwritten
- provenance records reproduced by an independent reviewer
- records reused after their expiry trigger without a new observation

## Frequently asked questions

### Is an AI citation enough to verify a tender?

No. It proves what link or label the recipient was shown. Resolve the locator, establish the source role, bind the identifiers and verify each material claim against the source authorized for that fact.

### Should I replace the agent’s wrong deadline with the official one?

Keep both. Preserve the original assertion unchanged, mark it contradicted and store the official raw value in a separate observation with its source, scope and time.

### Does a SHA-256 digest prove that a tender notice is official?

No. The digest identifies the bytes that were captured. Publisher identity, source authority and factual correctness require other evidence.

### Can an official API be used instead of the website?

Yes for claims inside the API’s documented publication and version coverage. Record the endpoint, request, returned identifiers, response time and coverage limits. Follow the designated operational source for documents or instructions that the API does not publish.

### What if the official source is behind registration?

Verify what the public source can establish and mark the restricted claim unresolved. Do not create an account, accept terms or use credentials unless the task and authorization explicitly allow it.

### Does one verified claim make the whole opportunity verified?

No. Buyer, procedure, lot, deadline, status, documents and route need separate states. A record can contain verified, contradicted and unresolved claims at the same time.

### How should OCR or translation appear in the record?

Record each as an activity with its input, output, responsible system, time and relevant configuration. Preserve the original representation and do not let the derived text replace it.

### When must the provenance record be checked again?

Recheck when a new notice or version appears, a source changes, a time-sensitive claim reaches its threshold, the portal relationship changes or an identity conflict is discovered.

### Can this record decide whether we should bid?

No. It supplies an inspectable lead and claim states to the qualification process. Commercial fit, delivery capacity, risk acceptance and bid authority belong to later decisions.


## Primary sources

- [PROV-O: The PROV Ontology](https://www.w3.org/TR/prov-o/), World Wide Web Consortium
- [PROV-AQ: Provenance Access and Query](https://www.w3.org/TR/prov-aq/), World Wide Web Consortium
- [Data on the Web Best Practices](https://www.w3.org/TR/dwbp/), World Wide Web Consortium
- [Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf), National Institute of Standards and Technology
- [TED Search API](https://docs.ted.europa.eu/api/latest/search.html), Publications Office of the European Union
- [TED Open Data](https://docs.ted.europa.eu/ODS/latest/index.html), Publications Office of the European Union
- [eForms schema usage](https://docs.ted.europa.eu/eforms/latest/schema/all-in-one.html), Publications Office of the European Union
- [OCDS identifiers](https://standard.open-contracting.org/latest/en/schema/identifiers/), Open Contracting Partnership
- [OCDS releases and records](https://standard.open-contracting.org/latest/en/primer/releases_and_records/), Open Contracting Partnership
- [RFC 9110: HTTP Semantics, Validator Fields](https://www.rfc-editor.org/rfc/rfc9110.html#section-8.8), RFC Editor


## Related articles

- [Which tender notice is the official source?](https://zephior.com/insights/identify-the-official-tender-notice)
- [Where must tender questions be submitted?](https://zephior.com/insights/verify-the-official-clarification-channel)
- [How to audit proposal citations before submission](https://zephior.com/insights/audit-citations-in-an-rfp-response)
- [How to trace an RFP answer down to individual claims](https://zephior.com/insights/build-claim-level-rfp-traceability)