AI for Spreadsheets & Reporting

AI for Spreadsheets & Reporting: The Monday Report

Stop spending Friday building the report you needed Monday.

A one-day class where you build the machine that makes your recurring report. Raw export in, a cleaning recipe that re-runs, checks you can count, anomalies explained instead of smoothed, one chart per question, an honest forecast, and a one-page memo a stranger can act on. You build it on your real export, run it on two periods, then build a second one for a different report with nobody helping.

No code. The AI's analysis tool writes and runs the code. Your job is to read its plan, check its numbers, and decide what the numbers mean, because you're the one who knows what a strange Tuesday in your data actually was.

Part of AI at Work. Uses the Spec Card.

Who this is for

• Whoever builds the weekly or monthly report. Ops, finance, program managers, grant managers, nonprofit directors, store managers, the person who gets the export from the system nobody else knows how to use.
• Anyone who's had a number in a report turn out to be wrong after it went out. Most of the day is about making that stop happening.
• People who already ask ChatGPT about spreadsheets. That's most people. In Anthropic's Economic Index, data and spreadsheet work is "over-represented and especially autonomous" in chat (as of June 2026, the "Cadences" report), and business and financial operations was 5.9% of Claude conversations (as of February 2025). You don't need convincing that AI can read a CSV. What you probably don't have yet is the recurring, checked version: the same report every period, built the same way, with the checks that catch it when it's wrong.

The machine you leave with

INTAKE → STRUCTURE → CHECK → GATE → ACT → LEDGER → RHYTHM
raw       numbered    row count,  you sign   the sheet /  change log,  every Monday,
export    cleaning    totals,     the memo   the memo     anomaly log  next period's
          recipe      planted                                          export
                      error

The Monday Report: a ChatGPT Project (or custom GPT) or a Claude Project whose instructions hold your spec card and your cleaning recipe, and which takes this period's raw export and returns a clean table, a check sheet, an anomaly log, one chart per question, a forecast with its baseline, and a one-page memo. You read it, check three numbers, and sign it. It writes to the sheet or doc where the report already lives.

The metaphor: the water works

Raw water comes in at the intake. It goes through numbered filter stages, and everything they take out is logged. The lab tests samples, including ones spiked with a contaminant they put there themselves, to prove the test works. When a reading is strange, someone investigates before anyone adjusts the dial. The distribution map shows where it goes, and the operator signs the report to council. The atlas is drawn this way: /x/ai-at-work-spreadsheets-map.

The day (10am–4pm, with lunch)

The six blocks

Standards

Capability ids from _capabilities.yml. Only assessed standards are assessed, and they're assessed by looking at the artifact, never by a quiz.

Practised on the day but not claimed as standards: the strawberry test behind the "never compute in your head" rule (Block 1), checking that the planted-error copy keeps the original's columns and types (Block 3), and the forecast against "same as last period" (Block 4). Choosing a statistical method for a civic argument belongs to Data Activism's Method Selection Cheat Sheet.

Portfolio: one link, five boxes

Submit one shared link to your machine (the custom GPT, or the shared Claude Project or artifact), plus the sheet or doc it writes to. The facilitator checks five boxes against that link:

• [ ] Spec card at the top of the instructions, every slot filled
• [ ] Two real runs visible: two periods through the same recipe, row counts reconciled to the source
• [ ] One failure the check caught: the planted error, or a real one, with what the check said
• [ ] The human gate named: who signs the memo before it goes out, by name
• [ ] A second machine for a different report

If your data can't leave work, the machine can still be shared: run it on the practice pack and show your own run as a screenshot with the numbers blurred.

Prerequisites

• No code. You'll never write any. You'll read a plan the tool writes in English and you'll check numbers. If you can sort a spreadsheet column, you're ready.
• An export you rebuild on a schedule, two periods of it (this month and last, this week and last). CSV or Excel. If you can't bring it, use the Practice Pack.
• One AI account with an analysis tool. As of Nov 2026:
• ChatGPT: the free tier can upload a CSV and run analysis with tight limits. Projects with instructions and files, custom GPTs and scheduled tasks are fuller on paid plans.
• Claude: the free tier can upload files; code execution, Projects and Claude for Excel (generally available since May 2026) need a paid plan. Scheduled tasks live in Claude Cowork on paid plans.
• Plan tiers move often, so check your own account before class. If you're on a free tier, partner with someone who isn't for Blocks 5 and 6.
• Helpful, not required: a second export from a different report, for Block 6.

What this replaces

This class replaces part of Using Large Language Models, which last ran 2025-08-15. Its foundations aren't dropped. They're in Block 1, pointed at a report:

• 1.1 LLM Foundations How AI Thinks: tokens and the strawberry problem become why the machine never does arithmetic in its head.
• 1.2 LLM Model Comparison and Selection: becomes picking a model for analysis, written into the spec card.
• 1.4 LLM Assistant Onboarding Process: the flipped interaction, where the Project interviews you about your report.
• 2.1 LLM Critical Thinking Vocabulary: "good" isn't a criterion, so the checks are counts.
• 2.4 LLM Projects and Context Management: Projects become the machine's home.
• Exercise 2.4 Data Extraction and Structured Information: fields fixed first, now as the cleaning recipe's output schema.
• 3.1 LLM Few-Shot and Synthetic Data and Exercise 3.1 Synthetic Data Generation: synthetic data becomes the planted-error test copy.

Next door

• Data Activism turns public data into civic pressure, once, with real statistics in its Data Analysis Intensive. This class is the recurring internal report: same file shape every period, the recipe re-runs, anomalies get explained. Take Data Activism when the question is "is this difference real?" and the audience is a council. Take this one when the question is "what happened this month, and what do we do Monday?"
• Infographic Design (Data Activism) is the deeper version of Block 4's chart rule.

Facilitator: every product claim on these pages is marked "as of Nov 2026". Re-check each one in a live account the week before you teach. These features rename themselves and move between plans every few months.

↑ Contents

Block 1: Set Up the Machine Room

10:00–10:50 · Water works: the intake · Atlas: /x/ai-at-work-spreadsheets-map#d-intake

What you'll have at the end of this block

• A ChatGPT Project (or custom GPT) or a Claude Project that is the home of your report machine
• Your Spec Card at the top of its instructions
• A rule in those instructions that the machine computes every number with code, and never in its head
• Your export read by the analysis tool, with a row count and one total that match the source exactly

ULM foundations reused here

• 1.1 LLM Foundations How AI Thinks: tokens and the strawberry problem
• 1.2 LLM Model Comparison and Selection: picking a model for a workload
• 1.4 LLM Assistant Onboarding Process and Exercise 1.1 Assistant Onboarding: the flipped interaction
• 2.4 LLM Projects and Context Management: Projects as the place a machine lives
• 2.1 LLM Critical Thinking Vocabulary: "good" is a sound you make with your face, so the check is a count

The idea

Paste 60 rows of a spreadsheet into a chat and ask "how many of these are trash requests?" You'll get a number, delivered with total confidence. Sometimes it's right.

It never saw your rows as rows. Type "strawberry" into the OpenAI Tokenizer and you'll see it doesn't see "strawberry" either. It sees st, raw, berry: three numbers, and zero R's. Your 60 rows arrive the same way, as a few thousand chunks, and "how many" is a guess about what the answer usually looks like. A good guess is still a guess, and a report built on guesses is wrong in a way nobody can find.

So there's one rule for the whole day: the model never does arithmetic in its head. It writes code, the code runs, and the code counts. ChatGPT and Claude can both do this. It's the thing that turns a chatbot into an analyst. (As of Nov 2026: ChatGPT runs Python in its data analysis tool on files you upload. Claude does it when "Code execution and file creation" is switched on in Settings → Capabilities, and Claude for Excel works inside the workbook itself. Re-check the names before class.)

Your job changes too. You don't read the code. You read the plan: the English sentences the tool writes before it runs anything ("I'll load the file, count rows excluding the header, then group by request type…"). You can check a plan. "Count rows excluding the header" is right. "Count lines in the file" is wrong if any address has a line break in it, and you'll catch that from the sentence, without reading any Python.

And the machine needs a home that remembers. A one-off chat forgets your column names, your rules and last month's numbers. A Project keeps instructions and files across every chat you start inside it. That's where the spec card goes.

Worked example: the practice pack

New Orleans 311, September 2026 (Practice Pack). The portal's own count for September is 9,337. Its own count of Trash/Recycling requests is 5,140. Both come from the city's API, not from us.

The strawberry test, run on the file:

1. Open sep.csv in a spreadsheet, copy the header and the first 60 data rows, and paste them into a normal chat (not your Project) after this: Don't use code or any tools. Just read these rows and answer: how many have request_type "Trash/Recycling"? One number.
2. Then, in the same chat: Now load exactly those rows with code and count them. Show the line of code. Did your first answer match?
3. Compare. Whichever way the in-head number lands, notice that you had no way to know which one was right until code counted. That's the whole argument.

A first run in the Project should produce a plan like this. The wording is illustrative, and the three numbers are the file's real counts:

I'll read sep.csv with a CSV parser that respects quoted fields, count data rows excluding the header, list the columns, and count rows where request_type equals "Trash/Recycling" exactly. Rows: 9,337 · Columns: 19 · Trash/Recycling: 5,140

Both match the source. Now you have a machine you can start trusting, a little.

Model fit for this job

Write your choice into the spec card, with the reason.

Hands-on

1. Make the Project (5 min)

ChatGPT: sidebar → Projects → New project. Name it Monday Report: <your report>. You'll add instructions in step 3. (A custom GPT also works: Explore GPTs → Create, with Code Interpreter & Data Analysis ticked. Use the Project unless you want to share it with people who'll run it.)

Claude: Projects → Create project. Same name. Check that Code execution and file creation is on in Settings → Capabilities.

(UI paths as of Nov 2026.)

2. Let it interview you (10 min)

Inside the Project, start a chat and paste:

I'm building a machine that produces one recurring report for me, from the same
export every period. Before you suggest anything, interview me so you can fill in
this spec card:

Intake / Structure / Check / Gate / Act / Ledger / Rhythm

Ask ONE question at a time. Ask at least eight. Ask about: what the export is and
where it comes from, how often, who reads the report and what they decide with it,
which numbers they look at first, what went wrong with this report before, who
signs it, and where the finished report lives.
Don't give advice yet. When you have enough, show me the filled spec card and
mark any slot you had to guess.

Answer like it's a new colleague who'll be doing this report for you. "I hate it when the Q3 numbers don't match finance's" is more useful than "accuracy is important."

3. Write the instructions (10 min)

Open the Project's instructions (ChatGPT: the project's Instructions box; Claude: Set project instructions). Paste this skeleton and fill it in from the interview:

SPEC CARD
Intake:    <the export, its file name pattern, where it comes from, how often>
Structure: <the clean table's columns, fixed. Never add, drop or rename one>
Check:     row count and <one total> must match <the source's own figure>
Gate:      draft only. Nothing goes out until <name> signs it
Act:       <the sheet / doc / deck the report lives in>
Ledger:    a change log and an anomaly log for every run
Rhythm:    <every Monday / first of the month>, triggered by <who or what>
Model:     <which model and why>

RULES
1. Compute every number with code. Never estimate, round in your head or
   count by reading. If you can't run code, say so and stop.
2. Before running anything, write your plan in plain English, numbered,
   and wait for me to say "go".
3. For every number you report, show the line of code that produced it.
4. Never change, drop or invent a row without logging it.
5. If something in the file surprises you, say so. Don't fix it quietly.

4. First run: the intake meter (15 min)

Upload this period's export (or sep.csv from the Practice Pack) into the chat and paste:

Read the attached file with code. Plan first, then wait for "go".
Report:
- the number of data rows (excluding the header)
- the column names, in order
- the total of <the one number your report always leads with>
Show the line of code for each. Then tell me one thing about the file
that you'd want a human to double-check.

Read the plan. If it says "lines" where it means "rows", say so. Then say go.

The check

The row count and one total match the source exactly. Not "about". Exactly.

• Practice pack: rows = 9,337, Trash/Recycling = 5,140. Get the source's own numbers from the count URL in the Practice Pack.
• Your export: the system you exported from almost always shows a total somewhere: a record count at the bottom of the screen, a footer row, last period's report, an invoice total. That's your source figure. If there isn't one, filter the column yourself in the spreadsheet and count. That's your hand check.

Tick it in the instructions: add the two source figures under Check: so every future run compares against them.

Off by one? That's usually the header counted as a row, or one address with a line break inside quotes. Off by exactly 1,000 or 50,000 short? You hit an export limit (the NOLA portal returns 1,000 rows unless you ask for more). Each of those is a real failure your check just caught, so keep a note of it. You need one for the portfolio.

Common failures and what they look like

• The answer arrives with no code. You see a number and no "Analyzing…" / code block. It guessed. Rule 1 is missing or it's in a chat outside the Project.
• "The file contains approximately 9,300 rows." "Approximately" from a machine that can count means it didn't.
• The plan says "lines". A CSV line isn't a row when a field contains a line break.
• The total matches but the row count doesn't, or the other way round. Don't pick the one you like. Both must match.
• It renames a column ("I've tidied the column names for you"). Helpful and fatal: next month's file won't line up. That's why the Structure slot says "fixed".

Facilitator note

• Timing: 5 strawberry test, 5 Project, 10 interview, 10 instructions, 15 first run, 5 check share-out.
• Open with the room, not the tool. Before anyone opens a laptop: "What does your Monday actually look like? Which report, from which export, and what went wrong with it last time?" Write three answers on the board. You'll use them all day.
• Watch for students who skip the interview because "I know what I want". The interview's job is to find the slot they can't fill. Usually it's Gate or Rhythm.
• Watch for a model that gets strawberry right. Newer models often do, because they've seen that exact question many times. Switch to the 60-row count and it falls apart. The lesson isn't "it's bad at strawberry", it's "you couldn't tell until code counted".
• Think-pair-share: "Your partner's machine reports 9,336 rows and the portal says 9,337. List two explanations you could check in under a minute." (Header handling; a quoted line break; a filter on the export; a download that started before the last row was written.)
• Re-check before teaching: the Project / custom GPT / Claude Capabilities menu names, and whether code execution is on the free tiers. Marked as of Nov 2026.

Atlas: /x/ai-at-work-spreadsheets-map#d-intake. The bench there ("The machine says 9,336 rows") is the think-pair-share above, clickable.

↑ Contents

Block 2: Clean It With a Recipe

11:00–11:50 · Water works: filtration · Atlas: /x/ai-at-work-spreadsheets-map#d-filter

What you'll have at the end of this block

• A numbered cleaning recipe in your Project instructions, written so it runs on next period's file without you
• A change log from this period's run: every rule, how many rows it touched, examples of before → after
• Totals before and after, and a count of distinct rows changed that the log accounts for exactly
• A STOP rule: when the file contains a value the recipe has never seen, the machine asks instead of guessing

ULM foundations reused here

• Exercise 2.4 Data Extraction and Structured Information: fix the fields before you read the source
• 2.6 LLM Synthetic Data Generation and Meta-Language Patterns: a fixed template the output must fill
• 2.1 LLM Critical Thinking Vocabulary: "clean it up" isn't an instruction, "trim spaces from every text field" is

The idea

"Clean this data" is the most common spreadsheet prompt there is, and it makes a different file every time. Ask on Monday and it drops the blank rows. Ask on the 1st of next month and it fills them with "Unknown". Both are defensible, and together they make your two months incomparable, and you won't know.

A recipe is the fix. It's numbered rules, written down once, applied the same way every period:

R1  Trim leading/trailing spaces in every text column.
R2  Map status spellings to one value each, using this table: …
R3  Blank status → "(blank)". Keep the row.
R4  Never drop a row. Flag it instead, in a new column.
…
R9  STOP: if any category column has a value not in the known list, list it and ask me.

Water treatment works the same way. Each filter stage has a number and a job, and the plant weighs what comes out of each stage. Water in = water out + what the filters took. For a spreadsheet: rows in = rows out + rows dropped, and every changed cell is logged by the rule that changed it. If the arithmetic doesn't close, something changed that nobody wrote down.

Two habits make a recipe re-runnable:

• Plan before run. The tool proposes the rules and counts how many rows each would touch. You read the list and say go. That's where you catch "R5: drop rows with missing district". Those are real requests. Say no.
• Flag, don't drop. Odd rows get a flag column (close_before_create = TRUE) and stay in the table. The report decides what to exclude, and says so. The recipe never makes that call silently.

Worked example: the practice pack

September 2026, 9,337 rows in. Here's a recipe for the Practice Pack, with every count computed from the real file:

Rows in: 9,337. Rows out: 9,337. Rows dropped: 0. R1 to R4 touched 10 + 80 + 63 + 13 = 166 rows. But the tool's own comparison of raw against clean finds 156 distinct rows changed. Where did ten go? Ten rows were touched by two rules: a misspelled status and a blank district. The log has to say so, or the check fails. That's the check working: the first time the numbers disagree, you learn something about your data.

