GPT-5.5 Responses API File Search: Build a Human-Reviewed Long-Document Evidence Packet

Define the evidence packet before choosing the model

An evidence packet is an audit artefact, not a decision made by artificial intelligence. Its purpose is to let an authorised human work backwards from each material draft claim to a retrieved passage, then to an original document and a usable locator. The packet may help a reviewer organise evidence, expose gaps and frame unresolved questions. It must not declare that a policy, legal interpretation, operational change, external notice or publication is approved.

Three boundaries shape this workflow. The ChatGPT fallback notice does not identify a selectable application programming interface (API)A documented way for software systems to exchange requests and results. Open glossary entry or Codex model. A File Search call must be configured to include the returned passages needed for inspection; an answer alone is not a retrieval record. Choose the model from the documented API catalogue and actual project access, preserve the retrieved excerpts, and leave release to a named human.

Write the packet charter first

Before uploading anything, create a short packet charter. This is an editorial control recommended for this guide, not an OpenAI-provided certification. Record the packet identifier and version, creation date, business purpose, authorised source classes, excluded material, intended reviewers, permitted uses, release condition and named release authority. Add an explicit statement that generated text is a draft derived from admitted evidence and cannot itself authorise action.

A useful purpose is narrow and testable. For example: “Prepare an inspectable record of the authorised documents relevant to whether the proposed customer-notice process is ready to be sent for legal review.” A poor purpose would be: “Read everything and decide whether the company can launch.” The first defines evidence preparation and a human hand-off; the second delegates an undefined consequential decision and gives no reviewer a reliable completeness test.

Use this procedure: first, write the exact draft proposition or question; second, name the person or role that will interpret the evidence; third, list decisions that remain outside the packet; fourth, state what must be inspectable before release; and finally, obtain the source owner’s approval for the proposed source set and data handling. The decision rule is simple: if the purpose cannot distinguish evidence organisation from decision authority, place the work on HOLD (meaning it must not proceed to its intended consequential use) before upload.

For the fictional policy-operations example used in this section, the packet question is: “What authorised records support, qualify or contradict the proposition that a documented exception is required before the proposed notice route is used?” The intended readers are a support-operations lead, a policy owner, a privacy reviewer and the director who controls release. Non-goals include deciding the legal meaning of the policy, approving customer communications, judging an employee’s conduct and recommending that the route go live.

The release condition in that fictional example is also concrete: every material sentence in the draft must point to at least one checked source record; conflicting current language must be visible; superseded material must not be presented as controlling; privacy review must be complete; and the named director must record either release or HOLD. This does not require every background sentence to carry the same evidential weight. It does require every claim capable of changing the proposed operational decision to be traceable and reviewed.

Apply a source-admission gate before any upload

Source admission asks whether a document is authorised, relevant and safe enough to enter the retrieval environment. It is different from ingestion readiness. A document can be authorised but not yet uploaded; uploaded but not ready; marked ready but poorly extracted; accurately extracted but irrelevant; or relevant but prohibited from distribution to the packet’s audience. Keeping these states separate prevents a technical status from being mistaken for evidential permission.

Identify authority and the governing record

Begin with the organisation’s original record system, not a convenient local download. For each candidate, record a stable internal key, title, owner, version or effective date where known, original-system location, access classification, intended relevance and proposed reviewer. If the organisation uses a checksum under its own records procedure, record it; do not imply that a checksum proves substantive correctness or authority.

A practical admission sequence is:

1. Confirm that a named owner is entitled to authorise this document for the stated API workflow and reviewer group.

2. Confirm whether it is current, superseded, draft, disputed or merely background.

3. Identify the authoritative original and its locator convention, such as page and clause, section and paragraph, or record identifier and timestamp.

4. Assess whether the full file is necessary or whether an approved extract will answer the packet question.

5. Remove or mask information that is unnecessary for the purpose, while preserving a controlled note that redaction occurred.

6. Assign an admission result and reviewer before any OpenAI file or vector-store identifier exists.

Recommended admission states are admitted_current, admitted_qualifying, admitted_contradictory, background_only, pending_authority, excluded_superseded, excluded_irrelevant and excluded_sensitive. These labels are editorial examples, not OpenAI interface states. The important distinction is that contradictory material may be admitted deliberately, whereas superseded material may be retained only to explain history and must not silently support a current claim.

In the fictional notice packet, suppose the candidates are a current policy effective 1 September, an approved change proposal, a dated incident summary, an older policy and an unrelated spreadsheet of customer contact details. The current policy is admitted as potentially controlling. The proposal is admitted as proposed rather than current. The incident summary is admitted only for factual operational context. The old policy is labelled superseded and excluded from support for current requirements. The customer spreadsheet is excluded because individual contact details are unnecessary to answer the question.

The decision rule is: admit only material for which authority, purpose and audience can be stated. If provenance is uncertain, do not “let the model work it out”; mark the document pending and ask the record owner. If two versions might control, admit both as a visible conflict rather than selecting the more convenient wording. A human records owner or subject-matter reviewer must resolve any consequential version question.

Minimise before redacting, and redact before distributing

Minimisation and redaction solve different problems. Minimisation limits what enters the workflow at all. Redaction removes or masks information from a necessary source copy. Distribution control limits who receives the resulting packet. Applying only the last step leaves unnecessary data in files, vector stores, requests or internal packet copies.

Use a field-by-field procedure. Ask whether each attachment, appendix, column and identifier is needed to support or challenge the packet question. Omit irrelevant attachments before creating the upload copy. Where a relevant passage contains unnecessary personal data, secrets, access tokens, private keys, credentials or unrelated case details, prepare a controlled redacted copy. Preserve the original only in its authorised record system, not in the prompt. Record the redaction reason and the person who checked that the remaining text has not changed the material meaning.

For example, an incident summary might say that a notice route was used after an exception was approved, followed by customer names, account numbers and staff contact details. A minimised packet copy could retain the approved-exception sequence while removing the identifying schedule if that schedule has no bearing on the policy proposition. The reviewer should compare the redacted passage with the authorised original in the record system; the model should not be asked to decide whether omitted personal data is legally necessary.

The decision trade-off is between evidential context and unnecessary exposure. Removing too much may turn a qualified statement into a misleading excerpt; retaining too much may broaden access without serving the packet purpose. When context and minimisation conflict, use a human privacy or records reviewer to approve a bounded extract, or place the source on HOLD. Never paste secrets or untrusted instructions from documents into system or developer prompts. Treat document contents as evidence to inspect, not instructions to obey.

Separate non-training, retention and deletion questions

OpenAI’s API data usage policy, updated 8 January 2026 and checked on 3 October 2026, says business data are not used to train models by default unless the customer explicitly opts in. That statement is not equivalent to zero retention, automatic deletion, universal confidentiality or approval for a particular regulatory use.

OpenAI’s platform data-controls documentation, checked on 3 October 2026, says default abuse-monitoring logs may be retained for up to 30 days. It also says that Zero Data Retention (ZDR)An OpenAI API data-control option requiring prior approval; it excludes customer content from abuse-monitoring logs under documented limitations, but some features can still persist application state. Open glossary entry and Modified Abuse Monitoring require approval, and lists /v1/files and /v1/vector_stores as not eligible for ZDR, with application state retained until deleted. These are distinct controls and should be recorded as such.

Before admission, name an owner for retention and deletion. That person should document which files and vector stores will be created, the internal retention requirement, who may access packet copies, when deletion should be requested, what confirmation is required and which organisation-controlled logs or archives also need treatment. Do not put actual credentials or sensitive administrative details into the packet narrative.

The decision rule is: if the team cannot identify its applicable account settings, contractual arrangements, source authority, access boundary and deletion owner, it cannot claim an acceptable retention posture. Pause the upload until an authorised human resolves those questions. “Not used for training by default” may be recorded accurately; it must not be expanded into claims that the workflow stores nothing or satisfies a named legal regime.

