A public library’s help kiosk receives a question: is the east branch open after a water-main repair? Old calendars, third-party listing sites, and an emergency notice may disagree. The OpenAI Responses API can use the hosted web_search tool to discover current online sources and return citations. That does not make a model-generated sentence the branch’s official operating status. This fictional design keeps search, publication-date review, and staff approval as distinct steps.
Define the authority hierarchy before searching
For operational closures, the library’s official service alert or a named city agency should outrank a community directory, last year’s event schedule, or a cached review. Write down the branch’s exact name and address, what qualifies as a closure, and who can publish a status change. A page that says ‘closed for repairs’ may describe a temporary room, not the whole building. Preserve the distinction between branch opening hours, event cancellation, emergency access, and transit interruptions.
Build a source ledger with the notice URL, publisher, time zone, issue date, stated effective interval, last checked time, and any replacement notice. The ledger is authoritative only after staff verification. Search results can direct a reviewer to candidates, but a URL’s existence or a persuasive summary does not show that the page is current. Plan for conflicts and missing information rather than making every query return a confident open or closed answer.
Enable web_search as a tool, not a verdict
OpenAI’s Responses API supports a web_search tool in the tools array, allowing a compatible model to search online before answering. The documented output can contain a web_search_call item and a message whose annotations carry URL citation metadata. Depending on tool choice, a model may choose not to search, so an application requiring fresh evidence should enforce the intended search behavior and verify that a call occurred. Do not treat a model’s free-form statement that it searched as an audit log.
Choose a concise search question that includes the exact branch and the relevant date, not a vague phrase such as ‘library open’. Do not pass a patron’s account number or a private borrowing record to an external search tool. Request concise citations and inspect source links, then perform an application-side validation step. Product access, quotas, available models, pricing, and controls evolve; confirm current documentation before committing the workflow to a production kiosk.
Read the citation annotation and the actual notice
A citation in a web-search response identifies a source used by the model; it does not certify that the quoted page has been correctly interpreted. OpenAI documents URL citation annotations with titles and location information, and the API can return sources consulted by a search call. Store those identifiers alongside a stable source-review record. Open the publisher’s page and read the full operative sentence, not merely the snippet. Watch for reposted notices, old PDFs, and pages with date banners that refer to something else.
For a branch closure, reviewers should establish when the event happened and when the source was published or updated. ‘Updated today’ can reflect website maintenance while the closure notice applies to a past winter. Check the exact effective dates and whether an official page supersedes it. If the page cannot be opened or the relevant claim is absent, mark the result unverified. Do not copy a model-generated URL into the public kiosk merely because it looks plausible.
Compare stale, partial, and authoritative evidence
The illustration places three invented sources side by side: an old community events listing, an undated search excerpt, and a dated official branch alert. The dates and labels are fictional examples, not live search outputs. Only the relevant official notice can support an operational update once its effective interval and scope are checked. A directory may be useful corroboration, but should not outrank a specific publisher with responsibility for branch announcements.
A source can be authentic and still answer a different question. A water outage affecting the children’s room may not close the entire branch; a reopening notice may apply tomorrow rather than right now. Represent these distinctions explicitly in review notes. If an official alert conflicts with staff’s direct confirmation, escalate to the designated service manager and avoid automatic overwrites. The safest kiosk message may be ‘staff are confirming today’s status’ rather than an invented opening time.
Decouple evidence collection from site changes
The web_search result should create a proposed status with links and uncertainty, not publish directly to the website or digital signage. A human editor compares the evidence with internal branch operations before approving any visible update. Restrict the update tool so it accepts only a structured, staff-approved record with the branch ID, status, effective interval, source reference, and reviewer. Search itself grants no authority to write the library calendar.
Log whether the proposal was accepted, rejected, or held for clarification, and use idempotent update identifiers so a retry cannot create competing closure messages. Never announce that a branch has reopened solely because the search tool returned no recent closures. ‘No matching pages’ means the tool did not surface evidence, not that normal operations are confirmed. Keep a separate rollback plan for a mistakenly published alert and notify kiosk maintainers when the authoritative status changes.
Test temporal and location failure cases
Construct a review set with a similarly named branch, an old emergency page, a city-wide holiday notice, a future-dated reopening, and an unrelated event cancellation. The desired output is not just the right yes-or-no label; it is a source-grounded explanation that correctly identifies the branch, period, and scope. Include a case where sources conflict and the correct action is to ask staff. No search accuracy, cost, or speed numbers are claimed here because the scenarios were not executed against a real API.
Reviewers should examine whether inline citations are visible and clickable in the final application, whether the underlying publisher links still work, and whether evidence is retained with an appropriate access policy. Follow OpenAI’s guidance for showing clear clickable citations when web results appear in user-facing answers. The review interface should record the last confirmed time and avoid turning it into a false promise that the status remains valid indefinitely.
Publish the status with an expiry and an owner
Before approving a public announcement, have staff verify the source’s date, branch identity, precise restriction, accessible entrance status, and next scheduled recheck. An operational message should include an official contact path and the date of confirmation when that helps avoid ambiguity. Separate the source citation from a general-purpose model explanation. A public notice is a service commitment; its wording needs an accountable owner and a plan to remove it when conditions change.
Schedule or trigger a new verification whenever the official branch page changes, rather than assuming the model will keep monitoring it. If the public site is down, mark the information as needing confirmation and use a reliable alternative channel approved by the library. A web search can shorten the discovery step, but only source reading and an authorized branch decision make the final kiosk advice defensible.
How We Research
For this November 2026 editorial review, we consulted official vendor materials: OpenAI API: Web search; OpenAI API: Using tools. We checked the named feature, input/output scope, documented limitations, and the points where software results must be reviewed against an authoritative record. The project is a hypothetical instructional design; the graphics, source cards, time marks, sample identifiers, and decision states are original explanatory illustrations, not captured screenshots or measured service results. We did not upload real archival data, conduct a production API evaluation, obtain permissions on behalf of an institution, or measure an accuracy or latency result. Before deployment, verify current feature availability, regions, quotas, prices, data protection terms, licensing, and the latest developer documentation. A qualified human must review permissions, factual accuracy, accessibility, and any publication or high-impact changes.
Frequently Asked Questions
No. It can retrieve online evidence, but staff must verify official notices, dates, branch identity, and current operational status.
No. Citation annotations identify sources associated with an answer; their relevant claims and dates must be checked on the publisher page.
Not necessarily. With automatic tool choice, the model can decide whether to search; applications that require searching should enforce that behavior and inspect tool calls.
It should not. Keep searching and publication as separate permissions, with staff approval for a status change.
Use an uncertainty message and a verified human contact channel instead of guessing open or closed.