AI for Spreadsheets & Reporting — Atlas
AI for Spreadsheets & Reporting: The Monday Report Map
THE MONDAY REPORT Raw export in. A checked, signed, one-page report out. Every period. AI for Spreadsheets & Reporting · a one-day class in the AI at Work series · the water works ↖ AI AT WORK: THE OTHER FIVE MACHINES From Meetings to Action ↗ Build Your AI Research Department ↗ Build an AI Outreach & Follow-Up System ↗ Turn Documents into Working Systems ↗ Build Your Personal Life System ↗ the same file, through every station → 1 INTAKE the meter count with code, match the source the practice pack: sep.csv: 9,337 rows = the portal's 9,337 ✓ 2 FILTRATION the recipe numbered rules, every change logged the practice pack: 166 touched, 156 changed, 0 dropped 3 TESTING LAB the spike planted errors, three explanations the practice pack: second carts 149 → 210 → 579: error, event, or definition? 4 THE GAUGE charts + forecast one question per chart, a band the practice pack: Nov: 8,802 naive, band ≈7,300–10,600 5 THE REPORT run twice + memo fresh chat, one page, signed the practice pack: October run: STOP on 3 new values → recipe v2 6 SECOND PLANT make another new card, same seven slots the practice pack: Chicago permits, weekly: a new spec card the second run breaks the recipe → v2: that's the point EVERY MACHINE IS THE SAME SEVEN SLOTS (the spec card) INTAKE block B1 STRUCTURE block B2 CHECK block B1·3 GATE block B5 ACT block B4·5 LEDGER block B2·3 RHYTHM block B6
HOW TO READ THE COLOURS your raw material unverified model output a check a human decision plumbing / connectors verified, done trust boundary
HOW TO READ THE COLOURS your raw material unverified model output a check a human decision plumbing / connectors verified, done trust boundary
HOW TO READ THE COLOURS your raw material unverified model output a check a human decision plumbing / connectors verified, done trust boundary
HOW TO READ THE COLOURS your raw material unverified model output a check a human decision plumbing / connectors verified, done trust boundary
HOW TO READ THE COLOURS your raw material unverified model output a check a human decision plumbing / connectors verified, done trust boundary
HOW TO READ THE COLOURS your raw material unverified model output a check a human decision plumbing / connectors verified, done trust boundary
HOW TO READ THE COLOURS your raw material unverified model output a check a human decision plumbing / connectors verified, done trust boundary
BLOCK 1 · THE INTAKE Machine room The model never sees your rows, so it never counts in its head. It writes code, the code counts, and the count has to match the source exactly. the river: this period's raw export intake pump house 9,337 the meter the water works: the intake
1 It never sees your rows Text becomes tokens. A count from tokens is a guess, so make it compute. Type "strawberry" into a tokenizer and the model sees three chunks: st, raw, berry. Zero R's. A pasted spreadsheet arrives the same way, as a few thousand chunks, and "how many rows say Trash/Recycling?" gets answered by what answers usually look like. Sometimes that's right, and you can't tell when. So the first rule in every machine is: compute every number with code, and show the line that did it. Newer models often get strawberry itself right, because they've seen that question a lot. The 60-row test on your own file is the one that shows it. 1 of 3 YOU ARE HERE · Monday Report › Intake › Tokens
strawberry st 302 raw 1618 berry 19772 zero R's in any token 2026-1314801, Trash/Recycling, Return Recycling Cart, 2026-09-01… "about 30" a count read from tokens = a guess len(rows) → exact code counts; you can check it
▸ Worked example: the 60-row test on sep.csv zoom in STEP 1 · plain chat, no Project, no tools Paste the header + first 60 data rows of sep.csv after: "Don't use code or any tools. Just read these rows and answer: how many have request_type Trash/Recycling? One number." STEP 2 · same chat "Now load exactly those rows with code and count them. Show the line of code. Did your first answer match?" WHAT TO NOTICE Right or wrong, the first answer came with the same confidence. You had no way to tell which until code ran. SO THE INSTRUCTIONS SAY 1. Compute every number with code. Never estimate, round in your head or count by reading. 3. For every number you report, show the line of code that produced it. 2 Read the plan, not the code The tool writes its plan in English first. You check the plan, then say go. You don't need to read Python to check an analysis. You need the plan: numbered English sentences the tool writes before it runs anything. "Count data rows excluding the header, with a parser that respects quoted fields" is right. "Count the lines in the file" is wrong the moment an address contains a line break, and you can see that from the sentence. Until you say go, the plan is unverified model output. That's why it's red here, and why the gate before the code is amber: it's your decision, not the tool's. 2 of 3 YOU ARE HERE · Monday Report › Intake › Plan
you ask the plan English, unverified "go" your gate trust boundary: nothing runs until you've read it code runs a number + the line that made it check vs the source ✓ done
▸ Plans that pass, plans that don't zoom in PASSES (illustrative wording, real counts) 1. Read sep.csv with a CSV parser that respects quoted fields. 2. Count data rows, excluding the header. → 9,337 3. Count rows where request_type equals "Trash/Recycling" exactly. → 5,140 STOP AND ASK "Count the lines in the file." Lines aren't rows when a field holds a line break. "Tidy the column names first." Next month's file won't line up. "Drop incomplete rows." Which ones, how many, and are they real requests? "Approximately 9,300 rows." A machine that can count doesn't say approximately. 3 The intake meter Two independent counts, one comparison. Exact, or it isn't checked. The check for Block 1 is two numbers: the row count and one total. Each has to match a figure the machine didn't make: the source system's own record count, a footer row, last period's report, or your own filter in the spreadsheet. The New Orleans portal will count for you: its API says September 2026 has 9,337 requests and 5,140 of them are Trash/Recycling. The machine's code says the same. Two pipes that never touched each other agree, and that's what checked means. "Close" isn't checked. 3 of 3 YOU ARE HERE · Monday Report › Intake › Meter
portal's own count data.nola.gov count API machine's code count len(rows) in the Project = ? rows 9,337 = 9,337 trash 5,140 = 5,140
▸ When the meter disagrees: what the gap usually is zoom in OFF BY 1 the header counted as a row, or one quoted field with a line break in it EXACTLY 1,000 ROWS the NOLA portal's default page size: you forgot $limit=50000 A ROUND NUMBER SHORT an export cap in your own system (5,000 / 10,000 / 50,000) TOTAL MATCHES, ROWS DON'T don't pick the one you like; both must match MODEL FIT, FOR THE SPEC CARD runs code on the file (non-negotiable) · a reasoning model writes better plans · can you upload this data at all? · lives where the report lives (Claude for Excel, GA May 2026, paid plans; as of Nov 2026, re-check) BENCH · TRY IT ON YOUR DATA The machine says 9,336 rows The machine says 9,336 rows Your Project read sep.csv and reports 9,336 data rows. The portal's own count for September is 9,337. What do you do first?
Accept it: one row in 9,337 is 0.01%. Ask the model to recount more carefully. Read its plan: does it parse rows with a quote-aware CSV reader, excluding the header? Re-download the file in case it changed. Pick one. Every answer explains itself, and the wrong ones teach the most.
▶ Now yours: what's your source's own count, and where on the screen does it live? Write it in your Check slot.
YOU ARE HERE · Monday Report › Intake › Bench
BLOCK 2 · THE RECIPE Filtration Numbered rules, the same every period, and a log that accounts for every changed row. Flag odd rows, never drop them. R1 trim R2 spellings R3–R7 flags R9 STOP raw clean the water works: filtration
1 Numbered stages "Clean this data" makes a new file every time. A recipe makes the same one. Ask an AI to clean a file on Monday and it drops blank rows; ask next month and it fills them with "Unknown". Both are defensible, and together they make your two months incomparable. A recipe is numbered rules written once and stored in the Project's instructions: trim spaces, map spellings with a readable table, mark blanks, flag odd rows. The last rule is STOP: if a category column has a value the recipe has never seen, the machine lists it and asks. Get the recipe proposed first, with how many rows each rule WOULD touch, and strike anything that drops rows or guesses. 1 of 3 YOU ARE HERE · Monday Report › Filtration › Recipe
R1 trim spaces 10 R2 status spellings → one 80 R3 blank status → (blank) 63 R4 blank district → (no district) 13 R5–R7 flag, keep the row 536 · 213 · 631 R9 STOP on an unseen value 0 in Sep
▸ CLEANING RECIPE v1 (practice pack, excerpt) zoom in R1 Trim leading/trailing spaces in every text column. ("Sanitation Dept. " → "Sanitation Dept.") R2 status mapping table Not Enough Information- Resubmittal Required → Not Enough Information - Resubmittal Required Canceled By Citizen → Cancelled by Requester · Question Answered. → Question Answered R3–R4 Blank status → (blank). Blank council district → (no district). Keep every row. R5–R7 Add flags: close_before_create · closed_no_date · is_duplicate. Change no value. R8 Record download time + the source's own row count. R9 STOP Any request_type or status not in the known list → list it and ask. Never map to "Other". 2 In = out + what was removed Rows in = rows out + rows dropped. Every changed row is in the log. A plant weighs what each filter takes out, and if the arithmetic doesn't close, something happened that nobody wrote down. Same here, twice. Rows: 9,337 in, 9,337 out, 0 dropped. Changes: rules R1 to R4 touched 10 + 80 + 63 + 13 = 166 rows, but comparing raw and clean cell by cell finds 156 distinct rows changed. Ten rows went missing from the arithmetic. They weren't lost: ten rows had a misspelled status AND a blank district, so two rules touched them. The log has to say so, or the check fails. 2 of 3 YOU ARE HERE · Monday Report › Filtration › Balance
9,337 rows in = 9,337 rows out + 0 dropped R1 10 rows R2 80 rows R3 63 rows R4 13 rows 10 rows in both 166 touched − 10 twice = 156 ✓ raw vs clean, cell by cell, with code: 156 distinct rows changed
▸ The same check on October (second run) zoom in SEPTEMBER R1 10 · R2 80 · R3 63 · R4 13 → 166 touched · 156 distinct · 10 overlap (R2 + R4) OCTOBER, SAME RECIPE R1 3 · R2 68 · R3 93 · R4 11 → 175 touched · 171 distinct · 4 touched more than once RULES ROWS: IN = OUT + DROPPED Sep 9,337 = 9,337 + 0 · Oct 8,802 = 8,802 + 0 WHEN DISTINCT > TOUCHED Something changed that no rule declared, like dates reformatted on save or ZIP codes losing leading zeros. Ask for five of those rows. WHEN DISTINCT < TOUCHED Overlaps the log didn't name, or a rule that "touched" rows without changing them. 3 Flag, don't drop An odd row is still a real request. Flag it, keep it, let the report decide. The commonest cleaning step an AI proposes is "remove rows with missing values". On the practice pack that's 63 rows with a blank status, and 57 of them are traffic-signal requests. Drop them and the report says traffic signals got quieter. So the recipe never drops: it adds a flag column, and the report states what it excludes and why. Rows closed before they were created (536) stay in the closed count and out of time-to-close. Duplicate requests (631) stay in volume, flagged, so you can report requests and distinct problems separately. 3 of 3 YOU ARE HERE · Monday Report › Filtration › Flags
63 rows with a blank status (57 are Traffic Signals) DROP removed, unlogged FLAG status = (blank), row kept report: "traffic-signal requests fell" report: "63 requests had no status; shown separately" ▸ The practice pack's flags (September) zoom in close_before_create 536 rows counted as closed; left out of time-to-close until Block 3 explains them closed_no_date 213 rows request_status = Closed but case_close_date is blank is_duplicate 631 rows status = Duplicate Request: in volume, out of "distinct problems" (blank) status 63 rows 57 Traffic Signals · kept (no district) 13 rows addresses in a different format: probably a geocoding miss (unverified) THE REPORT, NOT THE RECIPE, DECIDES and it says so in a line: "Time to close excludes 536 rows whose close time precedes their open time." BENCH · TRY IT ON YOUR DATA Does your log close? Does your log close? Put in your own run's numbers. The bench checks both balances and tells you what a gap usually means.
Check my log Load September Load a broken October Type your own numbers, or load the practice pack, then check.
▶ Now yours: run Prompt Card 7 on your file, then type its numbers in here.
YOU ARE HERE · Monday Report › Filtration › Bench
BLOCK 3 · THE ANOMALIES Testing lab A check that has never caught a planted error has never been tested. And a strange number gets three explanations and evidence before anyone smooths it. sample the spike: a known error you put there data error? real event? definition? the water works: the testing lab
1 Spike the sample Your partner plants one error in a copy. Does your check sheet find it? The check sheet is a list of tests every run must pass, each a number with PASS or FAIL: row count vs the source, unique ids, every date inside the period, every category on the known list, blanks vs last period, daily volume vs a typical day. To test the tests, your partner makes a copy of your file with ONE planted error, in a separate chat your Project can't see, and checks the copy still has the same columns and date format (or the machine catches the wrong thing). You run the check sheet blind. Then you ask what they planted. 1 of 3 YOU ARE HERE · Monday Report › Lab › Spike
rows vs source ids unique dates in period known values daily volume A · 25 duplicate rows ✓ ✓ · · · B · 40 rows moved to Oct · · ✓ · · C · 150 fake dumping rows ✓ · · · ✓ D · 60 lowercase 'pending' · · · ✓ ·
▸ Which test catches which plant (and why C is hard) zoom in A · 25 exact duplicates unique-id test FAILs (25 repeats) · rows 9,362 vs the source's 9,337 B · 40 dates moved into October period test FAILs (40 rows outside Sept) · row count still 9,337, so the meter alone misses it C · 150 invented "Illegal Dumping" rows on one Tuesday rows 9,487 vs 9,337 · that Tuesday is far above a typical weekday (Sept weekdays averaged 318–440). It LOOKS like a real event. A machine that explains it has invented a cause. D · 60 lowercase "pending" known-values test FAILs: "pending" isn't on the list CHECKS COMPARE AGAINST THE SOURCE, THE LIST, OR LAST PERIOD never against this file's own average: a planted spike becomes part of "typical". 2 Three explanations Data error, real event, or a change in what's counted. Find evidence that tells them apart. Faced with a strange number, a model's default is a fluent story. Make it do the slower thing: list three explanations, name the evidence in this file that would support or rule out each one, compute that evidence with code, and only then say which survive. A data error leaves fingerprints: duplicate ids, one address, a clock pattern. A real event spreads across places and lines up with a date. A definition change shows up as a category appearing, vanishing, or a neighbour dropping by the same amount. If more than one survives, it goes to the owner as a question. 2 of 3 YOU ARE HERE · Monday Report › Lab › Three
536 rows close before they were created data error real event definition all < 5 h early; close +5 h = modified survives real fast closes end AFTER they open ruled out same in Aug, Sep, Oct: no change date ruled out
▸ Worked example: closed before created (real) zoom in WHAT WE SEE 536 Sept rows (557 Aug, 531 Oct) have case_close_date < date_created. EVIDENCE, COMPUTED every one is less than 5 hours early · on 6,573 of the 6,869 Sept rows with a close date, date_modified is almost exactly 5 hours after case_close_date · 5 h = the gap between Central Daylight Time and UTC VERDICT a timezone mismatch between two fields. Explained. Flag the rows, keep them closed, leave them out of time-to-close, and say so in the memo's caveat. STILL WORTH ONE EMAIL to the publisher ([email protected] is listed on the dataset). 3 Investigate, then ask Second-cart requests nearly quadrupled. The data says when, not why. Order Second Trash Cart: 149 in August, 210 in September, 579 in October. Data error? The October rows come from 567 different addresses in all five council districts, and only 14 are marked duplicates. Definition change? Ordinary cart orders didn't fall to compensate. Real event? It's a step, not a blip: about 40 a week through September, 136 in the week of Sept 28, 75 on October 1 alone. The city's trash page says a second cart is free through 311, and a fee change was reported for Oct 1. Timing isn't cause. It goes to the owner as a question. If it goes out unexplained, ask who gets blamed for it. 3 of 3 YOU ARE HERE · Monday Report › Lab › Second carts
Order Second Trash Cart, by month created, 2026 93 Jan 70 Feb 227 Mar 134 Apr 117 May 134 Jun 131 Jul 149 Aug 210 Sep 579 Oct source: data.nola.gov 2jgv-pqrq, counted 2026-11-10
▸ The evidence, and the question to the owner zoom in DATA ERROR? ruled out 579 rows · 567 distinct addresses · max 3 at one address · 14 marked Duplicate Request DEFINITION CHANGE? unlikely Order Trash Cart: 261 (Sep) → 315 (Oct). No category split. REAL EVENT? survives ~40/week in Sept → 136 the week of Sept 28 → 75 on Oct 1 alone · all 5 districts CONTEXT, NOT CAUSE nola.gov/trash: a free second cart via 311 · a fee change reported for Oct 1, 2026 DRAFT TO SANITATION (you send it, not the machine) "Second-cart requests went from about 40 a week to 136 the week of Sept 28, across all five districts, not duplicates. Did something change on Oct 1 that explains it? We'd like to plan November deliveries." BENCH · TRY IT ON YOUR DATA Which evidence tells them apart? Which evidence tells them apart? Second-cart requests: 149 (Aug) → 210 (Sep) → 579 (Oct). Which single piece of evidence best separates "data error" from "real event"?
October's total is much higher than August's. The 579 rows come from 567 different addresses in all five districts. News reports a sanitation fee change on Oct 1. Ordinary 'Order Trash Cart' requests didn't fall. Pick one. Every answer explains itself, and the wrong ones teach the most.
▶ Now yours: take your strangest number this period. Write one piece of evidence that would rule out each explanation.
YOU ARE HERE · Monday Report › Lab › Bench
BLOCK 4 · CHARTS + FORECAST The gauge One chart per question, its question as its title. A forecast is checked against "same as last month" on months it hasn't seen, and it's a band, not a line. the band today's level reservoir the distribution map the water works: the reservoir gauge
1 One chart, one question Write the reader's question first. The chart's title is its answer. Ask for "some charts" and you get a dashboard: eight panels, a pie, nobody sure what it shows. Write the question the reader actually asks ("Did large-item pickups fall in October?"), then make the one chart that answers it, titled with the answer and its number. Same chart, same place, every period, because people read a recurring report against last month's. And show what's unfinished: the newest period is incomplete in some way, so label it. If a question can't be answered honestly from this file, say so instead of drawing it. Data Activism's Infographic Design handout goes deeper. 1 of 3 YOU ARE HERE · Monday Report › Gauge › One chart
"some charts" Large-item pickups fell 13% in October 2,309 Sep 2,018 Oct request_reason = Request a Large Item Pick Up
▸ Three questions, three answers (practice pack) zoom in Did large-item pickups fall in October? Two bars: 2,309 → 2,018. Title: "Large-item pickups fell 13% in October." When did second-cart requests jump? Weekly line Aug–Oct, the week of Sept 28 marked (~40/week → 136). Are we closing requests faster? NO CHART YET. Median time to close: 4.72 days (Sep) vs 3.51 (Oct), but 32.1% of October is still open against 26.4% of September. The slow cases haven't closed, so they're not in the median. The honest chart compares months at the same age ("closed within 14 days of opening"). RULE The newest period always looks fastest. Ask whether it's finished before you chart it. 2 Same as last month The naive forecast is embarrassingly hard to beat. Test against it on months it hadn't seen. The dumbest forecast for next month is "same as this month". On New Orleans 311, from January 2025 to October 2026, it missed by 803 requests a month on average. "Same month last year" sounds smarter and missed by 952, which is worse. A seasonal ratio (last year's same month, scaled by how this year compares) missed by 633 over February 2025 to October 2026, against naive's 803 over the same months. So it's better, a little, on average. Any method you show has to clear this bar on months it wasn't fitted to, and if it doesn't, you report naive. Everybody can check naive. 2 of 3 YOU ARE HERE · Monday Report › Gauge › Naive
6k 8k 10k Jan 24 Jan 25 Jan 26 Oct 26 actual naive = last month avg miss: naive 803 · same-month-last-year 952 · seasonal ratio 633
▸ Held back: August, September, October 2026 zoom in MONTH ACTUAL NAIVE miss SEASONAL RATIO miss Aug 2026 8,967 9,860 893 9,176 209 Sep 2026 9,337 8,967 370 8,060 1,277 Oct 2026 8,802 9,337 535 8,679 123 AVERAGE MISS naive 599 · seasonal ratio 536 WHAT YOU WRITE UNDER THE CHART "The seasonal method beat 'same as last month' in two of the last three months and missed by 1,277 in the third. Over 21 months it's a little better on average (633 vs 803)." THREE HELD-BACK MONTHS IS THIN. SAY SO. 3 A band, not a line Next month could be like any month you've seen. The range comes from how much it has moved before. Nobody knows next month to the unit, so a forecast that says 8,947 is lying about what it knows. The simple, honest range: take every month-to-month change in your history and see where most of them fell. For New Orleans, 26 of the last 33 changes fell between −16.8% and +20.0%. Applied to October's 8,802, that's about 7,300 to 10,600 for November. The seasonal ratio says 7,274, because November fell in both earlier years. That's the whole forecast, and on December 1 it's right or wrong in public. A forecast can become a target, too. If this band becomes 'the number to stay under', ask who absorbs a bad month. 3 of 3 YOU ARE HERE · Monday Report › Gauge › Band
6,000 7,000 8,000 9,000 10,000 11,000 naive 8,802 (same as October) seasonal ratio 7,274 ≈10,600 (+20.0%) ≈7,300 (−16.8%) band: 26 of the last 33 monthly changes November 2026
▸ The November forecast, written properly zoom in THE FORECAST "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." SO FAR (portal, 2026-11-10) 2,517 November requests, a third of the month in. Too early to say. WHAT IT DOESN'T SAY No single number to the unit. No model nobody can explain. No trend from three points. BENCH · TRY IT ON YOUR DATA Does your forecast beat "same as last month"? Does your forecast beat "same as last month"? Paste your history (oldest first) and your method's forecasts for the last 3 periods. The bench holds those 3 back and compares.
Test it Clear Type your own numbers, or load the practice pack, then check.
▶ Now yours: paste your own report's last 12+ periods. If your method doesn't win, your forecast is naive.
YOU ARE HERE · Monday Report › Gauge › Bench
BLOCK 5 · RUN IT TWICE + MEMO The report A machine that worked once is a demo. Next period's file, a fresh chat, nothing explained, and a one-page memo a stranger can act on after 30 seconds. council one page signed by a person the water works: the report to council
1 Run it twice Fresh chat, same Project, next period's file. If you have to explain anything, it belongs in the instructions. October's file, 8,802 rows, into a new chat with one line: run the machine. The row count matches the source. Then STOP fires: October has a request type September never had (Tax and Revenue, 4 rows), a status called Reopen (1), and a spelling of "Not Enough Information-Resubmittal Required" with no space before the dash (1). A recipe without a STOP rule lumps them into Other and the report is quietly wrong. With one, you answer three questions, write CLEANING RECIPE v2 with a dated change-log line, and re-run. Reconcile row counts by creation date, never status counts: statuses keep changing after the month ends. 1 of 3 YOU ARE HERE · Monday Report › Council › Twice
sep.csv 9,337 rows oct.csv 8,802 rows recipe v1 same instructions STOP 3 values never seen you answer → recipe v2, dated re-run from the start rows: Sep 9,337 = source ✓ Oct 8,802 = source ✓ dropped: 0
▸ CLEANING RECIPE v1 → v2 (the diff) zoom in R2 mapping table + Not Enough Information-Resubmittal Required → Not Enough Information - Resubmittal Required known request_type values + Tax and Revenue known status values + Reopen CHANGE LOG 2026-11-10 · v2 · October export introduced 3 values unseen in September (1 + 4 + 1 rows). Added to the lists; no rule changed. Asked by STOP, answered by <you>. WHAT WOULD CHANGE ON A RE-DOWNLOAD Pending / Resolved counts, time to close, date_modified. Not: rows by date_created. 2 One page, five lines FOR · DECISION · NUMBER · CAVEAT · ASK. A partner reads it for 30 seconds and says the decision. The memo is the only part most people read. Five lines, in this order: who it's for, by role and name; the one decision they need to make; the one number that bears on it, with its comparison; the one thing that would change your mind about that number; what you need from them, and by when. Charts, forecast and anomaly log come after, for anyone who checks. Before you sign, check three numbers outside the machine: a spreadsheet filter, the source's count, the portal's count URL. Then the test: your partner gets 30 seconds, hands it back, and says the decision out loud. 2 of 3 YOU ARE HERE · Monday Report › Council › Memo
FOR DECISION NUMBER CAVEAT ASK SIGNED: 30 s then they say the decision
▸ The practice-pack memo (reader is a stand-in role) zoom in FOR Cart delivery scheduling, Department of Sanitation (a role invented for the exercise) DECISION Plan November cart deliveries for October's level of second-cart requests, or the summer's? NUMBER 579 in October vs 149 in August and 210 in September; from the week of Sept 28 (136 that week vs ~40); 567 different addresses, all five districts. CAVEAT We know when it rose, not why. 443 of the 579 are still "Assigned to Contractor". ASK Can you confirm whether the Oct 1 change explains it, by Friday? HAND-CHECKED 579 (CSV filter) · 567 addresses (pivot table) · 149 (portal count URL). All hold. 3 Whose work does it hide? Every number makes some work visible and some invisible. Ask before you sign. Count "requests closed" and you make the closers visible. You also hide 631 September requests that somebody read, matched to an existing case and closed as Duplicate Request: work, done, invisible. And 311 counts who called, not where the problems are. District E logged the most requests in August, September and October (2,220 in September), and that can't tell you whether District E has more broken things or more people who call. If the headline becomes "District E is the problem", someone gets blamed for a phone habit. One line in the memo usually fixes it. The memo prompt asks for that line. 3 of 3 YOU ARE HERE · Monday Report › Council › Invisible
September 2026: 9,337 requests counted as "requests" 631 duplicates: read, matched, closed ↑ requests by council district, Sept: calls, not problems 1,840 A 1,713 B 1,735 C 1,816 D 2,220 E
▸ The power line, and three numbers checked by hand zoom in THE LAST LINE OF THE MEMO PROMPT "Then add one line: whose work does this report's headline number leave out?" AN ANSWER THAT FIXES IT "Volume includes 631 requests staff identified as duplicates and closed; the headline counts requests, not distinct problems." AN ANSWER THAT NEEDS A SECOND LINE "District E has the most requests." → add: "311 counts calls, not conditions." BEFORE YOU SIGN: THREE NUMBERS, OUTSIDE THE MACHINE the headline · one from a chart · the one you'd be most embarrassed to get wrong BENCH · TRY IT ON YOUR DATA Which first line survives 30 seconds? Which first line survives 30 seconds? Same memo, four opening lines. Your reader gets 30 seconds. Which one lets them say the decision?
Using a cleaned dataset of 8,802 October records, we analysed service-request trends across categories. Decision for you: plan November cart deliveries for October's level (579 second-cart requests) or the summer's (about 150)? Second-cart requests surged 289% because of the new sanitation fee. October was a busy month with several notable anomalies worth discussing. Pick one. Every answer explains itself, and the wrong ones teach the most.
▶ Now yours: read your memo's first line to your partner, then ask what you want them to decide.
YOU ARE HERE · Monday Report › Council › Bench
BLOCK 6 · MAKE ANOTHER ONE Second plant You didn't learn the Monday Report. You learned seven slots. The second machine is a new spec card, built solo, and the rhythm is the slot that dies first. in filter lab memo 311, monthly in filter lab memo permits, weekly = the water works: a second plant
1 Seven slots, new river Change the file shape, the reader, or the cadence. The slots stay the same. Intake, structure, check, gate, act, ledger, rhythm. A good second machine differs from the first in a way that matters: a different file shape (a sign-up sheet, a bank export), a different reader (the board, volunteers), or a different cadence (weekly, not monthly). The demo here is New Orleans 311 monthly next to Chicago building permits weekly, from the city's open data portal (3,179 permits issued in September 2026). It's an outline for the demo, not a run we've done. Build yours from the Prompt Cards alone, in a new Project, with no help. 1 of 3 YOU ARE HERE · Monday Report › Second plant › Slots
Monday Report second machine Intake 311 export, monthly permits issued last week Structure 19 fixed columns + flags id, type, date, area, cost, fee Check rows = portal count rows + total fees = portal Gate I sign the memo the coordinator approves Act the monthly report doc the newsletter's sheet Ledger change + anomaly logs change + anomaly logs Rhythm 1st of month · me Monday 9am · me
▸ Second machines with the right shape zoom in DIFFERENT FILE SHAPE volunteer hours from a sign-up sheet · a bank export · inventory against reorder points DIFFERENT READER the board instead of your manager · volunteers instead of finance DIFFERENT CADENCE weekly ticket volumes by queue · monthly grant spend against budget NOT DIFFERENT ENOUGH the same export for the same reader, renamed. It proves nothing new. THE PERMITS DEMO (outline, not a run) data.cityofchicago.org dataset ydr8-5enu · filter issue_date to last week · check total fees against the portal's sum. Expect odd reported costs ($0 or $1?). That's a guess to test in the profile step, not a finding. 2 Rhythm is the slot that dies Be honest about what can run itself. Usually it's a reminder plus you. Machines die in week three because nobody wrote down what starts them. As of Nov 2026, ChatGPT has scheduled tasks and Claude has scheduled tasks in Cowork on paid plans. But a scheduled task can't log in to the system your export lives in, and reports conflict on whether ChatGPT's tasks can read a Project's files. So the honest rhythm for most people is a reminder that fires on Monday at 9, and you: download, upload, say run it, read the check sheet, sign. Ninety seconds, and it's also your gate. Write the next run's date in the Rhythm slot. 2 of 3 YOU ARE HERE · Monday Report › Second plant › Rhythm
9:00 reminder scheduled task you download from the system upload + "run" into the Project check sheet PASS / FAIL you sign the gate ✓ sent where it lives a task can't log in to your system
▸ Setting it, as of Nov 2026 (re-check) zoom in CHATGPT in the first Project: "Create a scheduled task: every Monday at 9am, remind me to download <the export> from <the system> and upload it here, then list the check sheet's tests." CLAUDE Cowork → Scheduled → New task, same prompt (paid plans). Or a recurring calendar event with the Project's link in it. THE RHYTHM SLOT, FILLED Rhythm: 1st of the month, 9am · reminder → me · next run 2026-12-01 NOT FILLED Rhythm: "automatically". Ask what fetches the export. If the answer is you, write you. 3 One link, five boxes Submission is one shared link to the machine. The facilitator ticks five boxes against it. Share the machine itself: the custom GPT link, or the shared Claude Project, plus the sheet or doc it writes to. The facilitator looks for five things: the spec card at the top of the instructions; two real runs with 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; and a second machine for a different case. Five boxes, one URL. If your data can't leave work, share a practice-pack version and screenshot your own run with the numbers blurred. 3 of 3 YOU ARE HERE · Monday Report › Second plant › Portfolio
one link ✓ spec card in the instructions ✓ two real runs, reconciled ✓ one failure the check caught ✓ the human gate, by name ✓ a second machine
▸ What counts for each box zoom in SPEC CARD every slot filled; Check names a number; Gate names a person TWO REAL RUNS two periods through the same recipe; row counts reconciled to the source ONE FAILURE CAUGHT planted error found by a named test · the STOP on run two · an off-by-one at the meter HUMAN GATE "Dana Ruiz signs" counts. "Someone reviews it" doesn't. (Dana is an example name.) SECOND MACHINE its own Project and spec card; one real run; different shape, reader or cadence NO QUIZ, NO REFLECTION ESSAY The machine working is the assessment. BENCH · TRY IT ON YOUR DATA Which slot fails in week three? Which slot fails in week three? Your partner's second machine. Intake: the volunteer sign-up sheet, weekly. Structure: name, shift date, site, hours. Check: total hours = the sheet's SUM row. Gate: Dana, the volunteer coordinator. Act: the board's weekly update. Ledger: change log. Rhythm: "runs automatically every Monday".
Check Gate Rhythm Structure Pick one. Every answer explains itself, and the wrong ones teach the most.
▶ Now yours: read your second machine's Rhythm slot aloud. What, exactly, starts it?
YOU ARE HERE · Monday Report › Second plant › Bench
Machine room THE INTAKE Filtration FILTRATION Testing lab THE TESTING LAB The gauge THE RESERVOIR GAUGE The report THE REPORT TO COUNCIL Second plant A SECOND PLANT
←
0 / 0
→
Explore
Click anything to zoom into it · scroll to zoom · drag to panEsc zoom out one level · Home whole atlas1 –4 jump to a quadrant · / search
Tour
→ / space next stop · ← previousTeach
N presenter notes for whatever you're looking at · F fullscreen
Explore
Tap anything to zoom into it ·
pinch to zoom ·
drag to move around.
On a phone the map is stacked into one column: drag up to see the next part.
⤺ zooms out one level ·
☰ Map lists and searches every stop.
Read
The bar along the bottom names where you are. Tap it to read this part: what it is, the
sources it cites (tap one to open it) and the teaching notes.
Tour
‹ and
› walk the guided tour in teaching order.
Course
Back to the course ↗
Reading the map
The whole atlas is one safety case. The top goal is “this agent is fit to deploy”;
each quadrant is one leg of the argument; each district is a family of tools for that leg.
Small text appears as you zoom in. Some tiles have controls you can click.
Click anything to zoom in · scroll to zoom · Esc to back out · → for the guided tour