Hands-on

Inside your Project, in a new chat, upload this period's export.

1. Profile before you touch anything (10 min)

Profile the attached file with code. Change nothing.
For every column: its type, how many blanks, how many distinct values.
For text columns with fewer than 40 distinct values, list every value with
its count, and show any values that differ only by spaces, case or punctuation.
For date columns: the earliest and latest value, and any that don't parse.
End with the five things in this file you'd most want a human to look at.

2. Get the recipe proposed, not run (10 min)

Propose a numbered cleaning recipe for this file. Don't run it yet.
Rules for the rules:
- Never drop a row. If a row is suspicious, add a flag column instead.
- Never change a number in a numeric column. Flag it instead.
- Fix spellings with an explicit mapping table I can read.
- Keep the column names and order exactly as they are, plus any flag columns at the end.
- The last rule is STOP: if a category column ever contains a value not in
  today's list, stop and list the new values for me.
For each rule, give: its number, what it does in one sentence, and how many
rows it WOULD touch in this file.

Read it like a contract. Strike any rule that drops rows, guesses, or "standardises" something you didn't ask for. Answer its questions.

3. Run it with a change log (10 min)

Run the recipe as agreed. Produce:
1. The clean file, as a download.
2. A change log table: rule number, rows touched, and three examples of
   before → after for each rule.
3. Rows in, rows out, rows dropped.
4. The number of DISTINCT rows where any original value changed, computed by
   comparing the raw file to the clean file with code, cell by cell.
5. If the sum of rows touched per rule doesn't equal the distinct count,
   explain the difference row by row (which rules overlapped, on which rows).

4. Put the recipe in the machine (10 min)

Rewrite the recipe as a block I can paste into the Project instructions,
headed CLEANING RECIPE v1 and dated today. Include the mapping tables in full
and the list of known values for each category column (that list is what the
STOP rule checks against). Nothing in it may refer to this month specifically.

Paste it into the instructions under the spec card. Every future run uses it.

The check

The log accounts for every changed row.

Two numbers must agree: the distinct rows changed, computed by comparing raw and clean with code, and what the change log explains. If R1 to R4 touched 166 and 156 rows changed, the log must show the ten rows touched twice. If the log can't explain a row, the recipe changed something it didn't declare. Find it before you go on.

And: rows in = rows out + rows dropped. On the practice pack that's 9,337 = 9,337 + 0.

Common failures and what they look like

• "I've removed 63 rows with missing status." It dropped real requests. Look at which ones: 57 of them are traffic-signal requests. A report that drops them says traffic signals got quieter.
• "Cleaned and standardised the data." No rules, no counts. Ask for the numbered list.
• The recipe mentions September. "Remove rows before Sept 1" is a filter for one month, not a rule. Next month it'll empty the file.
• Blanks become "Unknown" in one column and "N/A" in another. Pick one label per blank meaning and write it in the recipe.
• The distinct-row count is bigger than the sum of rules. Something changed that no rule declared, like dates reformatted on save or leading zeros stripped from ZIP codes. Ask it to show five of those rows.

Facilitator note

• Timing: 10 profile, 10 propose, 10 run, 10 into the instructions, 10 check and share-out.
• Watch for the "drop" reflex, in students and in the model. Ask: "Who made those 63 requests? Do they still count?"
• Watch for students who accept the proposed recipe without reading. Make every pair read their partner's rule list aloud, one rule each, and say "keep" or "strike" with a reason.
• The 166 vs 156 moment is the best one in the block. If a student's numbers match on the first try, ask them to check whether any row could be touched by two rules. That's how they learn what the check is actually testing.
• Think-pair-share: "Your recipe flags 536 rows that closed before they opened. Should the report count them as closed? Should they be in time-to-close? Decide with your partner and write the rule." (Closed, yes. Time-to-close, no, until Block 3 explains them.)

Atlas: /x/ai-at-work-spreadsheets-map#d-filter. The bench there is a balance sheet: put in your own rows in, rows out and rule counts, and it tells you whether your log closes.

↑ Contents

Block 3: Investigate the Anomaly Before You Smooth It

12:00–12:50 · Water works: the testing lab · Atlas: /x/ai-at-work-spreadsheets-map#d-lab

What you'll have at the end of this block

• A check sheet in your instructions: the tests every run must pass, each one a count
• A planted-error copy of your file, made by your partner, and proof that your checks catch it
• An anomaly log with one real anomaly: three competing explanations and the evidence that tells them apart, then either an explanation or a question sent to the person who owns that number

ULM foundations reused here

• 3.1 LLM Few-Shot and Synthetic Data and Exercise 3.1 Synthetic Data Generation: synthetic data, re-homed. Here it's a test copy with a known error, and it only works if it still looks like the real thing
• 2.1 LLM Critical Thinking Vocabulary: accuracy and significance as things you can count
• 2.2 LLM Expert Business Analysis: asking from more than one perspective, here pointed at whose explanation gets believed

The idea

A spike shows up. October's second-cart requests are almost three times August's. There are three things you can do with it, and only one of them is honest.

1. Smooth it. Average it out, cap it, call it an outlier, move on. The report looks calm and it's wrong.
2. Explain it. Write the first story that fits ("people want more bins in autumn"). The model is extremely good at this. Its explanation will be fluent, plausible, and invented.
3. Investigate it. Name the competing explanations, then find the evidence that tells them apart.

There are almost always three:

Water labs have the same problem, and a good solution to it. To know that a test detects lead, they spike a sample: add a known amount of lead themselves, and check the test finds it. A test that has never caught a planted contaminant has never been tested. Your check sheet is the same. Until it catches an error you planted, you don't know it works.

And a power question, said plainly. An unexplained anomaly gets explained by someone, usually the person with the least power in the room. A spike in missed pickups becomes the hauler's fault, or the night shift's, or "residents gaming the system". So before the report goes out, ask: if this number is left unexplained, who gets blamed for it? Then make sure the explanation you're writing down is evidence, not a guess about them.

Worked example: the practice pack

Two real anomalies from the Practice Pack. Neither was planted.

1. 536 September rows close before they were created.

• Data error? Every one of the 536 is less than 5 hours early. And on closed rows, date_modified sits almost exactly 5 hours after case_close_date (6,573 of the 6,869 September rows that have a close date). Five hours is the gap between Central Daylight Time and UTC.
• Real event? Real same-day closures would close after they open, by minutes or hours. None of these close more than 5 hours "early", which is the signature of a clock problem, not of fast crews.
• Definition change? The pattern is the same in August (557), September (536) and October (531). No change date.
• Verdict: a timezone mismatch between two fields, almost certainly. Explained, flagged, kept out of time-to-close, and noted in the memo's caveat. Still worth one email to the data publisher ([email protected] is listed on the dataset).

2. Order Second Trash Cart goes 149 → 210 → 579 (August, September, October).

• Data error? The 579 October rows come from 567 different addresses. Only 14 are marked Duplicate Request. One address appears 3 times at most. Not double entry.
• Real event? The rise is a step, not a blip: about 40 a week through September, then 136 in the week of 2026-09-28, and 75 on October 1 alone. It's spread across all five council districts. The city's trash page says residents can get a free second cart through 311 (https://nola.gov/trash/), and news reports say a sanitation fee change took effect on 2026-10-01.
• Definition change? Ordinary Order Trash Cart requests didn't fall to compensate (261 in September, 315 in October), so it isn't one category being split into two.
• Verdict: probably a real event that lines up with October 1. Not explained: the data shows when, not why. So it goes to the owner as a question, not into the memo as a cause.

Hands-on

1. Write the check sheet (10 min)

In your Project:

Write a CHECK SHEET for this machine: tests every run must pass before anything
else happens. Each test must produce a number and a pass/fail, computed with code.
Include at least:
- row count vs the source's own count (I'll supply it each run)
- every id unique
- every date inside the period
- every category value on the known list (from the recipe)
- blanks per column, compared to last period's blanks
- requests per day, with any day more than double the typical weekday (or
  weekend day) flagged
- each category's count compared to last period, flagging changes over 50%
Output the results as a table: test, number, expected, PASS/FAIL.
Don't explain or fix any failure. Just report it.

Paste the result into the instructions as CHECK SHEET v1.

2. Swap and plant (10 min)

Swap files with your partner. Each of you follows "Plant a known error" in the Practice Pack to plant one error in the other person's file, in a separate chat that isn't either person's Project. Check that the copy keeps the original's columns, column order and date format. If it doesn't, your partner's machine will catch the wrong thing. Hand the copy back without saying what you did.

