How to Audit a Completed ChatGPT Deep Research Report Before an Executive Brief

Start with one completed report and one pending briefing decision

Start with one completed ChatGPT Deep Research report. Preserve the available record of how it was created, then identify which individual findings need source and claim testing before use in an executive, market, vendor, policy or competitive-intelligence brief.

The completed report is an input to the audit, not authority to brief. Its sources-used list is a map of cited material, not proof that a claim follows from an opened original. A named accountable human approves the executive brief after source, access and qualification checks.

This method begins only after the report exists. It does not teach the analyst how to launch research, improve a prompt during a run or compare Deep Research with another product. The immediate output is a frozen intake packet and a provenance decision record, not a verdict on the truth of the report. Later gates can examine the source perimeter and test material claims against opened originals; the first gate establishes what was requested, what artefacts survive and which assumptions must not be made.

OpenAI’s Deep Research help page, opened for this article on 3 October 2026, says a user may review and modify a proposed plan, follow or interrupt progress, adjust source access, and receive a structured report with citations or source links. It also describes a completed-report view containing a table of contents, a sources-used section and activity history. These documented artefacts make a provenance review practicable. They do not establish that every historical report, shared view or export retains every intermediate detail.

OpenAI also warns, on its help page about ChatGPT’s truthfulness as opened on 3 October 2026, that ChatGPT can produce incorrect or misleading material, including fabricated citations and references, and recommends opening links directly when accuracy matters. That warning is a reason to verify consequential material, not evidence that the report in front of you contains an error. The auditor must neither trust the report because it looks polished nor condemn it because errors are possible.

Draw the audit boundary before reading for conclusions

The audit boundary lies after completion of the report. Treat the report as fixed evidence of what was delivered at a particular point, even if the underlying chat can still accept messages. Do not ask the system to rewrite, repair or “confirm” the report before preserving the original. A revised answer would be a new artefact, potentially blending later instructions, later sources and a different date with the output under review.

Procedure: first assign an intake identifier; then save or reference the completed report without changing it; next record the intended destination brief and its decision date; finally mark the intake time and the person performing the preservation. If an authorised export is permitted, preserve it according to the organisation’s records rules. If export is not permitted, record an authorised stable reference rather than copying restricted content into an uncontrolled file.

Illustrative example: an analyst receives a report entitled “Northern European procurement-platform outlook” for a committee meeting next month. The analyst labels the received report DR-INTAKE-014, a fictional local intake identifier, records the committee brief as its intended destination and notes that the visible report was received on 3 October 2026. The analyst does not yet accept the report’s statement that a fictional vendor is “available throughout Europe”; that sentence remains a candidate claim for later testing.

If a report is still being generated, being actively steered or awaiting requested additions, it is not ready for this audit. If it is complete but some provenance is absent, proceed and record the absence. Do not reopen the research merely to manufacture a cleaner history. This choice is deliberate: an incomplete but honest provenance record is more defensible than a retrospectively reconstructed one that cannot distinguish preserved fact from recollection.

This boundary also prohibits benchmarks. Do not score the report, calculate an accuracy percentage, count supposed hallucinations, compare completion times, rank models or infer reproducibility from a single artefact. Those activities require a separately designed evaluation with controlled tasks and evidence. Here, the unit of work is one delivered report and the unit of later judgement is one material candidate claim.

Check: before intake continues, write a scope note stating: “Post-completion provenance and claim-assurance review; not a benchmark, model comparison or performance measurement.” If a stakeholder asks for an accuracy score, separate that request from this audit. A tally of ledger states may help manage work, but it must not be relabelled as a model accuracy rate.

If a team later designs a new ChatGPT Work Mode research workflow, the 12-prompt autonomous research playbook provides prompt and deliverable examples. It concerns planning a future run, whereas this article audits the evidence in a report that already exists.

Freeze the intake packet before interpreting the report

The frozen intake packet is the set of preserved artefacts against which the audit will operate. It is distinct from the eventual evidence ledger. The packet records what arrived and what can be established about the run; the ledger will later record what individual sources and claims support. Mixing these stages encourages auditors to “improve” the historical record while assessing it.

The minimum packet consists of the completed report, the original request, the proposed plan and revisions if retained, run timing, source mode, the sources-used list, activity history, a note covering uploaded files and connected apps, and the intended decision timeframe. Preserve the artefacts as received or reference them through authorised locations. Add an intake cover sheet that distinguishes observed facts, information supplied by another person and fields that remain unknown.

Preserve the completed report as the delivered object

The completed report means the actual output submitted for possible use, including its title, visible sections, footnotes, citations or source links, table of contents where present, and any limitations stated within it. A copied executive summary alone is not the report. Nor is a later paraphrase by the commissioning manager.

Procedure: identify the report version; record how it was received; retain visible citation associations; and preserve formatting only where formatting carries meaning, such as a caveat attached to a table. Do not calculate an invented completeness indicator. If the organisation permits a checksum or document-management version identifier, it may be recorded as local records metadata, but it must not be presented as a ChatGPT feature or as proof that the claims are correct.

Illustrative example: a manager forwards three bullets copied from a longer fictional report. The analyst asks for authorised access to the completed report because the bullets omit dates and citation placement. If the report cannot be supplied, the analyst freezes the three bullets as the received object and records “full completed report unavailable”. The analyst does not pretend that the excerpt is a complete report.

Where the complete report is available, preserve it before extracting claims. Where only an excerpt is available, classify the intake as partial and prevent uncited contextual assumptions from entering the brief. An excerpt can be reviewed, but it cannot establish what qualifications, definitions or conflicting evidence appeared elsewhere in the report.

Capture the original request without silently rewriting it

The original request is the instruction or question that initiated the completed research. It is distinct from the report’s own restatement of the assignment. The request shows the intended outcome, audience, geography, date window, source expectations and exclusions only if those elements were actually included.

Procedure: retain the original wording where authorised. On the cover sheet, separately extract the requested outcome, intended audience, jurisdictions, time horizon, named source classes, exclusions and required form of answer. Mark each extracted field as “explicit”, “inferred” or “not stated”. Do not convert an inference into an explicit instruction.

Illustrative example: the fictional request says, “Assess whether Vendor North is suitable for a 2027 procurement shortlist.” It says nothing about geography or minimum company size. The analyst records the outcome and year as explicit, while geography and customer segment remain not stated. A later report sentence about “global suitability” cannot be justified by claiming that global coverage was part of the original request.

If the original request is unavailable, write “original request not retained” and use the report’s stated scope only as a secondary representation. Do not ask the requester to recreate exact wording from memory. A requester may provide a new, dated account of intended purpose, but label it “post-run stakeholder statement”, not “original request”. This preserves the distinction between contemporaneous evidence and later recollection.

Retain the proposed plan and revisions only where they survive

A proposed plan records how the task was intended to be approached; a plan revision records an accepted or requested change before or during research. Neither is equivalent to proof that every planned step occurred. OpenAI’s Deep Research help page, as accessed on 3 October 2026, documents that users may review and modify a proposed plan and may follow or interrupt progress. It does not guarantee that every old export preserves each plan version or intervention.

Procedure: retain the initial visible plan, preserved modifications and any authorised steering notes. Give each surviving version a sequence such as “plan as first retained”, “revision retained at run time” and “steering note retained”. Where timestamps are visible, copy them accurately; where they are absent, do not estimate them from memory or document order.

Illustrative example: a plan initially proposes reviewing public product pages and industry commentary. A retained revision asks for regulator publications to take priority. The completed report cites both categories. The revision shows intended emphasis, but it does not prove that regulator material was exhaustive, current or decisive. Later source-set review must inspect actual sources.

Treat plans as research-contract evidence, not execution evidence. If activity history or source records conflict with the plan, preserve both and record the discrepancy. Plans explain intention while activity artefacts may better indicate conduct; neither alone establishes claim support.

Record run identity, timing and destination without overclaiming

Run identity tells a reviewer which completed artefact is being audited. It is distinct from model identity. A conversation reference, report title, completion time, workspace surface or retained version may identify the run without establishing the underlying model, deployment, fallback behaviour or API configuration.

Use observed dates, not guessed chronology

Record the completion date and time where visibly available, including the time zone. If only a date is visible, do not invent a time. Also record the intake date, audit start date, intended brief date and intended decision period. These dates answer different questions: when the research finished, when the reviewer received it, when evidence was checked and when leaders expect to act.

Procedure: create four separate fields: “run completed”, “packet received”, “sources last opened by auditor” and “decision effective period”. Use “unknown” where necessary. If the report discusses current availability but the decision will occur six months later, flag a mandatory freshness review rather than treating completion date as continuing validity.

Illustrative example: a report completed in July is proposed for an October procurement brief. Its claim that a fictional service is “rolling out now” may have been temporally reasonable in July but unsuitable as an October current-state statement. The intake record does not resolve the claim; it marks the three-month gap and sends it to later date-and-scope verification.

When the decision period materially post-dates the report, require sources supporting time-sensitive claims to be reopened near briefing approval. For stable historical claims, the same refresh may be unnecessary. Frequent reopening improves currentness but consumes review time, so prioritise availability, pricing, policy, leadership, product and regulatory claims whose truth can change.

Do not infer the model from an API documentation page

The official GPT-5.5 developer page, opened on 3 October 2026, identifies an API model and snapshot. It does not identify the model that generated a specific ChatGPT Deep Research report. ChatGPT Deep Research and an API model page are different product surfaces and different forms of evidence.

Procedure: record a model or surface only when the preserved report or authorised workspace evidence visibly establishes it. Use precise labels such as “ChatGPT Deep Research report; underlying model not established from retained artefacts”. Do not use a current API model catalogue to backfill a historical ChatGPT run.

Illustrative example: a report’s recipient says, “This must have used GPT-5.5 because that is the newest model page I found.” The auditor records the recipient’s statement as unverified and leaves model identity unknown. The report can still undergo provenance and claim review without a model label.

Unknown model identity is normally a provenance limitation, not an automatic reason to discard every claim. Escalate it only where the decision specifically depends on a documented processing requirement or approved surface. Refusing to invent the model preserves accuracy without blocking unrelated source verification.

Define the intended decision and timeframe

A research topic is not the same as a decision. “European market conditions” names a subject; “whether to invite three suppliers to due diligence for the 2027 programme” names an intended decision. The audit needs the latter because materiality depends on what leadership will do with the information.

Procedure: record the decision owner, briefing audience, decision date or period, geography, business unit and consequence of a wrong or stale claim. Where these are not yet set, ask the brief owner for a prospective statement and date it as intake metadata. Do not present it as part of the original research request unless it was.