Correct the ChatGPT, API and Codex model-name boundary

Use the documented GPT-5.5 identifiers precisely

The GPT-5.5 model page checked on 3 October 2026 documents the model ID gpt-5.5 and default snapshot gpt-5.5-2026-04-23. The packet header should distinguish the alias requested from the snapshot selected or reported for the controlled run. For example, an illustrative header might record “requested model alias: gpt-5.5; selected snapshot: gpt-5.5-2026-04-23”. This is a sample record, not a claim about a reader’s execution.

The same model page, as checked on that date, marks GPT-5.5 as supporting the Responses API, File Search, file uploads and Structured Outputs. That support table establishes a documented workflow combination; it does not promise availability for every project, account, region, entitlement or future snapshot. Verification must therefore occur in two directions: check the current official model page, then check the actual controlled project without exposing credentials.

A fictional preflight record could say: “Official documentation supports Responses, file_search, file uploads and Structured Outputs for GPT-5.5 as of 3 October 2026; project eligibility remains pending confirmation by the platform owner.” It should not say “available everywhere” or “enabled automatically”. The release decision remains HOLD until the platform owner confirms the relevant environment and records the exact model used.

Once your team has a human-reviewed evidence packet working with File Search, the next decision is where that workflow should live, and comparing Which OpenAI Integration Surface Fits Your Team? can help you weigh who invokes each option, what data it can access, and who owns approvals.

Treat capacity as a boundary, not as proof

A model page can document what an API model is capable of, but capacity is not evidence that a particular source was ingested or a relevant passage was retrieved. Verify the live model and project access separately. For the packet, check returned passages, tables, contradictions and original locators against authorised documents before allowing a consequential claim to proceed.

For a separate budgeting decision about unusually long API inputs, the long-context pricing and cache analysis discusses pricing, caching and session budgets. That operational analysis cannot establish whether this evidence packet retrieved the necessary passages or accurately cites the original documents.

Specify the packet as an inspectable deliverable

A useful packet is more than a generated summary. It is a dated bundle of controlled records that preserves what was admitted, what was asked, what File Search returned, how each excerpt maps to an original locator, what humans checked and why release was granted or withheld. The format may be a controlled database export, review workbook, case-management record or rendered report. The essential requirement is inspectability, not a particular file type.

Define the minimum packet contents

Use the following components as an editorially recommended minimum:

1. Packet header: packet ID, version, purpose, run date and time zone, owner, intended reviewers, permitted audience, requested model alias, selected snapshot, controlled environment label and release authority.

2. Source inventory: stable internal source ID, title, version or effective date, original-system location, classification, admission state, redaction note and responsible reviewer.

3. Platform references: OpenAI file ID, vector-store ID, file-addition status and relevant File Search call IDs. These support technical provenance but do not replace internal source identity.

4. Retrieval register: query ID, exact query wording, query time, returned result, rank where available, cited file, returned text and selection or rejection reason.

5. Claim register: narrow draft claim, linked excerpts, relationship to each source, original locator, context note, contradiction state and reviewer status.

6. Exceptions register: unreadable scans, uncertain versions, missing annexes, extraction doubts, restricted originals, unresolved interpretation and assigned next action.

7. Release record: privacy and disclosure review, subject-matter review, factual traceability review, unresolved risks, distribution boundary and a named human’s release or HOLD decision.

Keep four evidence objects distinct

For the file_search_call result-inclusion control, follow the authoritative procedure in “Preserve the retrieval event, not merely the generated citation” below, including its file_search_call.results setting. This section keeps the evidence objects distinct.

A citation identifies a referenced file in the response. A returned result records what the search tool surfaced. An excerpt record is the controlled packet entry that preserves relevant returned wording and review notes. An original locator tells a human where to verify that wording in the governing document. Finally, human validation confirms fidelity, context, currency and relevance. None of these objects should be collapsed into another.

OpenAI’s citation-formatting guidance, checked on 3 October 2026, recommends stable source identifiers and readable text, distinguishes a source ID from a precise locator, and says citation results should be validated before display. Apply that distinction by retaining an internal key such as SRC-004 independently from a locator such as “Customer Notice Operating Policy, version 4.2, section 7.2, page 41”. If no reliable locator exists, write unknown and assign follow-up rather than fabricating a page number.

The decision rule is: no material claim may be released solely because a filename citation appears. Require included returned text, a route to the original and a human review status. If the source is image-only, a table is malformed, the original cannot be opened or surrounding text changes the apparent meaning, mark the evidence not_verified and prevent its use for that claim.

Record ingestion readiness without overstating fidelity

OpenAI’s File Search guide checked on 3 October 2026 documents setting up a vector-store knowledge base, uploading a file through the Files API, adding it to the vector store and checking until processing is completed before use. Record the returned file and vector-store identifiers and the readiness check. Do not convert “completed” into “faithfully extracted”, “fully searchable” or “evidentially complete”.

Use a two-stage verification. First, confirm the documented technical sequence and readiness state. Second, inspect representative and material content against the original: headings, numbered clauses, effective dates, footnotes, tables, appendices and text around likely claims. The first stage answers whether the workflow reports readiness; the second asks whether humans can rely on particular passages.

Consider a fictional scanned appendix containing an exception matrix. Its file may reach the documented completed state, yet a reviewer may be unable to confirm row labels or footnotes from returned text. The proper packet entry is “technical readiness recorded; source fidelity not verified; appendix withheld from material claims; readable original requested”. The model must not reconstruct obscured cells or select the most plausible interpretation.

Run the fictional policy-operations packet through the gate

Stage 1: frame the question and admit sources

This worked example is fictional and illustrates the recommended method; it is not a product result or performance claim. A policy-operations team wants to prepare evidence for a director considering whether a proposed customer-notice route is ready to proceed to legal review. The packet does not determine legality, approve wording or authorise deployment.

The analyst assigns PACKET-NOTICE-017 and records the proposition: “The current policy requires a documented exception before the proposed route is used.” Four source candidates are reviewed. SRC-004 is the current policy; SRC-007 is an approved proposal not yet effective; SRC-009 is a dated incident summary; and SRC-011 is an older policy superseded by SRC-004. A customer list is rejected before upload because it is unnecessary.

The source owner confirms that the first four records may be used by the named internal reviewers. The analyst creates minimised copies, removes unrelated personal details from the incident summary and records the redaction. The old policy remains admitted only as historical context because it may explain conflicting staff assumptions. It is explicitly forbidden from supporting a statement about the current rule.

Verification at this stage is documentary: each admitted copy is compared with its authoritative record, version information is recorded and any missing annex is flagged. The decision rule is that an uncertain effective date or unexplained duplicate prevents the document from being treated as controlling. Human review is required because the model cannot determine organisational authority from filename recency or confident prose.

Stage 2: verify the model and environment boundary

The platform owner checks the current official model documentation and the controlled project. The proposed run records gpt-5.5 as the requested alias and, if deliberately selected and available, gpt-5.5-2026-04-23 as the snapshot. The owner confirms whether Responses, File Search and file uploads are available in that actual environment. No name is inferred from GPT-5.5 Instant Mini.

If the analyst had written “switch the API fallback to GPT-5.5 Instant Mini”, the request would be rejected and corrected. The dated ChatGPT release note describes a ChatGPT fallback after rate limits, says it is absent from the ChatGPT picker and says the change does not affect the API or Codex. The official API catalogue checked on 3 October 2026 did not list an exact gpt-5.5-mini item.

The decision rule is to use only the documented API identifier that the actual project can access. Documentation support without project access is insufficient; project access without a recorded exact identifier is insufficient for the packet. Any mismatch causes HOLD until the platform owner resolves it.

