From Meetings to Action

From Meetings to Action: The Commitment Tracker

Your meetings end. Your action items shouldn't disappear.

A one-day, no-code class in which you build a machine inside ChatGPT or Claude that turns a meeting into owned, dated, sourced action items, puts them on the board your team already uses, chases them, and writes the Friday status report from what actually happened. You build it on your own meeting, run it on the next one, then build a second machine for a different kind of conversation without help.

Part of AI at Work. Every machine in the series starts with a Spec Card.

Who this is for

• You run meetings and you're the one who remembers. The team lead, chief of staff, project manager, organiser, department chair: whoever ends up texting "hey, did that ever happen?" three weeks later.
• You sit in meetings where things get decided and then evaporate. Boards, councils, committees, steering groups, union locals, PTAs.
• You already paste transcripts into a chatbot and get back a summary. A summary isn't a record. Today you build the record.

The tracker doesn't replace the conversation, and it doesn't decide who does what. People decide. The tracker makes sure nobody has to rely on their memory to find out whether they did.

The machine you leave with

The Commitment Tracker

INTAKE      STRUCTURE       CHECK          GATE           ACT        LEDGER           RHYTHM
transcript → decisions,  →  hand-marked →  each owner  →  your    →  board history → weekly, a
of your      action items,  span check,    confirms      board      + decision log   scheduled
meeting      questions,     zero invented  their own     (update,   + Friday report  task
             parked items   owners         item          don't      from board state
             quoted to                                   duplicate)
             the transcript

It lives in a ChatGPT Project (or custom GPT) or a Claude Project: spec card and rules in its instructions, the transcripts in its files, memory switched on deliberately, and a connector (or a CSV) to the board you already use. It writes only to where your work already lives. You won't maintain a new document.

Metaphor for the day, and for the atlas: the harbour. Talk arrives as ships. The manifest is the record. Customs is the human gate. The warehouse is the board. Dispatch sends the follow-ups. The harbour log is the status report.

Why this rung

Most people use AI one question at a time: they ask. Organisations with engineers have already moved on to running it. In Anthropic's Economic Index, 77% of enterprise API transcripts were automation (as of Sep 2025), and scheduling and meeting coordination shows up mainly as API automation (as of Jan 2026). Management tasks were about 5% of Claude.ai use (as of Mar 2026). This class hands you the third rung, a recurring machine with a human gate, without an engineer.

The day

10am–4pm, with lunch. Remote or in the room.

Every prompt of the day is on the Prompt Cards, in order. If you can't bring a meeting, use the Practice Pack: two real Austin City Council meetings, two days apart, with published transcripts.

Standards

Capability ids from the school's capability map. Only assessed counts toward a credential, and assessed means the artifact gets produced and the facilitator looks at it.

Portfolio: one link, five boxes

Submit one link: your shared custom GPT, or your shared Claude Project, or an artifact of it. Include the board or sheet it writes to if you can share that. The facilitator checks five things against that link:

• [ ] Spec card present at the top of the instructions
• [ ] Two real runs visible (meeting one and meeting two, or the practice pack pair)
• [ ] One failure the check caught: an invented owner, a duplicate, a missing item. Show it.
• [ ] The human gate named: which human signs before anything leaves, by name or role
• [ ] A second machine for a different case (the Block 6 thread tracker)

No quiz. No reflection essay. If the machine works and the check caught something, you've shown everything this class teaches.

Prerequisites

• No code. None at any point.
• A ChatGPT or Claude account. Free tiers carry Blocks 1–3 (Projects, files and instructions, as of Nov 2026). Connectors that write to a board, and scheduled tasks, generally need a paid plan. If you're on a free tier, Block 4 uses the CSV path and Block 6 uses a calendar reminder instead of a scheduled task. It's the same machine with a manual last step.
• A board, sheet or tracker your team already uses: Asana, Trello, Notion, GitHub Projects, Jira, Linear, Monday, or a Google Sheet. Bring a login, and permission to add a test list or column.
• A meeting transcript you have consent to use, and ideally the next meeting of the same group. Read "Getting the transcript of your own meetings" in the Practice Pack first. If you can't bring one, the practice pack is two real public meetings.
• Helpful: one long email or Slack thread with decisions buried in it, for Block 6.

What it replaces

This class is one of five that replace Using Large Language Models. The ULM foundations are still here, pointed at a real job:

• 1.3 LLM Advanced Setup and Ethics: custom instructions, memory settings, human-in-the-loop, privacy, now the spec card and the gate (Block 1).
• 1.4 LLM Assistant Onboarding Process: the flipped interaction, now the Project interviewing you about your team, board and cadence (Block 1).
• 2.4 LLM Projects and Context Management: Projects vs memory vs temporary chats, the needle in a haystack, now a 30,000-word meeting where item 57 hides (Blocks 1, 5).
• Exercise 2.4 Data Extraction and Structured Information: fields fixed first, now an action-item record quoted to its source (Block 2).
• 2.1 LLM Critical Thinking Vocabulary: "good is not a quality," now the check you can count (every block).
• 2.2 LLM Expert Business Analysis: the bell hooks / Emma Goldman perspective pass, now aimed at the tracker itself: who it makes visible, and who it might surveil (Blocks 3, 5).
• Daily Practice Protocol: the morning triage and portable summary, now a weekly rhythm with a scheduled task (Block 6).

ULM's health, affective-use and values material isn't part of this class. It went to Build Your Personal Life System.

How it differs from the classes next to it

• Automate Your Email moves information between inboxes and tools. This class manages commitments: who promised what, by when, and whether it happened.
• Turn Documents into Working Systems tracks obligations in documents. This one tracks the promises people make out loud.

Related

• AI at Work - Series Overview · Spec Card · Prompt Cards · Practice Pack
• Atlas: /x/ai-at-work-meetings-map, with one district per block

Last updated: November 2026. Product features are described as of Nov 2026, and facilitators re-check them before every run.

↑ Contents

Block 1: Set Up the Machine Room

Time: 10:00–10:50 · Harbour: the harbour office, where the rules are posted before any ship comes in Atlas: /x/ai-at-work-meetings-map#d-office Back to: From Meetings to Action Syllabus

What you'll have at the end of it

• A ChatGPT Project (or custom GPT) or a Claude Project named for one recurring meeting, e.g. Tracker: Tuesday Ops
• Your spec card at the top of its instructions, written from an interview the Project ran on you
• A RULES block under the card that every later block adds to
• Memory set on purpose: on for this Project, off for what doesn't belong
• Your first transcript in its files, or the Practice Pack's October 21 transcript

ULM foundations reused here

• 1.4 LLM Assistant Onboarding Process: the flipped interaction. "Instead of trying to figure out what to tell your AI assistant, get it to interview you."
• 1.3 LLM Advanced Setup and Ethics: custom instructions, memory settings, temporary chats, human-in-the-loop validation, and never putting other people's private information in without consent.
• 2.4 LLM Projects and Context Management: memory vs Projects vs new chats. One meeting series = one Project.
• 2.1 LLM Critical Thinking Vocabulary: "good" isn't a check. Name the thing you'll count.

The idea

Think of the last meeting where somebody said "great, let's do that." Who was "us"? When was "that" due? Did it happen?

Right. Nobody knows, and that's not a character flaw in your team. Meetings make commitments out loud, and out loud doesn't persist. The minutes, if anyone takes them, record the topics, not the promises. Two weeks later the only record of who said they'd do what is whoever remembers.

So the tracker isn't a summariser. A summary describes the meeting back to you. The tracker produces a record: rows whose fields you fixed before you read anything. It checks that record against the transcript, has each person confirm their own item, and puts it where the work already lives.

Before it touches a transcript, the machine needs to know its job. The Spec Card is that job in seven slots: intake, structure, check, gate, act, ledger, rhythm. You don't write it from scratch. You make the Project interview you, because you know your team's Monday better than any template does, and the details only come out when someone asks.

Worked example: the practice pack's spec card

The Practice Pack meeting is the Austin City Council work session of 21 October 2025. Here's the card a facilitator built for it from a five-minute interview:

SPEC CARD: Austin City Council tracker (practice)
Intake:    The published transcript of each council meeting (work session Tuesday,
           regular meeting Thursday), from the meeting page on austintexas.gov.
Structure: ID · Type (DECISION/ACTION/QUESTION/PARKED) · What · Owner · Due ·
           Status · Source quote · Where (timestamp) · Confidence
           (fields fixed; never add or rename a field)
Check:     I hand-mark the transcript for 10 minutes first, then count misses and
           inventions. Every owner and date must be in a quote.
Gate:      Me (the facilitator) approves every board change. Owners confirm their
           own items. In practice, drafts only: we never contact city staff.
Act:       A Trello board "Austin practice", lists: Needs an owner · Owned · Done
Ledger:    Trello card history + a decision log card + each Friday report
Rhythm:    After each meeting's transcript is posted; Friday report every Friday.
           If a week has no run, the Friday report says so.

