25 ChatGPT Prompts for Non-Profit Grant Officers: Restricted-Source, Funder-Requirement-Traceable Drafts
Set the permission and rule boundary before drafting
OpenAI’s Projects guidance, accessed on 3 October 2026, says project instructions apply only within that Project. That makes a Project a possible working context for a source-only drafting instruction, subject to the actual account, plan and workspace settings. It does not make the Project the non-profit’s authoritative grant record or establish permission to upload restricted material.
Before using any prompt below, a named information owner should confirm the approved environment, permitted source packet and intended application purpose. According to OpenAI’s Data Controls guidance and business-data page, accessed on 3 October 2026, personal-account controls and managed-workspace defaults differ. Turning off model improvement affects whether new personal-account conversations are used for training; it is not deletion, retention, sharing or data-residency control. OpenAI separately says listed business offerings and its application programming interface do not use organisational data for training by default. Neither fact settles a non-profit’s contractual, confidentiality, privacy, safeguarding or records-management requirements.
The recommended decision rule is: if authority, environment or permitted use is unknown, stop before supplying the packet. If those matters are confirmed, provide only the minimum authorised material and retain the reviewed artefacts in the organisation’s controlled repository. OpenAI’s prompting guidance, accessed on 3 October 2026, recommends clear, specific context and iterative refinement; that supports the structured instructions below but does not guarantee source fidelity. Consequential conclusions about compliance, eligibility, funding or submission readiness require named human review.
All examples in this library are fictional. Identifiers such as FND-01 (fictional funder guidance), BUD-01 (fictional budget) and PR-01 (fictional prior report) are teaching labels only; replace them with authorised controlled identifiers.
Prompt 1: Authorisation and named application purpose
Purpose
This prompt creates the entry gate for a restricted drafting task. It distinguishes possession of files from permission to use them and a broad intention to “prepare a grant” from a named, bounded application purpose. Use it before uploading substantive content. The recommended procedure is to identify the funder, programme, opportunity or guidance version, internal owner, intended artefact, authorised environment and approving person. The decision rule is: proceed only when each mandatory authority field is confirmed by an accountable human; otherwise return HOLD. This prompt does not determine whether the applicant is eligible or whether any eventual application may be submitted.
Copy-paste prompt
Act as a source-control assistant for an internal non-profit grant draft. First confirm the named application purpose and permission boundary. Use only the authorised sources listed below and cite a source locator for every extracted statement. Stop unless permission or authorisation for both the source packet and the approved environment is explicitly confirmed. Do not use the web or outside knowledge unless [Named human scope owner] expands the scope in writing and identifies the added sources. Do not invent facts, funder rules, deadlines, eligibility findings, budget values, citations, permissions or approval. Label every unknown, uncertain, missing or conflicting item rather than inferring or silently reconciling it. Apply privacy and data minimisation: exclude unnecessary personal, confidential, sensitive or restricted material, including credentials, bank details, signatures and identifiable beneficiary histories. Require review and explicit approval by [Named application owner] before any consequential use. Do not submit, email, sign, publish or transmit an application, and do not claim compliance, eligibility, funding likelihood or submission readiness.
Create an authorisation gate containing: named funder and programme; opportunity title or identifier; supplied version or amendment date; precise internal purpose; intended draft artefacts; packet owner; source-use permission confirmer; approved account or workspace confirmer; permitted users; prohibited uses; retention repository; and named reviewers. For each field, show Confirmed, Unknown or Conflict. Finish with Proceed to minimum-data screen only if every mandatory authority field is confirmed; otherwise show Hold and list the human decisions required.
Required inputs
Supply metadata rather than restricted document contents: the fictional opportunity name, packet owner, purpose, environment approval record and named reviewers. Example: “Fictional Northbridge Community Fund, Youth Mentoring Renewal 2027, guidance version dated 4 June; purpose: prepare an internal requirement-traceable draft; packet owner: Priya Shah, Grants Manager; environment confirmed by Morgan Lee, Information Governance Lead.” Also identify the controlled repository where authorised staff will retain reviewed outputs. Do not paste passwords, access tokens, donor contact lists, signatures or beneficiary records. If environment approval is represented only by an assumption such as “we have always used this account”, record it as Unknown.
Expected output
The result should be a draft authorisation cover sheet, not an approval certificate. A useful example is: “Purpose—internal narrative and requirement-register drafting: Confirmed; source-use authority—written confirmation not supplied: Unknown; environment—organisation-approved workspace named by Morgan Lee: Confirmed; state: Hold; human decision required from Priya Shah.” It should distinguish the authority to inspect metadata, the authority to process document contents and the separate authority to release an application. No field may imply that the model granted permission. If all fields are genuinely supplied, the closing state may be “Proceed to minimum-data screen”, never “approved to submit”.
Verification checkpoint
The named application owner should compare the cover sheet with the actual internal instruction and source permissions, while the environment confirmer checks the real account or workspace configuration. Verify that the opportunity identifier and version are copied exactly, that no substantive source was introduced during this gate, and that release authority remains separate. Reject the artefact if permission is vague, inherited from an unrelated project or attributed to the model. Human reviewers must record corrections outside the prompt and preserve the reviewed version in the controlled repository. Passing this checkpoint authorises only the next screening step, not drafting, eligibility interpretation or submission.
Evidence checkpoints
Documented point: Projects keep related chats, files and instructions together, and project instructions apply only within that Project. Availability, sharing and workspace configuration are account-specific; this does not make a Project the official grant record. [Projects in ChatGPT]
Documented point: The reviewed Projects page documents plan-based file-count limits and says only 10 files can be uploaded at one time. This is not a reason to upload a complete archive or proof that a particular account has the feature. [Projects in ChatGPT]
Documented point: The File Uploads frequently asked questions (FAQ)A collection of recurring questions and concise answers about a subject. Open glossary entry documents 512 megabytes (MB)A file-size unit based on bytes; under the international decimal convention one megabyte equals one million bytes, while some software uses different binary conventions. Open glossary entry per file and two million tokens for text/documents, with lower/qualified spreadsheet and image limits. A ceiling does not prove reliable extraction, especially for scans, tables and images. [File Uploads FAQ]
Documented point: The FAQ says ChatGPT Enterprise supports Portable Document Format (PDF)A fixed-layout document format used to preserve page appearance across systems. Open glossary entry Visual Retrieval while other plans and document files use text-based retrieval. Readers must compare critical tables, scans, charts and image-only content with the original. [File Uploads FAQ]
Documented point: Turning off Improve the model for everyone means new personal-account conversations are not used for training, but does not delete or hide existing/saved chats. This is not a deletion, sharing, retention or data-residency control. [Data controls in ChatGPT]
Documented point: Temporary Chats may be retained for up to 30 days for safety and are not a substitute for a non-profit’s permission, retention or funder-confidentiality review. Saving converts a Temporary Chat to a regular chat. [Data controls in ChatGPT]
Documented point: OpenAI’s business page says listed business/application programming interface (API)A documented way for software systems to exchange requests and results. Open glossary entry data are not used for training by default. The statement does not establish the reader’s product, authorisation, contract, confidentiality handling or compliance. [OpenAI business data privacy, security and compliance]
Fictional example roles: Maya Chen is the grant lead; Amina Yusuf is the Programme Lead; Tom Reed is the Finance Lead; Priya Shah is the Grants Manager; Morgan Lee is the Information Governance Lead; Elise Ward is the Director. A separate named privacy reviewer handles any privacy checks. These invented people do not represent a real applicant, and nothing here records an approval. Each prompt must be adapted to real, authorised people and documents before use.
Prompt 2: Minimum-data screen for restricted materials
Purpose
This prompt reduces the packet before upload or transcription. It separates information needed to answer supplied funder questions from information merely present in organisational records. The practical procedure is to review a document-level inventory, classify each data category and select the least-sensitive substitute that still supports the drafting purpose. OpenAI’s File Uploads Frequently Asked Questions, accessed on 3 October 2026, lists technical ceilings such as 512 megabytes per file and two million tokens for text documents, but ceilings are not permission, extraction guarantees or reasons to upload an archive. The decision rule is to exclude unnecessary restricted content; where necessity or authority is disputed, place the item on Hold for the named privacy or information-governance reviewer.
Copy-paste prompt
Screen the proposed grant source packet before any substantive drafting. Stop unless permission or authorisation for the source packet and approved environment is confirmed. Use only the listed authorised source inventory and cite source locators such as inventory row, document identifier (ID)A value used to distinguish one record, task, source or object from another. Open glossary entry, page, section, sheet or cell range. Do not use the web or outside knowledge unless [Named human scope owner] explicitly expands scope and lists the additional authorised sources. Never invent facts, rules, deadlines, budget values, citations, eligibility decisions, permissions or approval. Label unknown, uncertain, missing and conflicting information; do not infer necessity or consent. Apply privacy and data minimisation by excluding unnecessary personal, confidential, sensitive or restricted material. Require named review by [Privacy or information-governance owner] and approval by [Application owner] before consequential use. Do not submit, email, sign, publish or transmit anything.
For each inventory item, report: data category; purpose connection; minimum necessary fields; proposed treatment of Include as supplied, Use aggregate, Redact under organisational process, Substitute controlled extract, Exclude or Human decision required; authority evidence; and residual question. Flag credentials, bank details, signatures, direct identifiers, individual health or safeguarding details, confidential third-party correspondence and full case histories. Do not perform or certify legal anonymisation. End with a reduced-packet proposal and Hold if necessity, permission or environment approval remains unresolved.
Required inputs
Provide a document inventory and short descriptions, not the sensitive values under review. Include the drafting purpose from Prompt 1, supplied funder questions, organisational data classifications, confirmed permissions and the named reviewer. A fictional example might list “PN-04 programme note: participant names, health-adjacent case narrative and aggregate attendance”; “BUD-02 controlled budget: staff roles, costs and supplier bank details”; and “REP-01 prior report: aggregate reach”. If the funder question asks only for delivery approach and aggregate reach, direct identifiers and banking fields have no demonstrated purpose connection. State whether a controlled aggregate or redacted extract already exists rather than asking the model to manufacture one.
Expected output
Expect a draft data-minimisation schedule and reduced-packet recommendation. For the fictional example, it might say: “PN-04 aggregate attendance—Substitute controlled extract; participant names and health narrative—Exclude because no purpose connection is supplied; BUD-02 authorised cost rows—Substitute controlled extract; bank details—Exclude; REP-01 aggregate reach—Include, subject to date and locator verification.” Where a case story may be requested but permission is unclear, the correct state is “Human decision required”, not an invented consent or synthetic rewrite presented as evidence. The artefact must remain a review draft and must not certify that redaction, de-identification or use is legally sufficient.
Verification checkpoint
The privacy or information-governance owner should inspect the proposed inclusions against the actual classification and permission records. The grant officer should confirm that every retained field supports a supplied requirement and that aggregate substitutes preserve the necessary period, unit and meaning. Test the exclusion list for hidden content in appendices, comments, spreadsheet tabs, file names and scanned pages; this is a recommended manual check, not a product guarantee. If a critical table or image is later uploaded, compare it with the original because the OpenAI file guidance states that document retrieval can be text-based depending on plan and file type. Continue only with the approved reduced packet.
A grant requirement-to-evidence map should show where each funder condition appears in the draft and who checked the source. A parallel procurement workflow appears in the human-led request-for-proposal evaluation prompts; those prompts trace requirements to evidence while keeping the approval decision with people, not the model.
Prompt 3: Controlled source manifest
Purpose
This prompt establishes which documents may support the draft and how each claim will point back to them. A manifest differs from a file list: it records identity, version, authority, sensitivity, permitted use and stable locators. “Uploaded” means only that a file entered the working context; it does not mean current, controlling or approved. The procedure is to assign each authorised item a controlled ID, preserve its title and version, identify an accountable owner, define page, section, sheet or cell locators, and note extraction risks. The decision rule is that an unmanifested or version-ambiguous document cannot support a material claim until a named human resolves it.
Copy-paste prompt
Create a controlled source manifest for an internal funder-requirement-traceable draft. Stop unless permission or authorisation for the source packet and the approved environment is confirmed. Use only the listed authorised sources and cite precise source locators. Do not use web search or outside knowledge unless [Named human scope owner] explicitly expands the scope and names each added source. Do not invent facts, rules, deadlines, budget values, citations, eligibility findings, document versions, permissions or approval. Mark all unknown, uncertain, missing or conflicting information instead of inferring it. Apply privacy and data minimisation by excluding unnecessary personal, confidential, sensitive or restricted content; use metadata and approved extracts where possible. Require review by [Named record owner] and approval by [Named application owner] before consequential use. Do not submit, email, sign, publish or transmit an application.
For every source, record: controlled ID; exact title; category; filename if authorised; issuer or owner; date; version or amendment status; sensitivity; permission evidence; permitted use; authority level without deciding precedence; stable locator scheme; extraction method; known scan, image, table or formula risk; and status of Active, Superseded, Reference only, Unknown or Hold. Do not treat presence in a Project as record authority. Produce duplicate, missing-version and unreadable-content exceptions separately.
Required inputs
Provide the reduced packet approved after Prompt 2, its metadata, any checksum or controlled repository reference used by the organisation, and the desired locator scheme. A fictional packet could contain “FND-01 Fictional Northbridge Guidance, version 2, sections 1–9”; “AMD-01 written amendment dated 18 June”; “BUD-01 approved internal budget workbook, sheets Summary and Delivery”; “PN-01 programme planning note”; and “REP-01 prior annual report”. Include who supplied each item and whether its use is restricted to internal drafting. If two files share a title but have different dates, preserve both and mark the version relationship Unknown rather than selecting the newer-looking file automatically.
Expected output
The expected artefact is a draft manifest plus an exceptions register. A sample row might read: “FND-01 | guidance | version 2 | issuer stated as fictional funder | permitted for internal drafting | locator: section/page/paragraph | Active pending owner verification.” Another might read: “BUD-01 | workbook | date supplied, approval status absent | locator: sheet/cell | formula visibility requires finance check | Hold.” The exceptions list should expose a missing amendment, duplicate filename or image-only appendix. A visible overall state should say “Hold—manifest owner must resolve BUD-01 approval status” or “Ready for precedence review”, never “sources validated” without human confirmation.
Verification checkpoint
The record owner should compare every manifest row with the controlled originals, not merely the extracted text. Confirm titles, dates, versions, page counts, sheet names and locator usability; open a sample of cited locations to ensure another reviewer can find the same passage. For spreadsheets, inspect formulas and hidden or filtered areas under organisational procedure. For scans, charts and image-only pages, perform manual comparison because OpenAI’s File Uploads guidance, accessed on 3 October 2026, distinguishes Portable Document Format visual retrieval on ChatGPT Enterprise from text-based retrieval for other plans and document files. Record discrepancies as exceptions. Only the human source owner may mark an item Active or Superseded.
Prompt 4: Source precedence and permitted-use note
Purpose
This prompt prevents a persuasive prior report or informal programme note from silently overriding supplied funder instructions. A source manifest answers “what is present”; a precedence note answers “which supplied source governs which question, if authorised humans have established that hierarchy”. The procedure is to map source categories to decisions, record written amendments, separate external requirements from internal evidence and preserve conflicts. The trade-off is between convenient harmonisation and traceability: retaining a visible conflict slows drafting but avoids disguising an unresolved rule. The decision rule is never to create a hierarchy from document tone, date or filename alone; use only a hierarchy confirmed in the authorised packet or by the named owner.
Copy-paste prompt
Draft a source-precedence and permitted-use note for this restricted grant packet. Stop unless permission or authorisation for the packet and approved environment is confirmed. Use only listed authorised sources and cite exact source locators for every rule or hierarchy statement. Do not use the web or outside knowledge unless [Named human scope owner] explicitly expands scope and lists authorised additions. Never invent facts, funder rules, deadlines, budget values, citations, eligibility conclusions, precedence, permissions or approval. Label unknown, uncertain, missing and conflicting information rather than inferring or merging it. Apply privacy and data minimisation: omit unnecessary personal, confidential, sensitive or restricted material. Require review by [Named grant owner], with finance review for budget precedence, before consequential use. Do not submit, email, sign, publish or transmit anything.
Separate: current funder guidance; mandatory questions; budget template; written amendments; internal approved budget; programme notes; and prior reports. For each decision type, state the controlling source only where supplied authority confirms it, permitted evidential uses, prohibited uses and unresolved conflicts. Treat prior reports as historical evidence, not current funder rules or guaranteed future outcomes. Treat programme notes as planning evidence, not approval. Return Hold wherever precedence or permitted use is not documented.
Required inputs
Supply the reviewed manifest, any written hierarchy instruction, amendment notice, internal approval record and the decision types to be governed. In a fictional example, FND-01 says equipment is ineligible at section 6.2, AMD-01 modifies only the reporting timetable, BUD-01 includes “tablet kits”, PN-01 describes their programme rationale and REP-01 mentions earlier equipment use. Do not instruct the model that the budget or narrative must be correct, because that wording invites unsupported reconciliation. State whether the organisation has confirmed that written amendments override the affected guidance provisions. If that confirmation is absent, request a human decision rather than using recency as an automatic rule.
Expected output
Expect a draft precedence table and permitted-use note. For the fictional case, an appropriate entry is: “Equipment cost treatment—FND-01 §6.2 states the supplied rule; AMD-01 has no located equipment change; BUD-01 contains tablet kits; PN-01 provides rationale only; conflict: Human decision required from grant owner and finance.” It must not relabel the cost, remove it, pronounce it eligible or claim the amendment has been exhaustively checked beyond supplied material. Another entry may permit REP-01 to support a historical statement only when its period and locator remain visible. The overall state should be Hold until every conflict affecting the draft has an accountable owner.
Verification checkpoint
The grant owner should compare each precedence statement with the exact authorised provision and confirm that every amendment is represented. Finance should review rules mapped to cost treatment; programme staff should review the permitted use of planning notes and prior reports. Verify that no source was promoted because it appeared polished, recent or convenient, and that a historical outcome has not become a future target. Search the note for unsupported words such as “therefore eligible”, “approved” or “supersedes” and replace them with source-grounded wording or a decision flag. Approval of this note governs internal drafting only and cannot establish legal compliance, funder acceptance or submission readiness.
When a grant officer needs a draft that stays within approved sources and can be traced to funder requirements, a separate research stage helps, and this set of Prompts for Source-Controlled Deep Research covers plan review and citation checks that can be applied before any language moves into a proposal narrative.
Prompt 5: Funder requirement register
Purpose
This prompt decomposes supplied funder material into traceable drafting obligations without interpreting absent portal rules or deciding eligibility. A requirement register differs from a narrative outline: it preserves the funder’s supplied wording, locator, answer form, evidence need, owner and status before prose is written. The practical procedure is to inspect each controlling source section by section, create one row per atomic requirement and cross-reference related rules without merging them. The trade-off is granularity: overly broad rows hide conditions, while fragmenting every sentence obscures context. The decision rule is to split a provision whenever its format, owner, evidence, condition or verification route differs.
Copy-paste prompt
Build a draft funder requirement register from this authorised packet. Stop unless permission or authorisation for the source packet and approved environment is confirmed. Use only the listed authorised sources and cite an exact source locator for every requirement. Do not use the web, an unsupplied portal or outside knowledge unless [Named human scope owner] expands scope in writing and names the new authorised sources. Never invent facts, rules, deadlines, eligibility decisions, budget values, citations, permissions or approval. Label unknown, uncertain, missing and conflicting information instead of inferring it. Apply privacy and data minimisation by excluding unnecessary personal, confidential, sensitive or restricted material. Require named review by [Grant owner] and relevant programme or finance owners before consequential use. Do not submit, email, sign, publish or transmit an application.
Create one row per atomic supplied requirement with: requirement ID; exact or faithfully delimited wording; source ID and locator; category; applicability condition; required response or attachment; supplied limit; required evidence; prohibited content if stated; dependency; internal owner; status of Located, Ambiguous, Conflict, Missing input or Not verified; and reviewer decision. Do not decide eligibility or compliance. If a portal, amendment or referenced policy is absent, state Not verified and place affected rows on Hold.
Required inputs
Provide the approved precedence note and controlling documents with stable locators. Include the named internal owners, but do not pre-populate their decisions. A fictional example could supply a question asking for programme need, a separate instruction requiring a delivery timetable, an equipment restriction at FND-01 §6.2 and an attachment reference whose template is absent. Where the same provision contains “describe delivery partners” and “attach letters of commitment”, treat these as linked but distinct requirements because they need different evidence and checks. If a deadline is not in the packet, enter “deadline not supplied”; do not insert a familiar grant-cycle date.
Expected output
The output should be a draft requirement register, a missing-input list and a visible gate state. Example: “REQ-014 | attach delivery timetable | FND-01 §4.3 | attachment | format not supplied | evidence: authorised timetable | owner: Programme Lead | Missing input.” A second row might state: “REQ-021 | equipment restriction | FND-01 §6.2 | budget rule | conflict with BUD-01 Delivery!B18 | owner: Finance Lead | Conflict—human decision required.” Requirements referenced but not supplied should remain Not verified. The model must not state that the register is complete against a live website or portal. Completion means only that the authorised packet has been processed for human review.
Verification checkpoint
The grant owner should perform a line-by-line comparison against every controlling source and amendment, marking where each paragraph was represented or intentionally excluded. Sample each register row by opening its locator and checking wording, conditions and exceptions. Programme and finance owners should verify only their assigned domains; they should not be represented as approving other fields. Count mandatory questions and attachments manually against the originals, but do not treat equal counts as proof of completeness. If a referenced template, portal field or amendment is absent, retain Not verified and Hold. Neither the model nor the register determines compliance, eligibility, funding or whether an application can be submitted.
Prompt 6: Format, limit and attachment table
Purpose
This prompt isolates mechanical constraints from substantive requirements. A requirement register may say what must be answered; this table records how the authorised packet says each answer or attachment must be presented. The procedure is to capture supplied word or character limits, file types, naming rules, templates, page constraints, date formats and attachment conditions, preserving the unit exactly. This matters because “500 words” and “500 characters” are not interchangeable, and a referenced but absent portal field cannot be inspected. The decision rule is to mark any unsupplied format as Not verified and block final assembly where the missing constraint could alter content or packaging.
Copy-paste prompt
Create a draft format, limit and attachment table for this internal grant package. Stop unless permission or authorisation for the source packet and approved environment is confirmed. Use only the listed authorised sources and cite precise locators for every constraint. Do not use the web, outside knowledge or an unsupplied portal unless [Named human scope owner] explicitly expands scope and identifies authorised sources. Never invent facts, funder rules, deadlines, budget values, limits, filenames, citations, eligibility conclusions, permissions or approval. Label unknown, uncertain, missing and conflicting information rather than inferring it. Apply privacy and data minimisation by excluding unnecessary personal, confidential, sensitive or restricted material. Require named review by [Grant owner], [Finance reviewer] for budget templates and [Authorised submitter] for packaging constraints before consequential use. Do not submit, email, sign, publish or transmit anything.
For each question and attachment, record: linked requirement ID; supplied label; response medium; word, character, page, row or file limit with its exact unit; inclusion or exclusion rule for headings if supplied; mandated template; file type; naming convention; date format; signature requirement; conditional trigger; source locator; status; and human owner. Never create a signature or assume electronic acceptance. Return Hold for absent templates, contradictory limits or unverified portal-only constraints.
Required inputs
Supply the reviewed requirement register, authorised forms, attachment instructions, budget template and any captured portal specification that the organisation is permitted to use. A fictional example may state: “Narrative question N2: 1,500 characters at FND-01 §3.4”; “delivery timetable required, template referenced but not supplied”; and “budget workbook BUD-T01 must be used”. If one document says 1,500 characters and another authorised amendment says 300 words, provide both locators and the confirmed precedence instruction, if any. Do not convert one unit into another or estimate how much prose will fit. Exclude actual signatures, credentials and portal access details.
Expected output
Expect a draft constraint table, attachment inventory and packaging exception list. A useful example is: “REQ-008/N2 | narrative field | 1,500 characters | treatment of spaces not supplied | FND-01 §3.4 | Ambiguous—human decision required.” Another is: “REQ-014 | delivery timetable | required attachment | referenced template absent | Hold.” For a budget workbook, list only supplied sheet, format and naming requirements; do not claim that completing the template makes costs eligible. Include a status banner such as “Hold—missing timetable template and portal character-count convention”. The artefact is a review aid, not a portal check or evidence that files will upload successfully.
Verification checkpoint
The grant owner should compare every limit with the original wording and verify the unit, scope and exceptions. Finance should open the controlled budget template and confirm sheet names and protected formula expectations without altering the source. The authorised submitter should later inspect the actual permitted portal or submission instructions, but must not provide credentials to the prompt. Where constraints conflict, apply only a human-confirmed precedence rule; otherwise retain Hold. OpenAI’s Projects and File Uploads guidance, accessed on 3 October 2026, documents plan-dependent file counts and technical upload limits, but those product limits do not establish funder attachment rules or extraction success. Human review is mandatory before any packaging or consequential decision.
Prompt 7: Ambiguity and contradiction log
Purpose
Create a review artefact that distinguishes an ambiguity, where supplied wording permits more than one reasonable reading, from a contradiction, where two authorised sources assert incompatible facts or instructions. The practical procedure is to compare the funder rules, written amendments, mandatory questions, controlled budget, programme notes and prior reports statement by statement; preserve each source’s wording, version and locator; and route rather than resolve discrepancies. Use this prompt when unresolved meaning could alter eligibility, scope, cost treatment, evidence or timing. The decision rule is: record an ambiguity if interpretation is required; record a contradiction if both statements cannot simultaneously be true; record a missing input if no supplied source addresses the issue. None establishes compliance or submission readiness.
Copy-paste prompt
First confirm that the source packet is authorised for this task and that the named organisation-approved environment is permitted for it. Stop unless both permission or authorisation for the packet and the approved environment are confirmed by [Named grant lead]. Apply privacy and data minimisation: exclude unnecessary personal, confidential, sensitive or restricted material, including beneficiary details, credentials, signatures and bank information. Use only the authorised sources listed below and cite a precise source locator for every extracted statement. Do not use the web or outside knowledge unless [Named grant lead] explicitly expands the scope in writing. Do not invent facts, funder rules, interpretations, deadlines, budget values, citations, calculations or approval. Label unknown, uncertain, missing and conflicting information; do not infer or silently reconcile it. Compare sources and produce an internal ambiguity and contradiction log. For each item, provide an identifier, issue type, exact propositions in tension, source IDs and locators, affected draft section, practical consequence if unresolved, named decision owner, question requiring answer and status. Distinguish source conflict from ordinary difference in reporting period or terminology. Preserve both values where dates, populations or units differ. Recommend no substantive choice. Require named human review and approval by [Named grant lead] and the relevant programme or finance owner before consequential use. Do not submit, email, sign, publish or represent this output as approved, compliant, eligible or ready for submission.
Required inputs
Supply the approved-environment confirmation, authority record, source manifest, source-precedence note and only the minimum necessary excerpts from the authorised packet. Include stable locators such as “Funder guidance v2, section 6.2, page 11” or “Budget B-04, worksheet Delivery, cell F18”; do not rely on “the uploaded file”. Identify Maya Chen as the fictional grant lead and name the actual internal owners when adapting the example. A fictional case might contain a handbook excluding equipment, a budget line labelled “tablet kits” and a programme note describing those kits as necessary. The conflict must remain visible; the model must not rename the line as training materials or decide that it is eligible.
Expected output
Expect an internal draft register headed “Hold — unresolved source issues”, not a corrected application. An illustrative entry could state: “AC-07-03; contradiction; handbook says equipment is ineligible at section 6.2, while Budget B-04 includes an unverified amount in pounds sterling for tablet kits at Delivery!F18; effect: cost classification and narrative may change; owner: Finance Lead; decision requested: retain, remove or seek authorised clarification; status: Human decision required.” A separate ambiguity might record that “local residents” lacks a supplied geographic definition. The output should preserve exact periods, currencies and source hierarchy, identify duplicate issues, and avoid treating an older report as authority over current funder instructions.
Verification checkpoint
[Named grant lead] should open every cited original, verify wording and locator, then ask the named programme or finance owner to classify each issue. Check that no row contains a model-created resolution, blended number or implied permission. For scans, image-only rules and critical tables, compare the output directly with the originals: OpenAI’s File Uploads FAQ, accessed on 3 October 2026, distinguishes Portable Document Format (PDF) visual retrieval in ChatGPT Enterprise from text-based retrieval for other plans and document files, so upload is not proof of complete extraction. The human decision rule is: any unresolved issue affecting a rule, amount, deadline, target or required evidence keeps the relevant draft section on Hold. Neither the model nor this prompt determines compliance, eligibility, funding or readiness to submit.
Prompt 8: Requirement-owner assignment
Purpose
Turn the existing funder requirement register into an accountability map without fabricating organisational authority. This differs from merely naming the person who will write prose: the requirement owner validates the underlying response, while a reviewer tests a specialist aspect and an authorised officer separately controls release. The procedure is to classify each supplied requirement by subject, match it only to a documented role, expose unassigned or disputed ownership and state the evidence that the owner must review. Use named people where authority is supplied; otherwise retain a role placeholder. The decision rule is that one accountable owner should be requested for each requirement, but specialist review may be shared. Missing authority produces Human decision required, never an assumed appointment.
Copy-paste prompt
Confirm first that this restricted source packet is authorised for the stated grant-drafting task and that its use in the named organisation-approved environment is permitted. Stop unless permission or authorisation for both the packet and environment is confirmed by [Named grant lead]. Apply privacy and data minimisation: do not include unnecessary personal, confidential, sensitive or restricted information, and omit private contact details, credentials, signatures and beneficiary records. Use only the listed authorised sources and cite source locators for every requirement and every supplied authority statement. Do not use the web or outside knowledge unless [Named grant lead] explicitly expands scope. Do not invent facts, rules, deadlines, budget values, citations, job authority, delegation, review completion or approval. Label unknown, uncertain, missing or conflicting information rather than infer it. For each requirement, propose an owner only where the packet documents that person’s remit; otherwise write ‘Owner not confirmed’. Distinguish accountable requirement owner, contributor, specialist reviewer and authorised submitter. Show the requirement ID, source wording and locator, topic, proposed named owner, authority evidence and locator, contributor, required review, due point if supplied, dependency and status. Flag incompatible assignments or separation-of-duty concerns for organisational decision without making a compliance judgement. Require named review and approval by [Named grant lead] and each proposed owner before consequential use. Do not submit, email, sign, publish or state that any assignment, application, eligibility or approval is final.
Required inputs
Provide the authorised requirement register, controlled staff-role note, internal approval route, source manifest and any supplied timetable. Minimise it to role and authority information needed for assignment; personal telephone numbers, signatures, human-resources records and private correspondence are unnecessary. In a fictional example, the packet states that Programme Lead Amina Yusuf validates service design, Finance Lead Tom Reed validates the budget, and only Director Elise Ward may authorise submission. A safeguarding narrative can therefore have Amina as response owner and a separately documented safeguarding reviewer, while Elise remains the release authority. If no source names a safeguarding reviewer, the output must not assign one by guesswork.
Expected output
Expect a draft “Requirement ownership and review map” with an overall Hold until assignments are accepted. An illustrative row could read: “R-18; explain delivery model; guidance v2, question 6; proposed owner Amina Yusuf; authority source Governance Note G-02, paragraph 8; contributor: monitoring officer; reviewer: safeguarding role not confirmed; status: Human decision required.” Another could show Finance Lead Tom Reed owning validation of a supplied cost table while the grant lead, Maya Chen, coordinates drafting. The artefact should also contain an unassigned-requirements view, conflicting-authority view and owner acceptance field left blank. It must not pre-populate approvals, transform silence into delegation or describe the authorised submitter as having approved the draft.
Verification checkpoint
Maya should compare every assignment with the organisation’s supplied authority record, then obtain explicit acceptance from each named person through the organisation’s normal process. The programme owner checks facts and proposed targets; finance checks figures and rules; privacy or information-governance reviewers check handling; specialist reviewers examine their domains; the authorised officer alone decides release. The trade-off is between clear accountability and false precision: use a role placeholder rather than attaching consequential responsibility to an unsupported name. If ownership, authority or required specialist review is disputed, mark the requirement Hold and prevent downstream drafting from presenting it as settled. This editorial workflow is an example, not a product guarantee. Neither ChatGPT nor the prompt can appoint staff, determine compliance or eligibility, approve funding, or establish submission readiness.
Community input introduces a different evidence type into a grant proposal. The public consultation response prompt set uses an evidence ledger and human sign-off before themes enter a summary; a grant team still needs to verify permission and relevance to its own funder.
Prompt 9: Programme facts extraction
Purpose
Extract source-located programme facts without converting plans, opinions or old statements into current truth. A fact register differs from narrative drafting: it records what a supplied source says, its period and evidential status before persuasive language is attempted. The procedure is to identify entities, activities, delivery locations, participant definitions, dates, staffing, partnerships, quantities and methods; copy or closely paraphrase only what is necessary; classify each item as current fact, historic fact, proposal, estimate or unverified assertion; and retain its locator. The decision rule is that a material statement without a locator does not enter the draft as fact. Conflicts go to the existing contradiction log rather than being averaged or silently harmonised.
Copy-paste prompt
Before processing content, confirm that the listed source packet is authorised for this purpose and that the named organisation-approved environment is permitted. Stop unless [Named grant lead] confirms permission or authorisation for both the packet and environment. Apply privacy and data minimisation: exclude unnecessary personal, confidential, sensitive or restricted content, particularly identifiable beneficiary narratives, health details, credentials, signatures and private correspondence. Use only the authorised sources listed below and cite a stable source locator for each extracted fact. Do not use the web or outside knowledge unless [Named grant lead] explicitly expands scope. Do not invent facts, funder rules, definitions, deadlines, budget values, citations, calculations or approval. Label unknown, uncertain, missing and conflicting information rather than infer it. Extract programme statements into a fact register. For every entry, provide fact ID, neutral statement, classification as current documented fact, historic fact, proposed activity, forecast, estimate or unsupported assertion, source ID, exact locator, applicable date or period, geography, population definition, unit, limitations, related requirement and verification owner. Preserve qualifications such as ‘planned’, ‘up to’ and ‘subject to’. Do not turn intentions into delivery history or individual examples into population evidence. Require named human review and approval by [Named grant lead] and Programme Lead Amina Yusuf before any consequential use. Do not submit, email, sign, publish or claim compliance, eligibility, approval, funding or submission readiness.
Required inputs
Provide the authorised source manifest, relevant programme-note excerpts, prior reports, current plan, requirement IDs and contradiction-log references. Include document dates and page, paragraph, table or cell locators. Remove case histories and identifiers when aggregate information suffices. A fictional packet might say in Programme Note P-03 that a community food programme proposes weekly distribution at two venues, while Prior Report PR-01 records activity at one venue in an earlier period. Those are two time-bounded facts, not evidence that two venues currently operate. If a note says “families in the district” but supplies no district boundary or family definition, preserve both as unknowns requiring programme-owner clarification.
Expected output
Expect a reviewable “Programme fact register — Draft” plus a short quarantine table for statements that cannot yet support narrative claims. An illustrative entry is: “PF-09-14; proposed weekly distribution at two venues; classification: proposal; P-03, page 4, paragraph 2; period: next grant year as described, exact dates missing; geography: district not defined; owner: Amina Yusuf; status: Human decision required.” A historic row would retain its old reporting period and could not be relabelled current. The register should expose synonymous terms needing controlled definitions, cross-reference conflicting values, and mark every uncited or contextless assertion Hold rather than improving it into polished prose.
Verification checkpoint
Amina should sample every category and verify all material entries against the originals, then check all dates, units, geography and population definitions. Maya should test the reverse direction: select each proposed narrative fact and confirm that a register row and locator exist. Compare tables, charts and scanned material visually with the original rather than trusting extracted text. OpenAI’s prompting guidance, accessed on 3 October 2026, recommends clear, specific instructions, sufficient context and iterative refinement; that supports this structured review method but does not guarantee factual fidelity. The trade-off is completeness versus minimisation: include enough context to prevent misreading, but not unnecessary restricted data. Any unsupported material fact remains quarantined. Human reviewers, not the model, determine its accuracy and suitability; this artefact does not determine compliance, eligibility, funding or submission readiness.
Prompt 10: Prior-report results versus future targets
Purpose
Prevent past reporting from being recast as a promised future result. Prior results are time-bounded statements about an earlier period; future targets are proposed commitments requiring current programme, budget and funder-rule support. The procedure is to extract both into separate columns, preserve metric definitions and denominators, identify whether the future figure is copied, calculated or newly proposed, and compare it with current capacity and budget without inventing a reconciliation. Use this prompt before drafting an outcomes section. The decision rule is that no past value becomes a target by default, and no forecast becomes a guaranteed outcome. Where source periods, populations or measurement methods differ, comparison is “not established” pending named review.
Copy-paste prompt
Confirm first that the restricted packet is authorised for this comparison and that the named organisation-approved environment is permitted. Stop unless [Named grant lead] confirms permission or authorisation for the packet and environment. Apply privacy and data minimisation: exclude unnecessary personal, confidential, sensitive or restricted material, including identifiable case data, health details, credentials and private monitoring records. Use only the listed authorised sources and cite exact source locators. Do not use web research or outside knowledge unless [Named grant lead] explicitly expands scope. Do not invent facts, funder rules, metric definitions, deadlines, budget values, targets, calculations, citations or approval. Label unknown, uncertain, missing and conflicting information instead of inferring it. Build a comparison separating prior reported result, prior commitment, current baseline, proposed future activity, proposed target and unsupported aspiration. For each metric, preserve wording, period, numerator, denominator, population, geography, method, unit, source and locator. State whether figures are directly sourced or arithmetically derived; show any permitted formula without filling absent operands. Do not average conflicting counts or describe targets as guaranteed. Require named human review and approval by [Named grant lead], Programme Lead Amina Yusuf and Finance Lead Tom Reed before consequential use. Do not submit, email, sign, publish or claim compliance, eligibility, funding, approval or submission readiness.
Required inputs
Supply authorised excerpts from prior reports, current programme plans, the controlled budget, monitoring definitions, funder questions and any written target-setting decision. Include reporting periods and stable locators. In a fictional example, Prior Report PR-02 says 180 households received parcels in the previous year; Planning Note P-05 forecasts 240 next year; Budget B-07 contains unit costs for 200. Preserve three rows or linked propositions. Do not invent 220 as a compromise, assume the budget proves delivery capacity, or call 240 funder-approved. If “household reached” changed definition between years, provide both definitions and mark comparability Human decision required.
Expected output
Expect an internal “Results and targets separation ledger — Hold pending programme and finance review”. An illustrative line could show: “Metric: households receiving parcels; historic result: 180, PR-02 table 3, previous reporting year; proposed target: 240, P-05 paragraph 6; budget basis: 200 units, B-07 Delivery!D12; comparability: definition supplied only for historic result; status: Conflict — human decision required.” Include columns for evidence quality as a descriptive source condition, not a model score; measurement method; assumptions explicitly supplied; arithmetic link; narrative-use restriction; and named owner. Label any sample draft wording as illustrative, for example: “[Draft] The programme proposes a target of [Unresolved] households; programme and finance reconciliation is required.”
Verification checkpoint
Amina verifies metric meaning, delivery period, population and whether any proposed target has been authorised internally. Tom checks units, current budget linkage and arithmetic without deciding programme feasibility outside his remit. Maya checks that historic achievements retain past tense and that no source qualification disappeared. Recalculate only from supplied operands and document the formula; if an operand, rounding rule or period is absent, stop. The decision rule is that a target enters narrative only after the named programme and finance reviewers resolve all material mismatches and record the authorised source. Until then, use Hold or remove the number. This method does not predict outcomes or establish that targets are achievable. Neither the model nor the prompts determine compliance, eligibility, funding or readiness for submission.
When a grant officer’s draft touches legal questions, such as contract terms or compliance language, it helps to see how another field handles reviewable drafting, as laid out in the Legal Context-to-Draft Prompting Playbook, which covers source packets and lawyer sign-off as parts of one workflow for moving from scattered materials toward a draft that others can review.
Prompt 11: Quote and outcome evidence ledger
Purpose
Build a controlled ledger for quotations and outcome claims, which require different checks. A quotation needs exact wording, speaker or document attribution, context, permission status and locator; an outcome claim needs a defined measure, period, population, method and source. The practical procedure is to inventory candidate evidence, minimise personal data, reproduce only necessary excerpts, label paraphrases, identify missing permissions and connect each item to a proposed narrative use. Use the ledger to prevent compelling wording from exceeding the available evidence. The decision rule is that unverifiable, contextless or permission-uncertain quotations remain excluded, while outcome claims missing a measure or period remain Hold rather than being softened into apparently factual prose.
Copy-paste prompt
Confirm that the restricted packet is authorised for this evidence-ledger task and that the named organisation-approved environment is permitted. Stop unless [Named grant lead] confirms permission or authorisation for both the packet and environment. Apply privacy and data minimisation: exclude unnecessary personal, confidential, sensitive or restricted material; do not reproduce identifiable beneficiary stories, health information, contact details, credentials, signatures or private correspondence when aggregate or de-identified material is sufficient. Use only the listed authorised sources and cite precise source locators. Do not use the web or outside knowledge unless [Named grant lead] explicitly expands scope. Do not invent quotations, speakers, consent, permissions, outcome facts, funder rules, deadlines, budget values, citations, calculations or approval. Label unknown, uncertain, missing and conflicting information rather than infer it. Create separate quote and outcome entries. For quotes, record exact text, attribution as supplied, context, date, locator, proposed use, permission evidence and minimisation action. For outcomes, record claim, metric definition, period, population, method, result, limitations and locator. Mark paraphrases explicitly and never repair wording inside quotation marks. Require named human review and approval by [Named grant lead], Programme Lead Amina Yusuf and the named privacy reviewer before consequential use. Do not submit, email, sign, publish or claim compliance, eligibility, funding, approval or submission readiness.
Required inputs
Provide the authorised prior-report extracts, aggregate monitoring tables, programme notes, permissions record if one exists, requirement IDs and source manifest. Do not supply raw beneficiary files merely to locate a usable sentence. A fictional report might contain the unattributed line “The weekly session helped me feel connected” beside an aggregate attendance table. The quotation’s presence in a report does not prove permission for reuse in a new application; record permission as not supplied. Separately, a statement that 60 participants attended belongs in the outcome side only if its period, definition and locator are supplied. Do not infer that attendance caused improved wellbeing.
Expected output
Expect a draft “Quote and outcome evidence ledger” with visible use states: Provisionally usable, Hold, Exclude or Human decision required. These are workflow recommendations, not legal determinations. An illustrative quote row could state: “Q-11-04; exact excerpt retained; speaker identity not needed; source PR-04, page 7; reuse permission not supplied; proposed narrative use blocked; state: Hold — privacy review.” An outcome row could state: “O-11-08; 60 attendances, not necessarily 60 unique participants; period supplied; method unclear; source table 2; state: Human decision required.” Include a claim-versus-evidence note so correlation, testimony, outputs and measured outcomes are not treated as interchangeable.
Verification checkpoint
The named privacy reviewer reviews handling and documented permission under the organisation’s process; Amina verifies programme context and metric meaning; Maya checks exact quotation marks, source locators and proposed use. Human reviewers should compare every quote character by character with the authorised original and confirm that surrounding context does not reverse its meaning. For outcomes, independently inspect totals, footnotes, periods and whether counts represent people, contacts or sessions. The trade-off is narrative specificity versus privacy and evidential strength: omit an appealing quote when permission or context is uncertain rather than treating inclusion as harmless. No product setting supplies consent or reuse authority. Any unresolved quotation stays excluded and any unsupported causal outcome stays on Hold. Neither this ledger nor the model determines compliance, eligibility, funding or submission readiness.
Prompt 12: Unsupported-claim and missing-input register
Purpose
Consolidate every assertion or required answer that the authorised packet cannot presently support. An unsupported claim is proposed prose lacking adequate source evidence; a missing input is information needed to answer a supplied requirement but absent from the packet. This differs from contradiction logging because there may be no competing statement. The procedure is to test the requirement register, programme facts, target comparison, quote ledger and emerging draft sentence by sentence; identify the precise gap; assign a named information owner; and choose remove, qualify, obtain an authorised source or leave blank. The decision rule is that material unsupported claims never survive as polished assertions. Missing mandatory inputs place the affected section on Hold.
Copy-paste prompt
Before reviewing the draft, confirm that the source packet is authorised for this task and that the named organisation-approved environment is permitted. Stop unless [Named grant lead] confirms permission or authorisation for both the packet and environment. Apply privacy and data minimisation: exclude unnecessary personal, confidential, sensitive or restricted information, including raw beneficiary data, credentials, bank information, signatures and unrelated correspondence. Use only the listed authorised sources and cite source locators for every supported statement and requirement. Do not use the web or outside knowledge unless [Named grant lead] explicitly expands scope. Do not invent facts, funder rules, eligibility interpretations, deadlines, budget values, metrics, citations, calculations, permissions or approval. Label unknown, uncertain, missing and conflicting information rather than infer it. Review each material draft claim and required answer. Record claim or input ID, proposed wording or requirement, support found, source and locator, exact deficiency, material consequence, permitted interim treatment, named information owner, requested evidence and status. Distinguish absent evidence, incomplete evidence, undefined term, stale period, missing approval and inaccessible source. Do not fill blanks with plausible language. Require named human review and approval by [Named grant lead] and the relevant programme, finance, privacy or authorised-release owner before consequential use. Do not submit, email, sign, publish or claim compliance, eligibility, funding, approval or submission readiness.
Required inputs
Supply the authorised requirement register, source manifest, ambiguity log, ownership map, programme fact register, results comparison, evidence ledger and current internal draft. Use a minimised draft without comments or personal details irrelevant to gap analysis. A fictional draft might say, “The programme will serve 240 households across the entire district and reduce isolation.” The packet supports only a planning forecast of 240, lacks the district boundary and contains no supplied outcome measure for reduced isolation. Split this into three issues: target authorisation, geographic definition and unsupported outcome claim. Do not downgrade “will reduce” to “aims to reduce” and then treat it as evidenced; record the evidence gap separately.
Expected output
Expect a draft “Unsupported-claim and missing-input register — Hold” and a marked-up claim inventory, not rewritten final prose. An illustrative row could read: “UC-12-09; ‘will reduce isolation’; no supplied outcome measure or causal evidence; related requirement R-22; interim treatment: remove or label as proposed objective after programme review; evidence owner: Amina Yusuf; state: Human decision required.” Another row could state: “MI-12-05; application deadline required by cover sheet; no authorised source supplied; do not search portal; owner: [Named grant lead] to obtain current written source; Hold.” The artefact should prioritise by effect—mandatory answer, financial figure, target, evidence claim or descriptive enhancement—without inventing a risk score.
Verification checkpoint
Maya performs a reverse-source audit: every material claim in the draft must map to a current authorised source locator or a visible draft/decision marker. Relevant owners decide whether to provide a new authorised source, narrow the wording, remove the claim or keep the section blank. If scope is expanded, record who authorised it and add the new source to the manifest before use; do not conduct web research merely because an input is missing. OpenAI’s Projects documentation, accessed on 3 October 2026, says Projects can keep related chats, files and instructions together and that project instructions apply within that Project. Treat this only as conditional working context, subject to account and workspace settings—not as authorisation or the official grant record. Preserve reviewed artefacts in the organisation’s approved repository. Any unresolved mandatory input, material number or approval keeps the package on Hold. Human reviewers alone decide compliance, eligibility, funding and submission readiness.
Prompt 13: Budget data dictionary
Purpose
Convert an authorised budget workbook or table into a reviewable dictionary that explains what each field, row and category means without treating blank cells, labels or formatting as self-explanatory. This differs from checking arithmetic: the task establishes definitions, provenance, units, periods and ownership before calculations begin. Use it when programme and finance colleagues may interpret terms such as “participants”, “session”, “direct cost” or “match” differently. The recommended decision rule is: if a definition, treatment or source location is absent or conflicting, mark it for finance or programme-owner resolution rather than normalising it. Neither this method nor the model determines allowability, compliance, eligibility, funding or submission readiness.
Copy-paste prompt
First confirm that [Authorising person and role] has authorised this source packet and that [Approved account/workspace] is approved for this restricted drafting task. Stop unless both permission for the packet and authorisation for the environment are confirmed. Use only these listed authorised sources: [Controlled budget], [Funder rules], [Programme notes] and [Approved amendments]. Cite a precise source locator for every extracted definition or value, using sheet, table, row, column, cell, page, section or paragraph as available. Do not use the web or outside knowledge unless [Named human] explicitly expands the scope. Do not invent facts, definitions, funder rules, deadlines, budget values, calculations, citations, eligibility interpretations or approval. Label every unknown, uncertain, missing or conflicting item instead of inferring it. Apply privacy and data minimisation: exclude unnecessary personal, confidential, sensitive or restricted material, including bank details, credentials, signatures and identifiable beneficiary information. Create a budget data dictionary with columns for controlled field name, plain-language meaning, source locator, source status, cost category, unit, quantity, unit rate, period, currency, tax treatment if supplied, rounding rule if supplied, formula or dependency, restricted-use note, owner and review status. Distinguish copied source values from definitions and from proposed editorial labels. Preserve original terminology alongside any suggested clearer label. Do not silently interpret blanks as zero, not applicable or missing. Flag duplicate labels, merged cells, unexplained acronyms, hidden assumptions and inconsistent category names. Require review and explicit approval by [Finance reviewer] and, for delivery definitions, [Programme reviewer] before consequential use. Do not submit, email, sign, publish or represent the dictionary as approved. Return Draft — HOLD where a material field lacks a definition, locator or owner.
Required inputs
Supply the controlled budget version and a short source manifest showing filename, version, date, owner and permitted use; list only the relevant funder rule extracts and programme definitions. Provide the named finance and programme reviewers, the confirmed environment, and an agreed locator convention. If a spreadsheet contains unnecessary payroll identifiers or account details, prepare a minimised authorised extract instead. OpenAI’s File Uploads Frequently Asked Questions, accessed on 3 October 2026, documents upload ceilings but does not promise accurate extraction; compare critical cells, formulae and tables with the original workbook.
Expected output
Expect an internal draft dictionary, not a rewritten budget. For the fictional “Harbour Youth Mentoring” programme, an example row might read: “Mentoring session | meaning not defined | Budget v3, Delivery sheet, row 18 | unit: session | period: April–March | currency: pounds sterling | owner: Programme Lead | Human decision required.” Another might preserve “tablet kits” exactly while linking it to the fictional handbook’s equipment restriction and marking “Hold — classification not resolved”. A useful artefact separates source text, proposed clarification and unresolved interpretation so reviewers can accept, amend or reject each entry.
Verification checkpoint
The grant officer should sample every worksheet and reconcile dictionary entries to visible headers, notes and formula references in the original. Finance must verify monetary fields, category meanings and blank-cell treatment; the programme lead must verify delivery units. Reject the artefact if it merges unlike periods, converts currencies, supplies absent tax treatment or changes a source label without preserving it. The release rule is: proceed to arithmetic checking only when every material field has a locator and named owner; otherwise retain Hold — human decision required.
Prompt 14: Unit, period, currency and arithmetic check
Purpose
Test whether supplied budget figures are internally coherent while keeping source values separate from recomputed results. This is not an eligibility or allowability review: it checks equations, units, dates, currencies, rounding and subtotal relationships visible in authorised materials. The practical distinction is between copied values, derived calculations and unresolved assumptions. Use the check only after Prompt 13 has defined the fields. The decision rule is to report a variance rather than repair it whenever the controlling formula, period, exchange basis, treatment of blanks or rounding convention has not been supplied. A named finance reviewer remains responsible for consequential interpretation.
Copy-paste prompt
Confirm first that [Authorising person and role] has authorised the listed source packet and that [Approved account/workspace] is approved for this task. Stop unless permission for the packet and authorisation for the environment are confirmed. Use only [Budget version], [Budget data dictionary], [Supplied funder budget rules] and [Authorised amendments], citing sheet and cell or another precise source locator for every input. Do not use the web or outside knowledge unless [Named human] explicitly expands scope. Never invent a fact, rule, deadline, budget value, exchange rate, formula, citation, eligibility judgement, rounding policy or approval. Label unknown, uncertain, missing and conflicting information rather than infer it. Apply privacy and data minimisation by excluding unnecessary personal, confidential, sensitive or restricted material; do not include bank data, named salaries, credentials, signatures or beneficiary records unless expressly necessary and authorised. Build an arithmetic review table. For each line, show source value, unit, quantity, rate, period, currency, supplied formula, independently recomputed result, variance and locator. Mark source values [Source], mechanical calculations [Derived] and unresolved interpretations [Human decision required]. Check additions, multiplications, percentage applications and subtotal-to-total relationships only where inputs and operations are supplied. Do not assume that a blank means zero, that monthly means twelve months, that a percentage applies to every category, or that currencies may be combined. Do not change the workbook. Require [Finance reviewer] to review and explicitly approve any corrected value before consequential use. Do not submit, email, sign, publish or describe the budget as compliant, eligible, approved or submission-ready. Return Draft — HOLD if a material variance or undefined basis remains.
Required inputs
Provide the exact controlled workbook version, the completed data dictionary, supplied budget instructions and any authorised exchange-rate or rounding statement. State the grant and project periods separately, because they may differ. Identify the finance reviewer and the variance threshold, if organisational policy supplies one; otherwise mark the threshold missing. Where formulae are hidden or scans are involved, provide an authorised human-readable extract. OpenAI’s File Uploads guidance, accessed on 3 October 2026, documents upload limits but does not promise accurate extraction; critical spreadsheet content must be checked against the original.
Expected output
Expect a draft arithmetic exception report plus a reconciliation table. In a fictional food programme, the planning note proposes 240 households, the controlled budget calculates 200 parcels, and a prior report records 180 households in an earlier period. The output must retain three distinct values and periods, not average them. An illustrative calculation could show “[Source] 200 parcels × [Source] £12 per parcel = [Derived] £2,400”; if the source subtotal says £2,450, report a £50 variance without selecting a correction. Material uncertainty should display Hold — finance decision required.
Verification checkpoint
Finance should recalculate flagged equations in the original workbook, inspect formula ranges and verify period, currency, tax and rounding treatment. The grant officer should confirm that every number in the report has a locator and that previous-period results were not treated as current targets. Reject any “corrected” figure lacking signed-off source authority. Proceed only where all material variances are resolved in a controlled budget version; otherwise preserve both values, record the owner and keep the narrative work on Hold.
If your grant team also wants to see how similar drafting habits apply beyond funder proposals, the catalog entry for 60 ChatGPT & Claude Workflows for Business Leaders offers practical workflow ideas aimed at non-technical leaders, along with a four-week responsible adoption plan.
Prompt 15: Narrative-to-budget crosswalk
Purpose
Link each material narrative commitment to the budget lines that could support it, and each material budget line to the narrative passage that explains it. This bidirectional test differs from arithmetic checking: a mathematically correct budget can still omit the costs implied by the prose, while a cost can lack a supplied programme rationale. The recommended procedure compares activities, staffing, quantities, dates, geography and outputs without declaring a cost allowable. The decision rule is that unmatched or contradictory material items remain visible and cannot be smoothed over with persuasive wording. Programme and finance reviewers must decide whether to revise the sources or the draft.
Copy-paste prompt
Before analysis, confirm that [Authorising person and role] has authorised this packet and [Approved account/workspace] is approved for restricted-source grant drafting. Stop unless both source-packet permission and environment authorisation are confirmed. Use only [Controlled narrative notes], [Controlled budget], [Budget dictionary], [Funder requirements] and [Authorised amendments]. Cite exact source locators for every activity, quantity, role, date and cost. Do not use the web or outside knowledge unless [Named human] explicitly expands scope. Do not invent facts, funder rules, deadlines, budget values, unit costs, citations, targets, eligibility decisions, explanations or approval. Label unknown, uncertain, missing and conflicting information rather than infer it. Apply privacy and data minimisation: omit unnecessary personal, confidential, sensitive or restricted data, and use role labels or aggregate information where authorised and sufficient. Produce a two-way narrative-to-budget crosswalk. For every narrative commitment, list narrative locator, activity or claim, quantity, period, geography, responsible role, linked budget line and status. For every material budget line, list its locator, value, period, linked narrative passage, supplied rationale and status. Classify links as exact, partial, absent or conflicting, explaining the classification without resolving it. Preserve distinctions between past results, future proposals and budget assumptions. Do not relabel a questionable cost to fit a rule. Require [Programme reviewer] to approve delivery mappings and [Finance reviewer] to approve financial mappings before consequential use. Do not submit, email, sign, publish or claim compliance, eligibility, approval, funding or submission readiness. Return Draft — HOLD whenever a material narrative promise lacks budget support or a material cost lacks sourced narrative support.
Required inputs
Supply the current narrative plan or section notes, controlled budget and dictionary, relevant requirement-register rows, and the named programme and finance reviewers. Define “material” only if organisational policy or the funder packet does so; otherwise mark it as a reviewer decision. Include exact periods and versions. Remove individual beneficiary details where aggregate delivery descriptions suffice. If tables were extracted from an uploaded document, compare them with the source: OpenAI’s File Uploads Frequently Asked Questions, accessed on 3 October 2026, says document handling can be text-based depending on plan and file type, so image-only or visually structured material needs human inspection.
Expected output
Expect a review crosswalk with paired traceability and an exception queue. In the fictional mentoring example, “provide weekly mentoring sessions” might link to facilitator hours but have no supplied venue-cost relationship; mark the link partial, not complete. A “tablet kits” budget line might have no narrative counterpart and conflict with a supplied fictional equipment rule. Its state should be Hold — human decision required, with the precise rule and budget locators. The artefact must not suggest moving, renaming or deleting the line unless a named reviewer records that decision.
Verification checkpoint
Programme staff should verify that activities, volumes, staffing and dates reflect the authorised plan; finance should verify that links point to the correct budget rows and periods. Trace a sample in both directions, then inspect all unmatched items. Reject the crosswalk if it turns correlation into justification, treats prior performance as a promised outcome or silently reconciles competing quantities. Continue to drafting only when reviewers resolve material conflicts in controlled sources; otherwise keep affected passages and lines on Hold.
Prompt 16: Budget discrepancy log for finance
Purpose
Consolidate unresolved financial differences into an action-oriented log for a named finance reviewer. Unlike the crosswalk, which maps relationships, this artefact records specific exceptions, their evidence, potential draft effect and the decision needed. It should preserve competing values rather than choose a preferred one. The practical procedure is to deduplicate only genuinely identical issues, assign stable identifiers and separate factual discrepancies from interpretation questions. The decision rule is conservative: if resolution could alter a total, funding request, cost category, unit rate, narrative commitment or rule treatment, the affected item remains on Hold until finance records a decision in the organisation’s controlled process.
Copy-paste prompt
Confirm that [Authorising person and role] has authorised the source packet and that [Approved account/workspace] is approved for this restricted task. Stop unless permission for the packet and authorisation for the environment are confirmed. Use only [Controlled budget], [Arithmetic check], [Narrative-budget crosswalk], [Funder rule extracts] and [Authorised amendments]. Cite an exact source locator for every competing value and relevant rule. Do not use the web or outside knowledge unless [Named human] explicitly expands scope. Never invent facts, funder rules, deadlines, budget values, formulae, citations, eligibility conclusions, materiality thresholds, resolutions or approval. Label unknown, uncertain, missing and conflicting information rather than infer it. Apply privacy and data minimisation by excluding unnecessary personal, confidential, sensitive or restricted material; use role names and minimised extracts rather than payroll identities, bank details, credentials or signatures. Create a finance discrepancy log with: issue ID, concise issue, source A value and locator, source B value and locator, units, periods, currency, relevant supplied rule, affected totals or passages, discrepancy type, severity basis if supplied, decision required, named owner, due date only if supplied, status and resolution-evidence locator. Distinguish arithmetic errors, source-version conflicts, undefined treatments, narrative mismatches and possible rule conflicts. Never relabel, offset, delete, convert or average values. Draft neutral questions for [Finance reviewer], but do not answer them. Require that reviewer’s explicit recorded approval before any consequential correction or use. Do not submit, email, sign, publish or present the log or budget as compliant, eligible, approved, funded or ready to submit. Output Draft — HOLD for every unresolved material issue.
Required inputs
Provide the current controlled workbook, previous reconciliation artefacts, relevant rule extracts, source-version history and the finance reviewer’s name and role. Include a supplied due date only if it exists; do not create one for convenience. State where approved resolutions must be recorded, because a chat or Project should not be treated as the official grant record. OpenAI’s Projects guidance, accessed on 3 October 2026, says Projects can keep related chats, files and instructions together, but availability and sharing depend on account settings and this convenience does not establish organisational recordkeeping authority.
Expected output
Expect an internal review log, a short count by unresolved issue type and a list of affected draft sections. For the fictional community food programme, one entry could preserve “180 households — prior report, prior period”, “240 households — planning note, proposed period” and “200 parcels — budget formula, proposed period”. The decision question might be: “Which proposed-period volume is authorised, and must the controlled budget or programme note be revised?” The state remains Hold — finance and programme decision required; no blended figure or implied answer is acceptable.
Verification checkpoint
Finance must inspect each cited source, confirm that the discrepancy is accurately framed, and record any resolution with a controlled evidence locator. The grant officer should verify that closed items identify who decided, what source changed and which downstream artefacts need refreshing. Reopen an item if only chat text, an uncited comment or an assumed convention supports closure. The release rule is not “no discrepancies”; it is “no unresolved material discrepancies affecting the draft”, confirmed by named human reviewers.
Prompt 17: Draft section outline from requirements
Purpose
Turn the authorised requirement register into a section-by-section drafting plan before prose is generated. This differs from writing an attractive generic proposal outline: headings, order, response limits, mandatory evidence and attachments must come from supplied requirements, while absent portal fields remain unverified. The procedure maps each requirement to a proposed response location, source candidates, owner and unresolved decision. The decision rule is that every mandatory supplied requirement must have one accountable location or an explicit gap; optional editorial structure may be suggested only when clearly labelled and must not displace the funder’s supplied format.
Copy-paste prompt
First confirm that [Authorising person and role] has authorised the listed packet and that [Approved account/workspace] is approved for this restricted drafting work. Stop unless permission for the packet and environment authorisation are confirmed. Use only [Requirement register], [Format and limit table], [Source precedence note], [Programme evidence], [Budget crosswalk] and [Authorised amendments]. Cite exact source locators for every funder requirement and proposed factual content source. Do not use the web or outside knowledge unless [Named human] explicitly expands scope. Do not invent facts, application sections, funder rules, deadlines, word or character limits, budget values, citations, eligibility judgements, portal fields or approval. Label unknown, uncertain, missing and conflicting information rather than infer it. Apply privacy and data minimisation by excluding unnecessary personal, confidential, sensitive or restricted material; use only the least-sensitive evidence needed to plan each section. Produce a Draft outline table with section ID, exact supplied question or requirement, requirement locator, mandatory or optional status if supplied, response limit if supplied, proposed answer structure, authorised evidence locators, budget links, attachments, named content owner, unresolved questions and review state. Clearly label any editorial subheading as Suggested, not funder-required. Do not merge requirements if doing so could obscure a mandatory response. Mark unsupplied portal configuration Not verified. Require [Grant lead] to approve requirement coverage, [Programme reviewer] to review delivery content and [Finance reviewer] to review financial links before consequential drafting. Do not submit, email, sign, publish or claim that the outline establishes compliance, eligibility, funding or submission readiness. Return Hold where a mandatory requirement, limit, evidence source or owner is missing.
Required inputs
Supply the current requirement register, format limits, attachment list, source-precedence decision, evidence ledger and budget crosswalk. Name the grant lead, programme reviewer and finance reviewer. Include the exact application version and any authorised amendment sequence. If the portal itself is not part of the packet, state that explicitly. OpenAI’s prompting guidance, accessed on 3 October 2026, recommends clear, specific context and iterative refinement; here, that supports reviewing the outline before drafting but does not guarantee source fidelity or suitability.
Expected output
Expect an internal drafting blueprint rather than narrative prose. For a fictional requirement, “Describe proposed reach in no more than 300 words”, the outline might allocate: need and geography; delivery method; proposed reach; evidence limitations. If the programme note says 240 households while the budget reflects 200 parcels, the proposed-reach subsection must display Hold — target unresolved. The outline should point to both locators and assign programme and finance owners, not select whichever number produces a stronger application.
Verification checkpoint
The grant lead should compare every outline row against the requirement register and confirm that no mandatory question, attachment or supplied limit disappeared. Programme and finance reviewers should validate their evidence and budget links. Check that suggested headings are visibly editorial and that unsupplied portal details remain “not verified”. Begin prose only for rows whose required sources and owners are present; retain Hold for unresolved mandatory elements. Human approval of the outline authorises drafting, not submission or a compliance conclusion.
Prompt 18: Source-located narrative draft
Purpose
Produce restrained draft prose in which every material factual claim, number, date, quotation and funding-history statement can be traced to the authorised packet. This differs from a polished final application: visible source tags, uncertainty labels and review gates take priority over seamless rhetoric. The procedure drafts one approved outline section at a time, preserving funder wording and response limits where supplied. The decision rule is: omit or visibly bracket unsupported content rather than fill a persuasive gap. The result is an internal review artefact; neither ChatGPT nor this prompt determines compliance, eligibility, funding, formal approval or readiness to submit.
Copy-paste prompt
Confirm first that [Authorising person and role] has authorised this source packet and [Approved account/workspace] is approved for restricted-source drafting. Stop unless packet permission and environment authorisation are confirmed. Use only [Approved section outline], [Requirement register], [Programme evidence ledger], [Prior-results table], [Controlled budget], [Crosswalk] and [Authorised amendments]. Cite precise source locators immediately after every material factual claim, figure, target, date, quotation, financial statement and past-result reference. Do not use the web or outside knowledge unless [Named human] explicitly expands scope. Never invent facts, funder rules, deadlines, budget values, citations, targets, outcomes, causal claims, eligibility decisions, approval or connective wording that implies facts. Label unknown, uncertain, missing and conflicting information instead of inferring it. Apply privacy and data minimisation by excluding unnecessary personal, confidential, sensitive or restricted material; do not insert identifiable stories, health details, safeguarding information, credentials, signatures or confidential correspondence merely to make prose vivid. Draft only [Named section] within the supplied limit. Mark sourced content [Source], arithmetic transparently derived from supplied values [Derived], editorial connective wording [Draft], and unresolved matters [Human decision required]. Distinguish previous results from proposed activities and do not present targets as guaranteed outcomes. Preserve conflicts in bracketed review notes. Require [Grant lead] to approve factual presentation, [Programme reviewer] to approve delivery claims, [Finance reviewer] to approve numbers and [Privacy or safeguarding reviewer, if applicable] to review sensitive content before consequential use. Do not submit, email, sign, publish or portray the draft as compliant, eligible, approved, funded or submission-ready. Return Draft — HOLD if any required claim lacks support or any material conflict remains.
Required inputs
Provide one approved outline row, its exact question and supplied limit, the relevant authorised evidence extracts, budget links, prior-results distinctions and named reviewers. Use stable locators that reviewers can reproduce. Remove unnecessary personal data before prompting. OpenAI’s Projects page, accessed on 3 October 2026, says project instructions apply within that Project; this may help maintain a source boundary, but it cannot guarantee adherence or replace human review. Organisation-specific permission, access and retention decisions still govern the packet.
Expected output
Expect a labelled narrative draft followed by a claim-to-source table and unresolved-items list. A fictional example might read: “[Draft] The programme proposes weekly food-parcel distribution during the supplied project period. [Source: Programme Note v2, section 3] [Human decision required: proposed household volume conflicts between Programme Note v2, section 4, and Budget v3, Delivery row 12].” It must not choose 200 or 240, convert the earlier 180-household result into a forecast, or claim impact. Unsupported mandatory content should appear as Hold — source or human decision required, not elegant filler.
Verification checkpoint
Reviewers should read the prose against original sources, then audit the claim table in both directions: every material claim needs a locator, and each cited source must support the exact wording and period. Recount the supplied word or character limit using the organisation’s chosen method and mark method uncertainty. Finance verifies every figure; programme staff verify activities and targets; privacy or safeguarding reviewers assess sensitive material where relevant. Approval permits controlled revision only. Any unsupported claim, unresolved numerical conflict or unsupplied portal requirement keeps the section on Hold and forbids submission, publication or external circulation.
Prompt 19: Impact and results draft with visible gaps
Purpose
Produce an evidence-bounded impact and results section that distinguishes prior results, current conditions, proposed activities and future targets. This is not permission to convert historical performance into a promised outcome. The recommended procedure is to build a four-part table before drafting: claim, time period, source locator and status. For example, a fictional prior report might record 180 households served last year, while a planning note proposes 240 next year and the budget supports 200. Preserve all three figures and place the proposed target on HOLD; do not average them. The decision rule is: a factual statement may enter prose only when its source and period are explicit; a future target also needs named programme and finance review.
Copy-paste prompt
First confirm that a named human has authorised this source packet and its use in the approved environment. Stop unless both permission for the packet and authorisation for the environment are confirmed. Use only these listed authorised sources: [Source manifest with controlled identifiers, versions and locators]. Cite a precise source locator for every factual claim, result, target, quotation and financial reference. Do not use the web or outside knowledge unless [Named human and role] explicitly expands the scope in writing. Do not invent facts, rules, deadlines, eligibility interpretations, budget values, citations, calculations, outcomes or approval. Label all unknown, uncertain, missing or conflicting information instead of inferring or reconciling it silently. Apply privacy and data minimisation: exclude unnecessary personal, confidential, sensitive or restricted material, including identifiable beneficiary details. Draft an impact-and-results section that separately labels prior reported results, proposed activities, proposed targets, assumptions and unresolved evidence gaps. For each material sentence, append [Source: controlled ID, page/section/cell] or [Human decision required]. Where sources conflict, show each version and its period without choosing one. Require named review by [Programme lead], [Finance reviewer] and [Grant officer] before any consequential use. Do not submit, email, sign, publish, certify compliance or state that the draft is eligible, fundable or submission-ready. Return Hold if any material target, baseline, method, period or source is unresolved.
Required inputs
Supply the authorised source manifest; the relevant funder question and any supplied limit; programme notes; controlled prior reports; the approved budget version; the uncertainty register; and names of the programme, finance and grant reviewers. Remove case histories, health details and direct identifiers unless specifically authorised and necessary. Record whether every table or scan has been checked against the original. The File Uploads Frequently Asked Questions (FAQ), accessed on 3 October 2026, warns that document handling can be text-based rather than visual on some plans, so an extracted chart or image-only result is not sufficient evidence by itself.
Expected output
An internal Draft — HOLD comprising a period-labelled evidence table, source-located prose, a list of excluded unsupported statements and a gap register. In the fictional household example, the output should retain “180 prior”, “240 proposed” and “200 budget basis” as separate entries, followed by Human decision required. It must not declare impact, compliance, eligibility, funding likelihood or submission readiness.
Verification checkpoint
A human reviewer compares every material sentence with the cited original, verifies tense and period, and confirms that targets are proposals rather than achieved results. Programme reviews delivery meaning; finance checks budget-supported quantities; the grant officer checks the funder question. Release to the next internal stage only when contradictions have an owner and disposition. Otherwise retain Hold.
Prompt 20: Attachments and implementation checklist
Purpose
Turn supplied attachment rules and internal dependencies into a controlled implementation checklist without pretending that an unseen portal or omitted guidance has been checked. The procedure is to map each supplied requirement to an attachment, owner, source locator, version, due point and verification state. Distinguish “required by supplied rule”, “internally recommended”, “not evidenced” and “not applicable only if an authorised human decides”. For example, if a fictional handbook lists a budget template and governing-body letter but the packet contains only the budget, mark the letter Missing — hold. The trade-off is useful completeness versus false certainty: record a possible dependency, but never describe it as a funder requirement without a source.
Copy-paste prompt
Confirm first that a named human authorised the restricted source packet and approved environment. Stop unless permission for the packet and authorisation for that environment are confirmed. Use only these listed authorised sources: [Source manifest with identifiers, versions and locators], and cite the exact source locator for each attachment or implementation requirement. Do not use the web, a portal, or outside knowledge unless [Named human and role] explicitly expands scope. Never invent a fact, rule, deadline, eligibility condition, budget value, citation, approval, attachment name or portal requirement. Label unknown, uncertain, missing and conflicting information rather than infer it. Apply privacy and data minimisation by excluding unnecessary personal, confidential, sensitive or restricted content; list a sensitive attachment by controlled identifier rather than reproducing its contents where possible. Create a draft checklist with columns for requirement wording, source locator, artefact, permitted format, supplied limit, owner, dependency, current version, privacy review, status and evidence of human verification. Separate funder-stated requirements from internal recommendations. Mark any requirement dependent on an unsupplied portal or amendment as Not verified. Require named review by [Grant officer], [Document owner], [Privacy owner] and, for financial attachments, [Finance reviewer] before consequential use. Do not submit, upload to a funder portal, email, sign, publish, certify compliance or claim eligibility, funding or readiness. Return Hold wherever a required artefact, owner, permission, signature authority, format rule or controlling source is absent.
Required inputs
Provide the requirement register, format-and-limit table, source-precedence note, attachment inventory, internal responsibility list and approved timetable. Include only attachment metadata needed for planning; do not paste bank details, signatures, credentials or identifiable beneficiary records. If an attachment contains tables, scans or image-only text, supply a human-verified transcription or flag it for original-document inspection. As documented by OpenAI’s File Uploads FAQ and accessed on 3 October 2026, upload ceilings are not extraction guarantees; they do not establish permission to upload a complete archive.
Expected output
A Draft implementation checklist — hold until reviewed, plus a missing-attachment register and dependency sequence. In the fictional example, the budget row can be “present, version check pending”, while the governing-body letter remains “missing; owner and signing authority required”. The artefact must not pre-populate completion, signature or approval, and must visibly distinguish source-backed requirements from editorial recommendations.
Verification checkpoint
The grant officer reads each cited rule in context and checks that every mandatory artefact appears once. Document owners verify versions; privacy reviews proposed handling; finance validates financial schedules; an authorised signatory confirms only their authority, not via the model. If a portal, amendment, template or signature requirement is unavailable, retain Not verified and Hold rather than extrapolating.
Sharing restricted grant materials also requires a permission-aware review space. The collaborative ChatGPT Spaces decision-page prompts cover source intake, alternatives, comments and explicit human approval; check the actual workspace sharing permissions before applying that workflow to a grant packet.
Prompt 21: Material claim-to-source audit
Purpose
Audit the assembled draft at sentence level so that fluent prose cannot obscure material claims. A material claim includes a programme fact, need statement, funding history, result, target, quotation, partnership statement or financial assertion that could affect a reviewer’s judgement. The recommended procedure is to assign each claim a unique identifier, quote it exactly, locate its evidence and classify support as direct, derived, conflicting or absent. For example, “weekly mentoring across three sites” must not pass if one source supports weekly delivery and another supports only two sites. The decision rule is strict: direct support may proceed to human review; derivation needs its method; conflict or absence triggers Human decision required.
Copy-paste prompt
Before auditing, confirm that a named human authorised the restricted source packet and its use in the approved environment. Stop unless packet permission and environment authorisation are confirmed. Use only these listed authorised sources: [Controlled source manifest] and this draft: [Draft identifier/version]. Cite exact source locators, including page, section, paragraph, table or cell where available. Do not use web research or outside knowledge unless [Named human and role] explicitly expands scope. Do not invent facts, funder rules, deadlines, eligibility conclusions, budget values, citations, calculations, approvals or missing evidence. Label unknown, uncertain, missing and conflicting information instead of inferring it. Apply privacy and data minimisation: exclude unnecessary personal, confidential, sensitive or restricted material, and quote only the minimum text required for audit. Extract every material claim into a ledger with claim ID, exact draft wording, claim type, period, source locator, support classification, discrepancy and proposed action. Do not repair an unsupported claim by rewriting it as fact; recommend source, qualification or removal. Require named review by [Grant officer], the relevant [Programme owner], and [Finance reviewer] for financial claims before consequential use. Do not submit, email, sign, publish, certify compliance, determine eligibility or claim funding or submission readiness. Return Hold for every unsupported, ambiguously sourced, materially conflicting or incorrectly cited claim.
Required inputs
Supply the frozen draft version, authorised manifest, requirement matrix, evidence ledger, budget crosswalk and contradiction register. Define “material” for this internal review, with a named human retaining authority to add claims. Provide stable locators rather than filenames alone. If the draft was developed in a ChatGPT Project, export or preserve the reviewed artefact in the organisation’s controlled repository: according to OpenAI’s Projects guidance accessed on 3 October 2026, Projects keep related chats, files and instructions together, but that product context does not make a Project the official grant record.
Expected output
A Draft claim audit — hold with one row per material claim, a summary grouped by support status and a proposed remediation queue. For the fictional mentoring statement, split frequency and site count into separate auditable propositions. Mark “weekly” with its locator and “three sites” as conflicting or unsupported. The audit is a review artefact, not a declaration of truth, compliance, eligibility or likely funding.
Verification checkpoint
The grant officer samples every “directly supported” classification against the original and reviews all other classifications. Programme owners confirm operational meaning; finance checks monetary and quantity claims. Check quotations word for word and confirm periods have not shifted. A claim leaves Hold only after a named reviewer records keep, qualify, replace or remove, with the supporting locator and date.
Prompt 22: Numbers, periods and arithmetic audit
Purpose
Test numerical consistency without allowing arithmetic to disguise an unsupported input. Separate copied values from calculated values, and record units, currency, period, rounding and blank-cell treatment. The procedure is to extract every number from the draft, compare it with the controlled budget and evidence sources, then recompute only equations whose inputs and rules are supplied. In a fictional food programme, prior reach of 180 households, a proposed target of 240 and a budget quantity of 200 are not interchangeable. A mathematically correct average would still be unauthorised. The decision rule is: arithmetic can verify a relationship, but only a named source owner can validate the meaning and authority of each input.
Copy-paste prompt
Confirm before processing that a named human authorised the restricted packet and approved environment. Stop unless source-packet permission and environment authorisation are confirmed. Use only these listed authorised sources: [Source manifest], the controlled budget [ID/version], and draft [ID/version]. Cite exact source locators for every input number and rule. Do not use the web or outside knowledge unless [Named human and role] explicitly expands scope. Never invent a fact, rule, deadline, budget value, unit, period, exchange rate, indirect-cost treatment, rounding convention, citation, eligibility conclusion or approval. Label unknown, uncertain, missing or conflicting information rather than infer it. Apply privacy and data minimisation by excluding unnecessary personal, confidential, sensitive or restricted material; use aggregate values where the authorised task permits. Build an audit ledger for every material number showing draft context, copied or derived status, source value, locator, unit, currency, period, equation, recalculation, variance and reviewer. Preserve blanks as blanks unless a supplied rule defines them as zero. Do not blend figures from different periods. Require named review by [Finance reviewer], [Programme lead] and [Grant officer] before consequential use. Do not submit, email, sign, publish, certify compliance, determine eligibility or state funding or submission readiness. Return Hold for missing units, unsupported inputs, unexplained variances, period mismatches, conflicting totals or absent calculation rules.
Required inputs
Provide the locked budget workbook or authorised extract, budget data dictionary, narrative draft, source-located results ledger, relevant funder calculation rules and finance-approved currency and rounding instructions where supplied. Do not include bank-account data, payroll identifiers or unrelated transaction detail. For spreadsheets, identify exact sheet and cell ranges. OpenAI’s File Uploads FAQ, accessed on 3 October 2026, describes qualified spreadsheet limits and does not promise reliable table extraction; therefore a named reviewer must compare critical cells, formulas and merged-table meanings with the original workbook.
Expected output
A Draft numerical audit — hold for finance containing a number inventory, recalculation sheet, variance log and period crosswalk. In the fictional household example, list 180 as a prior-period result, 240 as a proposed programme target and 200 as the budget basis. Do not manufacture a reconciled figure. Show the exact decision required and which narrative or budget locations would change after approval.
Verification checkpoint
Finance independently recalculates totals from the controlled workbook and confirms units, periods, currency, formulas and rounding. Programme review tests whether quantities represent the same population and activity. The grant officer checks supplied funder rules. Derived values proceed only when inputs and method are approved and reproducible; otherwise the package remains Hold. Neither the model nor this prompt determines financial compliance, eligibility or readiness.
Prompt 23: Funder-rule and format audit
Purpose
Compare the draft with only the funder rules and formats actually present in the authorised packet. This differs from a general quality review: it tests traceability to supplied instructions, not what a funder might ordinarily expect. The procedure is to inspect each requirement-row against the draft or attachment, record evidence and mark unseen interfaces as not verified. For example, if fictional guidance sets a 2,000-character response but no portal field is supplied, test the draft against the documented limit while marking portal behaviour Not verified. The decision rule is: supplied wording controls only after a human confirms source precedence; absent or conflicting instructions cannot be resolved through custom or assumption.
Copy-paste prompt
First confirm that a named human authorised the restricted source packet and its use in the approved environment. Stop unless packet permission and environment authorisation are confirmed. Use only these listed authorised sources: [Source manifest], [Requirement register] and [Draft version]. Cite an exact source locator for every rule and finding. Do not browse the web, inspect an external portal or use outside knowledge unless [Named human and role] explicitly expands the scope. Never invent a fact, funder rule, deadline, eligibility interpretation, budget value, citation, format requirement, portal behaviour or approval. Label every unknown, uncertain, missing or conflicting matter instead of inferring it. Apply privacy and data minimisation by excluding unnecessary personal, confidential, sensitive or restricted material from the audit. Compare each supplied requirement with the corresponding draft passage or artefact. Report requirement wording, hierarchy status, locator, draft evidence, measured length where mechanically countable, attachment state, exception, owner and disposition. Treat unsupplied portal fields, amendments and guidance as Not verified. Require named review by [Grant officer], [Application owner] and the relevant [Finance or programme reviewer] before any consequential use. Do not submit, email, sign, publish, certify compliance, decide eligibility, or state that funding or submission readiness has been achieved. Return Hold for missing mandatory content, exceeded supplied limits, unresolved rule conflicts, absent attachments, unknown hierarchy or unverified portal-dependent requirements.
Required inputs
Supply the authorised requirement register, source-precedence decision, amendment list, question set, templates, attachment table and frozen draft. Include the unit for each limit—words, characters, pages or file type—only where the source specifies it. Name the human who confirmed which version controls. OpenAI’s prompting guidance, accessed on 3 October 2026, recommends clear, specific instructions and iterative refinement; this supports structured auditing but does not guarantee factual accuracy, rule compliance or a submission-suitable result.
Expected output
A Draft funder-rule audit — hold with pass-for-review, revise, not verified and human-decision states. The fictional character-limit row should show the source wording, counted draft length and method, while separately recording that portal counting is unknown. Include a list of apparent compliance statements removed or softened because the evidence establishes only consistency with supplied documents, not compliance with the complete opportunity.
Verification checkpoint
The grant officer rereads every cited instruction in context, verifies the controlling version and manually checks consequential limits. Attachment owners inspect required forms; finance and programme reviewers address domain rules. If the portal, latest amendment or definitive hierarchy has not been authorised and supplied, the reviewer must preserve Not verified. Only an authorised human can decide whether further sourcing or revision is required.
Prompt 24: Privacy, membership and permission audit
Purpose
Audit whether the working environment, source permissions and access list match the restricted drafting purpose. This is distinct from checking prose: it asks who was permitted to provide, view and edit each source, and whether less data could serve the task. The procedure is to document the actual account or workspace, approved purpose, source owner, membership, sharing state, data-minimisation action and independent records location. For example, fictional health-adjacent notes may contain identifiable stories although only aggregate reach is needed; recommend removing those stories under organisational process and place handling on HOLD pending the privacy owner’s decision. The model must not infer consent, confidentiality permission or lawful handling.
Copy-paste prompt
Confirm first that a named human authorised the restricted packet and the specific approved environment. Stop unless both source-packet permission and environment authorisation are confirmed. Use only these listed authorised sources and administrative records: [Minimised source manifest], [Approved-environment record], [Membership list] and [Permission decisions]. Cite exact locators for every permission or configuration statement. Do not use the web or outside knowledge unless [Named human and role] explicitly expands scope. Never invent facts, rules, deadlines, budget values, citations, consent, confidentiality terms, access rights, eligibility conclusions or approval. Label unknown, uncertain, missing or conflicting information rather than infer it. Apply privacy and data minimisation: exclude unnecessary personal, confidential, sensitive or restricted material, credentials, signatures, bank details and identifiable beneficiary histories. Produce a draft audit of purpose, source authority, permitted use, environment, membership, access level, sharing event, retention destination, minimisation action and unresolved restriction. Recommend removal or controlled substitution; do not claim anonymisation or de-identification is legally sufficient. Require named review by [Information-governance or privacy owner], [Source owner], [Grant officer] and [Safeguarding lead, if applicable] before consequential use. Do not submit, email, sign, publish, certify compliance, determine eligibility or claim funding or submission readiness. Return Hold for unknown permission, excessive access, unnecessary sensitive data, unapproved environment, unclear retention, or missing reviewer authority.
Required inputs
Provide metadata rather than sensitive contents: source IDs, classifications, owners, authorised purpose, actual environment, current members, access levels, sharing history and controlled repository. Verify the actual account and workspace before assuming any Project feature. A Project does not establish organisational recordkeeping authority.
Expected output
A Draft privacy, membership and permission audit — hold, including an access matrix, minimisation log and unanswered-permission register. The fictional health-note row should say that identifiable stories are unnecessary for the stated drafting purpose, identify the source owner and request a controlled aggregate substitute. It must not pronounce legal compliance or silently delete evidence needed by the organisation; a named human decides disposition under approved process.
Verification checkpoint
The privacy or information-governance owner verifies the product, workspace configuration, permissions, retention route and minimum necessary data. Source owners confirm permitted use; safeguarding reviews relevant sensitive material; the grant officer checks membership against task need. OpenAI’s Data Controls guidance, accessed on 3 October 2026, distinguishes training choice, chat storage and Temporary Chat retention. None substitutes for organisational authorisation. Any unresolved permission or access issue keeps the package on Hold.
Prompt 25: Human release cover sheet with hold conditions
Purpose
Assemble a final internal cover sheet that makes unresolved matters and named review responsibilities impossible to overlook. This is a release gate for human consideration, not an automated approval or submission instruction. The procedure is to consolidate open findings from claims, numbers, rules, attachments and privacy audits; assign each to an accountable reviewer; and leave every approval field blank. For example, if a fictional equipment cost conflicts with a supplied eligibility rule, the cover sheet must cite both locations, identify finance and grant owners, and retain HOLD. The decision rule is conservative: any material unresolved source, figure, rule, permission, attachment or authority issue prevents internal release towards submission.
Copy-paste prompt
Before assembling the cover sheet, confirm that a named human authorised the restricted source packet and its use in the approved environment. Stop unless both packet permission and environment authorisation are confirmed. Use only these listed authorised sources and review artefacts: [Source manifest and audit artefact IDs]. Cite exact source locators for every material status and unresolved issue. Do not use the web, an external portal or outside knowledge unless [Named human and role] explicitly expands scope. Never invent facts, rules, deadlines, eligibility conclusions, budget values, citations, signatures, reviewer decisions or approval. Label unknown, uncertain, missing and conflicting information instead of inferring it. Apply privacy and data minimisation by excluding unnecessary personal, confidential, sensitive or restricted material; refer to controlled records by identifier. Prepare a draft release-cover sheet listing package version, authorised purpose, included artefacts, unresolved findings, Hold conditions, required named reviewers, blank decision fields and proposed controlled repository. Require actual review by [Grant officer], [Programme lead], [Finance reviewer], [Privacy owner], [Safeguarding or technical reviewer if required], [Executive approver] and [Authorised submitting officer] before any consequential use. Do not pre-fill approval, submit, email, sign, publish, certify compliance, determine eligibility, represent likely funding or state submission readiness. Return Hold unless every material condition has a recorded human disposition and the authorised submitting officer separately confirms authority.
Required inputs
Supply frozen versions of the draft, source manifest, requirement matrix, attachment checklist, claim audit, numerical audit, funder-rule audit, privacy audit and decision log. Include the organisation’s named roles and controlled filing destination, but no credentials or signature images. State which external elements remain unseen. According to OpenAI sources accessed on 3 October 2026, Projects can organise chats, files and instructions, while account and workspace settings vary; neither a Project nor a generated cover sheet is the authoritative grant record or proof of organisational approval.
Expected output
A Draft human release-cover sheet — hold with document inventory, version identifiers, source-boundary statement, review table, unresolved-condition table and blank dated decision fields. The fictional equipment conflict should remain prominent until authorised reviewers decide whether to remove, replace or seek clarification. Suggested states may include Hold, Revise and Human decision required, but never “approved” unless a named human records that decision outside the model output under organisational procedure.
Verification checkpoint
Each named reviewer examines the underlying originals rather than relying on the summary. Programme validates delivery claims; finance validates figures; privacy and safeguarding validate handling; the grant officer checks supplied funder instructions; the executive and authorised submitting officer act only within documented authority. Preserve the human-approved artefact in the controlled repository. Neither ChatGPT nor these prompts determines compliance, eligibility, funding, legal sufficiency or submission readiness, and no output may itself trigger submission.
Access 40,000+ AI Prompts for ChatGPT, Claude & Codex — Free!
Subscribe to get instant access to our complete Notion Prompt Library — the largest curated collection of prompts for ChatGPT, Claude, OpenAI Codex, and other leading AI models. Optimized for real-world workflows across coding, research, content creation, and business.
Useful Links
- OpenAI Help: Projects in ChatGPT
- OpenAI Help: File Uploads FAQ
- OpenAI Help: Prompt engineering best practices for ChatGPT
- OpenAI Help: Data controls in ChatGPT
- OpenAI Help: How OpenAI handles data in consumer services
- OpenAI: Business data privacy, security and compliance