Illustrative example: a general competitor report is redirected to support a board decision on market entry. The source requirements for a board decision may be stricter than those for an exploratory analyst note. The auditor records this destination change and requires fresh human approval rather than assuming the research was commissioned for the board.

If no intended decision or audience can be named, the report may be catalogued but should not be promoted into an executive brief. Exploratory research remains useful for orientation, yet without a defined decision there is no defensible way to judge materiality, acceptable uncertainty or the necessary authority of sources.

Establish the source mode without confusing preference, access and use

Source mode describes the configured research perimeter where that setting was retained. It is distinct from the source set actually used and from the authority of any source. OpenAI’s Deep Research help page, accessed on 3 October 2026, distinguishes restricting research only to entered sites from prioritising entered sites while allowing full-web search. Those settings have materially different audit implications.

Separate site restriction from site prioritisation

“Restrict to these sites” defines an intended domain boundary. “Prioritise these sites but allow full-web search” expresses a preference while retaining a broader perimeter. A report containing citations to preferred domains does not reveal which mode was selected. Conversely, a recorded restriction does not prove that the permitted sites were complete, current or authoritative for every proposition.

Procedure: preserve the visible source-mode wording or authorised run setting where available. Record one of four intake states: “restricted to recorded sites”, “recorded sites prioritised with wider web allowed”, “no site mode retained”, or “mode unclear”. Then list the entered domains separately from sources found in the report. Later review can compare intended perimeter with actual citations.

Illustrative example: a fictional report cites a regulator, a vendor blog and a trade publication. The requester remembers entering the regulator’s domain but cannot show whether it was restricted or prioritised. The auditor records “mode unclear; regulator domain reportedly entered in post-run recollection”. The presence of other domains does not by itself prove a malfunction because full-web search may have been allowed.

Never convert “prioritised” into “restricted”, and never describe either mode as an approval or trust certification. If a decision requires an allowlisted source universe and the retained packet cannot prove restriction, mark the perimeter requirement unmet. The distinction matters: broader search can surface useful contrary evidence, while a strict domain boundary can improve control but omit necessary evidence.

OpenAI’s release notes record that, on 10 February 2026, users could focus Deep Research on specific websites and a larger collection of connected apps as trusted sources. That dated chronology does not prove that a particular account, historical run or report used the capability. Use it only to explain why preserving run-specific configuration matters.

Distinguish available connected apps from actual source use

A connected app being available to an account is not evidence that the run accessed it. A source from a connected app appearing in a report is not evidence that every document in the app was searchable. OpenAI’s Deep Research help page says app availability can depend on plan, country or territory, workspace configuration, role access, provider permissions, connected account and whether the app supports Deep Research.

Procedure: record three separate fields: “connected app reportedly available”, “connected app selected or permitted for this run”, and “specific connected source visibly used”. For each assertion, cite the retained artefact that establishes it. If the export merely displays a generic internal citation that an authorised reviewer cannot reopen, record an access-path gap.

Illustrative example: an internal report cites “Quarterly strategy document” without a stable document identifier. The commissioning analyst can see the citation, but the executive-brief reviewer cannot reopen it under their permissions. The audit records that the connected source appears to have been used but is not independently reviewable by the approver. An authorised evidence extract may be attached under organisational rules; otherwise the dependent claim must be replaced, deferred or excluded later.

Count connected-source use only when the run artefact identifies actual use with enough information for an authorised reviewer to trace it. Do not ask anyone to bypass access controls or paste restricted documents into the audit. Retain enough provenance to support review, but do not duplicate sensitive content merely for convenience.

Record uploaded files as inputs, not automatically authoritative evidence

An uploaded file can be an available input without being current, complete, authentic or suitable for the proposition. The source route “uploaded file” describes access, not authority. A company-created spreadsheet, for example, may be the best source for an internal forecast but a poor source for an external vendor’s current public availability.

Procedure: create an uploaded-file note listing the authorised file title or identifier, version or date if visible, uploader or custodian if known, and whether the approver can reopen it. Record only metadata necessary for the audit packet. Do not include credentials, private access tokens, personal data or unrestricted extracts.

Illustrative example: a fictional report relies on “Supplier comparison final.xlsx”, but two files with similar names exist. The auditor does not guess which version was used. The packet records the ambiguous title and requests an authorised identifier. If none survives, every material claim depending on the workbook carries a provenance limitation.

Where a file cannot be uniquely identified or reopened by an authorised reviewer, do not treat its dependent material as independently verified. A narrow, non-consequential background statement may remain contextual with a clear limitation; a procurement, policy, financial or safety decision requires human review and an accessible evidential basis.

To audit a finished report, first reconstruct how the research run was set up. For a separate pre-run walkthrough of source choices and live steering, see How to Run Deep Research in ChatGPT Work and Codex, then compare those choices with the completed report’s actual source and instruction record.

Preserve the sources-used list and activity history without treating either as proof

The sources-used list is an inventory presented with the completed report. It is distinct from a claim-to-source map and from a source-authority assessment. Activity history records aspects of how research progressed; it is distinct from a complete technical log. OpenAI identifies both as completed-report artefacts on the Deep Research help page accessed on 3 October 2026, but does not describe them as an audit certification.

Freeze the sources-used list before normalising it

Procedure: preserve the list as displayed, then create a separate working copy for later normalisation. Retain duplicate appearances, visible titles, publishers and links at intake because differences may reveal redirects, editions or separate pages. Do not silently replace a cited link with a preferred source at this stage.

Illustrative example: the report lists a fictional vendor announcement twice under slightly different titles and also cites a support page. The intake packet preserves all three entries. A later source manifest may determine that two links resolve to the same canonical page, but the frozen list continues to show what the report presented.

A source’s presence proves only that the completed artefact associates it with the research at some level. It does not prove that the source supports a particular sentence, that it was read in full, that it is authoritative, or that contrary sources were considered. If leadership asks whether “all sources were approved”, answer only from a separate source-control policy and manifest, not from the list’s existence.

Use activity history to identify questions, not to invent execution detail

Procedure: preserve visible activity entries and note whether they indicate searches, source consultation, interruption or other recorded progression. Compare them with the retained plan and source mode. Log discrepancies as questions: planned category absent from visible history; unplanned domain visible; steering request without a retained result; or source access mentioned but not identifiable in the report.

Illustrative example: a retained plan calls for checking official pricing and regulatory status. The visible activity history refers to product announcements and market commentary but contains no clear pricing or regulator step. The auditor records “planned source categories not evidenced in retained activity history”. That is not proof the checks never happened; it is a provenance gap requiring later source-manifest review.

Use activity history as corroborative provenance, not as a comprehensive log of every retrieval, transformation or reasoning step. Where it conflicts with the completed report, preserve the conflict. Do not resolve it by asking ChatGPT to explain retrospectively what it “must have done”. A new explanation would not be contemporaneous run evidence.

Test packet completeness without awarding a score

A completeness check is a field-by-field status review, not a numeric quality score. For every required intake item, use “preserved”, “partially preserved”, “not retained”, “not applicable” or “unknown”. Add the evidence location and reviewer. Avoid traffic-light totals that could be mistaken for assurance of factual accuracy.

Procedure: review the report, original request, plan and revisions, timing, source mode, sources-used list, activity history, uploaded-file note, connected-app note and decision timeframe. For every partial or missing item, write the consequence for later review. “Source mode unknown”, for example, means the auditor cannot claim an allowlisted run; it does not automatically mean every cited source is unusable.

Illustrative example: a packet contains the report, request and sources-used list but lacks the plan and activity history. The auditor records those two absences and continues to build a source manifest from the available citations. The brief owner is warned that research-process conformance cannot be reconstructed, while individual claims may still be verified directly.

Stop the audit only when missing provenance prevents identification of the report, intended decision or evidence needed for a consequential claim. Otherwise continue with explicit limitations. Provenance gaps reduce what can defensibly be said about the run, but direct primary evidence may still support a narrowly rewritten executive statement.

Apply the provenance and plan gate

The provenance and plan gate is an editorial method informed by documented product artefacts. It is not an OpenAI certification, compliance standard, legal opinion or guarantee of accuracy. Passing this gate means that the report and decision context are sufficiently identified for the audit to proceed to source-set and claim-entailment work. It does not mean that the report’s conclusions are correct.

Compare the research contract with the delivered scope

Create a research-contract table with one row for each material scope dimension: intended outcome, audience, geography, date window, population or customer segment, source hierarchy, exclusions, source mode and requested deliverable. Use separate columns for the original request, retained plan, completed report and auditor finding.

Procedure: quote or closely transcribe short scope statements where authorised; classify each relationship as aligned, narrower, broader, changed, absent or indeterminate; and describe the practical consequence. Do not evaluate factual truth yet. This step asks whether the delivered report answers the assignment it was given.

Illustrative example: the request asks about public-sector procurement in the United Kingdom, while the completed report repeatedly generalises from European private-sector examples. The provenance gate marks geography and customer segment as broader or changed. Even if those examples are accurately cited, they do not automatically answer the specified decision.

Proceed where scope differences can be isolated and candidate claims can be narrowed. Require recommissioning or substantial replacement where the delivered report addresses a materially different decision. This permits valid evidence to be salvaged without allowing a well-written but mis-scoped narrative to drive an unrelated executive choice.

Record the gate decision in accountable terms

Use one of four provenance outcomes: “proceed”, “proceed with recorded limitations”, “hold for authorised artefact retrieval” or “stop as unsuitable for this decision”. Name the intake reviewer, record the date and identify the person responsible for resolving each limitation. These outcomes govern movement to the next audit gate; they are not include-or-exclude decisions for individual claims.

Illustrative example: the fictional procurement report has a complete report and request, an unclear source mode, no retained plan revisions and a defined committee date. The reviewer selects “proceed with recorded limitations”, prohibits any statement that the research used only approved sites and sends all material vendor-availability claims to direct source testing.

Choose “proceed” only when the report, decision context and material provenance fields are sufficiently identifiable; use “proceed with recorded limitations” when gaps can be contained; use “hold” when an authorised artefact is likely retrievable and materially necessary; and stop when the artefact cannot be tied to the intended decision or consequential evidence cannot be reviewed. A named human must make and sign this gate decision.

Carry unresolved provenance forward visibly

Do not bury limitations in an intake appendix that later reviewers will not see. Transfer each unresolved item to the source manifest or claim ledger field it affects. “Connected source not reopenable” follows every dependent claim; “decision geography absent” triggers a scope qualifier; “run date unknown” triggers stronger currentness checks.

