Start with notes you can trace
Choose the version of the notes that the meeting owner wants reviewed. If a transcript and a handwritten summary disagree, settle which one is authoritative before extracting tasks. Remove material that the selected AI tool is not approved to receive. Give each independently checkable statement its own ID; split a line that contains both a decision and a separate commitment. OpenAI's prompting guide recommends supplying the relevant source, desired output, and boundaries, then reviewing the result.
Here are the five Project Cedar source lines. The meeting header gives context, but it does not automatically supply a deadline or time zone for every action. For your meeting, replace the entire block with your reviewed notes. Paste the notes and the first prompt into the same ChatGPT conversation, or attach the note file and name it in the prompt.
Meeting: 2026-08-25, 09:00–09:25 America/New_York
N-01 — Decision: pilot stays limited to 20 invited users through Friday 2026-08-28.
N-02 — Action: Priya will send the revised onboarding checklist by 2026-08-26 15:00.
N-03 — Action: Mateo will rerun the access test after the checklist arrives; no due date stated.
N-04 — Proposal only: add a second region next week; no decision and no owner.
N-05 — Blocker: two synthetic test accounts still lack reviewer access; owner unknown.Classify the statements before drafting tasks
Ask for a small evidence table first. Its job is to preserve what each line says, including whether someone accepted a task. It should not squeeze every date into a general Date column.
Using only the numbered meeting notes below, return a table with Source ID, Class (decision, action, proposal, blocker, or other), exact supporting words, stated owner, and open question. Write UNKNOWN when the notes do not name an owner or settle a question. Keep date wording in the supporting words; do not create a general Date or Due Date column. Do not turn a suggestion or a blocker into an accepted task. Flag a line that contains two separate claims so I can split it.
Meeting notes:
[Paste your reviewed, numbered notes here]For Project Cedar, the classification should leave five source facts visible. N-01 belongs in a decision log. N-02 and N-03 are actions, although N-03 lacks a date. N-04 is still a proposal. N-05 is a blocker whose owner has not been assigned. If the model returns more than two actions, compare the extra rows with the original lines before keeping them.
Build a decision log and an action register
Once the classifications match the notes, request fields that say what each date means. A decision's scheduled end, the date it was recorded, an action's deadline, and an event that triggers work are different facts. Keep proposals and unowned blockers in the questions list so they remain visible without appearing as assigned work.
Using the original numbered notes and the classification above, make three outputs:
1. Decision log: Source ID, decision, Decision_recorded_at, Scheduled_end.
2. Action register: Source ID, task, owner, Due_at, Due_timezone, Trigger, status.
3. Needs-confirmation list: Source ID, exact unanswered question.
Use UNKNOWN for a value the notes do not state. Do not copy the meeting time zone into an action deadline unless that action says so. Keep proposals and blockers out of the action register unless someone explicitly accepted a task to address them. Merge duplicate mentions of the same commitment only after checking that they really describe one task. Cite the source ID in every row. Do not send a message or create tasks.Compare the output with the reviewed Project Cedar register. These are the fields that matter most in this example:
| Source | Keep this value | Do not infer |
|---|---|---|
| N-01, decision | Scheduled_end = 2026-08-28 | Decision_recorded_at = UNKNOWN. The pilot end is not an action deadline. |
| N-02, Priya's action | Due_at = 2026-08-26 15:00 | Due_timezone = UNKNOWN. The meeting's New York time zone does not establish Priya's deadline time zone. |
| N-03, Mateo's action | Trigger = checklist arrives | Due_at = UNKNOWN. A dependency is not a deadline. |
| N-04, second region | NOT_DECIDED in the questions list | No owner or action was accepted. |
| N-05, access blocker | NEEDS_OWNER in the questions list | Attendance does not assign the blocker to anyone. |
If ChatGPT labels the pilot end as a task deadline, correct the record before drafting a follow-up. For this example, the repair request is:
Recheck N-01 through N-03 against the original notes. Move 2026-08-28 from any action deadline field to N-01's Scheduled_end. Leave N-01's Decision_recorded_at UNKNOWN. Keep N-02's Due_at as 2026-08-26 15:00 and its Due_timezone UNKNOWN. Keep N-03's trigger as "after the checklist arrives" and its Due_at UNKNOWN. Return the changed rows with their source IDs; explain any field you could not verify.For your own notes, replace those IDs and values with the disputed lines. Check the revised rows yourself. A correction that merely moves a date to another column without matching the source is still an error.
When real notes are less tidy
The Project Cedar run covers one small, clean record. The following snippets are illustrative review cases, not additional ChatGPT test results. They show when a neat-looking action row should be held for confirmation.
| If the notes say | What to record and check |
|---|---|
| “Riley can probably send the deck.” | Record a possible task or open question. “Probably” does not establish that Riley accepted it. Ask who owns the deck before assigning it. |
| “Sam will finish by Friday.” | Keep “Friday” as the source wording. Confirm the calendar date and time zone before setting a reminder, especially if notes from several meetings are combined. |
| One line assigns QA to Lee; a later line assigns it to Morgan. | Flag the conflict and check which statement was the accepted correction. Avoid creating two QA tasks while ownership is disputed. |
| A task appears twice, then someone says it was canceled. | Keep the cancellation with its source ID. Check whether it applies to both mentions before closing the task or treating the repeated lines as two commitments. |
If the source itself is unclear, another prompt cannot establish what the group agreed. Put the exact disputed wording in the needs-confirmation list and ask the meeting owner or participants. Keep their answer with the notes so the change can be traced.
Draft the follow-up, then get it checked
The final message should separate confirmed decisions and commitments from the questions participants must answer. Ask ChatGPT to draft it from the reviewed tables, then read it against the source before sharing it.
Using only the reviewed decision log, action register, and needs-confirmation list above, draft a follow-up for participants in under 90 words. State confirmed commitments with their exact owners, dates, or triggers. Label missing dates, owners, and time zones as questions. Keep proposals separate from decisions. End with READY_FOR_PARTICIPANT_REVIEW. Prepare a draft only; do not send it or create tasks.The reviewed Project Cedar follow-up states Priya's commitment, keeps Mateo's date open, and asks for the access blocker's owner and Priya's deadline time zone. Its second-region idea remains a proposal. No message was sent and no task was created.
Before anything goes into a task system, check each action's source ID, verb, deliverable, owner, deadline or trigger, and status. Ask participants to correct any wrong commitment and supply genuinely missing details. Record who made each correction and when. If a task system requires a date that the meeting never supplied, leave it pending rather than inventing one. Then transfer the reviewed actions; leave decisions, proposals, and blockers in their own records.
The review kit contains the fictional notes, corrected register, follow-up, and an optional Python checker. Run python3 meeting-evidence-gate.py after extracting the kit if you want to check selected fields in this sample. Its saved result checks the fixture, not whether real participants agreed. The reusable prompts and illustrative cases above have not been separately tested in ChatGPT; the retained screenshots and files document the Project Cedar run.