Notice the gate. "Someone reviews it" is how nobody reviews it, so it names a person.

Exercise (35 minutes)

1. Make the Project (5 min)

• ChatGPT: sidebar → New project. Name it Tracker: <your meeting>. If it asks about memory, choose project-only memory, so the tracker remembers your team's names and your board but doesn't carry them into your other chats (as of Nov 2026).
• Claude: Projects → Create project. Name it the same. Claude's memory, where your plan has it, is kept per project (as of Nov 2026).
• Custom GPT instead (ChatGPT): Explore GPTs → Create. A custom GPT is easier to share for the portfolio, but it has no project memory. Pick one and stay with it.

Don't upload a transcript yet. The interview goes first, so the machine learns your world before it sees your data.

2. Make it interview you (12 min)

Paste this into a chat inside the Project:

You're going to become my Commitment Tracker: you'll turn the transcript of a
recurring meeting into owned, dated, sourced action items, put them on the board
my team already uses, chase them, and write a Friday status report from the board.

Before you do anything, interview me. Ask ONE short, specific question at a time,
at least five and no more than twelve. Cover: who is in this meeting and what each
person owns; where our work actually lives (which board, which lists or columns);
how we name and date things; what "done" means here; who must approve anything
before it leaves; what must never go into a tracker; and when the meeting happens.

Don't summarise, don't suggest features, and don't start working until I type
"build the card".

Answer by voice if you can. The microphone in either app is faster than typing and you'll say more. Be specific: "Priya owns vendor contracts and hates being tagged on Fridays" is more useful than "we have a small team."

3. Build the card (8 min)

build the card

Write my spec card in exactly these seven slots: Intake, Structure, Check, Gate,
Act, Ledger, Rhythm. Use only what I told you. Where I didn't tell you something,
write UNKNOWN and the question you'd need answered. Don't fill any gap with a guess.
Structure must be a fixed list of fields. Check must be something I can count.
Gate must be a named person.

Fix the card yourself. You're the authority on your team, so the card says what you say. Any UNKNOWN is a real gap in how this meeting runs, with or without AI.

4. Put it in the instructions (10 min)

Open the Project's instructions (ChatGPT: the project's ⋯ menu → Instructions; Claude: Project instructions / Set project instructions). Paste the card, then this RULES block under it:

RULES
1. Never invent an owner, a date or a decision. If the transcript doesn't say it,
   the field says "not stated" and the item goes on the question list.
2. Every item quotes the transcript: exact words, plus the timestamp or line.
3. Draft only. Nothing is sent, posted or changed anywhere until <GATE NAME> says
   yes to that specific change.
4. Dates are absolute (2025-10-23), never "Thursday" or "next week". Convert
   relative dates from the meeting date, and show the conversion.
5. Fields are fixed. Never add, rename or drop a field.
6. End every run with the items you're least sure of, and why.

Now add the transcript to the Project's files (ChatGPT: Add files; Claude: Project knowledge → Add content). Read the consent section of the Practice Pack before uploading anything from your own job.

The check

Open a new chat in the Project and type: Here's this week's meeting. Go., without attaching anything.

A machine that knows its job asks before it acts. Count its questions before it produces anything: which meeting? which date? is the transcript the one in files?

• Five or more questions, or a refusal to proceed until something's settled = pass.
• Fewer than five: it guessed. Read what it guessed, add a rule that forbids that guess, and run the check again.

Second count, on the card: the seven slot names are all present, and none of these appear in it: someone, the team, looks right, good, as needed. Any hit is a slot you haven't actually filled.

Common failures and what they look like

• The interview asks "What are your goals?" That's a broad question. Say "smaller, please: one question about the board" and it'll recover.
• The card's Structure slot says "a summary of key points." That's a summary, not a record. Fields are nouns you could make column headers from.
• Gate = "the team reviews." That's nobody. Pick a name.
• Memory soaked up something it shouldn't have. Open memory (ChatGPT: Settings → Personalization → Manage memories; Claude: Settings, then the project's memory view, as of Nov 2026) and delete it. Then add "Never store personal details about colleagues" to RULES.
• You uploaded the transcript first. The model reads the meeting and builds the card around it: fields picked after looking at the source. Delete the chat and re-run the interview.

Facilitator note

• Timing: 5 min "what does your Monday actually look like?" before any screen-share, 35 min exercise, 10 min the check plus a pair-share.
• Open with the students, not the tool. Ask two or three people: what happens to an action item in your world after the meeting ends? Their answers are the class's material. They're the authorities on their own work, and the tracker is only as good as what they know about it.
• Watch for people skipping the interview because "I already know what I want." Point at their UNKNOWN slots.
• Think-pair-share: "Read your partner's Gate slot aloud. Is that a person? Would they say yes if you asked them today?"
• Re-check before class: every menu path above is as of Nov 2026. Project memory scope, instructions location and free-tier Project limits change often, so click through both products the morning of.
• Practice-pack people use the worked example card above as a model, but they still run the interview, answering as if they were the council clerk.

↑ Contents

Block 2: Pull the Commitments Out

Time: 11:00–11:50 · Harbour: the manifest. Every crate that came off the ship gets listed, with where it came from Atlas: /x/ai-at-work-meetings-map#d-manifest Back to: From Meetings to Action Syllabus

What you'll have at the end of it

• One table for one real meeting: every decision, action item, open question and parked item, each quoted to its transcript span
• Your own ten-minute hand-mark of the same transcript
• Two numbers: misses (you marked it, the machine didn't) and inventions (the machine has it, the transcript doesn't)
• The extraction prompt saved as the Project's standard run

ULM foundations reused here

• Exercise 2.4 Data Extraction and Structured Information: fields first, then extraction, then "what was missed? what was extracted that wasn't relevant?" This block turns those two questions into two counts.
• 1.3 LLM Advanced Setup and Ethics: "Prevent hallucination: cite sources and verify at least one claim." Here every row cites, and you verify by hand.
• 2.4 LLM Projects and Context Management: the needle in a haystack. The ghost commitment is usually one sentence in the middle.

The idea

Paste a transcript into a chatbot and type "what are the action items?" and you get a tidy bulleted list. It reads well. It's also impossible to check, because it doesn't tell you where any of it came from, so you either trust it or you re-read the whole meeting. Neither is a system.

So, two moves.

Fix the fields before you read. If the model picks the columns after it sees the meeting, it describes the meeting back to you. You picked the fields in Block 1, so the model fills them or says "not stated."

Every row carries its receipt. The exact words from the transcript, copied rather than paraphrased, plus the timestamp. Now checking a row takes Ctrl-F, not a re-read. The quote is also what lets you catch the model inventing things, and it will, because filling in a plausible owner is exactly what a helpful text predictor does.

Then you check it against the one instrument you trust: you, reading the transcript for ten minutes.

Worked example: Austin, 21 October 2025