Procedure: assign each limitation an identifier, affected artefacts, owner, required action and closure evidence. Close it only when authorised evidence resolves it. A verbal assurance may be recorded as a new stakeholder statement, but it does not replace missing contemporaneous provenance.

Illustrative example: limitation PROV-07 states that the site mode was not retained. The later source-set ledger therefore examines every cited domain individually and the executive brief avoids the phrase “research restricted to approved sources”. If an authorised run record is subsequently found, the auditor updates the packet as a dated addition rather than altering the frozen original.

No unresolved provenance item may be silently converted into certainty during executive editing. Consequential decisions require human review of the relevant source, limitation and proposed wording. The model may assist with organising a ledger using sanitised, authorised material, but it cannot approve inclusion, resolve permissions or determine organisational risk.

At the end of this gate, the analyst should possess a frozen, access-controlled intake packet; a research-contract comparison; a clear source-mode status; a record of missing artefacts; and a named human decision about whether to continue. The next stage may build the source manifest, but it must preserve the distinction established here: the existence of a report, citation, sources-used list, preferred-site setting or connected app is provenance evidence, not proof that a material executive claim is supported.

Apply the source-set gate before testing individual claims

The source-set gate asks whether the completed report drew from a source universe suitable for the pending executive decision. It does not yet ask whether a particular citation supports a sentence; that belongs to the later claim-entailment review. The distinction matters because a report can quote every listed source accurately while still omitting the source class needed to answer the question. Conversely, a broad and balanced-looking bibliography can contain citations that do not support the report’s conclusions.

This gate is an editorial assurance method, not an OpenAI certification or a measurement of model accuracy. OpenAI’s Deep Research help page, opened for this article on 3 October 2026, says the completed-report view includes a sources-used section and activity history. Those artefacts make reconstruction practical, but OpenAI does not describe the sources-used section as proof of completeness, authority, approval or balance. OpenAI also warns in its separate truthfulness guidance, opened on the same date, that ChatGPT can produce incorrect or misleading information, including fabricated citations and references, and recommends opening links directly when accuracy matters.

Define what the gate must establish

Begin with the pending briefing decision rather than the apparent prestige of the bibliography. Write one sentence stating the proposition for which the source set must be adequate. For example, a fictional competitive-intelligence brief might need to establish: “What publicly documented pricing conditions apply to Vendor Alder’s fictional analytics service for United Kingdom enterprise customers at the briefing cut-off date?” That formulation creates source requirements: current pricing evidence, enterprise scope, United Kingdom applicability and a stated cut-off date. A general industry article may provide context, but it cannot by itself establish Vendor Alder’s current contractual price.

Next, translate the proposition into required source classes. For the fictional pricing question, recommended classes might include the vendor’s current pricing material, dated contractual or ordering documentation where authorised and relevant, public filings containing attributable commercial information, and contemporaneous product documentation defining what the priced offer includes. Secondary reporting may help identify changes or disputes, but it should not silently replace the issuer’s current commercial terms. This hierarchy is an editorial recommendation: it does not guarantee that an official source is complete, accurate for every customer or free from commercial framing.

Use three checks in sequence:

1. Perimeter check: determine which source environments the run was permitted to search and whether entered sites were restrictive or merely preferred.

2. Manifest check: identify every unique source that appears in citations or the sources-used section, then record enough metadata for another authorised reviewer to reopen and assess it.

3. Coverage check: compare the manifested source classes with the evidence classes required by the decision, recording absences and access failures rather than filling them from memory.

Pass a source set to claim-level review only when its perimeter is known or explicitly marked unknown, its material sources are independently reopenable or formally recorded as unavailable, and it contains—or transparently lacks—the source classes necessary for the intended proposition. “Pass” means suitable for the next audit gate, not suitable for publication. If an essential primary source class is absent, the appropriate result is “research required” or “scope the claim more narrowly”, even when the report contains many reputable secondary sources.

Breadth must serve decision relevance. A broader source set can reveal contradictions and alternative interpretations, but it also increases the work required to distinguish originals from repetition. A tightly restricted set can improve provenance control, yet it may exclude critics, regulators, later corrections or relevant market evidence. Do not resolve that trade-off by counting sources. Resolve it by asking whether each necessary evidential role is represented and whether material counter-evidence had a plausible route into the run.

Reconstruct the permitted source perimeter precisely

A source perimeter describes where the completed run could look; a source manifest records what evidence can actually be identified after the run. These are not interchangeable. A site may have been permitted but never used, while a cited page may have entered through full-web search even though several preferred domains were entered. Record both dimensions separately.

Classify site restriction and site prioritisation differently

OpenAI’s Deep Research help page, as reviewed on 3 October 2026, distinguishes research restricted “only” to entered websites or domains from an option to prioritise entered sites while allowing full-web search. The first is a perimeter constraint. The second is a preference within a wider public-web perimeter. OpenAI’s 10 February 2026 release note provides chronology for the ability to focus research on named websites and a larger collection of connected apps as trusted sources, but it does not prove which setting governed any particular report.

For an already completed report, inspect the preserved run record for visible evidence of the selected mode. Record the setting in one of four recommended states: “restricted to recorded sites”, “recorded sites prioritised with full web permitted”, “full web with no recorded site preference”, or “not established”. Copy the observed wording or preserve an authorised screenshot where policy permits; do not reconstruct a setting from the citations alone.

Consider a fictional competitive-intelligence report citing Vendor Birch’s website, an industry association and several newspapers. If the intake packet shows that vendor-birch.example was prioritised while full-web search remained permitted, classify the perimeter as full web with a named priority. Do not describe the source set as an allowlist. If the packet instead shows that research was restricted only to Vendor Birch’s domain, record that narrower perimeter and flag the structural inability to discover independent sources outside it. The presence of reputable vendor pages does not remove that limitation.

Use “restricted” only when preserved evidence establishes a constraint limiting research to the entered sites. Use “prioritised” when named sites received preference but the wider web remained permitted. If the configuration is missing, mark it “not established”; never infer restriction because every visible citation happens to share a domain. Restriction offers stronger control over where evidence originates but weaker protection against omission and one-sided framing. Prioritisation allows broader discovery but cannot assure an executive reader that every used source came from an approved list.

Separate public-web access, uploaded files and connected-app routes

OpenAI’s help page describes research that may use web content, uploaded files and, where configured, supported connected apps. App access can vary by plan, country or territory, workspace configuration, role, provider permission and connected account. The access-route labels used in this audit are the reviewer’s own fields, not product telemetry; each route raises different questions about reopening, permissions and source freshness.

For each manifested source, use one access-route label: “public web”, “uploaded file”, “connected app”, or “route not established”. If a public page was also uploaded as a file, record the route actually evidenced by the report and cross-reference the other copy rather than merging them. An uploaded copy may preserve historical content that has since changed online; the live page may be current but no longer reproduce what the run saw. That difference must remain visible.

For a fictional pricing review, suppose the report cites a Portable Document Format (PDF)A fixed-layout document format used to preserve page appearance across systems. Open glossary entry named Alder-enterprise-pricing.pdf. The filename does not establish whether it came from a public webpage, an analyst upload or an internal connected repository. The reviewer should inspect the citation target and activity evidence, then record the route that can be demonstrated. If no route survives, enter “route not established” and ask the report owner whether an authorised copy or stable source location can be supplied. Do not search personal storage or paste private content into a new prompt merely to make the ledger look complete.

Availability of an access route is not evidence of use. A connected app’s presence in a workspace, or its appearance among available options, must not be recorded as a source used by the completed run. Require a citation, activity entry, source identifier or other authorised run evidence that ties a particular item to the report. Internal material may be highly relevant, but a briefing approver who cannot lawfully reopen it cannot verify the proposition from a bare citation label.

Respect the read-action boundary

A connected-app citation can show that a source was referenced, but not that its content was approved, unchanged or visible to every later reviewer. The audit must test whether an authorised reviewer can reopen the relied-upon original, identify its version and determine whether the cited passage supports the claim. This method does not infer what actions the research tool took inside the connected app.

Record the source item read, its accessible identifier, the connected provider or repository where that can be disclosed, and the reviewer’s own access result. Do not imply that the report modified an internal record, wrote back an approval or created a source-of-truth entry. If an audit process needs an approved extract attached to the briefing record, that is a separate human-controlled records action outside the research run.

In a fictional case, the report references “fiscal-year planning sheet” through a connected document store. The auditor should attempt to reopen that exact authorised item, record the repository route and version or date visible to the reviewer, and note whether the relevant passage can be located. If the item cannot be reopened, the correct status is “connected source unavailable to reviewer”, not “confirmed from internal data”. The decision rule is to defer or replace any consequential claim that depends solely on an inaccessible connected item unless a named authorised owner supplies reviewable evidence. Attaching an extract can improve reviewability but may duplicate sensitive material; follow the organisation’s permissions and records rules, retain only what is necessary, and require human approval.

A completed report audit should record who was permitted to run the work and which review records are available. The enterprise workspace administration-controls overview discusses groups, model access and Codex policy logging as separate workspace governance topics; none proves authorisation or source validity for this particular report.

Build an audit-ready source manifest rather than a cleaned bibliography

A bibliography is designed for reading and attribution. An audit manifest is designed for reopening, comparison, exception handling and accountability. Keep the report’s original citation labels intact, then add normalised metadata in separate fields. Do not “improve” malformed entries by replacing them with plausible sources without recording the substitution.

Create one row for each identifiable source object

Start from both the sources-used section and all in-text citations. Deduplicate only after opening the targets. Two links may resolve to the same canonical page, while two identically titled files may be different versions. Assign a stable audit identifier such as S-001 to each source object. Keep a crosswalk listing every original citation label that points to it.

For each row, record the following recommended fields:

The decision rule is to preserve ambiguity as data. If a date, route, publisher or permission status cannot be established, enter “not established” or “not stated”; do not leave the field blank and do not substitute an assumption. The additional review time produces a manifest that another person can actually interrogate. A shorter, honest manifest is more useful than a polished one containing reconstructed metadata.

Judge authority proposition by proposition

“Official” is not a universal authority label. A vendor’s current pricing page may be the direct source for a displayed list price, but it may not establish what a particular enterprise pays after negotiation. A company press release may directly establish what the company announced, yet it cannot independently establish market adoption, customer satisfaction or competitive superiority. A regulator may be authoritative for a formal decision within its jurisdiction but not for a vendor’s current product packaging.

Write the authority field as a bounded sentence. For fictional source S-014, an acceptable entry might be: “Vendor Alder is the original issuer for the displayed United Kingdom list price and named package inclusions; this page does not establish negotiated enterprise cost, taxes, discounts or availability outside the stated region.” That formulation tells the later claim auditor what the source can and cannot support.

