The museum label that sounded more certain than its sources
Imagine an education team preparing short labels for a new exhibit about the restoration of a nineteenth-century camera. The inventory card lists an approximate manufacturing period, but an AI-generated paragraph confidently assigns an exact year. A colleague proposes lowering top_p in the OpenAI Responses API so the answer will become more factual. That confuses a generation setting with evidence. A sampling parameter changes which next-token candidates a model can consider; it does not inspect the museum catalog, authenticate dates or make the model admit uncertainty. The useful workflow is to test how wording changes while keeping source verification independent from sampling.
What top_p means in a Responses request
OpenAI documents top_p as nucleus sampling: the model considers tokens within a cumulative probability mass specified by the parameter. The reference describes values between zero and one and explains that a smaller value narrows the candidate set. For an illustrative probability distribution, a high cumulative threshold admits more alternatives, while a lower threshold may favor a smaller pool. These diagrams are synthetic, not measured model probabilities. Crucially, even a highly likely word can be wrong for a particular artifact. The setting affects a generation mechanism; it is neither an evidence confidence score nor a requirement that the same answer appear on repeated requests.
Confirm model compatibility before selecting a value
Do not copy a top_p setting from an older tutorial into an unrelated model. Available parameters can differ by model family and version, and some modern reasoning models restrict sampling controls. Review the current Responses create schema together with the exact model’s documentation and test the request in a nonproduction environment. If the model rejects the parameter, remove the unsupported parameter rather than silently switching the model to obtain the desired setting. Save the model identifier and accepted generation configuration with the draft. Avoid suggesting that every OpenAI model supports the same range or that tuning always produces a measurable quality improvement.
Choose one sampling control at a time
OpenAI recommends changing top_p or temperature rather than changing both in the same experiment. For an editorial comparison, hold the prompt, approved source text, model and other controls stable. Prepare a small group of invented collection facts: object ID, material, dates with explicit uncertainty and prohibited unsupported claims. Try one documented, accepted setting and compare it with an approved baseline. Review whether the draft keeps hedging language and respects the source. A reader should be able to understand which input changed. If both controls and the source context vary, any observed difference cannot reasonably be attributed to nucleus sampling alone.
Use the complete evidence packet, not a guessed year
Supply an authorized transcription or catalog excerpt and identify each factual proposition that must be checked before publication. A draft could say that a camera was produced in 1885 even when the approved record specifies 1880–1890. Tightening top_p may make the unsupported year more consistently phrased. It has not made the statement defensible. Require the editor to match names, dates, accession codes, conservation claims and quoted statements to their source records. If the catalog is ambiguous, prefer a traceable statement of uncertainty. Never turn a fluent response into proof that the museum holds the object or that a photograph may be reused.
Separate a language experiment from a reliability test
Run a deliberately modest trial with synthetic labels and record the proposed settings, model identifier and reviewer decisions. Categorize outcomes as accurate, uncertain, contradictory or unverified rather than producing a fabricated accuracy percentage. Keep an original draft for comparison and annotate changes such as removed hedge words or altered dates. Because generation is probabilistic, one sample does not establish how an application will behave over time. Do not promise that low top_p makes an output deterministic. If reproducibility is important for regulated publication, use source-controlled editorial templates, fixed records and human approval instead of assuming that sampling knobs solve the problem.
Watch for citations that remain plausible but unsupported
The failure mode is sometimes subtle: a generated paragraph correctly names the object but inserts a plausible provenance detail or an appealing interpretation. Another draft may be more cautious yet omit a required safety note. Both can arise under different sampling settings. A comparison should therefore use a fact checklist aligned to each claim, not a single overall preference score. Keep the source URL or stable internal record ID next to each approved fact. Treat generated citations as leads to inspect, not independent confirmation. An editor should reject an attractive sentence if its claimed evidence is absent, even if the language looks consistent across runs.
Protect private collection data in testing
Use invented object descriptions or material cleared for a vendor API; some institution records may contain donor data, unpublished locations or accession notes restricted by contract. The decision to send information to a model is a data-governance question, separate from top_p. Do not log full prompts by default simply to compare sampling outcomes. Record a test identifier, version of the cleared source fixture, selected parameters and human review result. Review application retention and access requirements before using production records. These safeguards help the experiment answer a narrow editorial question without expanding the museum’s exposure of confidential catalog material.
Release the label only after source and rights review
The final handoff should include the approved label, linked source record, reviewer identity or role, effective version and a list of open questions. Keep the generation setting as supporting provenance, not as the reason the text is publishable. A release note might state that the team tested a supported nucleus-sampling option and verified the resulting statements manually against accession records. It must not claim that a particular top_p proved factual accuracy, removed hallucinations or established reuse rights. If the chosen model or API behavior changes, repeat the compatibility review. Publication depends on evidence and editorial responsibility, not the apparent confidence of generated prose.
How We Research
Our November 11, 2026 source review used these named official references: OpenAI Responses create API reference; OpenAI Models documentation; OpenAI text generation guide. We checked the documented operation or parameter, supported scenarios, error conditions and limitations against an explicitly hypothetical museum workflow. The diagrams depict synthetic examples; we did not send real collection records to an API, inspect private infrastructure, run production benchmarks, measure accuracy or capture authentic vendor UI screens. Where a setting is model-, account-, service- or policy-dependent, confirm the current vendor reference and the actual deployment before acting. Content and compliance approval remain with the authorized operator or editor.
Frequently Asked Questions
Not by itself. It narrows generation candidates but does not validate facts against catalog sources.
No. Check the specific model and current API documentation for accepted parameters before sending a request.
OpenAI generally recommends adjusting one or the other, rather than both, for a controlled comparison.
No. Repetition does not establish provenance, rights, dates or conservation accuracy.
An editor should verify each factual claim against an approved source record and clear image or text rights separately.