If you're on your own export and can't share it, plant in the practice pack copy and run your machine's check sheet on that.

3. Run the checks blind (10 min)

Upload the copy into your Project:

New period's file attached. Run the CHECK SHEET only. Report the table.

Look at the FAILs. Then ask your partner for the answer.

4. One real anomaly (15 min)

Pick one real anomaly from your own data, or from the practice pack's list. Then:

Investigate this anomaly: <describe it in one line>.
Do NOT explain it yet. First list three competing explanations:
1. a data error, 2. a real event, 3. a change in definition or process.
For each one, name the specific evidence in THIS file that would support it
and the evidence that would rule it out. Then compute each piece of evidence
with code and report the numbers. Only then say which explanations survive.
If more than one survives, say so. Don't pick one to be helpful.

If one explanation survives, write it in the anomaly log. If more than one does, the anomaly goes to its owner:

Draft a short message to <the person who owns this number> asking about this
anomaly. Say what we see (with the numbers), the explanations we've ruled out
and why, and ask the one question that would settle it. No guesses about
causes. No blame. Under 120 words. Draft only. I'll send it.

The check

Two things, both visible in the Project:

1. The planted error is caught, and you can name which test in the check sheet caught it. If none did, add a test that would have, and re-run. That counts too: it's the "one failure the check caught" box in your portfolio.
2. One real anomaly is either explained or escalated: three explanations, each with a computed piece of evidence, and either a verdict or a drafted question to its owner.

Common failures and what they look like

• The fluent explanation. "The October increase likely reflects seasonal demand ahead of the holidays." No evidence was computed. That's option 2 above, and it's the model's default.
• The averaged-away spike. "Excluding outliers, volumes were stable." Ask what was excluded and who it was.
• The checks pass on the planted copy. The usual cause: the check compares against this file's own statistics, so a planted spike becomes part of "typical". Checks compare against the source, the known list, or last period.
• The planted copy is broken. Columns renamed, dates reformatted, so every check fails and the planted error is lost in the noise. Check the copy's columns before using it.
• The escalation blames someone. "Contractor X appears to be under-reporting…" A question to an owner names what you see and asks. It doesn't accuse.

Facilitator note

• Timing: 10 check sheet, 10 swap and plant, 10 blind run and reveal, 15 real anomaly, 5 share-out. Lunch is right after, so the planted-error reveal is a good last moment.
• Planted error C (150 fake "Illegal Dumping" rows) is the most useful one to watch. Some machines flag it as a spike and then explain it as a clean-up event. Stop the room and show that. It's the fluent-explanation failure, caught live.
• Watch for students whose real anomaly is "a number went down". Ask what would have to be true for it to be a data error. Falls are anomalies too.
• The power question goes in out loud, once, plainly. Don't lecture. Ask it about their own anomaly: "If you sent this report without explaining that spike, who would your boss assume caused it?"
• Think-pair-share: "Second-cart requests nearly tripled. Your partner says 'it's the fee change'. What's the one number you'd want before you'd write that in a memo?" (The date the requests rose against the date the change took effect is a start, and it only gives you timing. Cause needs the owner.)

Atlas: /x/ai-at-work-spreadsheets-map#d-lab. The bench there: three explanations for the real second-cart spike, so which evidence tells them apart?

↑ Contents

Block 4: Chart One Question and Forecast Against a Baseline

1:30–2:20 · Water works: the distribution map and the reservoir gauge · Atlas: /x/ai-at-work-spreadsheets-map#d-gauge

What you'll have at the end of this block

• One chart per question, each with its question written above it as the title
• A forecast for next period, stated as a range, with its error on held-back periods printed next to the error of "same as last period"
• Both written into the Project's output format, so every run makes them the same way, and saved to the sheet or doc where the report lives

ULM foundations reused here

• 2.1 LLM Critical Thinking Vocabulary: "a nicer chart" isn't a request; "one message, read in 5 seconds" is
• 1.2 LLM Model Comparison and Selection: reasoning models write better plans; that matters most here

Cross-links: Data Activism's Infographic Design (the rule of one, in depth) and Method Selection Cheat Sheet (when the question is "is this difference real?", you need a statistical test, and that's their class).

The idea

Charts. Ask for "some charts" and you get a dashboard: eight panels, four colours, a pie. Nobody can say what it shows, including you. Flip it round. Write the question first, as a sentence the reader is actually asking ("Did large-item pickups fall in October?"), then ask for the one chart that answers it, with the question as its title. If you can't write the question, you don't need the chart.

Three rules, borrowed from Data Activism's Infographic Design and pointed at a recurring report:

1. One question, one chart. The title is the question, or the answer ("Large-item pickups fell 13% in October").
2. Same chart, same place, every period. A recurring report is read by people who've seen last month's. Don't make them re-learn it.
3. Show what's unfinished. The newest period is incomplete in some way (open cases, late entries). Shade it, or label it, or leave it out. Never let it sit there looking final.

Forecasts. The dumbest possible forecast for next month is "same as this month". It has a name, the naive baseline, and it's embarrassingly hard to beat. Any forecast you show has to answer one question first: did it beat "same as last month" on months it hadn't seen? If it didn't, report the naive one. It's honest, and everybody understands it.

And a forecast is never one number. It's a range, because next month could be like any of the months you've already seen. The simple, honest range: take how much the number has moved month to month in the past, and apply those moves to this month.

That's all the forecasting this class does. No models you can't explain to the person reading the memo. A water operator forecasting tomorrow's reservoir level starts with "same as today", adjusts for what they know (it's a dry week; it's a holiday), and writes a band on the gauge, not a line.

Worked example: the practice pack

Monthly totals for New Orleans 311, January 2024 to October 2026, straight from the portal's monthly-count query in the Practice Pack. Three candidate forecasts, each tested on months it hadn't seen:

Held back: August, September and October 2026. The naive forecast missed by 893, 370 and 535. The seasonal ratio missed by 209, 1,277 and 123. It wins two months out of three and loses one badly. On a window that short, that's an honest "a bit better, sometimes much worse". Say exactly that.

The forecast for November 2026, written properly:

Naive: 8,802 (same as October). 26 of the last 33 month-to-month changes fell between −16.8% and +20.0%, so the range is about 7,300 to 10,600. The seasonal ratio says 7,274, because November fell in both earlier years (−23.4% in 2024, −17.4% in 2025). We'll know on December 1.

That's the whole forecast. It's modest, it's checkable, and in three weeks it'll be right or wrong in public. Through November 10 the portal showed 2,517 November requests, a third of the month in, so it's too early to say.

One chart per question, from the same file:

Hands-on

1. Questions first (10 min)

Write the three questions your report's reader asks every period. Real sentences, in their words. Then:

Here are the three questions the reader of this report asks every period:
1. ...
2. ...
3. ...
For each question, make exactly ONE chart that answers it, using the clean file.
Title each chart with the answer in one short sentence, with the number in it.
No pie charts. No more than two colours unless a third is essential, and say why.
If the latest period is incomplete in a way that affects a chart, label it on the chart.
If a question can't be answered honestly from this file, say so instead of charting it.
Plan first, then wait for "go".

2. The baseline (15 min)

You need at least 12 past periods of your headline number. If your export only has this period, pull totals from old reports, or use the practice pack's monthly counts.

Here are my monthly totals, oldest first: <paste them, or attach the file>.
With code:
1. Hold back the last 3 months. For each held-back month, forecast it with
   "same as last month" (naive) and with one other simple method you choose and
   explain in one sentence. Report each method's miss for each held-back month,
   and its average miss.
2. Compute the same average misses over every month you can.
3. Using the month-to-month percentage changes in my history, give a range for
   next month: the band that contains about 80% of past changes. Say how many
   changes it's based on.
4. Say plainly whether your method beats naive. If it doesn't, the forecast is naive.
Don't use any method you can't explain in two sentences to the person reading the memo.

3. Into the machine (10 min)

Add a section to the Project instructions called OUTPUT FORMAT that says:
the three questions, in order, with one chart each, built the same way every run;
the forecast for next period as a range, with naive's error and the chosen
method's error on the last 3 held-back periods printed underneath.
Write it so it works next month without me.

Paste it in. Save the charts to wherever the report lives (the sheet, the slide, the doc).

The check

The forecast is honestly compared to the baseline. In your Project, visible:

• the naive baseline's error and your method's error, on at least three held-back periods
• the forecast stated as a range, with the number of past periods the range rests on
• if your method didn't beat naive, the forecast is naive, and it says so

And for the charts: you can point at each chart and read its question out loud.

Common failures and what they look like