The practical procedure is to isolate the proposition before assigning authority. Ask: who controls or directly observes this fact; what period and geography does the source cover; and is the source reporting an action, a claim, a measurement or an interpretation? Then compare the answer with the executive wording. If the report says “Vendor Alder is the cheapest enterprise option”, no single vendor pricing page is authoritative for the comparative claim. The manifest should identify it as original for Alder’s displayed price but insufficient for cross-market comparison.

Assign authority only for a specified proposition, never to an entire publisher or domain. Primary sources can be closest to an event while also being selective or commercially interested. Secondary sources can add scrutiny and comparison but may repeat stale or misread primary material. Preserve both roles rather than treating “primary” as automatically true or “secondary” as automatically weak.

Preserve history without mistaking it for current state

A source can be superseded and still be valuable. Historical announcements establish what was said at a particular time; current support or pricing pages are usually more relevant to current-state wording. Do not delete old sources merely because a newer page differs. Mark the temporal role and record the conflict.

In a fictional pricing case, an archived announcement may state that Vendor Cedar introduced a service at one price, while the current official pricing page displays a different package structure. The manifest should classify the announcement as historical and the live page according to the current cut-off date. It should not average the figures or describe the older announcement as false without evidence. The later claim review can then decide whether the executive brief needs current pricing, change chronology or both.

For a current-state proposition, prefer the most current source that is authoritative for that proposition, while retaining older authoritative material as chronology. If sources conflict and neither clearly supersedes the other, mark the proposition unresolved and require a named human decision. Where price, market access or competitive positioning could affect a consequential decision, preserve material uncertainty even if it makes executive wording less concise.

A citation in a completed report still needs a check against the current source-of-record. The offline-search source freshness guide explains how indexed or cached workspace web results can be stale and when an approved live source, document upload or archived record is a more suitable fallback. It does not establish which search mode produced this particular report.

Test completeness and balance by evidential role, not visual credibility

A trusted-looking source list cannot establish completeness because completeness is relative to a defined question, timeframe, geography and source perimeter. It cannot establish balance because multiple sources may repeat one original statement, share the same commercial interest or omit the same affected group. Ten polished citations may represent one evidential chain.

Map source families and repetition

For every material source, add a “derives from” note where the source visibly relies on another item. If three trade articles quote the same Vendor Elm announcement, group them as one source family for the announced fact. Keep all three manifest rows if the report cited them, but do not count them as three independent confirmations. Where derivation is unclear, record “dependency not established” rather than asserting independence.

Use a source-role matrix with rows for the questions the executive claim requires and columns for available evidence classes. A fictional claim that Vendor Elm “cut enterprise pricing and expanded availability across Europe” contains at least two propositions. The price proposition may require dated comparable pricing terms; the availability proposition may require current eligibility, countries, plans and rollout status. A press release may announce both, but current support material or terms may be needed to establish present applicability.

A source set is not balanced merely because it contains different domains or publication names. Treat sources as materially independent only when they add distinct first-hand evidence, analysis, jurisdiction, timeframe or stakeholder perspective. Dependency mapping takes longer than scanning a bibliography, but it prevents repeated publicity from masquerading as corroboration.

Look for missing source classes

Compare the manifest with the source classes specified at the start of the gate. Mark each class “present and reopenable”, “present but unavailable”, “represented only by secondary evidence”, “not present”, or “not applicable”. Avoid a numerical completeness score; it would imply comparability and precision that the audit does not establish.

For a fictional claim that Vendor Fir reduced enterprise costs by 40 per cent, a marketing blog that repeats the percentage is not enough to establish the commercial proposition. The reviewer should look for the attributable basis: comparable pricing schedules, a defined cost model, a public filing, an authorised contractual source or a named primary statement explaining the baseline and population. If none appears in the report’s source set, record the missing primary basis. Do not invent a denominator or treat the repeated percentage as verified.

Recommended handling for that illustrative case is “research required” or “exclude”, depending on the brief deadline and materiality. A narrower wording such as “Vendor Fir’s marketing blog claims a 40 per cent reduction” may be factually attributable if the original page can be opened, but attribution does not make the underlying saving true. A human editor must decide whether repeating the claim, even with attribution, is useful and proportionate for the executive decision.

If the claim depends on a source class absent from the manifest, do not allow secondary repetition to fill the gap. Either obtain authorised primary evidence, narrow the wording to what the available source directly establishes, defer the item or exclude it. A time-sensitive brief may proceed with a clearly qualified unknown, but it must not convert urgency into certainty.

Interrogate apparent balance

Balance does not require an equal number of favourable and critical sources. It requires a source design capable of revealing material qualifications, counter-evidence and changes relevant to the decision. For a vendor claim, that may mean checking issuer material, current customer-facing documentation, relevant official records and credible independent reporting. The exact mix depends on the proposition.

In a fictional competitive review, every source may agree that Vendor Grove announced a new package. That agreement establishes little about adoption or comparative value if all articles reproduce the announcement. The reviewer should separate the undisputed event—an announcement—from untested conclusions about market effect. If the brief needs only the announcement, the set may be adequate. If it needs a conclusion about competitive displacement, additional evidence classes are required.

The decision rule is tied to the intended wording: approve the source set for a narrow announcement claim only if the announcement can be directly verified; do not approve it for market-impact language without evidence suited to that proposition. Broader claims can sound more useful to executives, but they demand broader and more independent evidence. Prefer a narrow verified fact over a strategically attractive inference presented as fact.

Record unavailable, changed and inaccessible evidence as findings

An unavailable source is not an empty administrative field. It changes what the audit can establish. A human reviewer must document the failure and decide whether the claim can be supported another way. Neither the analyst nor ChatGPT should reconstruct the missing content from memory, a search snippet or an uncited paraphrase.

Use a controlled reopening procedure

Open each source through the recorded access route. Confirm the title or identifying metadata, publisher, displayed date, relevant geography and whether the content still contains the passage apparently relied upon. Record the check date, reviewer and one factual result: opened as expected, redirected to an equivalent canonical page, content changed, page unavailable, paywalled, permission denied, identifier missing or source not identifiable.

If the page has changed, preserve the distinction between “current page differs” and “the report was wrong”. The completed report may have relied on content visible at run time, but unless an authorised historical copy survives, the auditor cannot confirm that. Record what is observable now, identify any preserved dated copy already in the audit packet, and avoid asserting undocumented past content.

For a fictional Vendor Hazel pricing claim, suppose the citation now redirects to a generic products page without the cited figure. Enter: “Changed or redirected; cited pricing statement not located during last-opened check.” If an authorised uploaded copy in the packet contains the old page, manifest it as a separate historical source and compare dates. If no copy survives, classify the pricing evidence as unavailable rather than recalling what the page supposedly said.

A material claim whose only cited support is unavailable, changed beyond verification or inaccessible to the approver cannot be treated as verified. Replace it with reopenable evidence, qualify it as an unresolved historical statement where appropriate, defer it or exclude it. Preserving an exception may delay the brief, but silent reconstruction destroys the audit trail.

Handle paywalls and permission boundaries without bypassing them

A paywalled source may still be legitimate evidence for an authorised subscriber, while being unusable to a reviewer without access. Record the publication, article identifier, date, author where visible, access status and which authorised reviewer—if any—can reopen it. Do not copy substantial restricted content into an unauthorised prompt or shared ledger.

Apply the same discipline to connected-app and uploaded-file evidence. Keep untrusted data, personal information, credentials, secrets, private links and unrestricted internal document contents out of prompts. Store only the minimum authorised excerpt or location needed for review, subject to the organisation’s permissions and records rules. OpenAI’s documented app conditions do not override provider permissions or workspace access controls.

In a fictional case, a report’s decisive market-share statement cites an internal slide available only to the original analyst. The reviewer should request an authorised evidence extract or access route from the content owner. If that cannot be provided, record “permission-restricted; independent review not completed”. Do not ask the analyst to paraphrase the slide from memory and enter that paraphrase as source evidence.

Access by the original run or analyst does not equal reviewability by the brief approver. Consequential inclusion requires either authorised reopening by an accountable reviewer or replacement with evidence that can be reviewed. Where disclosure must remain limited, use a named authorised reviewer who can attest to the bounded proposition and record that approval without exposing unnecessary source content.

Escalate exceptions to a named human

Create an exception entry for every material source that is missing, changed, paywalled, permission-restricted or otherwise inaccessible. Record the affected claim identifiers, attempted route, date checked, result, required follow-up, content owner and decision deadline. The report itself must not decide that an exception is immaterial.

A recommended source-set gate outcome uses four non-numeric states: “ready for claim review”, “ready with declared source limitations”, “additional source work required”, or “cannot support the intended briefing scope”. For example, a fictional pricing report might be ready for review of a narrow published-list-price claim while being unable to support its broader assertion about total enterprise cost. Record both outcomes against their respective propositions instead of assigning one label to the whole report.

The final decision rule is that a named human must approve progression whenever source limitations could affect a consequential executive conclusion. That person may accept qualified wording, commission replacement research, narrow the brief, defer publication or exclude the item. The model may organise the manifest and surface gaps, but it cannot grant permissions, establish unavailable content or approve the executive decision.

An honest decision record takes precedence over a clean narrative. Executives may prefer concise conclusions, yet removing unresolved source limitations can make the brief deceptively certain. Carry material exceptions forward in proportionate language, retain the manifest behind the brief, and require the approver to sign off on any decision to include a claim whose source perimeter or evidence access remains incomplete.

Convert report prose into claims that can be tested

A completed ChatGPT Deep Research report may look like a finished briefing document, but its paragraphs are only the starting material for this gate. OpenAI’s Deep Research help page, accessed for this article on 3 October 2026, says that a completed report can contain citations or source links, a sources-used section and activity history. Those artefacts make claim-level review possible; they do not establish that a cited sentence is accurate, complete, current or suitable for an executive decision. OpenAI’s separate truthfulness guidance, also accessed on 3 October 2026, warns that ChatGPT can produce incorrect or misleading material, including fabricated citations and references, and recommends opening links directly when accuracy matters.

The practical distinction is between citation presence and evidential entailment. Citation presence asks whether the report points somewhere. Entailment asks whether the opened source actually supports the precise proposition being considered. An accurate, current link can support only a narrower claim than the report makes. Conversely, a source may contain useful background without supplying evidence for the adjacent conclusion. The recommended procedure is therefore to work from individual claims rather than approving or rejecting a paragraph as a whole.

Extract the exact wording before paraphrasing it