Stage 3: define release before retrieval

The team specifies that a material claim must have returned text, an original locator, a current-version check and a named reviewer. A contradictory current passage must be displayed beside supporting material. A superseded source must be labelled visibly. Any unreadable table, missing annex, unresolved source authority, unreviewed sensitive material or inaccessible original blocks release.

The intended reviewers receive separate responsibilities. The evidence reviewer checks excerpts against originals. The policy owner interprets operational meaning. The privacy reviewer checks minimisation and distribution. The director alone records release or HOLD. Combining all four into “the model reviewed it” would erase accountability and must not be permitted.

An illustrative release note might read: “Packet may proceed to legal review only; it does not approve the notice route or notice wording.” If the current policy supports the exception requirement but the not-yet-effective proposal removes it, the packet should show both temporal states. It may say that proposed wording differs from the current requirement; it may not decide that the proposal already governs.

Stage 4: verify that the packet remains an evidence artefact

Before retrieval begins, a reviewer performs a boundary check. Can every admitted source be traced to its original? Are excluded records recorded without uploading their unnecessary content? Are secrets and unrelated personal data absent from prompts and source copies? Is the exact API model name documented rather than guessed? Is there a person who can stop distribution? If any answer is no, the packet remains on HOLD.

The final decision rule for this section is intentionally conservative: technical readiness permits retrieval; it does not permit reliance. A generated draft may enter human review only when its evidence records preserve returned passages and locators. It may leave human review only when authorised people have checked source fidelity, context, contradiction, privacy and decision ownership. The packet records their judgement; it does not replace it.

Build a source inventory that survives platform changes

Once documents have passed the admission gate, create a frozen inventory before uploading anything. The inventory answers a records question: “What source did the organisation authorise for this packet?” File Search answers a different technical question: “Which uploaded file and vector store were searched?” Preserve both layers. If a file is renamed, re-uploaded or moved between vector stores, its organisational identity should remain intelligible.

OpenAI’s citation-formatting guidance, checked on 3 October 2026, distinguishes a stable source identifier from a precise locator. Apply that distinction before retrieval. Give each admitted document a stable internal source key, then record its original-system locator separately. A recommended source key such as SRC-004 identifies the controlled source record; a locator such as “Records Library / Customer Notices / Current / section 7.2, page 41” tells a reviewer where to inspect the relevant passage.

Create one inventory row per controlled document version

Use one inventory row for each version admitted to the packet. Do not put “Current and previous policies” in one row, because the authority, dates and admissible uses may differ. Where a document has no reliable version or effective date, write unknown and assign an owner to resolve it. Do not infer a date from an upload timestamp or file name unless the organisation’s record owner confirms that convention.

Carry the admission record forward rather than re-admitting the document: it already holds the stable, non-semantic source key, title and version, original-system locator, authority, permission, data class, admission state, named reviewer and known limitations. The frozen inventory adds an inventory version and, where already used by the organisation, an integrity reference; log platform file and vector-store identifiers only after they exist as a separate technical layer.

Illustrative example: SRC-004 might identify the fictional “Customer Notice Operating Policy, version 4.2, effective 12 September 2026”. Its original locator could point to the organisation’s controlled policy library, while its authority field names the policy owner. A separately admitted version 3.9 becomes SRC-011, even if both files happen to be named notice-policy.pdf when supplied. The reviewer can then exclude the older version from current-policy claims without erasing the fact that it was present.

Decision rule: admit a source only when the team can identify what it is, who controls it, why it is authorised and where a reviewer can find the original. If any of those matters is consequential and unresolved, mark the row pending and do not use it to support a material claim. A platform upload must never silently convert a pending record into an admitted one.

Keep source identity, file identity and storage identity separate

The internal source key, OpenAI file identifier and vector-store identifier serve different purposes. The internal key belongs to the organisation’s evidence record. The file identifier refers to a platform file. The vector-store identifier refers to the search collection into which files are added. Record all three, but do not substitute one for another.

Freeze the inventory without freezing investigation

“Frozen” means that the admitted set and its metadata are versioned, not that discoveries are forbidden. If a reviewer later finds a missing annex or a superseding instruction, create a new inventory version and record the change. Do not edit a released inventory in place. The packet should show which source set each retrieval run searched.

Move from Files to a ready vector store without confusing status with fidelity

OpenAI’s File Search guide, as checked on 3 October 2026, documents the preparation sequence needed before using File Search with the Responses API: upload the file through the Files API, create a vector store, add the file to that vector store and check processing until it is completed. The order is operationally important because an uploaded file is not, merely by being uploaded, established as ready for search in the intended vector store.

Follow the documented sequence and log each transition

1. Prepare the authorised derivative. Link it to its internal source key and record any redaction, format conversion or page selection.
2. Upload the file. Save the returned platform file ID in the upload register; do not use that ID as the source key.
3. Create or select the intended vector store. Record its returned vector-store ID, controlled purpose, owner and packet scope.
4. Add the uploaded file to the vector store. Preserve the membership association so a reviewer can tell which upload was intended to be searchable.
5. Poll or check readiness as documented. Do not begin the controlled retrieval run until the relevant processing state is completed.
6. Perform separate fidelity checks. Test important passages against the original before allowing them into claim evidence.

This section deliberately provides no fabricated request or response IDs. In a real packet, copy exact identifiers returned by the platform into restricted operational fields. Do not type approximations, shorten them in the authoritative log or reuse examples from documentation. If an identifier is missing, record it as missing and rerun or investigate rather than manufacturing continuity.

Illustrative example: the fictional team has three admitted sources: current policy SRC-004, approved proposal SRC-007 and incident summary SRC-009. Each receives its own upload record. The packet records one controlled vector store for this source-set version, then associates each platform file ID with the corresponding internal key. If SRC-009 has not reached the documented completed state, the team postpones retrieval rather than allowing the model to work from only the two ready files without disclosing that omission.

Decision rule: all sources designated mandatory for a query must be in the intended vector store and show completed processing before the run starts. If an optional source is not ready, the run may proceed only when the packet explicitly narrows the question and identifies the omission. If the missing source could govern or contradict the answer, place the claim on HOLD.

Apply a readiness ladder rather than a single readiness signal

A completed processing state is a platform-readiness observation. It is not proof that a scan is legible, every page was represented, a table retained its relationships, footnotes remained attached to clauses or the admitted file is the governing version. Use a layered readiness ladder so that technical completion cannot masquerade as evidential approval.

Fictional failed-ingestion example: a scanned appendix reaches completed processing, but a human cannot reliably read the image-only approval table in the available original. Record platform readiness as completed and evidential status as not_verified. Do not cite the appendix for the claim “all exceptions require director approval”. Obtain an accessible authoritative copy, arrange approved manual transcription with a second-person check, or leave the claim unresolved.

Trade-off: checking every character in a very long corpus may be disproportionate, while checking nothing makes the packet unsafe for consequential use. A defensible recommendation is risk-based verification: inspect identity and completeness indicators for every file, then compare every excerpt used for a material claim with the original. Increase sampling for scans, complex tables, multi-column layouts, appendices and converted files. This is an editorial method, not an OpenAI guarantee.

Confirm model and project readiness separately

The GPT-5.5 model page checked on 3 October 2026 documents the model ID gpt-5.5, default snapshot gpt-5.5-2026-04-23, and support for Responses, File Search, file uploads and Structured Outputs. These documentation facts support the workflow design; they do not prove that a particular project has the required model, feature, region or data-control eligibility.

Before a production retrieval, record the requested alias, selected snapshot where pinned, API project or controlled-environment label, retrieval tool configuration and vector-store ID. Confirm actual project access through an authorised operational check. Do not infer API entitlement from ChatGPT access, a model catalogue entry or another project’s successful use.

