Action Items — capture into a fixed owner / task / due / status table

What this does

Given raw notes from a meeting or call — the messy running text someone typed while people talked — this pulls out the things somebody committed to do and lays them in one fixed table:

| owner | task | due | status | |-------|------|-----|--------|

Handed those notes and asked to "get the action items out", base models fail two ways. They over-capture — every topic discussed becomes a to-do, so background, opinions, and decisions-with-no-task all end up as rows. And they invent the missing parts — when the notes never say who owns a task or when it is due, the model fills in a plausible name or a smooth "by next week" that nobody actually said. Both are worse than an honest gap: a made-up owner sends the task to the wrong person, and a made-up date creates a deadline no one agreed to.

The K here is the discipline, not the four columns: only real commitments become rows, and a missing owner or missing due date is written UNASSIGNED — never guessed.

When to use / when NOT

• Use when someone hands over raw meeting or call notes and wants the action items

/ follow-ups / who-owns-what pulled out so nothing falls through.

• Do NOT use for a pre-meeting brief or agenda (that is meeting-brief-format), an

outbound recap email to a prospect after a sales call (sales-follow-up-recap), or quiz-style study notes from a lecture (cornell-note-format). This governs the post-meeting action list only.

The table contract

Every action item is one row with exactly these four columns, in this order:

1. owner — the person the notes name as responsible. If the notes name no one, write

UNASSIGNED. Do not pick the most likely person, the meeting organizer, or the reader.

1. task — the committed action, as a short imperative ("send the revised budget",

"review the API spec"). One action per row; if someone took on two things, that is two rows.

1. due — the deadline the notes actually state ("Friday", "by the 15th", "end of sprint").

If no date is stated, write UNASSIGNED. Do not infer a date from context or invent one.

1. status — where the item stands as the notes describe it: open by default, or

in progress / blocked / done only if the notes say so. If nothing is said, it is open.

The rules

1. Rows are commitments, nothing else. A row means someone will do something. Topics

discussed, information shared, opinions, and decisions that carry no follow-up task are not rows — leave them out entirely. If you cannot name the task as "someone will do X", it does not belong in the table.

1. Never invent an owner. No name in the notes → UNASSIGNED. A confidently wrong owner

is worse than an admitted gap: it routes the work to someone who never agreed to it.

1. Never invent a due date. No date in the notes → UNASSIGNED. Do not translate "soon",

"eventually", or "when we get to it" into a specific date the group never set.

1. Split, don't merge. "Dana will draft the doc and set up the review" is two commitments,

so two rows — each can have its own owner, date, and status.

1. Keep the owner's own words for who. If the notes say "the design team" rather than a

person, the owner is "design team" — that is a stated owner, not UNASSIGNED. UNASSIGNED is only for items where the notes name no one at all.

Worked example

Raw notes (what you were handed):

Kicked off with the launch date — everyone agrees end of month is tight but doable.
Priya said she'll finalize the pricing page copy by Thursday. We talked about whether to
gate the free tier; no decision, revisit next week. Someone needs to update the changelog
before we ship. Marcus is going to reach out to the two beta customers — didn't say when.
Long tangent about the old billing bug, nothing to do there. Design review is already done.

BEFORE (base default — over-captures and invents):

> - Priya: finalize pricing page copy — due Thursday > - Team: decide on gating the free tier — due next week > - Marcus: update the changelog before ship — due this week > - Marcus: reach out to beta customers — due Friday > - Priya: confirm launch date — due end of month

(It turned a no-decision discussion into a task, guessed Marcus owns the changelog and invented "Friday" for the beta outreach, invented a "this week"/"Friday" deadline, and added a "confirm launch date" task nobody committed to.)

AFTER (this format):

| owner | task | due | status | |-------|------|-----|--------| | Priya | Finalize the pricing page copy | Thursday | open | | UNASSIGNED | Update the changelog before ship | UNASSIGNED | open | | Marcus | Reach out to the two beta customers | UNASSIGNED | open |

(The gating question was a discussion with no task — dropped. The billing tangent — dropped. The design review was already done and needs nothing — dropped. The changelog has no owner and no date, so both are UNASSIGNED. Marcus's outreach has an owner but no stated date, so due is UNASSIGNED.)

Edge cases

• Nothing was committed. If the notes are all discussion and no one took anything on, say

so plainly ("No action items — this was a discussion, nothing was assigned") rather than inventing tasks to fill the table.

• A decision, not a task. "We decided to go with option B" is a decision. It only becomes

a row if someone also committed to do something about it ("Sam will write up option B").

• A group owner. "Ops will handle rollout" → owner is "Ops". That is a stated owner; do

not downgrade it to UNASSIGNED, and do not pick a single person out of the group.

• A vague time that is not a date. "soon", "before launch", "next sprint" with no anchor →

due is UNASSIGNED. Only write a due when the notes give a real point in time.

• Someone volunteered but the task is fuzzy. Keep the owner, phrase the task as best the

notes support, and if the deliverable is unclear leave a short note in the task cell rather than inventing specifics.

• No table support (plain text). Keep the four fields per line in the same order —

owner — task — due — status — with UNASSIGNED where a field is missing. The contract survives without literal columns.

Do / Don't

• Always produce one table with the columns owner, task, due, status, in that order.
• Always write UNASSIGNED for a missing owner and UNASSIGNED for a missing due date.
• Always make each row a single concrete commitment phrased as an action.
• Always drop discussion, background, and decisions that carry no task.
• Never guess an owner, the organizer, or the reader when the notes name no one.
• Never invent or infer a deadline the notes did not state.
• Never turn a topic that was merely discussed into an action item.

Common mistakes (the base's wrong defaults)

1. Every discussed topic becomes a to-do, so the table is padded with non-commitments.
2. A plausible owner is guessed for an ownerless task instead of UNASSIGNED.
3. A specific due date is invented ("by Friday") when the notes gave none.
4. "soon" / "next sprint" is silently converted into a concrete date.
5. Two commitments in one sentence are merged into a single row with a muddled owner.
6. A decision with no follow-up ("we agreed on option B") is logged as an action item.