Create one ledger row for every material statement that might enter the executive brief. Begin by copying the exact report wording, including its qualifiers, dates, quantities and verbs. Preserve the report version and paragraph or section location. Add a separate field for proposed brief wording, but leave that field blank until the evidence has been checked. This prevents a reviewer from unconsciously repairing an overstatement and then auditing the repaired version rather than what the report delivered.

Materiality should be defined for the destination brief, not by sentence length. A claim is material when changing or removing it could affect a decision, resource allocation, risk assessment, market view, vendor evaluation, policy position or public statement. A short assertion such as “The service is available globally” may be more material than a page of accurate company history. Editorial colour that cannot affect the decision may be reviewed less intensively, but it must not be allowed to carry an unsupported factual implication.

For example, suppose a fictional report states: “Vendor Alder’s new forecasting feature is available globally to all customers, reducing adoption barriers for multinational buyers.” Do not create one ledger row headed “availability”. Preserve the whole sentence, then identify at least four candidate propositions: the feature is available; its geographical scope is global; every customer plan is eligible; and the availability reduces adoption barriers for multinational buyers. The first three are factual availability claims. The final proposition is an inference about buyer behaviour and may require different evidence.

If two parts of a sentence could receive different entailment classifications or different inclusion decisions, split them. Excessive splitting can make the ledger cumbersome, but leaving independent propositions bundled allows one supported detail to lend false credibility to an unsupported conclusion. For an executive brief, clarity should prevail whenever a proposition is material.

Separate facts, quotations, calculations, inferences and recommendations

Assign each claim one or more types: fact, quotation, calculation, inference or recommendation. These labels describe what must be verified; they do not grade quality. A fact asserts an externally checkable state. A quotation attributes exact or closely paraphrased words to a speaker or document. A calculation derives a value from stated inputs. An inference interprets evidence or connects observations. A recommendation proposes an action. Compound wording should be split where these types are mixed.

Use a five-step procedure. First, underline externally checkable nouns, dates, quantities and availability conditions as factual elements. Second, isolate attributed language and verify whether quotation marks are literal or merely stylistic. Third, reproduce any arithmetic from the source inputs, retaining units, currency, period and denominator. Fourth, mark causal, comparative or predictive language as inference unless the source itself establishes it within an appropriate method. Fifth, mark verbs such as “should”, “prioritise”, “avoid” or “select” as recommendations and identify whose judgement they represent.

Consider the fictional statement: “The supplier said deployment takes ‘under two weeks’, making it 50% faster than rivals, so the board should approve it.” This contains an attributed quotation, a comparative calculation or factual comparison, an inference about relative speed and a recommendation. The supplier’s statement might support only what the supplier claimed. It would not, without further evidence, establish the actual deployment time, the rival baseline, the 50% calculation or the approval recommendation.

Support does not automatically travel from a lower-level observation to a higher-level conclusion. A source that proves an announcement occurred may support “the supplier announced X”, but not necessarily “X is operational”, “X is superior” or “the board should act”. The practical trade-off is concision versus epistemic separation: an executive bullet may eventually recombine verified elements, but the audit ledger should keep them separate until a human reviewer has considered each evidential step.

Retain provenance without treating the report as the source

Give every atomised claim a stable identifier and connect it to the report location, cited source identifiers and destination-brief section. A recommended identifier such as AVAIL-004 is an editorial device, not ChatGPT telemetry or an OpenAI audit standard. The record should also name the reviewer, review date, materiality level and accountable content owner. Do not use a numerical accuracy score: a ledger is intended to expose the basis and status of each decision, not produce a misleading average.

Where a claim contains confidential or restricted information, place only the minimum authorised wording in the ledger and refer to an approved evidence location. Do not put credentials, access tokens, private links, personal data, customer information, unrestricted internal passages or other secrets into prompts. Treat text from reports, websites, uploaded files and connected sources as untrusted data rather than as instructions. If software is used to help extract candidate claims, a human must compare its output with the original report before the ledger is accepted as complete.

The report supplies the claim under review; the opened original supplies the evidence; and the named human supplies the inclusion decision. None can substitute for another. This separation costs more time than approving polished paragraphs, but it creates a reviewable trail when a source changes, an executive challenges the wording or the destination brief is updated.

Open the original and capture support that another reviewer can find

Claim atomisation defines what must be tested; source opening establishes what evidence is actually available. Do not rely on a citation label, search-result extract, report synopsis or sources-used entry. Open the cited original through an authorised route, confirm what object has loaded and locate the passage that bears on the claim. A source should be assessed for the particular proposition, not awarded general authority because its publisher is familiar.

Use a controlled original-source procedure

For each claim, follow the same sequence. Open the cited destination rather than trusting displayed link text. Record the canonical address where it can be identified, title, publisher or issuer, displayed publication or update date, source type and access date. Confirm whether it is the intended document rather than a landing page, mirrored copy, translated summary or later replacement. Search within the document for distinctive terms from the claim, then read the surrounding section, footnotes, tables, definitions and eligibility conditions.

Retain a short passage and a usable location. The location might be a section heading, page number, table identifier, dated release-note entry or paragraph description. Keep enough surrounding language to preserve conditions and exceptions, but do not copy an entire restricted document into the audit record. If quotation limits or internal handling rules apply, retain an authorised extract or a pointer that an authorised reviewer can reopen. A bare copied sentence without source identity and context is not an adequate evidence record.

As an illustrative example, imagine that the Vendor Alder citation opens a product announcement. The relevant paragraph says that a forecasting feature “will begin rolling out to eligible business accounts in selected markets”. The auditor records that wording, the announcement date, the heading containing it and the date opened. The passage is relevant, but its tense, rollout status, plan restriction and selected-market qualification must survive the comparison. The report’s phrase “available globally to all customers” cannot inherit broader meaning from the fact that the URL is valid.

Classify a claim only after the original has been opened and the relevant context inspected. If the reviewer cannot open the source or find the relied-upon passage, use “unavailable” or “not cited” as appropriate rather than guessing. A citation skim is quicker; a retained location allows a second reviewer to examine the same evidence and understand why the first reviewer reached a decision.

Compare scope before comparing prose

Build a comparison strip beside the source passage with fields for subject, product or service surface, factual state, date, geography, eligible plan or population, rollout phase, quantity, unit, timeframe and exceptions. Populate only fields relevant to the claim. This turns vague impressions such as “the citation looks close” into explicit questions. It also exposes cases in which every word seems plausible but the report has silently widened one dimension.

For the fictional availability example, compare the report and source dimension by dimension. The report says “available”; the source says “will begin rolling out”. The report says “globally”; the source says “selected markets”. The report says “all customers”; the source says “eligible business accounts”. The report implies a completed state; the source describes a future or staged process. These are not stylistic discrepancies. They alter who can use the feature, where, when and under what conditions.

Date comparison needs more than checking whether a page is recent. Identify the state the claim purports to describe and the decision date for the brief. A launch announcement may accurately describe an intended rollout at publication but be insufficient for current availability. A current support page may supersede it for present-state wording, while the announcement remains useful chronology. Do not average conflicting dates or silently merge historical and current conditions.

OpenAI’s Deep Research help page, accessed on 3 October 2026, illustrates why these dimensions matter for product claims generally: it qualifies availability and connected-app access by such conditions as plan, country or territory, workspace configuration, role, provider permissions and account circumstances. The specific conditions for the fictional vendor must come from that vendor’s evidence, not from OpenAI’s page. The methodological lesson is that universal wording should trigger explicit checks for account, plan, region, permissions and rollout boundaries.

Use the narrowest wording that covers every material condition established by the controlling evidence. Where different sources govern different dimensions, cite and record each one rather than forcing one source to support the whole sentence. Executive prose should remain concise, but compression must not erase a condition that could change the decision.

Run a forward check from the controlling source

A backward check starts with the report claim and asks whether the citation supports it. Add a forward check: start with the controlling source and ask which important qualifications would be omitted if the proposed brief wording were published. This catches selective citation, in which a sentence is technically supported by one passage but nearby eligibility, definition or limitation language is left behind.

Use four forward-check questions. What does the source expressly limit? What population, date or product surface does it define? What exceptions or dependencies appear nearby? What would a reasonable executive infer from the proposed bullet that the source does not establish? Read headings, notes and linked definitions where they are part of the same controlling material. Do not expand into an endless web search; focus first on qualifications necessary to interpret the cited proposition.

Suppose a fictional policy document says a pilot applies to “participating offices”, while an appendix identifies only two offices and an expiry date. A report sentence stating “The organisation permits the practice” may quote a true fragment yet omit the pilot scope and end date. The forward check moves from the policy’s operative clause to its definitions and appendix, revealing that the organisation-wide present-tense claim is too broad.

If an omitted qualification would alter eligibility, timing, financial significance, legal or policy meaning, operational feasibility, or the executive’s likely action, it must appear in the brief or the claim must be withheld. Minor drafting detail can remain in the evidence record, but decision-changing qualifications belong in the executive wording.

Handle inaccessible and changed evidence without reconstructing it

If a citation fails, distinguish the failure modes. “Unavailable” means the identified source cannot be independently opened by the authorised reviewer, has moved without a reliable replacement, requires unavailable permission, or has materially changed so that the relied-upon passage cannot be confirmed. “Not cited” means the report provides no source for the proposition. A source can also be accessible to the original analyst but unavailable to the final approver because of internal permissions; that is still an approval problem.

Record the attempted authorised route, date, visible failure category and permissible next step. Do not bypass access controls, request credentials in a prompt or copy restricted content into an unauthorised system. For an internal connected-document example, the report may display a citation label but no stable document identifier that the approver can reopen. The analyst should obtain an authorised evidence extract or ask an authorised source owner to attest to the passage and scope. If neither is possible, the claim remains unavailable for this brief.

Inaccessible evidence cannot support an independently reviewable executive assertion unless the organisation’s authorised approval process provides an acceptable substitute. Restricted primary material may be stronger than public commentary, but its value is limited if the accountable reviewer cannot verify its content and conditions.

Classify the relationship between each claim and its evidence

Use seven entailment states: direct support, partial support, supports a narrower claim, background only, contradicted, unavailable or changed, and not cited. These classifications are an editorial recommendation informed by the product artefacts and limitations documented in OpenAI’s official pages; they are not an OpenAI certification. Apply the state to a particular claim-source relationship. The same source may directly support one proposition, provide background for another and contradict a third.

Reserve direct support for aligned propositions

Mark “direct support” when the source establishes the material proposition at the same relevant level of certainty and with compatible scope, date, geography, population, plan, product surface and units. Exact wording need not match, but the proposed claim must not add meaning. For a quotation, direct support also requires accurate attribution and faithful words or a clearly identified paraphrase. For a calculation, the inputs and method must be visible and reproducible.