Decision rule: if the exact model or required feature cannot be confirmed in the actual project, stop and resolve access rather than silently changing models. Any authorised substitution creates a new run configuration and may require renewed review. Snapshot pinning can improve reproducibility, but it cannot validate extracted text or a draft conclusion.

If File Search requests are throttled during the evidence-packet workflow, the API rate-limit and retry guide covers retries and quota handling. A successful retry establishes only that a request completed, not that a material claim was verified against an original source.

A delayed or retried request does not justify dropping mandatory sources, changing the source set or accepting a partial packet without review.

Preserve the retrieval event, not merely the generated citation

OpenAI’s File Search guide, checked on 3 October 2026, says a response can contain a file_search_call and a message with file citations. It also states that search results are not included by default and documents explicit inclusion of file_search_call.results. For an inspectable packet, request and retain those returned results. A filename citation alone does not show a reviewer the passage returned for the query.

Record enough detail to replay the reviewer’s route

For every controlled retrieval, preserve the query exactly as submitted, its date and time with time zone, the relevant run configuration, tool-call ID and included results. For each result, save the rank if the response returns one, platform file ID, filename, mapped internal source ID, returned text and review disposition. Then attach an original locator established by checking the authoritative document.

A recommended retrieval-result record contains:

• query_id and exact query_text;
• queried_at, including time zone;
• requested model alias and selected snapshot record;
• vector_store_id and File Search tool-call ID;
• result rank, only if actually returned;
• OpenAI file ID and returned filename;
• mapped internal source ID;
• verbatim returned text, kept distinct from any later quotation;
• verified original locator;
• selection or rejection reason;
• relationship to a draft claim;
• reviewer, review time and unresolved limitations.

Illustrative fictional returned-result record:

This sample is a schema illustration, not a claimed API output or product guarantee. In a real record, preserve the exact returned text without silently correcting spelling, joining separate passages or replacing defined terms. If the packet later uses a shorter quotation, retain both the returned text and the publication excerpt so the edit is visible.

Verification procedure: open the mapped original through the inventory locator; find the passage independently; compare wording, numbers, defined terms and negation; read enough preceding and following material to detect conditions or exceptions; confirm the version; then record a precise locator. If the passage cannot be found, mark the result rejected or not verified. Never ask the model to manufacture a page number from retrieved text.

Distinguish five states that are often collapsed

A robust packet separates readiness, retrieval, citation, ranking and truth. They answer different questions:

1. Ready: platform processing reached the documented completed state.
2. Returned: File Search surfaced text for a particular query.
3. Cited: the generated message attached citation metadata to output.
4. Highly ranked: a result appeared early in the returned ordering, where rank was provided.
5. Validated: a human checked the passage, context, authority and relevance against the original.

None of the first four entails the fifth. A highly ranked passage may be obsolete, narrowly scoped or contradicted elsewhere. A citation may identify a file but not expose the precise text needed to assess a claim. A completed file may contain a badly extracted table. Conversely, a lower-ranked result may contain the governing exception that changes the draft.

Decision rule: no material claim advances beyond draft status unless at least one authorised human can trace it to checked source text and an original locator, while any known qualifying or contradicting evidence is visible. Where interpretation is consequential, factual checking is necessary but not sufficient; route the issue to the authorised subject-matter, legal, policy or operational reviewer.

After the evidence packet is assembled and a reviewer has checked each passage, the next step is to gate any automated labelling you add on top of it, and the approach in this guide to Build an Eval-Gated GPT-5.5 Batch Classifier shows how a classifier can be paired with schema-constrained records, a human-labelled holdout, and review gates.

Structured records can make missing fields and inconsistent states easier to detect, but they do not convert model output into approval. Reject malformed or unsupported draft records automatically, then require human review for consequential interpretation and release.

Use rejection records to expose retrieval weaknesses

Do not delete an inconvenient result merely because it does not support the draft. Keep it with a controlled rejection reason. Useful reasons include superseded, wrong_scope, duplicate_passage, locator_unverified, context_reverses_meaning, extraction_uncertain, background_only and contradicts_claim. A contradiction is not a retrieval error and should not be labelled irrelevant merely to simplify prose.

Fictional example: result one comes from policy version 3.9 and says an exception may be documented after use; result two comes from version 4.2 and says it must be documented before use. The inventory identifies 4.2 as current, but the reviewer also discovers that a regional procedure still cites 3.9. Preserve both passages. Mark the older policy superseded for the current-policy proposition and the regional procedure as a contradiction requiring process-owner resolution. The draft may state “the records conflict”; it may not decide that operational staff can ignore one of them.

Trade-off: retaining every returned result improves inspectability but may expose sensitive text and create a larger retention burden. Minimise the query scope, restrict packet access and retain only what the approved evidential purpose requires. Do not remove contradictory evidence merely to reduce volume. A human records owner should approve retention and distribution rules.

Control capacity, cost and retention without weakening provenance

Attach lifecycle ownership to platform records

Apply the data-controls analysis in “Separate non-training, retention and deletion questions” before assigning lifecycle ownership. It is the authoritative account of non-training, retention, deletion, approval and endpoint scope, including the treatment of /v1/files and /v1/vector_stores; do not collapse those controls into one privacy label.

For each file and vector store, record a lifecycle owner, intended retention period, deletion trigger, deletion-request date and confirmation evidence required by organisational procedure. Also account for packet exports, internal logs and copied excerpts; deleting a platform object does not itself establish deletion from every organisational system.

Illustrative example: the fictional packet owner records that the vector store exists only for the authorised review, assigns deletion action after the review window and names a records administrator to collect confirmation. The packet does not call the workflow zero-retention and does not infer universal deletion from completion of the analysis.

Decision rule: if nobody owns deletion and retention confirmation, do not upload sensitive material. If retention requirements conflict with the intended use or approved controls, redesign the packet or keep the evidence in an authorised system outside this workflow. Consequential privacy, legal and records decisions require qualified human review.

Gate the excerpt register before drafting claims

End ingestion and retrieval with a reconciliation, not an answer. Compare the frozen inventory with the vector-store membership record and the returned-result register. The objective is to show what was admitted, what became ready, what was searched, what surfaced and what a human validated.

Perform a three-way reconciliation

1. Inventory to upload: every admitted source has the intended derivative and platform file record, or an explicit omission.
2. Upload to vector store: every mandatory platform file is associated with the recorded vector store and has the documented readiness state.
3. Result to original: every excerpt proposed for a material claim maps through file ID and internal source ID to a checked locator in the original.

Verification example: if result R-017-02 names customer-notice-policy-v4-2.pdf, the reviewer checks that its exact platform file ID maps to SRC-004, that SRC-004 is admitted in the run’s inventory version, and that the returned wording appears at the recorded section and page. A filename match alone is insufficient because duplicate names may exist.

Record the applicable controlled value—pending, text_checked, context_checked, rejected or HOLD—using the definitions in “Separate review roles and use controlled status values” in the source-register review section. The detailed meanings of text_checked and context_checked are defined only there.

Release rule for this stage: drafting may proceed only from records with context_checked status for material claims. Background material may use a lower state only if clearly labelled and non-consequential. Any missing mandatory source, unverifiable locator, uncertain extraction, unresolved controlling contradiction or absent responsible reviewer forces HOLD for the affected claim.

Hand forward a bounded evidence set

The next stage should receive a dated packet version containing the inventory version, exact run configuration, model alias and snapshot record, vector-store ID, query register, included File Search results, excerpt-to-original checks, rejected results, contradictions and open actions. It should not receive an unlogged conversational summary as the evidence base.

Fictional hand-off: the analyst passes forward two context-checked passages supporting the narrow current-policy statement, one superseded passage retained as excluded historical context, and one contradictory regional procedure marked for process-owner resolution. The draft may report the current wording and the unresolved operational conflict. It may not declare the proposed notice route approved.