• The forecast is a single number to the unit. "November: 8,947." Nobody knows anything to the unit. Ask for the range.
• The fancy model wins on the months it was fitted to. If it wasn't tested on months it hadn't seen, the comparison means nothing.
• "Trend: increasing." On three points. Ask how many periods support it.
• The dashboard comes back. Six panels for three questions. Ask which question each panel answers, and delete the ones that don't.
• The newest month looks best. Faster closures, fewer complaints, lower costs. Ask whether it's finished yet. (October's median time to close is 3.51 days against September's 4.72, and a third of October is still open.)

Facilitator note

• Timing: 10 questions and charts, 15 baseline, 10 into the instructions, 10 check, 5 share-out.
• Watch for students who want to "do proper forecasting". It's a fine instinct and the wrong class. Ask: "Can your reader check this in December?" If yes, it's honest enough. Point the keen ones at Data Activism's Data Analysis Intensive.
• Watch for reports with too few periods. With 6 months of history, the range is wide and should be. Say so in the memo.
• The power question, again: a forecast becomes a target. If November's range becomes "the number the call centre has to stay under", who absorbs a bad month? Ask it, then move on.
• Think-pair-share: project the three held-back months. "The seasonal ratio beat naive twice and missed by 1,277 once. Would you put it in front of your director? What sentence goes underneath it?"
• Re-check before teaching: the November 2026 actual will be in the portal by December 1. Use it. Whichever forecast was closer, that's the opening slide of the next run of this class.

Atlas: /x/ai-at-work-spreadsheets-map#d-gauge. The bench there runs the baseline test on your own numbers: paste a history, hold back three periods, and see whether your forecast beats "same as last month".

↑ Contents

Block 5: Run It Twice and Write the Memo

2:30–3:20 · Water works: the report to council · Atlas: /x/ai-at-work-spreadsheets-map#d-memo

What you'll have at the end of this block

• Next period's file through the same recipe, check sheet, charts and forecast, with nothing re-explained
• Row counts reconciled to the source for both periods, and the recipe's change log updated (v1 → v2) for whatever the second file broke
• A one-page decision memo: the reader, the decision, the number, the caveat, the ask
• Your signature on it. You're the gate. Nothing has been sent

ULM foundations reused here

• 2.1 LLM Critical Thinking Vocabulary: clarity, precision and relevance, as a rubric you can check a memo against
• 2.4 LLM Projects and Context Management: a new chat in the same Project, so nothing leaks from this morning except what's in the instructions
• Exercise 2.1 Multi-Perspective Business Analysis: reading the memo as the person it's about

The idea

A machine that worked once is a demo. The real test is next period's file, run in a fresh chat, with only the Project's instructions to go on. If the second run needs you to explain anything ("oh, the status column is the one with the misspellings"), that explanation belongs in the instructions, not in your head.

The second run will break. That's the most useful thing that happens all day. On the practice pack, October has a status spelling September never had (Not Enough Information-Resubmittal Required, one row), a status called Reopen, and a request type called Tax and Revenue. A recipe written on September doesn't know them. A recipe with a STOP rule asks about them. A recipe without one quietly lumps them into "Other", and the report is wrong in a way no one will find.

Then reconcile. The 311 file is a live snapshot: statuses keep changing after the month ends. So you reconcile row counts by creation date, which don't move, and never status counts, which do. Your export probably has its own version of this, like late-posted invoices or back-dated corrections. Find it now, not on the Monday it bites.

The memo is the only part most people will read. One page, four parts, in this order:

FOR:      the person who decides, by role and name
DECISION: what they need to decide, in one sentence
NUMBER:   the one number that bears on it, with its comparison
CAVEAT:   the one thing that would change your mind about that number
ASK:      what you need from them, and by when

Then the charts and the forecast, then the anomaly log, for anyone who wants to check.

The test is brutal and fair: a partner reads it for 30 seconds, then says what the decision is. If they can't, the memo isn't done.

And the power question. Every number makes some work visible and some invisible. A report that counts "requests closed" makes the closers visible. It hides the 631 September requests that someone read, matched to an existing case and closed as Duplicate Request: work, done, invisible. And 311 counts who called, not where the problems are. Before you sign, ask: whose work does this number make invisible, and who does it make look bad? Then decide whether one more line in the memo fixes it.

Worked example: the practice pack

The second run. October, 8,802 rows, in a new chat in the same Project, with nothing said but "October's file attached, run it."

The STOP fired. You answer it: add the new spelling to the R2 mapping table, add Tax and Revenue and Reopen to the known lists, write CLEANING RECIPE v2, date it, and note why in the change log. Re-run. That change log line is a portfolio box.

The memo. Written for a stand-in reader: the person who schedules cart deliveries for the city's sanitation department. (That's a role this class invented for the exercise, not a real person.)

FOR: Cart delivery scheduling, Department of Sanitation DECISION: Whether to plan November cart deliveries for the October level of second-cart requests or the summer level. NUMBER: 579 second-cart requests in October, against 149 in August and 210 in September. The jump started the week of Sept 28 (136 that week, against about 40 a week before) and came from 567 different addresses in all five districts. CAVEAT: We know when it rose, not why. It lines up with the sanitation fee change reported for Oct 1, but the data can't show cause, and 443 of the 579 are still "Assigned to Contractor". ASK: Can you confirm whether the Oct 1 change explains this, by Friday? If it does, plan for October's level, not the summer's.

Three numbers hand-checked before signing: 579 (filter request_reason in the CSV, count), 567 distinct addresses (the tool's count, checked against a pivot table), 149 for August (the portal's count URL with the August dates). All three hold.

Hands-on

1. The second run (15 min)

Start a new chat inside your Project. Upload next period's export (or oct.csv). Say only:

Next period's file attached. Run the machine: check sheet, recipe, charts,
forecast. Follow the instructions exactly. If anything stops you, stop and ask.

When it stops (it will), answer it, then:

Update the CLEANING RECIPE to v2 to handle what you just asked about.
Show me the diff from v1, and a change log line saying what changed and why.
Then re-run from the start.

Paste v2 into the instructions over v1, keeping the change log.

2. Reconcile (5 min)

Reconcile both periods: for each, the source's row count, the raw file's row
count, the clean file's row count and rows dropped. All computed with code.
Then list anything in this file that would change if I downloaded it again
next week, and which of my report's numbers depend on it.

3. The memo (15 min)

Write the one-page memo for this period. Use exactly this structure:
FOR / DECISION / NUMBER / CAVEAT / ASK, then the three charts, the forecast with
its baseline, and the anomaly log.
The reader is <role, name>. They decide <what>.
Rules: one decision. One headline number with its comparison. The caveat is the
single thing most likely to make the number misleading. No causes we haven't
established. Every number must come from code you ran in this chat; list them
at the bottom with the code that produced each.
Then add one line: whose work does this report's headline number leave out?

4. Hand-check three numbers, then sign (10 min)

Pick three numbers from the memo: the headline, one from a chart, and the one you'd be most embarrassed to get wrong. Check each one outside the machine: filter the CSV in a spreadsheet, use the source system's count, or use the portal's count URL. Write the three checks at the bottom of the memo. Then add your name under SIGNED:. It goes nowhere else today.

The check

1. Three numbers hand-checked, each against something the machine didn't compute, written at the bottom of the memo.
2. The 30-second partner test. Hand your partner the memo. Time 30 seconds. Take it back. They say the decision out loud. If what they say isn't the DECISION line, rewrite the first three lines and try again with someone else.

Plus: both periods' row counts reconciled to the source, in the Project.

Common failures and what they look like

• The second run gets helped. "It's the same as last time but the status column…" Stop. Put that in the instructions and start a fresh chat.
• New values vanish into "Other". No STOP rule, or a STOP rule the model talked itself out of. Check the October category list against September's.
• The memo leads with the method. "Using a cleaned dataset of 8,802 records, we…" The reader stopped at "cleaned". Lead with the decision.
• Two decisions. Pick one. The other goes in next week's memo.
• The caveat is boilerplate. "Data may contain errors." Name the error.
• A cause no one established. "Driven by the new fee." Block 3 said you don't know that yet.

Facilitator note

• Timing: 15 second run, 5 reconcile, 15 memo, 10 hand-check and sign, 5 partner tests (run them in a round, everyone at once).
• Celebrate the break. When someone's second run stops on a new value, announce it to the room. It's the day's best moment, and people who hit it should feel smart, not unlucky.
• Watch for memos written for "leadership". Make them name a person. "Leadership" can't decide anything.
• The power line at the end of the memo prompt is deliberate. Read three of them aloud. Don't comment on them; the room will.
• Think-pair-share: "Your memo's headline number is 'requests closed this month'. Name one person whose work it hides, and one person it could get blamed on."
• Re-check before teaching: that October still produces the STOP on the practice pack (re-download it; the city may have fixed its spellings).