The practice transcript is about 2,170 words. Hand-marking it takes about eight minutes. A careful run returns rows like these (quotes copied exactly, including the captioner's errors):

And here's what a typical first run does wrong. This is illustrative, and yours will differ, but these three failures turn up again and again:

• Invention: M1-02 · Owner: Joy Hardin · Due: 2025-10-23. The date was borrowed from the auditor sentence six minutes earlier. The name is the captioner's spelling. The minutes say Joi Harden.
• Invention: ACTION · Applicant submits PUD application, from "the applicant may submit their actual pud application." May isn't a commitment, and the applicant isn't in the room.
• Miss: M1-05, Velasquez's preference, left out because it doesn't look like a task. It isn't one, and it still belongs in the record as PARKED, attributed. Otherwise next month nobody can show she said it.

Hand-check result for that run: 1 miss, 2 inventions, 1 wrong name. That's what the check is for.

Exercise (40 minutes)

1. Hand-mark first (10 min, timer on)

Before the machine sees anything, open the transcript and mark it yourself, in the PDF or on paper: D decision, A action, Q open question, P parked. Ten minutes, then stop wherever you are. If your transcript is long, mark the first ten minutes' worth and tell the machine to do the same span.

You go first because once you've seen the model's list you can't un-see it. You'll start agreeing with it.

2. Run the extraction (10 min)

Attach the transcript (or point at it in the Project files) and paste:

Run the tracker on the attached transcript. Meeting: <name>, date <YYYY-MM-DD>.

Output ONE table with exactly these columns, in this order:
ID | Type | What | Owner | Due | Status | Source quote | Where | Confidence

- Type is one of: DECISION, ACTION, QUESTION, PARKED.
- ID: M1-01, M1-02 … (M1 = this meeting).
- Owner and Due: only if the transcript says them. Otherwise write "not stated".
- Status: "new" for everything in this run.
- Source quote: the exact words from the transcript, at most 30 words, copied,
  not paraphrased, including any transcription errors.
- Where: the timestamp in square brackets nearest before the quote.
- Confidence: high / medium / low; for medium or low, one sentence on why.

Under the table write "Least sure of:" and the three rows a human should check first.
Don't summarise the meeting.

If the output drifts (extra columns, paraphrased quotes, a summary on top), change the prompt, not the task. Tighten the wording, add an example row, say "copied, character for character." Keep revising until the output is the table you specified. That's the skill.

3. Verify the receipts (10 min)

For every row, Ctrl-F three or four distinctive words of its quote in the transcript.

• Found, and it says what the row says → ✓
• Found, but the row adds an owner or date the quote doesn't contain → invention
• Not found → invention (a paraphrase dressed up as a quote counts)

Then compare against your hand-mark. Anything you marked that has no row is a miss.

4. Save the run (10 min)

Once the prompt produces the right table, add one line to the Project instructions under RULES: 7. "Run the tracker" means: <paste the extraction prompt>. Next week you type "run the tracker" and attach the file.

The check

Write these numbers at the bottom of the chat where the run lives, so they stay visible in the Project:

Hand-check, <meeting>, <date>
Rows: __   Quotes found verbatim: __ / __
Misses (I marked, it didn't): __
Inventions (owner/date/item not in a quote): __

There's no passing score. The numbers are the result. A first run with zero misses and zero inventions on a real meeting is rare. If you got that, mark a second ten-minute stretch and look again. Every invention you found becomes a rule in Block 3.

Common failures and what they look like

• Quotes that are too clean. Real transcripts say "a fee. And Lou." A quote that reads like polished prose has been paraphrased. Ctrl-F won't find it.
• The "Where" column is the start of the meeting for every row. Ask for the nearest timestamp before the quote, and spot-check two.
• Everything is an ACTION. "I would like to see that increase" isn't a task. If PARKED and QUESTION are empty, the types aren't being used.
• The long-meeting fade. On a two-hour meeting, rows thin out after the first hour. That's the needle in the haystack. Run it in halves, by timestamp, and merge.
• No speaker names. Many auto-transcripts (Austin's included) don't label speakers. The owner is then inferred from context, and an inference isn't an owner. Block 3 is about exactly this.

Facilitator note

• Timing: 5 min idea, 10 min hand-mark (strict timer, everyone at once), 10 min run, 10 min receipts, 5 min save, 10 min share counts.
• Watch for people running the machine before hand-marking "just to see." Ask them to do the hand-mark on a different ten-minute stretch so the comparison is still fair.
• Collect the room's invention counts on the board, anonymously. A wall of 1s, 2s and 3s does more than any slide to make "always check" feel normal instead of paranoid.
• Think-pair-share: "Swap tables with your partner. Pick their highest-confidence row and Ctrl-F the quote. Did it hold?"
• Re-check before class: PDF reading in both products, and any Project-file size limits (as of Nov 2026).

↑ Contents

Block 3: Catch the Ghost Commitments

Time: 12:00–12:50 · Harbour: customs. A crate with no name on it doesn't get signed out to whoever's standing nearest Atlas: /x/ai-at-work-meetings-map#d-customs Back to: From Meetings to Action Syllabus

What you'll have at the end of it

• Ambiguity rules written into the Project instructions
• The meeting re-run under those rules, with every row classified owned, ambiguous or parked
• A question list: one sentence per ambiguous item, addressed to the person who can answer it
• "Confirm your own item" drafts, one per owner, unsent
• A critic pass on the record, aimed at power

ULM foundations reused here

• 2.1 LLM Critical Thinking Vocabulary: precision. "Soon" and "someone" are the "make it better" of meetings: words that sound like content and carry none.
• 1.3 LLM Advanced Setup and Ethics: challenge sycophancy, and the human-in-the-loop. The model wants to give you a complete-looking table, and completeness is how owners get invented.
• 2.2 LLM Expert Business Analysis: the bell hooks / Emma Goldman multi-perspective pass, pointed here at the tracker itself.

The idea

Listen for these in your next meeting:

"We should look into that." · "Someone needs to call them." · "Let's circle back next week." · "I could look it up." · "We'll get you something."

Every one sounds like a commitment and none of them is one. There's no person, no date, or no actual promise ("could" isn't "will"). These are ghost commitments. Most meetings have more of them than real ones, and they're where follow-through goes to die.

Now hand that sentence to a model whose whole job is producing a complete-looking table. It sees "I could look it up," sees the presenter's name two minutes earlier, sees "Thursday" in another paragraph, and writes Owner: Joy Hardin · Due: Thursday. That row is tidy, confident and invented. Put it on a board and Joi Harden now has a task she never agreed to and a deadline nobody set, and on Friday she shows up in "what slipped."

So the rule is simple and it's not negotiable: ambiguity goes to a question, never to an invented owner. An owner is someone who accepted the item in their own words. Being asked isn't accepting. Being in the room isn't owning.

Three bins:

• Owned: a named person accepted it, and it's in a quote.
• Ambiguous: it might be a commitment, but who or when or whether isn't said. → the question list.
• Parked: raised, and explicitly not being acted on now, or waiting on something outside this group. → the record, with what it waits on.

Worked example: Austin's five

Under the rules below, the re-run has 0 invented owners and 0 invented dates. The table got shorter on owners and longer on questions. That's the right direction.

Exercise (40 minutes)

1. Write the ambiguity rules in (10 min)

Add this under RULES in the Project instructions, then edit it with the ghost phrases your team actually uses. Every team has its own: "I'll take a look," "let me socialise that," "ping me."

AMBIGUITY RULES
A. Ghost words: "we should", "we need to", "someone", "somebody", "let's",
   "circle back", "I could", "I can try", "maybe", "at some point", "soon",
   "next week" (no day). An item with these is AMBIGUOUS unless the same speaker,
   in the same passage, names a person and a date.
B. An owner is a named person (or a role held by one person) who accepted the
   item in their own words. Being asked is not accepting. Being in the room is
   not owning.
C. If the transcript has no speaker labels, an owner worked out from context is
   written "inferred: <name> (because <evidence>)" and the item is AMBIGUOUS
   until that person confirms.
D. "Next week", "soon", "Thursday": convert from the meeting date and show the
   conversion; if you can't convert it to one calendar date, Due = "not stated".
E. Every AMBIGUOUS item gets one question on the QUESTION LIST, addressed to the
   person who can answer it, in one sentence.
F. PARKED = raised, explicitly not acted on now, or waiting on something
   outside this group. Say what it waits on.
G. A preference ("I'd like to see...") is not a commitment. It is PARKED,
   attributed to who said it.
H. Never resolve ambiguity by choosing the most likely person. Ask.

2. Re-run and classify (10 min)

Re-run the tracker on the same transcript under the AMBIGUITY RULES.
Add a column "Bin" (OWNED / AMBIGUOUS / PARKED) and, for every OWNED row,
a column "Accepted in" that quotes the words in which the owner accepted.
Then write the QUESTION LIST: one line per AMBIGUOUS row,
"<ID> → <person who can answer>: <one-sentence question>".
List every row whose Owner or Due changed from the previous run, and why.

(Adding two columns is the one sanctioned change to the fields. Put "Bin" and "Accepted in" into the Structure slot of your spec card now so the fields stay fixed from here on.)

3. Draft the confirmations (10 min)

This is the gate. Each owner confirms their own item. You don't confirm it for them, and neither does the machine.

For every OWNED row and every AMBIGUOUS row with an inferred owner, draft a
message to that person, from me. Two to four sentences: quote what they said
and when; state the item as recorded (what, due); ask them to reply with
"yes", "yes, but <correction>", or "not mine". Plain and friendly, no
pressure, no exclamation marks. Don't send anything. One list, grouped by person.

Read every draft. Would you be glad to receive it? Send the real ones yourself, from your own email or chat, after class or whenever your team's norms say. Practice pack: these stay drafts. Don't contact Austin city staff.

4. Point the critics at the tracker (10 min)

Read the record and the question list as three people, two sentences each:
(1) the most junior person named in it; (2) a union steward; (3) bell hooks.
Each answers: who does this record make more visible, whose offhand words got
turned into obligations, and who might use it to watch people rather than to
help them? Then propose ONE change to the RULES, not to the people.

Take the rule change seriously. A tracker that records every "I could" as a debt makes people stop saying "I could," and then your meetings get worse. A tracker that only ever shows the same three names in "slipped" turns into a performance file. You decide what goes in it, so decide on purpose.

The check

Zero invented owners. Zero invented dates.

Go row by row. For every row where Owner isn't "not stated": open the transcript at the "Accepted in" quote. Did that person say, in their own words, that they'd do it? For every Due that isn't "not stated": is that date in a quote, or converted from one with the conversion shown?

Ghost check, <meeting>, <date>
Rows with an owner: __   Owner accepted in a quote: __   Invented owners: __
Rows with a due date: __   Date in a quote or a shown conversion: __   Invented dates: __
Ambiguous rows: __   Each has a question: yes / no

Any invented owner or date → find the sentence it was built from, add a rule that names that pattern, re-run, re-count. The block's done when both invented counts are 0, not before.

Common failures and what they look like

• The model "helpfully" resolves the ambiguity. Owner: Joi Harden (most likely). Rule H exists for this. If it persists, add the exact failing row to the rules as a counter-example: "Not like this: …".
• Everything becomes AMBIGUOUS. Overcorrection. "On Thursday we will take up" has a clear owner, the body, and a date. Ambiguity means missing, not imperfect.
• Questions addressed to "the team." A question needs a person who can answer it. If you don't know who, the question is for you: find out.
• Confirmation drafts that sound like a summons. "Per the meeting, you are responsible for…" Nobody says yes to that. Rewrite in your own voice. The machine drafts and you sign.
• Skipping the critic pass because "my team is nice." The tracker outlives the current team and the current manager. Write the rules for the version of your org you're worried about.

Facilitator note

• Timing: 5 min "listen for these" (read the ghost lines aloud and let the room laugh in recognition), 35 min exercise, 10 min the check in pairs.
• Watch for people treating "inferred" as good enough. The Austin case is perfect here: the transcript genuinely has no speaker names, and the owner's name in the transcript is misspelled. An inferred, misspelled owner is two errors in one cell.
• The power conversation: don't preach it, ask it. "Whose name shows up most on your board? Is that because they do the most, or because they talk the most in meetings?" Let the room answer. People who work in unions, nonprofits or public bodies will have strong, specific answers, and they're the authorities here.
• Think-pair-share: "Read your partner one row you binned AMBIGUOUS. They argue it's OWNED. Who wins, and which quote settles it?"

↑ Contents

Block 4: Put It on the Board

Time: 1:30–2:20 · Harbour: the warehouse. Every crate gets a bay, and the next ship's crates go into the bays that already exist Atlas: /x/ai-at-work-meetings-map#d-warehouse Back to: From Meetings to Action Syllabus

What you'll have at the end of it

• A field map: tracker fields → your board's fields, with the tracker ID somewhere the board keeps and you can search
• Meeting one's confirmed and owned items on your real board (a test list is fine), by connector or CSV; ambiguous ones in a separate Needs an owner list, not assigned
• One written line on what you connected and what it can now read and write
• Meeting two run against the board as a change set: updates to existing items, then genuinely new ones
• After two meetings: no duplicates

ULM foundations reused here

• 1.3 LLM Advanced Setup and Ethics: human-in-the-loop for anything with consequences. A board change is a consequence, because it lands in somebody's notifications.
• 2.4 LLM Projects and Context Management: what lives in the Project (rules, transcripts) vs what lives outside it (the board). The board is the source of truth for status, and the Project's chats aren't.
• Exercise 2.4 Data Extraction and Structured Information: "create consistent data formats." This is the step where the format meets somebody else's system.

The idea

A record nobody looks at is a diary. The record has to land where your team already looks: the Asana project, the Trello board, the Notion database, the GitHub project, the sheet. Not a new doc. Not "the tracker." If your team has to remember to check a second place, they won't, and they shouldn't have to.

Two pipes go into the warehouse:

• A connector (violet on the atlas): ChatGPT or Claude reads and, sometimes, writes your board directly. It's convenient, and it's also a door you opened. Know what it can do.
• A CSV (blue): the machine writes a file, you import it. It's slower, works on every plan, and has a human gate built in, because nothing happens until you click Import.

Then the hard part, the one that makes or breaks every tracker after week two: meeting two talks about meeting one's items. "The auditor thing passed." If the machine adds a new card for that, your board has two cards for one commitment, one of them wrong, and by week four nobody trusts any of it. So the rule is update, don't duplicate. Every item keeps its ID for life, and the second run starts by reading the board, not the transcript.

Worked example: Austin, meeting two (23 October 2025)

The board after meeting one has M1-01 (council takes up the auditor item, due 2025-10-23) in Owned, and M1-02 and M1-03 in Needs an owner. Meeting two is a 30,000-word regular meeting. The right change set:

Three traps in that one meeting:

1. The 56/57 slip. The mayor first says "Item number 56 is the item in which we will, if passed … direct that the search firm," then corrects himself: "Did I read the wrong read it wrong 57." Item 56 is actually a fee waiver for a music event. A machine that doesn't check the board can create NEW: Item 56: auditor search firm: a duplicate and a wrong number.
2. "Done" means the step, not the story. The resolution authorizes negotiation with the finalist. Nobody has been hired. Done: city auditor hired overstates what was said. Status changes must match what was said, word for word.
3. Silence isn't completion. Nobody mentions the East Riverside cost lookup. The tempting move is to close it ("not raised, presumably resolved"). The right move is NO MENTION, which shows up in Friday's report as no update since 2025-10-21.

Exercise (40 minutes)

1. Map the fields (8 min)

Export one item from your board (or copy the column names) and paste:

Our board is <tool>. Its fields / columns are: <paste names, or a CSV header row>.
Map the tracker's fields onto them, as a two-column table: tracker field → board
field, or "no home: goes in the description". The tracker ID must go somewhere
the board keeps and I can search: a title prefix like [M1-02] or a custom field.
Bin decides the list/column: OWNED → <list>, AMBIGUOUS → "Needs an owner",
PARKED → <list or "description of a single Parked card">. Don't create anything.

Add the mapping to the spec card's Act slot.

2. Pick a pipe and write meeting one (15 min)

Connector path (paid plans, as of Nov 2026, so check your tool's connector exists and can write, because some are read-only): - ChatGPT: Settings → Apps / Connectors, connect your board's tool, then enable it in the Project chat. - Claude: Settings → Connectors, connect it, then turn it on from the chat's tools menu.

Using the <tool> connector, show me exactly the cards you would create: title
(with [ID] prefix), list, assignee, due date, description (with the source quote
and timestamp). As a table. Create NOTHING until I reply "yes <ID>" for each row.
Ambiguous items go to "Needs an owner" with no assignee and no due date.

CSV path (every plan):

Produce a CSV for import into <tool> with exactly these headers: <headers>.
One row per item. Title starts with [ID]. AMBIGUOUS rows have an empty assignee
and empty due date and go to the "Needs an owner" list. Description holds the
source quote and timestamp. Give it to me as a downloadable file.

Most boards import CSV (some only on paid tiers). If yours doesn't, use a Google Sheet tab as the board for today. It's still one place.

Then write the access line in the Project instructions under the card. This is the memory-and-connections standard, and it's one sentence:

ACCESS: Connected <tool> via <connector/CSV> on <date>. It can read <...> and
write <...>. Memory is <on/off> for this Project and holds <...>.
To revoke: <exact settings path>.

3. Run meeting two against the board (12 min)

Give it the board (connector, or a fresh CSV export) and the second transcript:

Here is the current board (<connector / attached export>) and the transcript of
the next meeting, <date>. Do this in order:
1. For EVERY item already on the board, decide: UPDATED (the meeting says
   something new about it: quote it), NO MENTION, or CLOSED (only if someone
   said it's done: quote it). Silence is NO MENTION, never CLOSED.
2. Then list NEW items from this meeting with fresh IDs (M2-01...). Before
   calling anything NEW, search the board for an item about the same thing.
   If one exists, it's an UPDATE to that ID, not a new item.
3. A status may only change to words the quote supports. "Authorized to
   negotiate" is not "hired".
Show the change set as one table: ID | change | old → new | quote | where.
Change nothing until I approve each row.

4. Approve, apply, look (5 min)

Approve row by row. Apply. Then open the board itself, not the chat, and look at it.

The check

After two meetings: no duplicates, and every status change matches what was said.

On the board, not in the chat:

Board check after meeting two
Cards: __   Distinct commitments (by your reading): __   Duplicates: __ (target 0)
Status changes this run: __   Each backed by a quote that says that status: __
Items closed by silence: __ (target 0)

To count duplicates, sort by title and skim, or use the Atlas bench, which flags look-alike titles in a pasted export. Any duplicate → find which instruction let it through (usually step 2 above was skipped), tighten it, re-run on a copy.

Common failures and what they look like

• The ID didn't survive the import. The board dropped your custom field and the second run can't match anything, so everything becomes NEW. Use the title prefix [M1-02]. Boards keep titles.
• Assigning the ambiguous. The CSV puts M1-02 on Joi's plate because the column was there. Ambiguous rows have empty assignee and due. That's the whole of Block 3.
• The connector wrote first and showed you after. That's a gate failure, not a tool quirk. Put "Create NOTHING until I reply yes " back in the prompt and in RULES, and turn off the connector's auto-actions if your product has that setting.
• "Done" for a step. Read the quote back. Does it say done, or does it say authorized, scheduled, discussed, sent to committee?
• Over-granted access. You connected all of Google Drive to get one sheet. Narrow it, or move the sheet. Write what it can read in the ACCESS line, because writing it down is how you notice.

Facilitator note

• Timing: 5 min idea, 8 field map, 15 first write, 12 meeting two, 10 the check and debrief.
• Free-tier students do the CSV path, and it's not second-best. Many teams prefer it for the built-in gate. Say so.
• Have a sandbox ready: a public Trello board or a shared Google Sheet with Owned / Needs an owner / Parked / Done columns, for anyone whose employer won't allow a test list.
• Watch for the 56/57 trap in the practice pack. Ask who got a card mentioning item 56. Whoever did found the best failure of the day. Celebrate it, because that's the "one failure the check caught" box on their portfolio.
• Think-pair-share: "Project your board. Your partner points at one card and asks 'which sentence moved this?' Can you find it in under a minute?"
• Power, briefly: a board with names, due dates and red "overdue" markers is a performance record whether you meant it to be or not. "Who can see this board? Would you be fine with your boss's boss reading every row of it?"
• Re-check before class: which board tools have write connectors in each product and on which plans (as of Nov 2026), and where connector permissions are managed.

↑ Contents

Block 5: Run It Twice and Write the Friday Report

Time: 2:30–3:20 · Harbour: dispatch and the harbour log. Messages go out to whoever's crate is waiting, and the log says what actually moved Atlas: /x/ai-at-work-meetings-map#d-log Back to: From Meetings to Action Syllabus

What you'll have at the end of it

• The machine's second real run finished end to end, with the gate exercised: every change approved by you, every owner's reply applied
• A decision log: what was decided, by whom, when, from which source, and what was known at the time
• Follow-up drafts for what's due soon or slipping, written from the board
• The Friday report, generated from board state, in three cuts: team, exec, stakeholders
• Every claim in it pointing at a board item, with a "what slipped" section

ULM foundations reused here

• 2.4 LLM Projects and Context Management: the context summary pattern ("key decisions, current status, open questions, next steps"), now drawn from the board instead of from a chat's memory.
• 2.1 LLM Critical Thinking Vocabulary: precision and accuracy. "Making good progress" isn't a status. A report sentence either points at an item or it's decoration.
• 2.2 LLM Expert Business Analysis: multiple perspectives, now as three audiences reading the same facts.
• Daily Practice Protocol: the end-of-session portable summary, turned weekly and pointed at a team.

The idea

Here's how most status reports get written: Friday at 4pm, someone scrolls Slack, remembers the meeting, and writes what it felt like happened. It's optimistic, because the things that went well are the things you remember. What slipped is quietly absent.

If you hand that habit to a model ("summarise this week's meeting into a status report"), you get the same optimism, fluently. The meeting is what people said. The board is what's true now: who confirmed, what moved, what nobody touched.

So the Friday report is generated from board state, not from the meeting. Every sentence that states a fact ends with the ID it came from. If a sentence can't point at an item, it's either a missing item (add it) or a sentence that shouldn't be there. And "what slipped" is a required section, even if it says "none." Leaving it out is the optimism.

Next to the report sits the decision log. Action items are about doing. Decisions are about what's now settled. In six months someone will ask "who decided that, and did they know about X at the time?" The log answers in one row.

Worked example: Austin, Friday 24 October 2025

Decision log, row one

The Friday report (team cut)

Austin practice board · week of 2025-10-20 · generated from the board 2025-10-24

DONE THIS WEEK
- Council authorized negotiation with the City Auditor finalist
  (Res. 20251023-057). [M1-01, D-01]

MOVING
- none

WHAT SLIPPED
- Cost of the development-assessment process for the East Riverside PUD,
  offered 10-21 ("I could look it up and get it back to you"): no owner
  confirmed, no update in 3 days. [M1-02]

WAITING ON A QUESTION
- A shorter "partial check-in" process for development assessments: who
  brings it, and as what? [M1-03]

PARKED
- Fee in lieu amount: waits on the applicant's site plan. [M1-04]
- CM Velasquez wants more than 15 affordable units. [M1-05]

DECISIONS THIS WEEK
- D-01 (above).

Seven sentences, seven IDs. M1-02 is in "slipped," not because Joi Harden failed at anything, but because the tracker never got an owner confirmed. That's why the slip is worded as a fact about the item, not the person.

Exercise (40 minutes)

1. Close the gate from Block 3 (5 min)

Owners have replied to your confirmations (or, in the practice pack, decide as a pair what each "owner" would plausibly say). Apply the replies:

Here are the owners' replies to the confirmation messages: <paste>.
For each: "yes" → Bin OWNED, Status confirmed. "yes, but <x>" → apply x, quote
the reply. "not mine" → back to AMBIGUOUS with a new question. No reply →
unchanged, and note the date asked. Show the change set; change nothing until I approve.

2. Build the decision log (10 min)

From the board and both transcripts, build the DECISION LOG:
ID | Decision (in the decider's words where possible) | Who decided (body or
person; the vote if stated) | When | Source (quote + where, or minutes item) |
Known at the time | Waiting on.
Only decisions actually made. A decision announced for a later date is listed as
PENDING with the expected date. Never upgrade "discussed" or "announced" to "decided".

Put the log where the work lives: a pinned card or a Decisions list on the board, or a tab of the sheet.

3. Draft the follow-ups (5 min)

From the board only: for every item due in the next 3 working days, and every
item past due or with no update for 7+ days, draft a two-sentence follow-up from
me to the owner (or, if there is no owner, to the person on the question list).
Name the item and its ID, ask one specific question. No guilt, no "just checking
in". Drafts only.

You send them, or you don't. Some items don't need chasing, and you know which.

4. Write the Friday report from board state (15 min)

Export the board fresh (or let the connector read it), then:

Write the Friday status report for the week of <date> from the BOARD ONLY:
not from the transcripts, not from memory. Every sentence that states a fact
ends with the item ID(s) it comes from, in square brackets. Sections, in order:
DONE THIS WEEK · MOVING · WHAT SLIPPED (past due, or no update since it was
assigned, with how long) · WAITING ON A QUESTION · PARKED · DECISIONS THIS WEEK
(from the decision log). An empty section says "none"; never drop a section.
Describe items, not people: no adjectives about anyone's effort.
At the end: "Last tracker run: <date>". If it's more than 7 days ago, say so first.

Then the three cuts:

Now three versions of the same report, adding NO facts:
(1) TEAM: everything above, with names and next steps.
(2) EXEC: at most five lines, decisions and slips only, still with IDs.
(3) STAKEHOLDERS (outside the team): decisions and dates only; no individual
    names below <role> unless the person has agreed; keep IDs.

5. Read it as the person in "slipped" (5 min)

Read the team cut as the person whose item is in WHAT SLIPPED. Is it accurate? Is it fair? Does it say what's true about the item without making a claim about the person? Fix the RULES, not just this one report, if it doesn't.

The check

Every claim traces to an item, and "what slipped" is present.

Print or project the report. Go sentence by sentence:

Trace check, Friday <date>
Sentences that state a fact: __
  ...ending in an ID: __     ...whose ID exists on the board: __
  ...whose board item actually says that: __
Untraced claims: __ (target 0)
"What slipped" section present: yes / no     Items in it: __

The third column is the one that matters. An ID that exists but doesn't say what the sentence claims ("done" for something merely authorized) is an untraced claim wearing a costume. Any untraced claim: fix the item or delete the sentence, and add the pattern to RULES.

Common failures and what they look like

• The report came from the transcript. Tell-tale: it mentions things that never reached the board, like a joke, a tangent, or something said once with no item. Re-run with "from the BOARD ONLY" and give it only the export.
• "What slipped: none" when something did. The model is being kind. Check the board's due dates yourself, then add to RULES: "Past due is computed from Due vs today's date; show the computation."
• IDs pasted on decoratively. "The team made great progress on several fronts [M1-01, M1-02, M1-03]." Three IDs, zero facts. One sentence, one fact, its ID.
• The exec cut invents a trend. "Momentum is strong." That's a sound you make with your face. Strike it.
• Names in the stakeholder cut. Someone is now named in a document that left the team, for something they never agreed to own. That's why the stakeholder cut has its own rule.

Facilitator note

• Timing: 5 min idea, 5 gate, 10 decision log, 5 follow-ups, 15 report, 10 the trace check in pairs.
• The trace check works best between partners. Your partner picks three sentences at random from your report, and you have to open the board item for each. Make it a game, not an audit.
• Watch for people tidying "what slipped" into vagueness to protect a colleague. Name the alternative: describe the item precisely and keep adjectives out. Accuracy is the protection: "no owner confirmed" is about the process, and it's true.
• Think-pair-share: "Read the exec cut aloud to your partner. Ask: what decision could your boss make from this that they couldn't before?"
• Power, out loud: "Who reads the stakeholder cut? Is anybody in it who'd be surprised to be there?" For public bodies this one's real: staff named in a published tracker get calls.

↑ Contents

Block 6: Build Another One

Time: 3:20–4:00 · Harbour: a second harbour on a different coast. Same plan, different ships Atlas: /x/ai-at-work-meetings-map#d-second Back to: From Meetings to Action Syllabus

What you'll have at the end of it

• A second spec card, written by you without help, for a long email or Slack thread with commitments buried in it
• A second machine (new Project or custom GPT) running that card, with one real run passed against its own check
• A short list: which slots changed, which carried over
• The weekly rhythm for the first machine: a scheduled task (or a calendar reminder), and a way to notice when it doesn't run
• The portfolio link

ULM foundations reused here

• Daily Practice Protocol: weekly check-ins and portable summaries. Habits, not heroics. The rhythm is what turns a demo into a practice.
• 1.4 LLM Assistant Onboarding Process: the flipped interaction again, but this time you run the interview on the new case without the facilitator.
• 2.4 LLM Projects and Context Management: one Project per machine. Don't bolt the thread tracker onto the meeting tracker.

The idea

An email thread is a meeting in slow motion. Forty messages over three weeks, six people, two of them CC'd halfway through. Somewhere in message 23 someone wrote "I'll take a look," and in message 31 someone else wrote "per my last email." Same ghost commitments, same missing owners, worse ordering.

If you had to learn a whole new skill for every kind of conversation, you'd have built a gadget today. You built an anatomy instead: intake, structure, check, gate, act, ledger, rhythm. The second machine is a new spec card, not a new skill. Some slots change (intake is now a thread, and "where" is a message's date and sender, not a timestamp). Some carry over untouched (the ambiguity rules, the gate, the board).

Then the rhythm. A machine that runs when you remember to run it is still a demo. Set it to run on the meeting's cadence, and make its absence visible: if the Friday report says last tracker run: 12 days ago, the missing week shows up on its own.

Worked example: the slots that change

Three of seven changed. That ratio is typical, and it's why the second one takes forty minutes instead of a day.

Exercise (35 minutes, solo: the facilitator answers questions about the tool, not about your card)

1. Pick the thread (3 min)

Yours: a long email or Slack thread from real work, with at least one "I'll" or "we should" in it, and consent from whoever you need. If you can't use your own, the facilitator has a long public thread ready (a public issue tracker or mailing-list thread with a decision in it).

2. Interview yourself into a new card (12 min)

New Project (or custom GPT): Tracker: <thread kind>. Paste:

You're going to become a Commitment Tracker for long email or Slack threads.
I already run one for meetings; here is its spec card and RULES:
<paste them>.

Interview me about the NEW case: one short question at a time, at least five.
Focus only on what is different for threads: how threads arrive, what "where"
means without timestamps, people added or dropped mid-thread, forwarded
messages, how I'd confirm with an owner without replying-all, and when a thread
is "done enough" to process. Then, when I type "build the card", write the new
spec card in the seven slots, and after it a list: SLOTS CHANGED (and how) /
SLOTS CARRIED OVER (unchanged).

Paste the card and the carried-over RULES into the new Project's instructions.

3. Run it once, check it once (12 min)

Hand-mark the last ten messages first (ownership words, dates, decisions). Then:

Run the tracker on this thread: <paste or attach>. Same table and rules as the
spec card. "Where" is sender + message date. Treat quoted text from earlier
messages as belonging to the earlier message, not the reply that quotes it.

Count misses, inventions and invented owners, exactly as in Blocks 2 and 3.

4. Set the rhythm for machine one (8 min)

ChatGPT (as of Nov 2026): in a chat, ask it to schedule a task. Recurring tasks appear under Tasks in your profile menu. Check whether a scheduled task can see your Project's files and connectors on your plan; if it can't, the task's job is to remind you, and you run the tracker.

Claude (as of Nov 2026): use scheduled tasks where your plan and app offer them. Otherwise create a recurring calendar event with the prompt below pasted in its description.

Every <day> at <time>: check whether this week's transcript for <meeting> is in
<place>. If it is, run the tracker on it and prepare the change set for my
approval. If it isn't, tell me: "No transcript this week. Did the meeting
happen?" Never apply any change without my yes. Put "Last tracker run: <date>"
at the top of anything you produce.

Add Rhythm: <cadence>; a missed run shows as "Last tracker run" > 7 days in the Friday report to card one.

The check

One real run of the second machine passes its own check: the check written on its own card.

Second machine, <thread>, <date>
Hand-check (last 10 messages): misses __  inventions __
Invented owners __ (target 0)   Invented dates __ (target 0)
Slots changed: __ / 7  (listed in the instructions)

If the check finds something, good. Fix the rule and re-run once. You now have a failure the check caught on both machines.

Portfolio: submit one link

• ChatGPT: share the custom GPT (Create → … → Share), or share the Project if your plan allows project sharing (as of Nov 2026).
• Claude: share the Project with the facilitator, or publish an artifact that shows the instructions and both runs (as of Nov 2026).

The facilitator checks five boxes against that one link:

• [ ] Spec card in the instructions
• [ ] Two real runs visible (meeting one + meeting two)
• [ ] One failure the check caught (name it in a line at the top of the instructions: "Caught: …")
• [ ] The human gate named
• [ ] A second machine for a different case (link it from the first machine's instructions)

Common failures and what they look like

• Copy-pasting the first Project and changing nothing. The intake slot still says "transcript," Where still expects timestamps, and every row says Where: not stated. The slots-changed list exists to stop this.
• The quote belongs to someone else. Email replies quote earlier messages. The model attributes Priya's "I'll handle it" from message 12 to Sam, who quoted it in message 19. That's the extra rule in step 3.
• The rhythm with no alarm. A scheduled task that silently stops is worse than none, because you think it's running. "Last tracker run" on every output is the alarm.
• Gating by reply-all. "Can everyone confirm their items?" to 14 people. Nobody does. One to one, one item, one question.

Facilitator note

• Timing: 35 min solo build, 5 min portfolio links into the class channel. Hands off. Answer tool questions ("where's the instructions box?") and don't answer card questions ("is my gate right?"). This block is what "generalise to a second case without help" means.
• Pre-pick a public thread the week of class for anyone without one: a long issue on a public tracker or a public mailing-list thread, 20+ messages, with at least one "I'll" and one decision. Check it's still public the morning of.
• Watch for people who finish early. Ask them to run machine two on a second thread. Run it twice applies here too.
• Think-pair-share (last five minutes): "Show your partner your SLOTS CHANGED list. Name one more kind of conversation in your job this anatomy fits: interviews, 1:1s, client calls, union grievance meetings. What's the one slot that would change?"
• Re-check before class: scheduled tasks in both products (where, which plans, whether they can reach Project files and connectors) and how Projects and custom GPTs are shared (as of Nov 2026). These change faster than anything else in this class.

↑ Contents

Practice Pack: Austin City Council, October 21 and October 23, 2025

Two real meetings of one public body, two days apart, both with published transcripts. Use them when you can't bring your own meeting, or alongside it. The first meeting is short enough to hand-mark in ten minutes. The second one picks up a decision the first one announced and drops one it didn't, so "run it twice" has something real to catch.

Everything below was checked on 2026-11-10: each URL returned the file named, and the transcript text was read. Back to From Meetings to Action Syllabus.

Meeting one: Work Session, Tuesday 21 October 2025

What's in it: the council goes into executive session for two items (Austin Energy, and the appointment of a new City Auditor), comes back at 11:29 and announces that on Thursday it'll take up a motion directing its search firm to negotiate with the auditor finalist. Then a planning briefing on a proposed planned unit development (PUD) at 1400½ and 1404 East Riverside Drive: 381 units, a request for 180 ft of height, 15 affordable units. Council members ask three questions. One gets "I could look it up and get it back to you." One gets "we don't have the cost at this time." One member says "we need to really start talking about a process" and nobody says who. Adjourned 11:39.

That's every kind of item this class is about, in 2,170 words:

• An announced decision with a date: the auditor motion, Thursday.
• A ghost commitment: "I could look it up and get it back to you." Conditional verb, no date, and the transcript has no speaker names, so the owner is inferred from context.
• A "we" with no owner: "we need to really start talking about a process."
• An open question that can't be answered yet: the fee in lieu, calculated at site plan.
• A preference, not a commitment: "I would like to see that increase."

Meeting two: Regular Meeting, Thursday 23 October 2025

What matters for the tracker: Item 57, "Approve a resolution authorizing negotiation of compensation and benefits with the City Auditor finalist," passed on consent as Resolution No. 20251023-057, 9–0, then 10–0 after a motion to reconsider recorded Council Member Harper Madison voting in favour. In the transcript (around 11:12 AM) the mayor first calls it "item number 56," then corrects himself. Item 56 is a fee waiver for a music event. That one slip is a duplicate waiting to happen.

The East Riverside follow-up from Tuesday doesn't come up. Nobody says the cost was looked up. That silence is information: on Friday it belongs in "no update," not quietly closed.

Things that are wrong in the source (find them before the machine does)

These are real, and they're the point. A transcript is unverified model output too: blue material with red errors in it.

• The transcript says "Joy Hardin." The minutes say Joi Harden, Zoning Officer, Planning Department.
• "Dyess" is dais. "a fee. And Lou." is a fee in lieu. "14.5 and 1404 east Riverside" is 1400½ and 1404.
• "Original Air Date: 10/121/2025."
• The transcript never names who chaired after the mayor stepped away ("the mayor asked me to step in"). The minutes do: Council Member Vela adjourned the meeting.
• The auditor finalist's surname appears in lowercase as the captioner heard it. Check the spelling against a city source before it goes on any board.
• The minutes have a typo too ("Velftsquez"). No record is the record. The source is whichever one you can check.

How to get the text into the machine

1. Download each transcript PDF.
2. ChatGPT: add it to the Project's files, or attach it in the chat. Claude: add it to the Project knowledge, or attach it in the chat. Both read PDFs directly (as of Nov 2026).
3. Meeting one fits in one go. Meeting two is about 30,000 words. That fits in either product's context, but long inputs are where items go missing. In Block 5 you'll count whether the machine found Item 57 at all.
4. Don't contact Austin city staff about any of this. It's practice. The "confirm your own item" messages you draft in Block 3 stay as drafts.

Getting the transcript of your own meetings

The tool you meet in probably already makes one. Paths as of Nov 2026, so check your plan and your admin's settings, because these features are often off by default or limited to paid tiers:

• Zoom: turn on cloud recording with audio transcript (Settings → Recording), or use AI Companion meeting summary if your account has it. The transcript (.vtt) arrives with the cloud recording.
• Google Meet: Transcripts and Take notes for me in eligible Workspace editions. The transcript lands as a Google Doc in the organiser's Drive.
• Microsoft Teams: start Transcription (or Record and transcribe) from the meeting's More menu. The transcript is in the meeting chat/recap afterwards.
• No platform transcript: the ChatGPT desktop app's record mode, or any phone voice recorder that transcribes, on a meeting you have consent to record.

Consent comes first, and it isn't a formality

• Say it at the top, every time: "I'm recording and transcribing this so I can track what we agree to. The transcript goes into an AI assistant. Is everyone OK with that?" If anyone says no, take notes by hand and run the machine on your notes.
• Some US states (California and Washington among them) require every party's consent to record. Other countries have their own rules, and so does your employer. If you don't know your rules, find out before Saturday, not during it.
• The transcript holds what people said off the cuff: a joke about a colleague, a health thing, a complaint. Before it goes into a Project, ask whose words these are and who'll be able to read them. Cut what doesn't belong.
• Your employer may forbid uploading internal meetings to a consumer AI account. Then use the practice pack. That's what it's for.

For facilitators

Re-download both transcripts the week of class. The city can replace a file behind the same id=, so check page counts against the numbers above. If either link has died, the meeting pages list every Austin City Council meeting by date. Any work session followed by a regular meeting two days later works the same way, as long as a decision announced on Tuesday is acted on by Thursday.

↑ Contents

Prompt Cards: From Meetings to Action

Every prompt of the day, in order, with the spec-card slot it fills. Copy from here. Replace anything in <angle brackets>. Prompts are identical to the ones in the block notes. If you change one here, change it there.

Slots: Intake · Structure · Check · Gate · Act · Ledger · Rhythm (see Spec Card). Back to From Meetings to Action Syllabus · practice material in Practice Pack.

Where ChatGPT and Claude differ, the block note gives both paths. These prompts work unchanged in either.

Set Up the Machine Room · Block 1 - Set Up the Machine Room

1.1 The flipped interview

All seven slots (gathers what fills them). Run inside the new Project, before any transcript is uploaded. The Project interviews you.

You're going to become my Commitment Tracker: you'll turn the transcript of a
recurring meeting into owned, dated, sourced action items, put them on the board
my team already uses, chase them, and write a Friday status report from the board.

Before you do anything, interview me. Ask ONE short, specific question at a time,
at least five and no more than twelve. Cover: who is in this meeting and what each
person owns; where our work actually lives (which board, which lists or columns);
how we name and date things; what "done" means here; who must approve anything
before it leaves; what must never go into a tracker; and when the meeting happens.

Don't summarise, don't suggest features, and don't start working until I type
"build the card".

1.2 Build the card

All seven slots. Writes the spec card from your answers; gaps become UNKNOWN, never guesses.

build the card

Write my spec card in exactly these seven slots: Intake, Structure, Check, Gate,
Act, Ledger, Rhythm. Use only what I told you. Where I didn't tell you something,
write UNKNOWN and the question you'd need answered. Don't fill any gap with a guess.
Structure must be a fixed list of fields. Check must be something I can count.
Gate must be a named person.

1.3 RULES (paste into instructions)

Structure · Gate · Check. Goes under the spec card in the Project instructions. Every later block adds to it.

RULES
1. Never invent an owner, a date or a decision. If the transcript doesn't say it,
   the field says "not stated" and the item goes on the question list.
2. Every item quotes the transcript: exact words, plus the timestamp or line.
3. Draft only. Nothing is sent, posted or changed anywhere until <GATE NAME> says
   yes to that specific change.
4. Dates are absolute (2025-10-23), never "Thursday" or "next week". Convert
   relative dates from the meeting date, and show the conversion.
5. Fields are fixed. Never add, rename or drop a field.
6. End every run with the items you're least sure of, and why.

1.3b The Block 1 check

Check. New chat in the Project, nothing attached. Count its questions before it acts: five or more passes.

Here's this week's meeting. Go.

1.4 Model: the practice-pack spec card

All seven slots, filled. A finished card for the Austin practice pack, for comparison.

SPEC CARD: Austin City Council tracker (practice)
Intake:    The published transcript of each council meeting (work session Tuesday,
           regular meeting Thursday), from the meeting page on austintexas.gov.
Structure: ID · Type (DECISION/ACTION/QUESTION/PARKED) · What · Owner · Due ·
           Status · Source quote · Where (timestamp) · Confidence
           (fields fixed; never add or rename a field)
Check:     I hand-mark the transcript for 10 minutes first, then count misses and
           inventions. Every owner and date must be in a quote.
Gate:      Me (the facilitator) approves every board change. Owners confirm their
           own items. In practice, drafts only: we never contact city staff.
Act:       A Trello board "Austin practice", lists: Needs an owner · Owned · Done
Ledger:    Trello card history + a decision log card + each Friday report
Rhythm:    After each meeting's transcript is posted; Friday report every Friday.
           If a week has no run, the Friday report says so.

Pull the Commitments Out · Block 2 - Pull the Commitments Out

2.1 Run the tracker (extraction)

Intake → Structure. The standard run. Saved as rule 7, so later you just type "run the tracker".

Run the tracker on the attached transcript. Meeting: <name>, date <YYYY-MM-DD>.

Output ONE table with exactly these columns, in this order:
ID | Type | What | Owner | Due | Status | Source quote | Where | Confidence

- Type is one of: DECISION, ACTION, QUESTION, PARKED.
- ID: M1-01, M1-02 … (M1 = this meeting).
- Owner and Due: only if the transcript says them. Otherwise write "not stated".
- Status: "new" for everything in this run.
- Source quote: the exact words from the transcript, at most 30 words, copied,
  not paraphrased, including any transcription errors.
- Where: the timestamp in square brackets nearest before the quote.
- Confidence: high / medium / low; for medium or low, one sentence on why.

Under the table write "Least sure of:" and the three rows a human should check first.
Don't summarise the meeting.

2.2 Hand-check counts

Check. Paste at the bottom of the run's chat.

Hand-check, <meeting>, <date>
Rows: __   Quotes found verbatim: __ / __
Misses (I marked, it didn't): __
Inventions (owner/date/item not in a quote): __

Catch the Ghost Commitments · Block 3 - Catch the Ghost Commitments

3.1 AMBIGUITY RULES (paste into instructions)

Structure · Check. Edit the ghost words to match your team's.

AMBIGUITY RULES
A. Ghost words: "we should", "we need to", "someone", "somebody", "let's",
   "circle back", "I could", "I can try", "maybe", "at some point", "soon",
   "next week" (no day). An item with these is AMBIGUOUS unless the same speaker,
   in the same passage, names a person and a date.
B. An owner is a named person (or a role held by one person) who accepted the
   item in their own words. Being asked is not accepting. Being in the room is
   not owning.
C. If the transcript has no speaker labels, an owner worked out from context is
   written "inferred: <name> (because <evidence>)" and the item is AMBIGUOUS
   until that person confirms.
D. "Next week", "soon", "Thursday": convert from the meeting date and show the
   conversion; if you can't convert it to one calendar date, Due = "not stated".
E. Every AMBIGUOUS item gets one question on the QUESTION LIST, addressed to the
   person who can answer it, in one sentence.
F. PARKED = raised, explicitly not acted on now, or waiting on something
   outside this group. Say what it waits on.
G. A preference ("I'd like to see...") is not a commitment. It is PARKED,
   attributed to who said it.
H. Never resolve ambiguity by choosing the most likely person. Ask.

3.2 Re-run and classify

Structure. Adds Bin and Accepted in; produces the QUESTION LIST.

Re-run the tracker on the same transcript under the AMBIGUITY RULES.
Add a column "Bin" (OWNED / AMBIGUOUS / PARKED) and, for every OWNED row,
a column "Accepted in" that quotes the words in which the owner accepted.
Then write the QUESTION LIST: one line per AMBIGUOUS row,
"<ID> → <person who can answer>: <one-sentence question>".
List every row whose Owner or Due changed from the previous run, and why.

3.3 Confirm-your-own-item drafts

Gate. Drafts only. You send them.

For every OWNED row and every AMBIGUOUS row with an inferred owner, draft a
message to that person, from me. Two to four sentences: quote what they said
and when; state the item as recorded (what, due); ask them to reply with
"yes", "yes, but <correction>", or "not mine". Plain and friendly, no
pressure, no exclamation marks. Don't send anything. One list, grouped by person.

3.4 Critic pass on the tracker

Gate · Ledger (who it serves). Proposes one rule change.

Read the record and the question list as three people, two sentences each:
(1) the most junior person named in it; (2) a union steward; (3) bell hooks.
Each answers: who does this record make more visible, whose offhand words got
turned into obligations, and who might use it to watch people rather than to
help them? Then propose ONE change to the RULES, not to the people.

3.5 Ghost check counts

Check. Target: 0 invented owners, 0 invented dates.

Ghost check, <meeting>, <date>
Rows with an owner: __   Owner accepted in a quote: __   Invented owners: __
Rows with a due date: __   Date in a quote or a shown conversion: __   Invented dates: __
Ambiguous rows: __   Each has a question: yes / no

Put It on the Board · Block 4 - Put It on the Board

4.1 Map the fields

Act. Goes into the Act slot of the card.

Our board is <tool>. Its fields / columns are: <paste names, or a CSV header row>.
Map the tracker's fields onto them, as a two-column table: tracker field → board
field, or "no home: goes in the description". The tracker ID must go somewhere
the board keeps and I can search: a title prefix like [M1-02] or a custom field.
Bin decides the list/column: OWNED → <list>, AMBIGUOUS → "Needs an owner",
PARKED → <list or "description of a single Parked card">. Don't create anything.

4.2a Write via connector

Act · Gate. Nothing is created until you reply "yes ".

Using the <tool> connector, show me exactly the cards you would create: title
(with [ID] prefix), list, assignee, due date, description (with the source quote
and timestamp). As a table. Create NOTHING until I reply "yes <ID>" for each row.
Ambiguous items go to "Needs an owner" with no assignee and no due date.

4.2b Write via CSV

Act · Gate. Works on every plan. The import click is the gate.

Produce a CSV for import into <tool> with exactly these headers: <headers>.
One row per item. Title starts with [ID]. AMBIGUOUS rows have an empty assignee
and empty due date and go to the "Needs an owner" list. Description holds the
source quote and timestamp. Give it to me as a downloadable file.

4.3 ACCESS line (paste into instructions)

Act · Ledger. What you connected and what it can read and write.

ACCESS: Connected <tool> via <connector/CSV> on <date>. It can read <...> and
write <...>. Memory is <on/off> for this Project and holds <...>.
To revoke: <exact settings path>.

4.4 Run meeting two against the board

Act · Ledger. Update, don't duplicate. Silence is NO MENTION.

Here is the current board (<connector / attached export>) and the transcript of
the next meeting, <date>. Do this in order:
1. For EVERY item already on the board, decide: UPDATED (the meeting says
   something new about it: quote it), NO MENTION, or CLOSED (only if someone
   said it's done: quote it). Silence is NO MENTION, never CLOSED.
2. Then list NEW items from this meeting with fresh IDs (M2-01...). Before
   calling anything NEW, search the board for an item about the same thing.
   If one exists, it's an UPDATE to that ID, not a new item.
3. A status may only change to words the quote supports. "Authorized to
   negotiate" is not "hired".
Show the change set as one table: ID | change | old → new | quote | where.
Change nothing until I approve each row.

4.5 Board check counts

Check. Target: 0 duplicates, 0 items closed by silence.

Board check after meeting two
Cards: __   Distinct commitments (by your reading): __   Duplicates: __ (target 0)
Status changes this run: __   Each backed by a quote that says that status: __
Items closed by silence: __ (target 0)

Run It Twice and Write the Friday Report · Block 5 - Run It Twice and Write the Friday Report

5.1 Apply owners' replies

Gate. Closes the loop opened by 3.3.

Here are the owners' replies to the confirmation messages: <paste>.
For each: "yes" → Bin OWNED, Status confirmed. "yes, but <x>" → apply x, quote
the reply. "not mine" → back to AMBIGUOUS with a new question. No reply →
unchanged, and note the date asked. Show the change set; change nothing until I approve.

5.2 Decision log

Ledger. Lives on the board as a pinned card, list or tab.

From the board and both transcripts, build the DECISION LOG:
ID | Decision (in the decider's words where possible) | Who decided (body or
person; the vote if stated) | When | Source (quote + where, or minutes item) |
Known at the time | Waiting on.
Only decisions actually made. A decision announced for a later date is listed as
PENDING with the expected date. Never upgrade "discussed" or "announced" to "decided".

5.3 Follow-up drafts

Act · Gate. Written from the board, sent by you.

From the board only: for every item due in the next 3 working days, and every
item past due or with no update for 7+ days, draft a two-sentence follow-up from
me to the owner (or, if there is no owner, to the person on the question list).
Name the item and its ID, ask one specific question. No guilt, no "just checking
in". Drafts only.

5.4 Friday report from board state

Ledger · Rhythm. Every fact ends in an ID. "What slipped" is required.

Write the Friday status report for the week of <date> from the BOARD ONLY:
not from the transcripts, not from memory. Every sentence that states a fact
ends with the item ID(s) it comes from, in square brackets. Sections, in order:
DONE THIS WEEK · MOVING · WHAT SLIPPED (past due, or no update since it was
assigned, with how long) · WAITING ON A QUESTION · PARKED · DECISIONS THIS WEEK
(from the decision log). An empty section says "none"; never drop a section.
Describe items, not people: no adjectives about anyone's effort.
At the end: "Last tracker run: <date>". If it's more than 7 days ago, say so first.

5.5 Three cuts

Act. Team, exec, stakeholders. Adds no facts.

Now three versions of the same report, adding NO facts:
(1) TEAM: everything above, with names and next steps.
(2) EXEC: at most five lines, decisions and slips only, still with IDs.
(3) STAKEHOLDERS (outside the team): decisions and dates only; no individual
    names below <role> unless the person has agreed; keep IDs.

5.6 Trace check counts

Check. Target: 0 untraced claims.

Trace check, Friday <date>
Sentences that state a fact: __
  ...ending in an ID: __     ...whose ID exists on the board: __
  ...whose board item actually says that: __
Untraced claims: __ (target 0)
"What slipped" section present: yes / no     Items in it: __

Build Another One · Block 6 - Build Another One

6.1 Interview for the second machine

All seven slots (second case). Ends with SLOTS CHANGED / CARRIED OVER.

You're going to become a Commitment Tracker for long email or Slack threads.
I already run one for meetings; here is its spec card and RULES:
<paste them>.

Interview me about the NEW case: one short question at a time, at least five.
Focus only on what is different for threads: how threads arrive, what "where"
means without timestamps, people added or dropped mid-thread, forwarded
messages, how I'd confirm with an owner without replying-all, and when a thread
is "done enough" to process. Then, when I type "build the card", write the new
spec card in the seven slots, and after it a list: SLOTS CHANGED (and how) /
SLOTS CARRIED OVER (unchanged).

6.2 Run the thread tracker

Intake → Structure for threads.

Run the tracker on this thread: <paste or attach>. Same table and rules as the
spec card. "Where" is sender + message date. Treat quoted text from earlier
messages as belonging to the earlier message, not the reply that quotes it.

6.3 The weekly rhythm (scheduled task or calendar event)

Rhythm. "Last tracker run" makes a missed week visible.

Every <day> at <time>: check whether this week's transcript for <meeting> is in
<place>. If it is, run the tracker on it and prepare the change set for my
approval. If it isn't, tell me: "No transcript this week. Did the meeting
happen?" Never apply any change without my yes. Put "Last tracker run: <date>"
at the top of anything you produce.

6.4 Second-machine check counts

Check.

Second machine, <thread>, <date>
Hand-check (last 10 messages): misses __  inventions __
Invented owners __ (target 0)   Invented dates __ (target 0)
Slots changed: __ / 7  (listed in the instructions)

Product paths referenced alongside these prompts are as of Nov 2026. The prompts themselves don't depend on any one product.

↑ Contents

Videos: From Meetings to Action

Block 1 fundamentals: Videos - Fundamentals. Times ±30 s.

Record these (no footage exists)

1. Turning on a meeting transcript and asking for consent. Zoom / Meet / Teams, and what you say out loud.
2. Paste a transcript, get the commitment record, with every item quoted and a ghost commitment caught. Cheap to make, and it's the heart of the class.
3. The weekly review. Board deltas into the Friday report.

↑ Contents