Final decision rule for ingestion and retrieval: ready, cited or highly ranked material is only a candidate. Promote it into the evidence packet when a named human has verified source identity, exact text, surrounding context, authority, locator and permitted use. Where that chain breaks, preserve the limitation and hold the consequential decision.

Turn retrieved material into a controlled source register

A retrieval record answers “what did File Search return for this query?” A source register answers a different question: “what may a reviewer responsibly do with that material?” Keep both. The retrieval record preserves the query, tool call, returned result and platform identifiers; the source register connects a narrowly written draft claim to an identified source, an original locator, a checked excerpt, its relationship to the claim and a human review state. Neither record should be treated as a decision in itself.

When building the packet, apply the file_search_call results-inclusion procedure, including file_search_call.results, stated in “Preserve the retrieval event, not merely the generated citation.” The retained results complete the review chain; a filename citation cannot by itself establish claim-to-excerpt, context and original-location review.

The practical procedure is to create a register row only after matching a returned passage to a frozen inventory source. Copy the returned text into a retrieval field without silently editing it; identify the original document; open that original; assign or confirm a locator; compare the wording; and record how the passage relates to one particular claim. If a reviewer cannot complete any link in that chain, retain the row but mark it for further work rather than promoting it into the release set.

For example, in a fictional customer-notice packet, a returned passage might mention a “documented exception”. The analyst links it to internal source SRC-004, opens the authorised policy, finds the wording in section 7.2 on page 41, and records that locator separately. The row can support the narrow claim that the current policy requires an exception record. It cannot, without further authority, support the broader claim that the proposed notice process is lawful or approved.

Decision rule: permit a passage to enter the checked evidence set only when its source identity, readable excerpt and original locator are available and a named human has reviewed the original context. Otherwise set the packet to HOLD for any material claim that depends on it. This is stricter than merely saving a citation, but it makes the packet inspectable without pretending that retrieval rank is an evidence grade.

Use a schema that separates provenance, meaning and permission

The following schema is an editorial recommendation, not an OpenAI-supplied control. OpenAI’s GPT-5.5 model page, checked on 3 October 2026, lists Structured Outputs among the model’s supported features. Structured Outputs can help shape generated material into a required record form, but it cannot certify that a source is authentic, that a locator is correct, that an excerpt is complete or that a person is authorised to release the packet. Validate every generated field against controlled records.

Use explicit null values. If a page number is unavailable, record unknown or not_applicable according to a documented convention; never manufacture “page 1” because a viewer displays the first image that way. If no reviewer has checked the record, use pending, not a blank that could be misread as approval. If the source has no known version date, preserve that uncertainty and assign an owner to investigate it.

In an independent fictional procedure example, whose source keys are unrelated to the customer-notice packet, CLM-017 might state: “The current procedure requires handoff within four working hours.” Its linked row identifies SRC-011.C08, records section 4.3 and page 18 as the original locator, preserves a checked verbatim excerpt, assigns supports, and notes that the procedure owner still needs to confirm whether an undated intranet copy is controlling. The support relationship and the authority question coexist; support does not erase uncertainty.

Decision rule: make fields mandatory according to the intended use. A background-only row may proceed with an unresolved fine-grained locator if it cannot affect a consequential claim, but a material quotation or decision premise requires a verified locator, checked text, accountable reviewer and permitted-use decision. Schema completeness is not substantive validity: a perfectly formed row containing a wrong page reference remains wrong.

Distinguish source identity from the place a reviewer must inspect

OpenAI’s citation-formatting guidance, checked on 3 October 2026, distinguishes a stable source identifier from a precise locator and calls for readable cited material and validation before display. Apply that distinction inside the packet. A source_id is the durable key by which the register refers to a source or citable unit. An original_locator is the route a person follows to inspect the relevant place in the authoritative original.

Decision rule: a stable source ID is sufficient for joining internal records; it is never sufficient for material human verification unless the controlled source system itself resolves that ID to an exact citable unit. Where no reliable locator exists, set fidelity_status or review_status to the appropriate unresolved state and place the dependent claim on HOLD.

Preserve verbatim excerpts separately from paraphrases

A verbatim excerpt reports source wording. A paraphrase is an analyst’s or model’s restatement. Store them in different fields because they carry different risks. A paraphrase can clarify technical prose or reduce irrelevant detail, but it may also broaden a duty, remove an exception, turn discretion into obligation or conceal uncertainty. Labelling a paraphrase as an excerpt destroys the reviewer’s ability to see that transformation.

In a fictional procedure, the source says, “Where operationally practicable, the receiving team should acknowledge transfer within four working hours.” A defective paraphrase would be, “The receiving team must accept every transfer within four hours.” It changes “should” to “must”, removes the practicability condition, changes acknowledgement to acceptance and loses “working”. A faithful paraphrase might say, “The procedure expresses a conditional expectation of acknowledgement within four working hours.” Even that remains an interpretation and must be labelled accordingly.

Decision rule: quotations require a checked verbatim field and locator; paraphrases require both that underlying field and a human comparison for material claims. Where wording itself controls the interpretation, prefer presenting the checked quotation with context rather than relying only on a compressed paraphrase.

Classify support, qualification and contradiction without averaging them away

Relevance is not a sufficient relationship label. Use a controlled vocabulary that tells reviewers what the record does to a specific claim. The recommended values are supports, qualifies, contradicts, background_only and not_admitted. These values are editorial controls, not OpenAI classifications, and a human must confirm them.

Supports means the passage provides direct grounds for the claim as narrowly written. Qualifies means it imposes a condition, exception, scope limit, date boundary or uncertainty that must travel with the claim. Contradicts means it asserts materially incompatible wording or facts. Background_only means it helps explain context but does not prove the claim. Not_admitted preserves why a retrieved item was excluded, such as wrong version, absent authority or irrelevant content.

Classify relationships claim by claim. One passage may support CLM-017 but qualify CLM-018. Avoid assigning “supports” at document level, because a long policy can contain both a general rule and exceptions. Similarly, two sources mentioning the same subject are not necessarily corroborating: one may describe an old process while the other establishes its replacement.

The procedure is to write the claim in an atomic form; attach every plausibly material row; compare each excerpt with that exact wording; assign the relationship; and document why. Then check whether qualifications and contradictions appear in the proposed narrative with prominence proportionate to their effect. Do not calculate a vote from the number of rows. Three old documents do not outweigh one controlling current instruction merely because retrieval produced more passages from the old set.

Worked example: a superseded policy is relevant but not governing

Consider a clearly fictional policy packet. This example uses independent source keys: SRC-003 is “Customer Notice Policy, version 2, effective 2024”; SRC-004 is version 3, effective 2026. A query about exception approval returns a clear passage from version 2 and a shorter passage from version 3. No executed retrieval or result is claimed here; this is an example of how records should be classified if such material were returned and verified.

The draft claim is: “The current policy permits a regional manager to approve the exception.” Version 2 expressly assigns that role, so its text appears superficially supportive. Version 3 instead assigns approval to a central policy owner and marks version 2 as superseded. Relative to the word “current”, the version 2 passage is not_admitted as governing support and may be background_only for change history. The version 3 passage contradicts the proposed claim.

Preserve the older row rather than deleting it. Record its version, locator, supersession note and exclusion reason. This shows why an apparently strong quotation was not used and warns reviewers that old wording remains discoverable. The corrected draft might say, “The admitted current policy assigns exception approval to the central policy owner,” subject to human confirmation of authority and effective date.

Decision rule: when a source is demonstrably superseded, do not use it to support a present-tense claim unless the claim is explicitly historical. If supersession is suspected but not established, classify authority as uncertain and hold any consequential present-tense conclusion until the record owner confirms which version governs.

Worked example: two current procedures conflict