An illustrative direct-support case would be a brief saying, “The fictional programme’s published eligibility period ends on 30 June”, where the controlling programme document explicitly gives that date for the same programme and period. Verification still includes checking whether the document has been superseded and whether the date refers to applications, service delivery or another milestone.

Use direct support only when no decision-relevant qualifier has been added, removed or changed. If a reviewer has to supply an unstated assumption to make the claim true, select another classification. This strictness may reduce the number of clean “verified fact” rows, but it prevents ambiguity from being laundered into certainty.

Distinguish partial support from a supportable narrower claim

Use “partial support” when a source substantiates some components of the exact claim but other material components remain unresolved. Use “supports a narrower claim” when the source permits a complete, precise rewrite with reduced scope. The distinction matters operationally: partial support usually requires additional evidence or deletion of unsupported components; narrower support already supplies a viable replacement proposition.

Return to “Vendor Alder’s feature is available globally to all customers.” If the source confirms that the feature exists but says nothing usable about availability, plans or countries, classify the whole original claim as partially supported. If it states that rollout has begun for eligible business accounts in named markets, classify the original as “supports a narrower claim” and draft an example replacement: “Vendor Alder says rollout has begun for eligible business accounts in the markets named in its announcement.” This sample wording is an editorial example, not a claim about a real vendor or a product guarantee.

Do not preserve “globally” as shorthand for “more than one market”, and do not convert “rolling out” into “available”. Mark unlisted countries, customer categories and completion timing as unknown unless another controlling source resolves them. If a current support page provides different conditions, compare publication roles and dates rather than combining the broadest fragments from each.

Choose “supports a narrower claim” only if the revised claim is fully supported and remains useful to the executive decision. Otherwise retain “partial” and seek evidence or remove the claim. A narrower finding may be less dramatic, but it is more defensible and can reveal that the market implication remains uncertain.

Keep background evidence out of the proof column

Classify a source as “background only” when it explains context, terminology, chronology or a general trend but does not establish the proposition under review. Background may improve a brief, yet it cannot carry a specific claim merely because the topics overlap. A company overview does not prove a current product entitlement; an industry article does not establish one supplier’s contract terms; a historical release note does not prove the configuration of a particular completed run.

For a product chronology example grounded in the assigned official sources, OpenAI’s release notes record that on 10 February 2026 Deep Research could focus on named websites and a larger collection of connected apps as trusted sources. That dated note can support the historical statement about the announced change. It cannot prove that a particular completed report used a named site restriction, had access to a particular app or drew evidence from that app. Those facts require the preserved run record and source manifest.

If the source merely makes the claim plausible, understandable or historically situated, classify it as background. Background can remain in a supporting note, but moving it into the proof column would conceal the absence of proposition-specific evidence.

Record contradiction rather than choosing convenient wording

Use “contradicted” when an authoritative source states a materially incompatible fact, condition or status. Record both the report wording and contrary passage. Then assess whether the conflict arises from dates, jurisdictions, definitions, versions or genuine disagreement. Contradiction is not resolved by counting sources or selecting the sentence that better suits the draft.

Imagine an earlier fictional announcement says a service is planned for five territories, while a current official support document lists only three eligible territories and labels two as pending. For a current-state claim, the current controlling document may deserve priority; the announcement remains historical evidence. The ledger should record the temporal explanation rather than describing the older page as simply false.

Do not include a contradicted claim as settled fact. A named human must choose whether to replace it with the current supported state, qualify it with the unresolved conflict, defer pending clarification or exclude it. Executive readers need a usable conclusion, but apparent certainty is not a legitimate solution to conflicting evidence.

Use unavailable and not cited as substantive findings

“Unavailable or changed” and “not cited” are not clerical placeholders. They identify different assurance gaps. An unavailable source was identifiable but could not be checked in the form required. A not-cited claim lacks an evidence route in the report. Searching for replacement evidence is a new research action, not proof that the completed report had adequate support.

For example, a report might say that a fictional rival reduced enterprise costs by 40 per cent while citing only a general marketing article elsewhere in the paragraph. If no citation maps to the 40 per cent statement, mark it “not cited”. Do not infer the denominator, period or customer profile. A reviewer may commission a search for an official pricing page, attributable primary statement, public filing or authorised contractual evidence, but the existing claim remains unsupported until that separate work is completed and reviewed.

No material claim enters as verified fact while its state is unavailable or not cited. It may be deferred as an open question if the uncertainty itself matters. Evidential sufficiency takes precedence over briefing completeness; an explicit gap is preferable to an exact-looking figure whose basis cannot be reproduced.

When a completed deep research report touches legal questions, verify each cited source against the draft claim it supports and route the result to a qualified reviewer, using prompts such as those in ChatGPT-5.5 and Codex Prompts for Legal Drafting to check source locations and flag uncertainty before the executive brief is signed off.

Translate entailment findings into accountable human decisions

Entailment classification describes the evidence relationship; it does not make the publication decision. Add a separate decision field with five controlled outcomes: include, qualify, replace, defer or exclude. This separation allows the same evidence state to be handled differently according to materiality and purpose. For example, background evidence may justify including a clearly labelled context sentence but cannot justify including a disputed availability claim.

Apply the five decisions consistently

Choose “include” when the material proposition has direct support, is current enough for the decision and has no unresolved qualification that would alter interpretation. Choose “qualify” when a supported statement remains useful but must carry a date, geography, plan, source-attribution or uncertainty boundary. Choose “replace” when the original claim is too broad or poorly sourced but a different directly supported claim can perform a legitimate role. Choose “defer” when evidence may become available and omission should remain visible. Choose “exclude” when the claim is contradicted, immaterial, unverifiable within the decision window or liable to mislead even with concise qualification.

For the fictional global-availability claim, a defensible record might read: exact report wording preserved; types marked as facts plus inference; announcement opened; rollout passage and location retained; scope comparison completed; original classified as supporting a narrower claim; decision marked “replace”; example brief wording limited to eligible business accounts and named markets; unverified geographies recorded as unknown. The inference that this reduces adoption barriers should receive its own row and might be deferred or excluded unless appropriate evidence supports it.

Never use “qualify” as a way to rescue a claim whose core is unsupported. Qualification narrows or contextualises a supported proposition; replacement changes the proposition; exclusion removes it. A shorter brief with explicit unknowns is generally more useful than a comprehensive brief built from mixed evidential states.

Document the reason, owner and approval condition

Each decision row should state the selected action, concise rationale, required follow-up, accountable content owner, named approver, approval date and final brief version. If approval is conditional, record the condition in observable terms: for example, “Include only after the policy owner confirms the current eligible territories in writing” rather than “Verify later”. The person who gathered evidence and the person accountable for consequential publication may be different.

A recommended decision note could say: “Replace because the cited announcement establishes a staged rollout for a limited eligible population, not completed worldwide availability. Owner: market analyst. Approver: intelligence lead. Condition: retain announcement date and named-market scope in the final bullet.” This is an illustrative record format, not a product-generated approval or assurance certificate.

Every material brief claim needs a named human decision, and consequential legal, financial, policy, employment, safety, procurement or public-communications conclusions require review by the appropriately authorised human specialist. The model may help organise candidate rows, but it cannot be recorded as approver. Named ownership may slow publication, but it prevents unresolved assumptions from disappearing during drafting.

Review the draft in both directions before sign-off

After decisions have been applied, run a backward and forward reconciliation. Backward reconciliation starts with every material sentence in the executive brief and confirms that it maps to an approved ledger row and evidence location. Forward reconciliation starts with every controlling source and decision-changing qualification and confirms that the final wording has not omitted it. This catches new claims introduced during compression as well as qualifiers lost during editing.

Use a practical read-across procedure. First, compare the exact approved wording with the final bullet. Second, confirm that dates, quantities, geography, plan and rollout verbs survived. Third, inspect headings and summaries, because they often broaden carefully qualified body text. Fourth, check charts and tables for truncated units or populations. Fifth, ask the approver to review every deferred or excluded item so that it cannot reappear through a later copy edit.

For example, the body may correctly say “rolling out to eligible business accounts in named markets”, while the executive-summary heading says “Global launch removes adoption barriers”. The heading introduces both the rejected global scope and the unsupported inference. It requires its own ledger mapping and should be rewritten or removed; proximity to a qualified paragraph does not cure it.

No final material wording may be broader than its approved ledger proposition. If executive compression would remove a decision-relevant qualification, retain a shorter qualified statement, move the detail to an adjacent note or omit the claim. Evidential fidelity takes precedence over brevity.

Close the gate without claiming certainty

Close the cited-claim-entailment gate only when every material candidate claim has exact report wording, a type, an opened-source record or explicit absence state, a retained passage or location where available, a scope comparison, an entailment classification and a named human decision. Open questions should remain visible, including inaccessible internal evidence, unresolved contradictions and conditions that may change before the executive decision date.

The closure record should say what was reviewed and which brief version was approved; it should not claim that the report is wholly correct, that the source set is complete or that future changes cannot invalidate the findings. OpenAI’s official warning about possible incorrect or misleading output supports direct verification, but it does not imply an error rate for this report or guarantee that this editorial method removes all risk.

Pass this gate only for the claims and version actually reviewed. Reopen it when a material source changes, the decision date moves, the destination audience changes or an editor alters substantive wording. This creates some maintenance work, but it preserves the distinction between a dated, reviewable decision record and a permanent assertion of truth.

Assemble a safe audit packet before executive circulation

The final audit packet is not the completed report with comments added. It is a controlled set of evidence showing which report was reviewed, which source objects were reopened, how material claims were classified, what wording is proposed for the executive brief, and which named human accepted each inclusion decision. This packet is an editorial recommendation, not an OpenAI-certified audit artefact.

OpenAI’s Deep Research help page, opened for this article on 3 October 2026, says a completed report view includes a table of contents, a sources-used section and activity history. It also describes a workflow in which the proposed plan can be reviewed and modified and progress can be followed or interrupted. These artefacts can help reconstruct the run, but the source does not establish that every historical export retains every intermediate detail. Record an absent plan, edit history or source-setting record as unavailable rather than reconstructing it from memory.

Create a packet index before copying evidence

Begin with an index that assigns a stable identifier to each authorised object. A recommended structure is: packet cover record; preserved report; available request and plan artefacts; source manifest; claim ledger; authorised evidence extracts; contradiction and exception register; executive-brief draft; and approval record. Keep source files separate from analyst annotations so that a reviewer can distinguish original evidence from editorial interpretation.