Atlas: /x/ai-at-work-spreadsheets-map#d-memo. The bench there: four first lines for the same memo, so which one lets a stranger say the decision in 30 seconds?

↑ Contents

Block 6: Make Another One

3:20–4:00 · Water works: a second plant on a different river · Atlas: /x/ai-at-work-spreadsheets-map#d-second

What you'll have at the end of this block

• A second machine for a different recurring report: its own Project, its own spec card, its own recipe and check sheet, one real run
• A rhythm: the date and trigger for the next run of your first machine, set where you'll actually see it
• Your portfolio link, with the five boxes ticked

ULM foundations reused here

• 1.4 LLM Assistant Onboarding Process: the flipped interaction, which you now run without a script
• 2.4 LLM Projects and Context Management: one Project per machine, so two machines never share a memory by accident

The idea

You didn't learn "how to make the Monday Report". You learned seven slots: intake, structure, check, gate, act, ledger, rhythm. Once you've filled them once, the second machine is a new spec card, not a new skill. This block proves it. The facilitator stops helping.

Good second machines are different from the first one in some way that matters:

• a different file shape (a sign-up sheet instead of a system export; a bank statement instead of a CRM)
• a different reader (the board instead of your manager; volunteers instead of finance)
• a different cadence (weekly instead of monthly)

Some that have the right shape: weekly volunteer hours from the sign-up sheet · monthly grant spend against budget · ticket volumes by queue · inventory against reorder points · class enrolments by week · a programme's monthly attendance · your own invoices and what's overdue.

Rhythm is the slot people leave blank, and it's why most machines die in week three. Be honest about what can run itself. As of Nov 2026, ChatGPT has scheduled tasks and Claude has scheduled tasks in Claude Cowork (paid plans, per Anthropic's help centre). But a scheduled task can't fetch your export from a system it can't log into, and reports conflict on whether ChatGPT's tasks can read a Project's files. So for most people, the honest rhythm is a scheduled reminder plus a human: the reminder fires on Monday at 9, you download the export, drop it into the Project and say "run it". That's ninety seconds, and it's also your gate.

Worked example

From the practice pack to a second plant. The first machine reported New Orleans 311 by month. A second, different one, on the same portal: Chicago building permits, weekly (data.cityofchicago.org, dataset ydr8-5enu; 3,179 permits were issued in September 2026). Different city, different file shape (fees and costs instead of statuses), different cadence (weekly), different reader (a neighbourhood housing group tracking new construction).

The permits machine above is an outline for the facilitator to demo, not a run we've done: the $0 / $1 reported-cost check is a guess about what you'll find, labelled as one, and that's exactly the kind of thing the profile step settles.

Hands-on

1. Pick the report and write the card (10 min)

Your own second report, or your partner's first one (with their permission and their file), or the practice pack at a different cadence or for a different reader. Open a new Project. Then run the interview from Block 1, from memory or from the Prompt Cards, and fill the Spec Card.

2. Build it solo (20 min)

No help from the facilitator, and none from your first Project. You have the Prompt Cards. In order:

1. Instructions: spec card + the compute-with-code rules
2. Profile → recipe proposed → recipe run with change log → recipe into the instructions
3. Check sheet → run it
4. One chart for one question

Skip the forecast if this report doesn't need one. Not every report does.

3. Set the rhythm (5 min)

ChatGPT: in your first Project, ask:

Create a scheduled task: every <Monday at 9am / 1st of the month at 9am>,
remind me to download <the export> from <the system> and upload it here,
then list the check sheet's tests so I remember what I'm signing.

Claude: in Cowork, Scheduled → New task with the same prompt, or put a recurring event in your calendar with the Project's link in it. (As of Nov 2026. Re-check where scheduled tasks live and what they can read.)

Write the date of the next run in the Rhythm slot of the first machine's spec card.

4. Portfolio (5 min)

Share the first machine: ChatGPT: share the custom GPT link, or share the Project if your plan allows it. Claude: share the Project with your facilitator, or publish the memo as an artifact and link the Project. Check the five boxes yourself before you submit.

The check

The five portfolio boxes, against one link:

• [ ] Spec card at the top of the instructions, every slot filled
• [ ] Two real runs visible, row counts reconciled
• [ ] One failure the check caught (the planted error, the STOP on the second run, or a real one)
• [ ] The human gate named, by name
• [ ] A second machine for a different case: its own spec card and one real run, with a check that passed or failed for a reason you can say

Common failures and what they look like

• The second machine is the first one renamed. Same export, same reader, same questions. It proves nothing new. Change at least one of shape, reader or cadence.
• The second spec card has blank slots. Usually Gate and Rhythm again. "Me" is a fine gate if it's true. "Someone" isn't.
• The Rhythm slot says "automatically". Ask what fetches the export. If the answer is "I do", write that down. It's not a weakness. It's the gate.
• Sharing exposes the data. A shared Project includes its files. If your export can't leave work, share a practice-pack version of the machine and screenshot your own run.

Facilitator note

• Timing: 10 card, 20 build, 5 rhythm, 5 portfolio. Firm stop at 4:00.
• Hands off. Answer only "where's the prompt card for that?" This is the point of the block: the transfer is the "ability to make new ones", and the portfolio is the evidence.
• Watch for people who finish fast by skipping the check sheet. Ask to see one PASS/FAIL table before they share.
• Close with the room, not the tool: "What's the first Monday this runs? Who'll notice if it doesn't?" Everyone answers in one sentence.
• Think-pair-share (if a pair finishes early): "Swap second machines. Plant one error in your partner's file. Does their check sheet catch it?"
• Re-check before teaching: where scheduled tasks live in ChatGPT and Claude, which plans have them, and whether they can read Project files. Marked as of Nov 2026, and the reports conflict.

Atlas: /x/ai-at-work-spreadsheets-map#d-second. The bench there: a second machine's spec card with one slot that will fail in week three. Which one?

↑ Contents

Practice Pack: New Orleans 311, September and October 2026

If you can't bring your own export, use this one. It's a real city's real service-request log, published by the city, refreshed daily, and messy in the ways your own export is messy. Every number on this page was counted from the files as downloaded on 2026-11-10. Download them yourself and your counts may differ a little, and the reason they differ is the first lesson of the day (see "It's a live snapshot" below).

Your own data always wins. Bring the export you rebuild every week or month (sales by region, tickets by queue, volunteer hours, grant spend, inventory, enrollments) and use this pack only for the parts you can't do on yours, like planting an error you're allowed to plant.

The dataset

311 OPCD Calls (2012-Present), City of New Orleans open data portal. Publisher: Orleans Parish Communications District. One row per service request (missed trash pickup, broken streetlight, abandoned car, illegal dumping and about 25 other request types). It updates daily: the portal's metadata showed its rows last updated 2026-11-10.

• Dataset page: https://data.nola.gov/d/2jgv-pqrq (redirects to https://data.nola.gov/City-Administration/311-OPCD-Calls-2012-Present-/2jgv-pqrq)
• API documentation: https://dev.socrata.com/foundry/data.nola.gov/2jgv-pqrq

Don't click the big "Export → CSV" button without a filter. That's every request since 2012. When we tested it, the unfiltered download was still going at 89 MB. You want one month at a time.

Download one month (the exact URLs)

These links ask the portal for one month of rows as a CSV, oldest first. Paste each into your browser's address bar and it downloads. All three resolved on 2026-11-10.

September 2026 (9,337 rows on 2026-11-10)

https://data.nola.gov/resource/2jgv-pqrq.csv?$where=date_created between '2026-09-01T00:00:00' and '2026-09-30T23:59:59'&$limit=50000&$order=date_created

October 2026 (8,802 rows on 2026-11-10)

https://data.nola.gov/resource/2jgv-pqrq.csv?$where=date_created between '2026-10-01T00:00:00' and '2026-10-31T23:59:59'&$limit=50000&$order=date_created

August 2026 (optional third month, 8,967 rows)

https://data.nola.gov/resource/2jgv-pqrq.csv?$where=date_created between '2026-08-01T00:00:00' and '2026-08-31T23:59:59'&$limit=50000&$order=date_created

The source's own count for a month (this is the number your Block 1 check compares against):

https://data.nola.gov/resource/2jgv-pqrq.json?$select=count(*)&$where=date_created between '2026-09-01T00:00:00' and '2026-09-30T23:59:59'