In a second fictional example, Procedure A says that the service team must hand off a priority case within two working hours. Procedure B says that operations must accept the same category within four working hours. Both appear current, both have authorised owners, and neither states which timing governs the boundary between handoff and acceptance.

Do not collapse the two into “handoff must occur within two to four hours”. That range appears nowhere and may conceal distinct events. Create separate claims: CLM-031, “The service team must initiate handoff within two working hours”; and CLM-032, “Operations must accept the case within four working hours.” Map each supporting passage to its own claim. Add a third issue record stating that the interaction between the deadlines is unresolved.

If the draft instead claims, “The entire handoff must be completed within two working hours,” Procedure A may qualify or fail to support it, while Procedure B may contradict it depending on defined terms and surrounding context. Ask the process owner whether “handoff” and “acceptance” are separate controlled events. Until that interpretation is documented, the packet may report the conflict but must not select a governing deadline.

Decision rule: a material contradiction requires either an authoritative resolution recorded by a named human or a HOLD. Editorial smoothing, majority counting, retrieval rank and generated confidence cannot resolve conflicting controlled instructions.

Apply backward and forward review to every material claim

Backward review starts with the draft and traces each material assertion to its evidence. Forward review starts with important original sources and asks whether their operative clauses, exceptions and conflicts are represented in the draft. The two directions detect different failures. Backward review finds unsupported prose and broken locators; forward review finds omitted qualifications, controlling sources that retrieval did not surface and contradictions the draft ignored.

For backward review, mark every factual or interpretive proposition that could affect a policy, operational, publication, funding, employment, privacy or legal decision. Assign a claim ID. Follow each claim to the register rows, then from each row to the verbatim excerpt, original locator and admitted source. Open the original and inspect adjacent material. Confirm that at least one row genuinely supports the claim and that all material qualifications or contradictions are visible.

Forward review should begin with sources likely to control the decision: the current policy, approved procedure, formal amendment, authoritative schedule or other governing record identified by the organisation. Select their operative sections and trace forward into the register and draft. Ask whether duties, exceptions, transitional dates, definitions and supersession clauses appear where relevant. Record “not applicable” with a reason if a controlling passage does not bear on the packet question.

In the fictional policy example, forward review of version 3 finds a transitional clause: regional managers may continue approving exceptions for requests lodged before the effective date. The initial draft’s absolute statement about central approval is therefore incomplete. Add a qualifying row and revise the claim to distinguish pre-effective-date requests. This is not evidence that forward review will always find every omission; it is a recommended check against relying solely on surfaced results.

Decision rule: release a material claim only after backward review succeeds and forward review of the identified controlling sources reveals no unaddressed material qualification or contradiction. Sampling may be proportionate for non-material background, but consequential claims require direct review. A large context window or an extensive result list does not substitute for either direction.

Separate review roles and use controlled status values

Use a controlled review-status vocabulary: pending, text_checked, context_checked, authority_checked, use_approved, rejected and HOLD. Treat these as progressive or role-specific states according to a written workflow; do not assume that reaching one state implies the others. In particular, accurate transcription does not establish authority, and subject-matter agreement does not approve disclosure.

Pending means no required human check has been completed. Text_checked means the excerpt was compared with the original. Context_checked means adjacent material, defined terms and relevant notes were inspected. Authority_checked means the reviewer confirmed the version’s status for the intended question. Use_approved means the designated person approved the specified quotation, paraphrase or internal reliance. Rejected records a reasoned exclusion. HOLD means a blocking issue remains.

Assign roles explicitly: a source checker confirms text and locator; a subject-matter owner interprets operational meaning; a privacy or disclosure reviewer handles sensitive information where required; and a release authority decides whether the packet may be distributed for its stated purpose. One person may hold multiple roles if organisational rules permit, but the register should show which role each action satisfied.

Decision rule: no model-generated status may promote a record into a human-approved state. Structured output may suggest pending, flag a possible contradiction or populate a review queue, but only an authorised person may record completion of the corresponding human check. Require human review for every consequential decision.

Make HOLD a binding outcome rather than an editorial note

HOLD means the packet or affected claim must not proceed to its intended consequential use. It is not synonymous with rejection: a held record may become usable after investigation, rescanning, authority confirmation, redaction or owner assignment. Define hold scope as row, claim, packet or distribution, so a local defect neither disappears nor unnecessarily blocks unrelated, independently supported material.

Trigger HOLD for uncertain authorisation

The procedure is to identify the admission decision and its owner, compare the intended use with the packet charter, and verify that any sensitive or restricted category remains within the approved boundary. Keep secrets and untrusted data out of prompts. If authorisation cannot be evidenced, stop dependent processing and refer the question to the accountable organisational owner rather than asking the model to infer permission.

For example, a fictional analyst receives an incident attachment that appears relevant but was not included in the authorised source inventory. The analyst records it as not_admitted, does not place its contents in a prompt and opens a hold action for the source owner. Decision rule: absence of a documented authorisation decision forces HOLD; relevance does not create permission.

Trigger HOLD for an unreadable original

Ingestion completion and source fidelity are separate. OpenAI’s File Search guide documents checking file processing until completion, but completion does not certify that a poor scan, image-only appendix, complex table or marginal note was extracted faithfully. The human reviewer must be able to inspect the original evidence used for a material claim.

For a fictional poor scan, a returned passage appears to say that approval is required within “10 days”, but the original image could plausibly read “16 days”. Record the returned text without treating it as verified, mark the fidelity problem, and request a better original or qualified transcription. Do not repair the number by contextual guesswork.

Decision rule: if an unreadable original affects a number, duty, exception, identity, date or other material term, hold the claim. A readable alternative authoritative copy may clear the hold after comparison; a model’s plausible reconstruction may not.

Trigger HOLD for a missing locator

A missing locator prevents independent inspection even when the excerpt looks credible. First search the controlled original using exact wording or an approved document index; then inspect headings, pagination and version data; then ask the record owner whether another locator convention is authoritative. Preserve unknown until resolved.

For example, a fictional returned sentence is associated with the correct filename but cannot be found in the admitted copy. It may come from another version, an extraction artefact or text outside the visible page images. Do not invent a page reference from result order. Decision rule: a material row without a reproducible original locator remains on HOLD, even if its file citation is present.

Trigger HOLD for a material contradiction

A contradiction is material when resolving it could change the claim, recommended action, responsible owner, deadline, permission or distribution decision. Place both sides in the register, preserve their authority and date information, and assign an appropriate subject-matter owner. The draft may accurately report “conflict unresolved”, but it must not choose a winner without authority.

In the fictional procedure conflict, one source requires a two-hour handoff and another permits four hours. The owner may resolve that they govern different events, but that interpretation must be documented. Decision rule: until authoritative resolution or removal of the affected claim, the consequential use is held; a neutral description of the unresolved conflict may be released only if the release authority approves that limited purpose.

Trigger HOLD for unreviewed sensitive data

For the applicable non-training, retention, endpoint and approval boundaries, apply the data-controls assessment in “Separate non-training, retention and deletion questions.” Sensitive-data review still requires authorised handling, access and disclosure decisions; it cannot be cleared by a single privacy label.

The procedure is to identify sensitive fields before use, minimise them, confirm intended recipients, assign the appropriate human review and record lifecycle ownership. Do not place secrets or unnecessary personal data in prompts or example records. If sensitive content is discovered after retrieval, restrict the packet, record the affected copies and ask the responsible reviewer to decide on redaction, replacement or exclusion.

Decision rule: unreviewed sensitive data forces a distribution hold and may force a processing hold according to the organisation’s authorisation boundary. Default non-training is not permission to circulate the material and is not a zero-retention guarantee.

Trigger HOLD when no accountable owner exists

