Separate space limits from factual requirements
Imagine a museum editing a label for a fragile nineteenth-century mineral sample. The original approved record states its accession number, provenance, light sensitivity and a handling warning. A kiosk has room for two short paragraphs, while a staff-facing screen can show a fuller explanation. OpenAI Responses exposes text.verbosity as a way to influence the amount of detail in compatible model output. That setting is useful for writing to a constrained display, but it cannot decide which collection facts the museum may omit. Begin with a list of facts that must remain explicit and a separate list of optional explanatory detail. Treat the latter as candidates for shortening, never the former.
Confirm the model and parameter before drafting
The Responses API documents text.verbosity with low, medium and high values and a medium default. The option is a verbosity preference rather than a strict word-count promise; model compatibility should be checked against the selected model documentation and actual response. An illustrative request can use a text configuration with verbosity set to low alongside instructions for a concise visitor label. Do not confuse this property with max_output_tokens. A token cap can truncate a response, whereas lower verbosity influences how the model describes the material. If an incomplete response arrives, inspect completion status and token usage instead of assuming the model chose a shorter stylistic form.
Build a source-of-truth fact card
Before any generation, assemble a compact fact card from the collections system: object identifier, approved title, catalog date, provenance claim and the precise safety or accessibility notice. Mark uncertain fields explicitly as not verified. For our hypothetical mineral label, the light sensitivity warning is a protected fact because staff may use the label wording in visitor briefings. Give each required fact a source reference and a person responsible for its approval. Keep restricted donor details out of both the prompt and public result. This evidence card turns a subjective preference for concise prose into a reviewable comparison between the output and the current record.
Run paired prompts with one frozen input
Generate two drafts from exactly the same fact card: one with medium verbosity and another with low verbosity. Keep the model, source revision, instructions and display target unchanged. Ask for a label suitable for the same reading level so the only planned difference is the detail preference. Save the returned text and metadata in an internal comparison worksheet without inventing benchmark numbers. Review each sentence against the fact card. A shorter sentence may still be accurate, while a fluent phrase that changes an object date or removes the safety warning is a failure regardless of how polished it sounds.
Inspect omissions, not just sentence length
Reviewers often notice visible errors such as a wrong date before they notice missing information. Make a required-facts matrix with columns for preserved verbatim, paraphrased faithfully, omitted and contradicted. Apply it separately to the opening label, accessible audio description and any printed leaflet. A reference to an unidentified “special condition” is not an adequate replacement for a specific handling notice. Check whether qualifications such as attributed to or probably made in have survived. The illustration compares a complete but long draft, a dangerously shortened one and a concise draft that restores the warning after review. These states are illustrative, not observed model performance.
Distinguish output style from safety controls
Neither low verbosity nor a specific output length constitutes a content safety control. If a label contains sensitive information, apply the same data minimization and approval practices that would be used for a human-written text. Structured fields may help a downstream system detect missing information, but a valid schema cannot prove that a provenance claim is true. Set a review gate that checks required concepts before a visitor display is updated. Keep the previously approved label available for rollback. Do not use any request setting as a substitute for the collection registrar or conservator who has authority over the language.
Test a hard case with a qualified fact
A productive edge case is a label containing uncertainty: perhaps the object is attributed to a workshop rather than conclusively made there. Ask the reviewer to identify exactly where the attribution survives in the shorter version. Another edge case includes a mandatory warning that seems tangential to the attractive main story. Verify that it remains prominent instead of being compressed to an ambiguous adjective. If a model repeatedly omits this requirement, revise the prompt and the application-level acceptance check; simply moving from low to medium verbosity may help readability but is not a reliable enforcement mechanism.
Prepare an accessible, approved release
Give the editor a controlled preview of every format where the label will appear. Check line breaks, contrast, screen-reader order and whether the warning falls below a folded mobile view. Record the approved accession ID and catalog revision so a future source update triggers re-review. When a reviewer corrects a generated draft, store the correction as editorial work rather than attributing it to an automated test. The release is ready only when the short version preserves protected facts, cites its internal source record and passes the museum’s ordinary accessibility and publication process.
Recheck after changing models or source records
Model behavior and text shaping can change across versions, and the catalog itself can gain new qualifications. Keep a small set of representative object types: a simple artifact, an uncertain attribution, a sensitive material and an item with a long legal notice. Repeat the same fact-coverage checks after a model upgrade, prompt change or source revision. Compare missing facts and human edits, not just character counts. If a run is too short to preserve the mandatory information, choose a larger display slot or link to a verified longer notice rather than weakening the source requirement to fit a design.
How We Research
For this guide we consulted the official documentation: OpenAI Responses create API reference; OpenAI response length guide. We compared named fields, supported behaviors and stated limitations, then developed an instructional museum scenario with explicit failure states. We did not run a live vendor API benchmark, inspect a production museum system, or measure vendor performance. The workflow and illustrations are proposed review steps; verify API-version support and your organization’s current policy before applying them.
Frequently Asked Questions
No. It influences response detail; specify a display target and measure the returned text separately.
Only when an output cap is operationally necessary. A cap can truncate text, so check for incomplete responses and missing facts.
No. A qualified collections reviewer must decide what is mandatory from the approved source record.
A schema can check field shape and presence, but it cannot independently establish historical truth.
After changes to the source catalog, protected facts, display format, instructions or selected model.