Monthly totals back to January 2024 (for the Block 4 forecast):

https://data.nola.gov/resource/2jgv-pqrq.json?$query=SELECT date_trunc_ym(date_created) AS m, count(*) AS n WHERE date_created >= '2024-01-01' GROUP BY m ORDER BY m

For any other month, change the two dates. Keep $limit=50000: without it the portal quietly returns only the first 1,000 rows, and you get a file that looks complete. (That's a planted error you didn't plant.)

If you'd rather click: open the dataset page → Actions → Query data (or View data) → filter Date Created is between the first and last day of the month → Export → CSV. The portal's menus move around, so if that path has changed, use the URLs above. Write down the row count the portal shows before you export.

What's in a row

The numbers, as downloaded 2026-11-10

Weekdays carry the load: in October, weekdays averaged 312 to 399 requests a day and weekends 88 to 100.

Known real quirks (these are your Block 3 anomalies)

None of these are planted. They're in the city's file.

1. Rows that close before they open. 531 to 557 rows a month have a case_close_date earlier than date_created. Every one of them is less than 5 hours early. And on closed rows, date_modified sits almost exactly 5 hours after case_close_date (6,573 of the 6,869 September rows that have a close date). Five hours is the gap between Central Daylight Time and UTC. Three explanations are possible (a timezone mismatch between two fields, real same-day closures recorded wrong, or a changed definition of "closed"), and the evidence points hard at the first. The fix isn't to drop the rows. Flag them and leave them out of time-to-close.
2. "Response time got better!" It didn't, or not that much. The median time to close falls from 4.72 days (September) to 3.51 (October). But 32.1% of October's rows were still open on 2026-11-10, against 26.4% of September's. The slow cases from October haven't closed yet, so they aren't in the median. That's censoring: the newest month always looks fastest. Your memo must not say "response time improved" from these two numbers.
3. The second-cart jump. Order Second Trash Cart ran between 70 and 149 a month in 2026 (except March, at 227), then 210 in September and 579 in October. It runs about 40 a week through September, then 136 in the week starting 2026-09-28, and 75 on October 1 alone. The October rows come from 567 different addresses in all five council districts, and only 14 are marked Duplicate Request, so it isn't one person resubmitting. The city's trash page says residents can request a free second cart through 311 (https://nola.gov/trash/), and news reports say a sanitation fee change took effect on 2026-10-01. Whether the fee change caused the jump isn't in the data. That's the question you take to the Department of Sanitation.
4. "Referred to Code Enforcement" collapses. 503 of September's 756 Property Maintenance rows are "Referred to Code Enforcement". In October it's 122 of 456, and 305 are still "Pending". status is the current status, and referral takes time. A comparison of status counts across months compares rows of different ages.
5. One outcome, three spellings. Not Enough Information- Resubmittal Required, Not Enough Information-Resubmittal Required and (in August) Not Enough Information - Resubmittal Required. Also Canceled By Citizen next to Cancelled by Requester, and Question Answered. with a full stop. September has 80 rows whose status needs remapping. October has 69, including one spelling that doesn't appear in September at all. A recipe written on September alone misses it. That's what Block 5 is for.
6. Blank statuses. 63 rows in September and 93 in October have no status. Most are Traffic Signals (57 and 86). Don't drop them: they're real requests with a missing field.
7. New categories. October has a request_type that September doesn't: Tax and Revenue (4 rows), and a status of Reopen (1 row). A machine with a fixed list of categories has to notice and ask, never guess.
8. "Closed" with no close date. 213 September rows have request_status = Closed and a blank case_close_date (187 in October).
9. Blank council districts come with a different address format. The blank ones look like 2438 Ursulines Ave, New Orleans, Louisiana, 70119 or an intersection (Port St … and N Claiborne Ave …), where the rest look like 6600 Avenue A. Probably a geocoding miss. Probably. Check before you write it down as fact.
10. Trailing spaces. Sanitation Dept. has a space at the end (10 rows in September). Group by contractor without trimming and you get two Sanitation Departments.

It's a live snapshot

Every request's status, case_close_date and date_modified keep changing after the month ends. Download September today and again next week and the row count should match (the rows were created in September), but the counts of Pending, Resolved and time-to-close won't. So your recipe's first line records when you downloaded, and your reconciliation compares row counts by date_created, never status counts.

The power question, for this dataset

311 counts who called, not where the problems are. Council District E had the most requests in all three months (2,113, 2,220 and 2,076), and that alone can't tell you whether District E has more broken things or more people who call 311. And Duplicate Request closures (631 in September) are work: someone read each one and matched it to an existing case. Count "requests closed" without them and that work disappears from the report.

Plant a known error (for Block 3)

You can't test whether your machine catches errors on data you haven't checked yourself. So you make a copy with an error you put there, give it to the machine without saying so, and see what it finds. This is ULM's synthetic-data exercise (Exercise 3.1 Synthetic Data Generation) with a sharper point: synthetic data is only useful if it keeps the property you're testing. Here that property is "this looks like a normal September".

Plant it in a different chat from your machine. If the machine's Project can see the planting conversation, the test is worthless.

Better: plant for your partner. You plant in their copy, they plant in yours. Neither of you knows what's coming.

Open a fresh chat with the analysis tool (not your Project), upload the September CSV, and paste:

Make a copy of this CSV with exactly ONE planted error, chosen from the list below.
Use code to make the change. Don't do it by hand.

A. Duplicate 25 randomly chosen rows exactly, including their service_request id.
B. Move date_created on 40 random rows into October 2026, keeping the time of day.
C. Add 150 new rows on one Tuesday, all request_type "Trash/Recycling" and
   request_reason "Illegal Dumping", with new service_request ids that continue the
   existing pattern and addresses copied from real rows.
D. Change status "Pending" to "pending" (lowercase) on 60 random rows.

Choose the letter at random and DON'T tell me which one yet.
Keep every column, the column order, the header, the quoting and the date format
exactly as they are. Save the copy as sep_copy.csv and give me the file.
Then write a sealed answer: the letter, the exact rows changed (by service_request),
and the count. Put it at the very end under the heading ANSWER and I'll scroll past it.

Then check that the copy still looks like September, because if it doesn't, the machine will catch the wrong thing:

Compare sep_copy.csv to the original. Use code. Report only:
the row count of each, the column names of each (same or different), and
the number of distinct request_type values in each. Don't describe any other differences.

Row counts may differ (A and C add rows). The columns and types must match. If the columns changed, plant again.

What each planted error should trip:

Downloaded and counted 2026-11-10. Before you teach from this page, re-run the count URL for September and October. If a number has moved, the live-snapshot section above explains why, so use that as the opening example.

↑ Contents

Prompt Cards: AI for Spreadsheets & Reporting

Every prompt of the day, in order. The right-hand label is the Spec Card slot the prompt fills. In Block 6 you build a second machine using only this page, so mark it up as you go.

Anything in <angle brackets> is yours to fill in. Run every card inside your Project unless it says otherwise.

Block 1: Set up the machine room

1. The strawberry test · why Rule 1 exists

In a normal chat, not your Project. Paste the header and 60 rows of your file after it.

Don't use code or any tools. Just read these rows and answer:
how many have request_type "Trash/Recycling"? One number.

Then:

Now load exactly those rows with code and count them. Show the line of code.
Did your first answer match?

2. Let it interview you · all seven slots

I'm building a machine that produces one recurring report for me, from the same
export every period. Before you suggest anything, interview me so you can fill in
this spec card:

Intake / Structure / Check / Gate / Act / Ledger / Rhythm

Ask ONE question at a time. Ask at least eight. Ask about: what the export is and
where it comes from, how often, who reads the report and what they decide with it,
which numbers they look at first, what went wrong with this report before, who
signs it, and where the finished report lives.
Don't give advice yet. When you have enough, show me the filled spec card and
mark any slot you had to guess.

3. The instructions skeleton · all seven slots

Paste into the Project's instructions, not the chat.

SPEC CARD
Intake:    <the export, its file name pattern, where it comes from, how often>
Structure: <the clean table's columns, fixed. Never add, drop or rename one>
Check:     row count and <one total> must match <the source's own figure>
Gate:      draft only. Nothing goes out until <name> signs it
Act:       <the sheet / doc / deck the report lives in>
Ledger:    a change log and an anomaly log for every run
Rhythm:    <every Monday / first of the month>, triggered by <who or what>
Model:     <which model and why>

RULES
1. Compute every number with code. Never estimate, round in your head or
   count by reading. If you can't run code, say so and stop.
2. Before running anything, write your plan in plain English, numbered,
   and wait for me to say "go".
3. For every number you report, show the line of code that produced it.
4. Never change, drop or invent a row without logging it.
5. If something in the file surprises you, say so. Don't fix it quietly.

4. First run: the intake meter · Intake · Check

Read the attached file with code. Plan first, then wait for "go".
Report:
- the number of data rows (excluding the header)
- the column names, in order
- the total of <the one number your report always leads with>
Show the line of code for each. Then tell me one thing about the file
that you'd want a human to double-check.

Check: row count and the total match the source exactly.

Block 2: Clean it with a recipe

5. Profile before you touch anything · Structure

Profile the attached file with code. Change nothing.
For every column: its type, how many blanks, how many distinct values.
For text columns with fewer than 40 distinct values, list every value with
its count, and show any values that differ only by spaces, case or punctuation.
For date columns: the earliest and latest value, and any that don't parse.
End with the five things in this file you'd most want a human to look at.

6. Propose the recipe, don't run it · Structure

Propose a numbered cleaning recipe for this file. Don't run it yet.
Rules for the rules:
- Never drop a row. If a row is suspicious, add a flag column instead.
- Never change a number in a numeric column. Flag it instead.
- Fix spellings with an explicit mapping table I can read.
- Keep the column names and order exactly as they are, plus any flag columns at the end.
- The last rule is STOP: if a category column ever contains a value not in
  today's list, stop and list the new values for me.
For each rule, give: its number, what it does in one sentence, and how many
rows it WOULD touch in this file.

7. Run it with a change log · Ledger

Run the recipe as agreed. Produce:
1. The clean file, as a download.
2. A change log table: rule number, rows touched, and three examples of
   before → after for each rule.
3. Rows in, rows out, rows dropped.
4. The number of DISTINCT rows where any original value changed, computed by
   comparing the raw file to the clean file with code, cell by cell.
5. If the sum of rows touched per rule doesn't equal the distinct count,
   explain the difference row by row (which rules overlapped, on which rows).

Check: the log accounts for every changed row.

8. Put the recipe in the machine · Structure

Rewrite the recipe as a block I can paste into the Project instructions,
headed CLEANING RECIPE v1 and dated today. Include the mapping tables in full
and the list of known values for each category column (that list is what the
STOP rule checks against). Nothing in it may refer to this month specifically.

Block 3: Investigate the anomaly before you smooth it

9. Write the check sheet · Check

Write a CHECK SHEET for this machine: tests every run must pass before anything
else happens. Each test must produce a number and a pass/fail, computed with code.
Include at least:
- row count vs the source's own count (I'll supply it each run)
- every id unique
- every date inside the period
- every category value on the known list (from the recipe)
- blanks per column, compared to last period's blanks
- requests per day, with any day more than double the typical weekday (or
  weekend day) flagged