For example, a fictional packet for “Project Alder” might identify the preserved report as ALD-RPT-01, its source manifest as ALD-SRC-01, the claim ledger as ALD-CLM-01 and the approval record as ALD-APR-01. The ALD prefix and the other codes in this example are fictional local record identifiers, not product-generated identifiers. The practical verification is to open each indexed object from the authorised packet location and confirm that its title, version, owner and access restriction agree with the index.

Include an object only if it is necessary to reproduce an audit finding, understand an unresolved exception or approve the target brief. If an entire report or source document is unnecessary, retain a properly authorised, contextualised extract instead. Too little evidence prevents review, while indiscriminate copying increases exposure, duplication and retention complexity.

Separate immutable evidence from working material

Preserve an original evidence layer and create a distinct working layer. The original layer should contain the received report and any legitimately available run artefacts without silent rewriting. The working layer may contain redactions, annotations, claim atomisation and proposed brief wording. A reviewer should never have to guess whether wording came from the completed report, an opened source or the auditor.

A practical procedure is to record, for every object, an evidence status such as “received original”, “authorised extract”, “auditor annotation” or “proposed brief text”. Then add the custodian, capture date, relevant source or claim identifiers, and any redaction notation. This is an editorial labelling method; it is not a claim that the product supplies chain-of-custody controls.

Consider a fictional internal document whose relevant paragraph supports a statement about a pilot in two territories. The packet need not contain the entire document if the reviewer is authorised to receive only that paragraph. The extract should preserve the document title or approved internal reference, date, section location, the sentence before or after where needed for meaning, access route and redaction reason. The proposed brief must not convert “pilot in two territories” into “global launch”.

If redaction removes text needed to assess scope, exception or contradiction, the extract is not independently reviewable. Either arrange authorised review of the fuller source, narrow the claim to what remains visible, defer it, or exclude it. A neat excerpt is not preferable to a complete evidential context when the omitted material controls meaning.

Apply data minimisation without destroying the decision trail

A useful packet contains the least material needed by its authorised audience, but “least” does not mean stripping away dates, qualifiers or locations that make verification possible. The safe unit of evidence is therefore not always the shortest quotation. It is the smallest authorised segment that allows another reviewer to find the source, understand the relevant proposition and see any controlling limitation.

Use a two-pass minimisation procedure

In the first pass, identify what the approver genuinely needs: the proposed executive wording, claim type, source identity, concise support location, entailment classification, exceptions, owner and decision. In the second pass, remove duplicated narrative, irrelevant personal data, embedded credentials, unrestricted internal content and source material unrelated to the decision. Do not place untrusted source text, private links, credentials, secrets, personal information or unrestricted internal document contents into prompts.

For example, suppose a fictional report cites an internal sales workbook to claim that “renewals rose in every segment”. The brief decision may require only the authorised table range, reporting period, segment definitions, calculation note and reviewer’s finding. It would not ordinarily require unrelated customer rows, contact details, hidden worksheets or workbook credentials. If the segment definitions cannot be disclosed to the approver, the claim may need a narrower wording or a different reviewer with appropriate permission.

Check: have a second authorised person inspect the packet from the recipient’s perspective. They should confirm that every included field has a review purpose, every redaction has a reason, every source extract retains enough context, and no secret or irrelevant personal information remains. This is a recommended editorial control, not a guarantee that all sensitive material will be detected.

When reproducibility requires broader access than the proposed recipient possesses, do not broaden distribution merely to make the packet self-contained. Route the evidence to an authorised specialist, obtain a review statement that identifies exactly what was checked, and give the executive approver only the minimum permissible record. The approver may have less direct access to restricted material; a named specialist can review it under controlled access and record a source-specific finding.

Keep redaction reversible only in the controlled source layer

A distributed redacted excerpt should not contain hidden text, comments, revision history or embedded source material that defeats the redaction. The controlled source layer may retain the authorised original under the organisation’s rules, but the circulation copy should be a separately reviewed object. Do not assume that changing font colour, cropping a screenshot or covering text visually removes the underlying content.

An illustrative record might say: “Extract EX-07; source INT-04; paragraphs 18–20; names and account identifiers removed as irrelevant; territorial limitation retained; full source review completed by authorised owner; executive recipient receives extract only.” This sample wording is a recommendation, not a product output or security certification.

If the redacted object cannot be checked safely in its final circulation format, do not distribute it. Replace it with a textual verification note, provide controlled viewing, or omit the underlying claim. Human review is mandatory where the evidence affects purchasing, employment, legal, regulatory, safety, financial or similarly consequential decisions.

Prevent prompts from becoming an uncontrolled evidence store

Using a model to organise a ledger does not justify supplying the full audit packet. Where model assistance is permitted, provide only approved, minimised fields and treat source text as untrusted data rather than instructions. Exclude credentials, access tokens, private-link parameters, confidential attachments, unrestricted personal data and content whose handling conditions have not been established.

For example, an analyst could supply fictional, sanitised rows containing claim identifiers, public source titles, dates and already approved excerpts, then ask for a consistency check on status labels. The analyst must verify any suggested changes against the source and retain responsibility for the decision. The model’s reformatted table is a draft, not evidence and not approval.

If the task can be completed from ledger metadata, do not provide source contents. If exact wording is necessary, use only the smallest authorised excerpt. If the organisation has not approved the relevant product, workspace or data class for that material, keep it out of the prompt and perform the step manually or in an authorised system.

Distinguish every retention domain in the packet

Retention must be reasoned about object by object. A ChatGPT conversation, a temporary chat, an exported report, a Library copy, a connected-provider document and the organisation’s audit ledger are not one record. Deleting or retaining one does not establish the state of the others.

Record regular and archived chats separately from temporary chats

According to OpenAI’s ChatGPT retention help page, opened on 3 October 2026, when the page showed an update dated two days earlier, regular and archived chats remain saved until the user deletes them or workspace retention removes them. Deleted saved chats are scheduled for permanent deletion within 30 days, subject to exceptions stated on that page.

The same official retention source should be consulted for the conditions governing temporary chats rather than treating them as ordinary saved conversations. For the audit, record the chat type only where authorised evidence establishes it. Do not infer that a report was temporary because it is absent from a sidebar, or regular because someone retained an export.

A practical record has separate fields for “conversation class”, “conversation deletion request date”, “workspace retention condition”, “evidence for classification” and “status last checked”. If the class cannot be established, enter “unknown”. That missing fact matters because the reviewer cannot rely on an assumed conversation lifecycle.

Never use deletion of a regular or temporary chat as proof that the packet’s other copies have been deleted. Treat chat disposition as one line in a copy register. Preserving a chat may assist provenance review, while keeping it longer or sharing it more widely than authorised creates avoidable exposure.

Treat exported reports as independent organisational copies

Once a report is downloaded, copied into a document, attached to a ticket or inserted into a records system, the organisation has created another object under its own handling and retention arrangements. The official ChatGPT retention statement does not establish the lifecycle of that exported object. Nor should an analyst assume that deleting the export changes the source conversation.

Use a copy register with an object identifier, format, custodian, storage location category, authorised audience, purpose, creation date, review date and disposition authority. Avoid recording live private links or credentials in the ledger. A location category such as “restricted research repository” may be sufficient where the precise path would itself be sensitive.

For example, fictional report ALD-RPT-01 might have one preserved read-only export for audit, one redacted excerpt for the approver and one approved claim table incorporated into the final brief. A convenience copy in an analyst’s downloads folder would have no distinct business purpose and should be removed in accordance with organisational rules once the controlled copy is confirmed.

Every retained copy needs a named purpose and custodian. If two copies serve the same purpose and neither is required by an applicable internal record rule, consolidate to the authorised controlled copy. Do not set a retention period from this article; use the organisation’s approved records authority and require human review for disputed or consequential disposition.

Do not collapse Library copies into chat retention

If a report or related file appears in a Library or other saved-file area, record it as a separate copy rather than presuming that the conversation is its sole container. The retention help source governs relevant OpenAI product handling as described there, but an auditor must verify the actual object and its documented status instead of claiming that deleting a chat necessarily removes a Library item.

The procedure is to inventory the conversation, report export, uploaded file and any visible Library copy as distinct rows. For each, record who can access it, what deletion or retention evidence is available, and whether it remains necessary. Where the interface or workspace record does not establish the relationship, mark it unknown and ask an authorised administrator rather than experimenting with live evidence.

If the packet relies on a Library object for reproducibility, preserve its authorised reference and access conditions until the decision record no longer requires it under organisational policy. If it is merely a duplicate, remove it through the approved process. Preserve a reopenable source without multiplying unmanaged copies.

Keep connected-provider content in its original permission domain

Connected-app access can depend on plan, territory, workspace configuration, role, provider permissions and the connected account. A cited app document should be treated as a lead to verify, not as proof that its content was approved or visible to the report’s later recipients. Copying or sharing it requires separate authorisation.

For each connected source, record the provider class, approved internal document identifier, access route, permission owner, reviewer who successfully reopened it and date of review. Record actual source use separately from the mere availability of a connected app. A provider appearing in workspace settings does not show that a completed run consulted it.

A fictional connected document might support a claim about a supplier’s service review. If the executive approver cannot access that document, an authorised owner could review it and provide a minimised evidence statement or approved extract. The analyst should not copy the entire document into the packet simply to bypass the provider’s access boundary.

If no authorised reviewer can reopen connected-provider evidence, classify the underlying claim as unavailable for this audit and replace, defer or exclude it. Do not treat a citation label as a substitute for access. The report’s reference may establish that it pointed somewhere; it does not establish that the proposition has been independently verified.

Give the organisation’s ledger its own retention decision

The claim ledger is a new organisational record. It may contain less source text than the report but more explicit decision information: materiality, contradictions, reviewer names, approval dates and reasons for exclusion. Its retention should therefore follow the organisation’s records classification for the decision it supports, not automatically mirror ChatGPT retention.

Record the ledger owner, authorised editors, read-only audience, version, decision or project reference, review trigger and approved disposition rule. Keep earlier approved versions where the organisation requires a history of consequential decisions; otherwise avoid retaining drafts without purpose. Do not invent legal retention duties or assume that every audit packet is a formal compliance record.

Preserve enough of the ledger to explain the final brief and subsequent changes, but do not preserve every scratch note by default. Where the brief could materially affect people, finances, regulation, safety or contractual commitments, a named records or governance owner should review the classification and access design.

Keep the data controls of a completed ChatGPT report separate from those of a different agent execution product. If a sourcing step specifically uses the OpenAI Agents API, the OpenAI Agents API Security and Data Guide discusses its managed-execution responsibility split, network allowlists, residency, retention and artefact handling. This Agents API-specific guidance does not establish ChatGPT Deep Research training or retention terms.