An open question without an owner is not a control. Assign owners for source authority, interpretation, privacy or disclosure, remediation and final release. The model may organise a list of unresolved items, but it cannot accept accountability or infer that silence means approval.

For example, the fictional packet identifies a transitional-policy ambiguity, but neither policy operations nor regional management accepts responsibility for resolving it. Record the disputed ownership and elevate it through the organisation’s governance route. Decision rule: if no named person has authority to clear a material issue or release the packet, the packet remains on HOLD.

Convert review findings into a release or HOLD decision

An evidence packet is ready for a release decision only when its review record exposes what was admitted, what was retrieved, what a human checked and what remains uncertain. “Release” means permission to distribute the packet to a defined audience for a defined purpose; it does not mean that the model has approved the underlying policy, legal interpretation, funding choice, publication or operational change. “HOLD” means that one or more conditions prevent that bounded distribution. This release taxonomy is an editorial recommendation, not an OpenAI-certified control.

Evaluate gates in dependency order

Run the final review in an order that prevents a polished packet from concealing a foundational failure. First confirm source authorisation and version identity. Then confirm model, snapshot and retrieval provenance. Next inspect material excerpts against their originals, including surrounding context. After that, examine contradictions, privacy and disclosure constraints. Finally, assign lifecycle and decision ownership. If an early gate fails, retain later observations if useful, but do not treat them as curing the failure.

A practical procedure is to give every gate one of four controlled states: PASS, HOLD, NOT_APPLICABLE or UNKNOWN. Use UNKNOWN when evidence is absent; do not convert it to PASS merely because no reviewer has identified a problem. Use NOT_APPLICABLE only with a written reason and named reviewer. The decision rule is conservative: any material HOLD or UNKNOWN produces an overall HOLD until an authorised human resolves it.

Use a release matrix rather than a single approval box

Create a matrix with the following rows: source admission; model and snapshot; query and retrieval provenance; checked excerpts; original locators; contradictions; privacy and redaction; retention and deletion; distribution audience; and accountable decision owner. Add columns for status, evidence reference, reviewer, review time, unresolved issue and required action. This separates evidence about readiness from the eventual decision and makes ownership inspectable.

The distinction matters because a technically reproducible retrieval run can still be unsuitable for distribution. Conversely, a carefully redacted packet can still fail if its material assertion has no checked locator. For each row, require an evidence reference such as an inventory entry, retrieval-event identifier, claim-register row or internal privacy assessment. A tick without a record should be treated as an assertion, not verification.

Consider a fictional matrix in which the snapshot row records gpt-5.5-2026-04-23, but the environment owner has not confirmed that this exact model was selected in the recorded run. The GPT-5.5 model page, checked on 3 October 2026, documents gpt-5.5 as the model identifier and gpt-5.5-2026-04-23 as its default snapshot. That documentation establishes the published identifier, not what a particular application actually sent or what an account was entitled to use. The row therefore remains UNKNOWN until the request record or controlled environment evidence is reviewed.

Separate packet release from the consequential decision

Record two decisions when the packet informs a consequential matter. The first is “May this evidence packet be distributed to the named reviewers?” The second is “What should the authorised decision-maker do about the underlying matter?” The model may help organise evidence and draft open questions, but a named human must make both decisions where they carry consequences. A released packet may still conclude that the policy question is unresolved.

Apply a claim-level release checklist

A packet-level pass is insufficient if one material claim has escaped review. Define a material claim as an assertion that could affect the audience’s interpretation, action, allocation, compliance assessment, external statement or approval. The organisation should define materiality for its context; where that definition is uncertain, the accountable human reviewer should decide and record the boundary.

Check the route from claim to governing original

For each material claim, follow this sequence: identify its draft_claim_id; open every linked source-record row; inspect the preserved retrieved text; follow the original locator; compare the excerpt with the original; read enough surrounding material to identify conditions and exceptions; confirm the document version; and record the reviewer’s conclusion. Do not stop at a filename annotation or stable source identifier.

The decision rule is that a claim may be marked context_checked only when a human with access to the original has confirmed that the excerpt is faithful, sufficiently contextual and linked to the correct version. If a page number is unknown, record unknown and supply another authoritative locator if one exists, such as a section heading and paragraph. Never manufacture a location from chunk order or a generated citation label.

In a fictional example, claim CLM-017 says, “A documented exception is required before the alternate notice route is used.” File Search returns text from SRC-004 that appears to support the statement. The reviewer opens section 8.3 of the current policy and finds that the requirement applies only to notices involving a specified customer class. The claim must be narrowed to include that condition or rejected. The citation did useful discovery work, but it did not prove the broader wording.

Compare four evidence layers explicitly

This compact comparison reflects the distinction in OpenAI’s citation-formatting guidance, checked on 3 October 2026, between a stable source identifier and a precise locator, and its instruction that citations should be validated before display. Apply the file_search_call results-inclusion and preservation procedure, including file_search_call.results, in “Preserve the retrieval event, not merely the generated citation” before this release comparison. Start with deliberately preserved returned text, not citation metadata alone.

Check forward from controlling sources for omissions

For example, an analyst may retrieve the operative notice clause but omit a later section that suspends it during a declared service incident. A reviewer sampling forward from the policy’s notice chapter can add the missing qualification. If the document is too complex for the assigned reviewer to judge, the status should become UNKNOWN and the issue should be assigned to a subject-matter owner rather than guessed.

Do not count supporting records as votes

Five similar excerpts do not automatically outweigh one controlling contradiction. Retrieval rank is not an evidence-quality score, and repeated wording may originate from copied or superseded material. Classify each record as supporting, qualifying, contradicting, background-only or not admitted, then assess authority, version and relevance separately.

Keep model naming and product routing out of evidential inference

Model identity is operational provenance, not substantive evidence. Record the exact identifier used, but do not infer an API model from a similarly named ChatGPT feature. OpenAI’s 6 July 2026 ChatGPT release note states that GPT-5.5 Instant Mini replaced GPT-5.3 Instant Mini as the ChatGPT fallback after GPT-5.5 Instant or Auto rate limits. It also says that this fallback is absent from the ChatGPT model picker and that the update does not affect the API or Codex.

Correct the Instant Mini naming trap before sign-off

Add a release check asking whether any request configuration, runbook or packet prose refers to an undocumented gpt-5.5-mini API fallback. The official all-model catalogue checked on 3 October 2026 listed gpt-5.5 and gpt-5.5-pro, but did not list an exact gpt-5.5-mini item. This is a bounded observation about that page on that date, not proof about future releases, private previews or account-specific offerings.

Model choice is a separate record from claim evidence. For background on the trade-offs between two documented API models, consult the GPT-5.5 and GPT-5.4 API comparison; any model-selection note still needs to identify the actual project configuration and does not replace source-to-claim review.

Pinning helps consistency but does not validate evidence

The GPT-5.5 model page checked on 3 October 2026 documents support for the Responses API, File Search, file uploads and Structured Outputs. It also documents the default snapshot gpt-5.5-2026-04-23. These facts support the feasibility of the described workflow, but they do not establish project eligibility, regional controls, source fidelity or correctness of a generated claim.

Use the alias field to record what the application requested and the snapshot field to record the pinned or otherwise established snapshot. If only the alias is known, say so. If a later rerun uses a different snapshot, create a new run record and compare material outputs; do not overwrite the earlier provenance. The release decision remains based on checked evidence, not on the mere presence of a snapshot identifier.

Assign retention and deletion ownership before distribution

Apply the data-controls assessment in “Separate non-training, retention and deletion questions” before distribution. It is the authoritative explanation of the separate non-training, abuse-monitoring, application-state, approval and endpoint questions; none may be compressed into “nothing is stored”, “Zero Data Retention applies” or automatic-deletion claims.

Separate three lifecycle questions