- each category's count compared to last period, flagging changes over 50%
Output the results as a table: test, number, expected, PASS/FAIL.
Don't explain or fix any failure. Just report it.

10. Plant a known error · Check · separate chat, ideally for your partner

The full version, with the list of errors to choose from, is in the Practice Pack under "Plant a known error".

Make a copy of this CSV with exactly ONE planted error, chosen from the list below.
Use code to make the change. Don't do it by hand.

A. Duplicate 25 randomly chosen rows exactly, including their id.
B. Move the date on 40 random rows into the next period, keeping the time of day.
C. Add 150 new rows on one weekday, all in one category, with new ids that
   continue the existing pattern and other values copied from real rows.
D. Change one common status value to lowercase on 60 random rows.

Choose the letter at random and DON'T tell me which one yet.
Keep every column, the column order, the header, the quoting and the date format
exactly as they are. Give me the copy as a file.
Then write a sealed answer: the letter, the exact rows changed (by id),
and the count. Put it at the very end under the heading ANSWER and I'll scroll past it.

11. Make sure the copy still looks real · Check · same separate chat

Compare the copy to the original. Use code. Report only:
the row count of each, the column names of each (same or different), and
the number of distinct values in each category column. Don't describe any other differences.

12. Run the checks blind · Check

New period's file attached. Run the CHECK SHEET only. Report the table.

13. Investigate one anomaly · Check · Ledger

Investigate this anomaly: <describe it in one line>.
Do NOT explain it yet. First list three competing explanations:
1. a data error, 2. a real event, 3. a change in definition or process.
For each one, name the specific evidence in THIS file that would support it
and the evidence that would rule it out. Then compute each piece of evidence
with code and report the numbers. Only then say which explanations survive.
If more than one survives, say so. Don't pick one to be helpful.

14. Ask the owner · Gate

Draft a short message to <the person who owns this number> asking about this
anomaly. Say what we see (with the numbers), the explanations we've ruled out
and why, and ask the one question that would settle it. No guesses about
causes. No blame. Under 120 words. Draft only. I'll send it.

Check: the planted error is caught by a named test; one real anomaly is explained or escalated.

Block 4: Chart one question and forecast against a baseline

15. One chart per question · Act

Here are the three questions the reader of this report asks every period:
1. ...
2. ...
3. ...
For each question, make exactly ONE chart that answers it, using the clean file.
Title each chart with the answer in one short sentence, with the number in it.
No pie charts. No more than two colours unless a third is essential, and say why.
If the latest period is incomplete in a way that affects a chart, label it on the chart.
If a question can't be answered honestly from this file, say so instead of charting it.
Plan first, then wait for "go".

16. Beat the baseline · Check · Act

Here are my monthly totals, oldest first: <paste them, or attach the file>.
With code:
1. Hold back the last 3 months. For each held-back month, forecast it with
   "same as last month" (naive) and with one other simple method you choose and
   explain in one sentence. Report each method's miss for each held-back month,
   and its average miss.
2. Compute the same average misses over every month you can.
3. Using the month-to-month percentage changes in my history, give a range for
   next month: the band that contains about 80% of past changes. Say how many
   changes it's based on.
4. Say plainly whether your method beats naive. If it doesn't, the forecast is naive.
Don't use any method you can't explain in two sentences to the person reading the memo.

Check: both errors on at least three held-back periods; the forecast is a range; naive wins ties.

17. Fix the output format · Act

Add a section to the Project instructions called OUTPUT FORMAT that says:
the three questions, in order, with one chart each, built the same way every run;
the forecast for next period as a range, with naive's error and the chosen
method's error on the last 3 held-back periods printed underneath.
Write it so it works next month without me.

Block 5: Run it twice and write the memo

18. The second run · Intake · Rhythm · new chat, same Project

Next period's file attached. Run the machine: check sheet, recipe, charts,
forecast. Follow the instructions exactly. If anything stops you, stop and ask.

19. Recipe v2 · Structure · Ledger

Update the CLEANING RECIPE to v2 to handle what you just asked about.
Show me the diff from v1, and a change log line saying what changed and why.
Then re-run from the start.

20. Reconcile · Check · Ledger

Reconcile both periods: for each, the source's row count, the raw file's row
count, the clean file's row count and rows dropped. All computed with code.
Then list anything in this file that would change if I downloaded it again
next week, and which of my report's numbers depend on it.

21. The memo · Act · Gate

Write the one-page memo for this period. Use exactly this structure:
FOR / DECISION / NUMBER / CAVEAT / ASK, then the three charts, the forecast with
its baseline, and the anomaly log.
The reader is <role, name>. They decide <what>.
Rules: one decision. One headline number with its comparison. The caveat is the
single thing most likely to make the number misleading. No causes we haven't
established. Every number must come from code you ran in this chat; list them
at the bottom with the code that produced each.
Then add one line: whose work does this report's headline number leave out?

Check: three numbers hand-checked outside the machine; a partner says the decision after 30 seconds.

Block 6: Make another one

Cards 2 to 9 and 15 again, in a new Project, for a different report. Then:

22. Set the rhythm · Rhythm

ChatGPT: in the first Project. Claude: in Cowork's Scheduled page. (As of Nov 2026, re-check.)

Create a scheduled task: every <Monday at 9am / 1st of the month at 9am>,
remind me to download <the export> from <the system> and upload it here,
then list the check sheet's tests so I remember what I'm signing.

↑ Contents

Videos: AI for Spreadsheets & Reporting

Block 1 fundamentals: Videos - Fundamentals. Times ±30 s. Best-covered class in the archive.

Record these

1. A literal hand check. Recompute three of the AI's numbers in the sheet, side by side. Five minutes.
2. Next period through the same recipe, with totals reconciled.
3. Find the Data Analysis Intensive full-day recording (only its transcript is indexed). It would be strong footage here.

↑ Contents