State model-improvement conditions precisely

Training and model-improvement statements must identify the actual service context. OpenAI’s data-use policy, dated 13 March 2026 and reviewed on 3 October 2026, says content from individual services such as ChatGPT may be used to improve models unless the user opts out. It separately says inputs and outputs from business products and the API are not used for training by default unless the organisation explicitly opts in.

Do not shorten conditional language into a universal promise

“Consumer chats are never used for training” would contradict the assigned source because individual-service use is conditional on the user’s choice. “Business data is never used” would also overstate the source because the default can be changed by an organisation that explicitly opts in, and the applicable product must first be identified. These statements also do not determine the organisation’s own export, app-provider, records or confidentiality obligations.

A practical check has four fields: service or workspace actually used; evidence for that classification; model-improvement setting or organisational opt-in status where authorised and relevant; and reviewer and date. If the audit team cannot establish these facts, record them as unknown and do not place sensitive material into a new prompt merely to continue the review.

For example, a fictional analyst receives a report by email but cannot tell whether it originated in an individual account or an approved business workspace. The correct response is not to infer the data-use condition from the report’s formatting. The analyst asks the authorised owner for workspace evidence and, pending confirmation, limits the packet to approved local handling.

Any claim that model training is excluded must identify the product context and applicable condition. Even when business inputs and outputs are not used for training by default, continue to apply internal data classification, permissions, retention and provider rules. A model-improvement default is not an information-governance programme.

Use a safe-handling checklist for every authorised copy

• Purpose: identify the executive decision and the exact audit purpose of the copy. Verify that each included item contributes to claim review, exception resolution or approval. Remove convenience duplicates.

• Minimum content: retain only necessary report sections, claim rows, source locations and contextual extracts. Keep credentials, secrets, private-link parameters, unrelated personal information and unrestricted internal contents out of prompts and circulation copies.

• Redaction: create a separate circulation object; preserve qualifiers needed for meaning; inspect the final format for hidden text, comments, layers or metadata; and record the reason and reviewer. If redaction prevents entailment review, narrow or withhold the claim.

• Permissions: confirm that the custodian, auditor, specialist reviewer and executive approver have only the access required for their roles. Connected-provider availability does not confer permission, and a report citation does not authorise redistribution.

• Copy register: list the regular or temporary chat, exports, Library objects, provider originals, extracts, ledger and final brief separately. Record custodian, purpose, access class, creation date and disposition authority without embedding live secrets.

• Original versus annotation: mark received evidence, authorised extracts, analyst notes and proposed wording distinctly. Never overwrite the only preserved report with corrections.

• Reopening: require an authorised reviewer to open each material source through its legitimate route. Record unavailable content as unavailable; do not bypass controls or fill gaps from memory.

• Model use: if a model is used to organise approved material, provide only minimised, non-secret data and verify its suggestions against originals. Do not let generated wording silently replace evidence.

• Retention: apply the organisation’s approved rule separately to each copy class. Do not infer that chat deletion disposes of exports, Library objects, provider records or the organisation’s ledger.

• Consequential review: route legal, regulatory, financial, employment, safety, purchasing or similarly material decisions to appropriately authorised humans. The audit packet supports judgement; it does not make the decision.

Circulation may proceed only when every required checklist item has an owner and an acceptable status. An unresolved permission, secret, material redaction defect or unreviewed consequential claim blocks circulation. A non-material formatting issue may be logged for correction without reopening substantive approval, according to the organisation’s procedure.

Record product surface and model claims without guessing

A completed Deep Research report is a ChatGPT product artefact. An API model documentation page describes an API model. The two may share names or technical lineage, but the latter does not identify what powered a particular completed report. Model attribution requires preserved run evidence from the report or an authorised workspace record.

Build a surface appendix from observed evidence

Use fields for product surface, account or workspace class where authorised, run date, source mode, model label if visibly preserved, evidence location, and confidence limited to what the evidence establishes. Record “not preserved” rather than translating a current product page into historical telemetry.

OpenAI’s Deep Research help page reviewed on 3 October 2026 says availability and usage vary with plan and country or territory, while connected-app access can also depend on workspace configuration, role, provider permissions and account conditions. The practical consequence is that one completed report cannot establish a universal plan allowance, connected-app list, region, interface or model choice.

The release notes reviewed on the same date document that on 10 February 2026 users could focus Deep Research on named websites and a larger collection of connected apps as trusted sources. That is chronology, not proof that a given run used those capabilities. Likewise, the release notes’ 19 March 2026 notice concerning removal of legacy Deep Research mode and continuing access to historical conversations does not prove that an old export preserves current metadata or that legacy mode remains selectable.

For example, a fictional report dated 1 March 2026 contains sources from two named domains, but no saved setting indicates how sites were configured. The auditor may record the observed domains. The auditor may not state that the run was restricted to those domains, because OpenAI distinguishes restricting research only to entered sites from prioritising entered sites while permitting full-web search.

Attribute only the surface, setting and model that contemporaneous, authorised evidence visibly establishes. If the evidence shows “ChatGPT Deep Research” but no model, record the product surface and leave the model unknown. This approach favours an incomplete but defensible record over a precise-sounding reconstruction.

Keep API documentation out of report-model attribution

OpenAI’s GPT-5.5 developer page, opened on 3 October 2026, identifies the API model identifier (ID)A value used to distinguish one record, task, source or object from another. Open glossary entry gpt-5.5 and a snapshot gpt-5.5-2026-04-23. That page provides API documentation; it does not supply Deep Research run telemetry and cannot identify the model used for a particular ChatGPT report.

A practical verification sequence is: inspect the preserved report for a visible model label; inspect authorised contemporaneous workspace evidence if policy permits; record the exact label and location; and stop if neither establishes it. Do not use report quality, writing style, completion date, API model availability or a current model catalogue as a proxy.

A fictional report completed after the API snapshot date still cannot be labelled “generated by GPT-5.5” merely because that API model existed. Conversely, absence of a model label does not prove that the report used an older model. Both propositions exceed the available evidence.

If model identity matters to the executive decision but was not preserved, mark it as an unresolved provenance limitation and ask whether the claim can be assessed from its sources without that attribution. If model identity is not material, omit speculation and continue the evidence audit. Never invent a model identifier or fallback path.

Issue a concise executive-brief approval record

The approval record should be short enough to read but specific enough to reconstruct the decision. It is not a certificate of truth. It records the packet reviewed, material exceptions, approved wording, owner and human decision.

Use a one-page decision structure

A recommended record contains: report and packet identifiers; intended brief and audience; audit scope and cut-off date; source and claim rows reviewed; unresolved exceptions; approved decisions by claim; prohibited uses; content owner; approver; approval date; and final brief version. Link internally by stable identifiers rather than duplicating sensitive evidence.

Illustrative fictional approval record: “Packet: ALD-AUD-03. Destination: Project Alder executive brief, version 1.4. Scope: claims C-01 to C-12 reviewed against sources S-01 to S-09 as available on the recorded review dates. Approved: C-01 and C-04 for qualified inclusion; C-07 deferred pending authorised access; C-09 excluded because the available source supports a narrower proposition not useful to the brief. Restriction: no statement of universal availability and no attribution to a named model. Content owner: Research Lead A. Human approver: Strategy Director B. Approval applies only to brief version 1.4.”

This example deliberately records decisions without claiming that any fictional claim is true. In a real packet, the approver should be able to open the corresponding ledger rows, see the precise supported wording and understand why excluded language must not reappear during editing.

Check: compare the final brief against the approval record sentence by sentence. Confirm that each material factual statement has an approved claim identifier, every required qualifier remains present, deferred or excluded claims have not returned through summary prose, and recommendations remain labelled as recommendations rather than source facts.

Approval is version-specific. Any edit that broadens geography, population, time, causality, certainty, availability, price, compliance meaning or recommendation requires renewed review of the affected claim. Purely typographical changes may follow the organisation’s lighter procedure if they do not alter meaning.

Make limitations part of approval, not a footnote after it

The approver should see unresolved source access, missing run evidence, changed pages, contradictory sources and material assumptions before signing. Do not bury them in an appendix that the executive wording silently outruns. Where a limitation is essential to interpretation, place it in the brief wording itself.

Suppose a fictional source says a service is “rolling out to eligible accounts” and the report says “available to all customers”. The approval record should not merely note a minor caveat. It should approve only a narrower statement that retains rollout and eligibility, or exclude the finding if that narrower statement does not serve the decision.

A qualifier belongs in the brief when removing it would make the claim broader than the evidence. A limitation may remain only in the packet when it concerns audit administration rather than the proposition’s meaning. The named human approver resolves borderline cases and remains accountable for consequential use.

Conclude with what the audit can and cannot establish

This post-completion audit reduces the risk that unsupported, over-broad, inaccessible or stale claims pass from a Deep Research report into an executive brief. It does so by preserving available provenance, controlling copies, reopening originals, distinguishing source routes, recording entailment and requiring named human decisions.

It cannot certify that the completed report is correct, complete, balanced or current. OpenAI’s truth guidance, reviewed on 3 October 2026, warns that ChatGPT can produce incorrect or misleading output, including fabricated quotations, studies, citations and references, and recommends direct verification of important information. Direct verification improves the basis for judgement; it does not create an error-free guarantee or an accuracy measurement.

The method also cannot prove that the source universe contained every relevant authority, that an unavailable document would support the claim, that no source changed between capture and review, or that an inference will remain valid as circumstances change. It is not a benchmark, model comparison, legal or compliance certification, security assessment, or proof that Deep Research performs better than another tool.

A polished report, citation marker, sources-used section, trusted-site setting or connected-app reference does not approve a claim. Restricting sites controls a source perimeter; it does not guarantee reliability. Prioritising sites still permits broader web search under the documented option and is not an allowlist. Connected-app availability does not prove use, access to every document or permission to redistribute content.

Release a material finding only when the authorised human approver accepts the exact brief wording, the evidence status, the necessary qualifications and the residual uncertainty. Otherwise replace, defer or exclude it. For consequential decisions, obtain review from the appropriate human domain owner; the packet supports that review but cannot certify the decision itself.

The defensible endpoint is therefore not “the report is verified”. It is narrower: “these identified claims, in this wording and version, were reviewed against these available sources under these recorded limitations, and this named human approved their stated use”.

Useful Links

OpenAI Help: Deep research in ChatGPT

OpenAI Help: Does ChatGPT tell the truth?

OpenAI Help: ChatGPT release notes

OpenAI Help: Chat and file retention in ChatGPT

OpenAI: How your data is used to improve model performance

OpenAI Developers: GPT-5.5 model documentation