Use the three lifecycle questions—training use, abuse-monitoring retention and application state—as a release checklist. For the applicable platform facts, including /v1/files and /v1/vector_stores, follow “Separate non-training, retention and deletion questions” rather than infer a single retention result from any one control.

The OpenAI data-controls guide is the first-party reference for the analysis above. Verify approval, scope and applicability for the actual organisation and endpoint; do not infer them from a request, contract discussion or use of the Responses API. Preserve unknowns as unknowns, and assign a human owner in the release record.

The decision rule is: do not release a packet containing sensitive or restricted information until a named owner has documented the applicable lifecycle for every relevant data location. If contract terms, project configuration, regional processing or internal obligations are unknown, record them as unknown and escalate. This guide does not supply a legal conclusion or a universal retention period. The public documentation cannot determine whether a reader’s records schedule, access arrangements or deletion evidence is sufficient; those matters remain for the organisation’s authorised privacy, security and records owners. The release record should identify each unresolved lifecycle question and its owner.

Minimise the release packet independently of source retention

The evidential working set may contain material that the distribution audience does not need. Before release, produce a distribution copy that includes only the excerpts, identifiers and limitations necessary for the stated purpose. Keep platform identifiers internal unless recipients require them for verification. Redact secrets, credentials, unrelated personal data and internal routing details under the organisation’s approved process.

Do not place untrusted document instructions or secrets into prompts. Treat document content as evidence to retrieve and review, not as authority to modify system instructions, change recipients, disclose credentials or bypass gates. If a retrieved passage tells the system to ignore review requirements, classify it as source text and exclude it from operational control.

For example, a fictional incident attachment might contain an embedded line asking the reader to send the full packet to an external address. That line has no authority over the workflow. The reviewer should assess whether it is relevant evidence, redact any unrelated personal details and preserve the approved distribution list. A packet that cannot be safely minimised for its audience should remain on HOLD.

Reconcile retention with the evidence record

Deletion should not destroy the only record needed to understand a consequential decision unless the authorised retention schedule requires that result and the accountable owners accept it. Before deleting retrieval application state, decide which minimal provenance must remain in the controlled packet: source inventory keys, run date, model and snapshot, queries, checked excerpts, locators, reviewer findings, contradictions and lifecycle actions. The choice should follow organisational policy, not an invented assumption that more retention is always safer.

In an illustrative temporary project, the platform objects may be scheduled for deletion after review while a redacted, approved evidence packet remains in the organisation’s records system. In another context, even the packet may need rapid disposal. The decision rule is to record the applicable authority, owner and scope; where those are not established, state the uncertainty and hold distribution or deletion as appropriate.

Run the final privacy, contradiction and audience review

The release reviewer should perform one last examination of the actual distribution artefact, not merely the working register. This catches changes introduced during redaction, formatting or export. It also verifies that warnings and unresolved conflicts remain visible rather than being lost when the packet is shortened.

Inspect the distributed excerpts after redaction

Compare each material excerpt in the release copy with the checked register. Confirm that redaction has not joined words from separate sentences, removed a material condition or made a quotation appear broader than its source. Record any paraphrase as a paraphrase and keep the checked verbatim excerpt in the controlled review record where authorised.

Make contradictions prominent enough to affect use

Place unresolved contradictions beside the claims they affect and repeat them in the release record. Do not confine them to an appendix that ordinary reviewers are unlikely to inspect. State the competing sources, versions, locators, authority question and assigned resolver. Avoid language such as “minor discrepancy” unless a human subject-matter owner has established that classification.

Bind release to a named audience

Record named roles or a controlled group, the permitted purpose, redistribution limits established by the organisation and the packet version. “Internal” is often too broad to be useful. The audience needed to validate source interpretation may differ from the audience authorised to see sensitive incident details, so prepare separate minimised copies when necessary.

Complete the reviewer-facing release record

The final release record should be short enough to inspect but complete enough to reconstruct the decision boundary. It should accompany the packet or reside in its controlled record system. The following structure is an editorial recommendation and illustrative template, not a schema supplied or certified by OpenAI.

Record source admission and exclusions

List every admitted source by stable internal identifier, title, version or date, original-system location, access classification and admission reviewer. Separately list rejected, superseded or unavailable sources and why they were not relied upon. If the authoritative version is unknown, write unknown; do not silently select the most recent filename.

Record model, snapshot and environment

State the requested model alias, established snapshot, execution date and time zone, controlled project or environment label, vector-store reference and relevant tool configuration. Do not include actual credentials or secrets. If project eligibility, regional controls or exact snapshot selection were not verified, mark those fields unknown.

Record query and retrieval provenance

For each material retrieval event, retain a query identifier, exact query wording, time, tool-call identifier, returned result reference, file identifier, internal source identifier, rank if returned, selection or rejection reason and preserved retrieved text. Rank should be treated as retrieval ordering, not evidential authority.

Record checked excerpts and original locators

For every material claim, provide the verbatim checked excerpt, source version, authoritative locator, context note, relationship to the claim, reviewer, review time and status. Distinguish text returned by File Search from text subsequently copied from the original. If they differ, preserve the difference and investigate extraction fidelity.

Record contradictions and uncertainty

List unresolved and resolved contradictions separately. For a resolved conflict, identify who resolved it, on what authority and whether the resolution changed any claim. For an unresolved conflict, identify the affected claim, competing records, next action and owner. Do not delete contradicted records merely because an owner selected one source as controlling.

Record the privacy assessment

State the assessed data classes, necessary redactions, excluded secrets, intended audience, disclosure limitations, assessment owner and unresolved questions. Keep sensitive detail out of the release header if the header has a wider audience than the packet. Reference the controlled assessment rather than copying unnecessary personal data.

Record retention and deletion responsibility

Name the owner for Files, vector stores, platform or application logs, retrieved-result stores, packet copies and internal originals. Record retention basis, deletion trigger, current status, expected confirmation and exclusions. Where multiple teams own different systems, list them separately.

Record the distribution audience and accountable owner

Specify the approved packet version, recipients or roles, purpose, release time, releaser and accountable decision owner. The releaser confirms that the evidence packet may be distributed; the accountable decision owner retains responsibility for the policy or operational choice. These may be different people.

Use a bounded final disposition

The final disposition should be one of: RELEASED_FOR_STATED_REVIEW, RELEASED_WITH_RECORDED_LIMITS, HOLD_PENDING_ACTION or WITHDRAWN. Include reasons and affected claims. Avoid an unqualified “approved”, which can blur packet distribution with approval of the underlying decision.

An illustrative final line might say: “HOLD_PENDING_ACTION: conflict between Procedure A and Procedure B remains unresolved; process owner to establish controlling authority; packet not authorised for implementation use.” This is an example of wording, not a product output or outcome claim. Human review is mandatory before any consequential use.

Conclude with an inspectable boundary, not an autonomous answer

The narrow objective is a dated chain from an authorised source, through a recorded File Search event and preserved excerpt, to an original locator and named human finding. The chain supports inspection; it does not prove completeness, confer authority on the model or replace specialist judgement. Release depends on the quality and ownership of that chain, while HOLD remains the correct result when a material link is unknown.

Preserve the minimum provenance needed to inspect material claims, minimise distribution copies, and assign retention and deletion decisions to authorised owners.

This guide does not cover generic API retries, model selection derived from a ChatGPT fallback, benchmark scores or autonomous decisions. It also does not turn ChatGPT’s GPT-5.5 Instant Mini fallback into an API or Codex model. Any policy, legal, publication, funding, safety, employment or operational conclusion requires an authorised human decision-maker.

Useful Links

OpenAI GPT-5.5 model documentation

OpenAI API model catalogue

ChatGPT release notes

OpenAI File Search guide

OpenAI citation-formatting guide

OpenAI platform data-controls documentation

OpenAI business and API data-usage policy