DEV Community: Stalefish Labs

The Order of Discovery

Stalefish Labs — Tue, 28 Jul 2026 17:36:26 +0000

Open any item in the Citizen's Daily Brief and there's a short chronology hanging off a thin vertical rule directly under the opening paragraph. Usually three or four entries. Grey dates in sans-serif, descriptions in the same Georgia as the body text, no dots, no icons, no color. Nothing to click. It's just there, the way a footnote is there.

That component was supposed to be something else.

What the Spec Asked For

The original spec of the app placed the timeline inside the expandable evidence panel, item five of six, between the common-ground checklist and the source list. It sketched the component like this:

Mar 9, 6:00pm   o  Federal Reserve releases policy statement
Mar 9, 6:03pm   o  AP reports rate decision
Mar 9, 6:15pm   o  Bloomberg analysis published
Mar 9, 6:30pm   o  Markets adjust expectations

Minute precision, a type indicator on every row, and a claim in the spec's own commentary that this was "genuinely novel — no other news product shows readers how a story developed, which sources were first, and whether official action preceded or followed reporting."

Look at those four rows again. Two are events: the Fed releases a statement, markets move. Two are publications: AP files, Bloomberg publishes. The mock is quietly doing two different jobs in one column, and I didn't notice until I tried to generate the data for it.

Two Kinds of Clock

Most news timelines answer when did this happen. A bill was introduced Monday, the committee voted Wednesday, the chamber voted Friday. That's a chronology of events, and it's the one every news product uses.

The other chronology answers when did we find out. A wire service filed at 7:41 AM. A national broadcaster picked it up at 4:58 PM. A government statement landed the next morning. Same story, different question.

Philosophically the event exists whether or not anyone reports it, and happened when it happened. Practically, for a reader trying to form an accurate picture, the reporting is the event. The story that breaks at 2 PM on a wire is a different epistemic object than the same story once a specialist publication has contextualized it twelve hours later. The facts can be identical while your understanding of them is not.

Intelligence analysts treat this as data in its own right. A story that surfaces informally, then gets wire confirmation, then gets official acknowledgment has a different information signature than one that opens as an official announcement and gets explained backward by reporting. The first pattern suggests something leaked. The second suggests something was managed. Neither tells you which story matters more, and both tell you something about the environment the story came out of.

What Got Built Instead

So in the CDB, the two kinds of timing ship as two separate components.

The timeline under the lede is the event clock. It runs at day granularity with a rough time-of-day qualifier, and it exists to give you the shape of the story before you read the analysis, the beats as they unfolded over time.

The discovery clock lives one layer down, in the Articles section of the evidence panel. Every source gets its outlet, its role in the assessment, its headline, and its publication time to the minute in Eastern time.

The two corroborate each other, which is the useful part. Take the July 27 wildfire item. Its first timeline entry is dated Jul 26 (early) and reads, in part, Reuters and FT first report Bordeaux threat. That's a checkable claim. Scroll the source list past the international and national outlets to the wire block and there they are: Financial Times filed at 7:41 AM, Reuters at 8:37 AM, both on the 26th, both earlier than anything else in the cluster of sixteen. The assessment says an outlet was first. The source list hands you the timestamp to test it with.

Which is all the wildfire item's timing proves. It's the ordinary case, and the ordinary case has no tell in it. A fire is a fire, the wires get there first, everyone else catches up across eighteen hours, and the sequence tells you nothing you didn't already assume. That's the right answer for most stories, and most stories are most of the brief.

When the Sequence Is the Story

The archive holds the other kind too. On June 30 the Supreme Court upheld state bans on transgender athletes in school sports. The first source in that item is a report of the ruling at 10:04 AM, classed primary because it broke the news of an official action. The second is at 10:06. Then 10:15, 10:17, 10:43, 11:05, 11:18 — twenty-eight sources, and everything past the first two minutes is commentary on a document that was already public. Official action, then a wave of reaction that couldn't have started earlier because until 10:04 there was nothing to react to. A scheduled release looks exactly like that.

Six weeks earlier the shape is inverted. On May 15 the brief carried "US Justice Department preparing to indict former Cuban President Raúl Castro." The Guardian filed at 1:31 PM. The New York Post at 3:47. Reuters at 4:35 and again at 5:17, AP at 5:50, ABC at 6:08. Nothing in the cluster gets classed as a primary source until 6:33 PM, five hours behind the first report. A story about a forthcoming indictment circulated most of an afternoon before anything official caught up with it. The word preparing in that headline is doing a lot of work, and the timestamps are where you can watch it work.

I'd put a caveat on the second one. "Primary" is the assessor's judgment about what a source is doing in the cluster, not a certificate that the source is an official document, so a five-hour gap is evidence rather than proof. But it's evidence the reader can see and weigh, which is the entire point of putting the timestamps there.

Splitting the two clocks was an accident of implementation that turned out to be a better design than the spec. The event chronology belongs above the fold because it's orientation, and every reader needs it. The discovery chronology belongs behind a disclosure because it's an audit trail, and an audit trail presented as narrative starts to look like the story rather than the receipt for it.

The Field That Never Shipped

The original schema for a timeline entry was {event_time, event_type, label}. That event_type was the hook for a categorization pass I'd planned: color-coded dots, blue for wire services, green for government sources, orange for international outlets. Informative at a glance.

It was also subtly dishonest. Color coding implies categories that map onto significance, and these don't. A government source isn't inherently more credible than a wire service. An international outlet isn't inherently more or less important than a domestic one. The scheme would have encoded editorial judgments I had no business making and no way to defend. Worse, for this project: style for style's sake.

So the dots never got built, and the field never got populated. What the pipeline emits is {date, event}. I checked: 2,912 timeline entries across 925 published items, every single one that shape. The frontend still carries a fallback branch that reads event_time and label if date and event are missing. It has never fired. Somewhere in briefUtils.ts there's a four-line return for a schema that lost an argument and has been dead code ever since.

The monochrome version that shipped in its place makes you read the entries instead of scanning the colors. Each one gives you the date and what happened, and where the reporting is the point, it says so in plain text: Reuters and FT first report Bordeaux threat. You form your own view of the source landscape. This is the same instinct that runs through the rest of the product's deliberately plain design — present the information, don't nudge the judgment.

The Bug the Timeline Caused

Here's the part I didn't anticipate. The timeline is generated in the same JSON payload as the prose, but for a while it wasn't shown to any of the validation passes that check the prose.

On June 25 the brief carried an item on the New York mayoral primary that called its subject "Zohran Mamdani" in the timeline and "Zoe Mamdani," with female pronouns, in the body. Both came out of the same model call. The grounded self-review that should have caught it never saw the timeline field, so it checked a body that was internally consistent and passed it.

That item is the opening example in When the LLM Isn't the Product, which takes up the general problem: a model writing a confident falsehood inches from a structured field that had the name right the whole time. The part that belongs here is narrower and more embarrassing. The field with the name right in it was the timeline, and nothing was reading it.

That produced two fixes. The fact-check prompt now renders the timeline as plain lines and reads it alongside the prose. And there's a deterministic check, name_consistency.py, that walks every field in an item, including nested structures, and flags any surname appearing with two different given names. No model call, no name catalog, just a regex and a set. Heuristic and admittedly crude — two genuinely different people sharing a surname in one item will trip it — so a conflict triggers regeneration rather than a silent edit.

Structured output that no reviewer reads is structured output you're publishing unverified. The timeline was the field that taught me that, which is a mildly humiliating thing to learn from a list of dates.

What I Haven't Built

The pipeline doesn't detect patterns in the discovery record. If three outlets file the same fact within four minutes of each other, that's a coordinated release or a shared wire origin, and it's a materially different signal from three outlets confirming independently across six hours. The data supports the inference. Nothing in the code draws it. That felt like over-engineering for v1 and it still does, though it's the first thing I'd look into adding if the panel ever expands.

The other one took me a while to think through, because it turns out not to be a bug. The Articles list isn't sorted chronologically. In the wildfire item the list opens at 3:21 AM, jumps back to 11:58 PM the previous night, then forward to 7:32 AM. The times are all there and the order ignores them.

Nobody chose that order. Sources carry a display_order the publisher assigns by walking the cluster's source indices, and those indices come from fetch_all_sources, which iterates the feed list in sources.py top to bottom. That file happens to be written in rough perspective blocks: the official feeds first, then international and left-leaning, public media, broadcast, specialist and tech, wire, business, political trade, with the right-leaning outlets in a block near the bottom. The panel inherits that grouping without a sort ever being written.

That list has a first job, though, and the inherited order happens to serve it. The toggle above the panel reads "16 sources, 6 perspectives," and the significance model weights editorial diversity over raw outlet count, so what the panel most needs to show is spread — whether a story is carried across the spectrum or only by one wing of it. Contiguous blocks by camp show that at a glance.

The order arrived by accident. It stays on purpose, because the two jobs aren't worth the same. Spread is the one a reader can't rebuild for themselves; you'd have to tally outlets by camp to see it. Sequence they can rebuild, because every timestamp is printed right there next to the outlet. And the wildfire item is the reminder that on most days reading them in order tells you nothing: a leak or a managed release is the exception; editorial breadth is every item, every day. Given one axis to sort on, it should be the one that can't be recovered by eye.

The Receipt for the Receipt

Most readers will never open the evidence panel. Of the ones who do, most won't cross-reference the timestamps against the timeline. I'm fine with that. What matters is that the brief can be audited, by anyone, on the spot, without asking me for anything. The evidence ships with the item, every item, whether or not a single reader opens it. It isn't a corrections page written after somebody catches you.

Confidence and agreement are the system's judgments, and they're labeled as such. Common ground and key disagreements are the system's reading of the sources. The two clocks are the closest thing in the product to raw material: here is when it happened, here is when we heard, here is the gap between them. Everything else in the item is built on top of those, and if the assessment and the timestamps disagree, the timestamps win.

That's a smaller promise than "trust us." It's the only one an automated brief has any standing to make.

The Citizen's Daily Brief is a free daily intelligence briefing from Stalefish Labs.

The Vault Opens: Three Tall Tales Decks Never Made It to Print, Until Now

Stalefish Labs — Fri, 24 Jul 2026 03:05:00 +0000

This series has spent its first few weeks on the almosts. Tall Tales almost ended up in Starbucks. It almost got a custom edition at Cracker Barrel. I pitched it to 70 retailers, most of them now out of business. What I haven't talked about is what I made for those almosts — the cards I wrote for editions that never went to print. They've been sitting in spreadsheets for twenty-three years. Today they go online.

There were three unreleased decks.

The Discovery Edition, about 35 cards, was the nature-leaning expansion: cryptids, weird-but-true biology, lost-explorer lore. It's the deck I had the most fun writing, and the one I'd bring back first.

The Hollywood Edition, about 33 cards, was pop culture and movie trivia. It sat closest to the original Pocket Edition in voice, which would have made it the safe next release.

The Down Home Edition, about 60 cards, was the Cracker Barrel pitch — folksy, Americana, regional, the most divergent of the three.

"Designed but never shipped" can sound like a polite way to say "a few notes in a drawer." These weren't that. They were finished cards — written, answered, fact-checked, formatted, color-coded by edition — that simply never met a printing press. They lived in a handful of master spreadsheets, and every row was colored by its fate. Blue meant it shipped in the Pocket Edition. Green was Discovery, brown was Hollywood, red was Down Home. For twenty-three years those cells sat in their colors, complete and unread. Well, mostly complete: some rows trail off into empty columns, a question written and its answers never filled in — cards caught mid-thought when the whole effort stopped.

Without a plan to relaunch a card game to put them back in the world, I decided to give them a new life directly on the web. I built a card viewer: every card gets its own page and its own URL, with the unreleased cards stamped Never Printed. No box, no rulebook, no reprint, no Kickstarter to run. Just the cards, readable and free to anyone curious enough to look.

I wanted each card individually indexed: a page holding a small piece of content that didn't exist on the web before — a fact, a question, a strange little story with its own address. People searching for the kind of trivia these cards are made of can now land on them, and every one of those pages points quietly back to the original 2003 Pocket Edition, still for sale while supplies last, and to a "let me know if Tall Tales ever comes back" list for anyone who wants more than the few hundred boxes I have left. I'm not hiding the funnel. I'm just not going to dress it up as more than it is.

Two ways in, if you want them:

Browse the decks, sorted by edition, Never-Printed cards included.
Draw a random card — shuffling, basically, except every draw is a shareable link.

What this isn't: a comeback announcement. Whether any of these three decks ever gets manufactured is a decision for later. I'll let engagement decide. If the web version finds an audience and the notify list fills up, that tells me something. If it doesn't, that tells me something else, and the cards still get to exist either way.

There was a fifth color in the spreadsheets, too: pale yellow, for base-game material that didn't make the original Pocket Edition cut. All five collections sat untouched together — a finished game, three finished expansions, and a pile of extras, visible only to me. As of today, four of those colors are online. The yellow stays in the file for now; if the rest proves out, it becomes the pool I'd draw a refresh from.

Three decks that never got printed, printed at last — just not on cardstock.

The remaining copies of Tall Tales Pocket Edition are here.

The Cracker Barrel Edition That Almost Was

Stalefish Labs — Wed, 22 Jul 2026 13:33:41 +0000

I'm a native Nashvillian, which is increasingly rare these days. I grew up with Cracker Barrel as a road trip staple, complete with the vintage candy in the gift shop, the triangle peg game, and endless biscuits. The company is based in Lebanon, Tennessee, half an hour east, and after getting an initial soft reply via a cold letter writing campaign about them carrying our card game Tall Tales, I learned I had a surprisingly direct connection to the top. I ended up getting a real sit-down, inside the building, with the founder and CEO himself, to show him the game. A truly rare opportunity for someone with zero marketing experience trying to launch a new game.

I brought our $12.95 Tall Tales Pocket Edition that had shipped at Toy Fair, and entered the foyer of Cracker Barrel's then corporate HQ. At that time their HQ was a restored 10,000 square foot mansion called The Mitchell House, which was originally part of the Castle Heights Military Academy. I had somehow managed to get a sit down with their founder and CEO, and Castle Heights graduate, Dan Evins, who was very kind and seemed to maybe appreciate the pluckiness of me trying to pitch a locally created product directly to the top. We talked a bit and he eventually passed me on to their buyer, Karen Smith. That meeting, in October 2002, is where the story starts to unravel. She named the problem with selling Tall Tales into Cracker Barrel without hedging. Their retail floor runs on nostalgia: tin signs, wooden toys, the candy your grandparents' grandparents ate, the rocking chairs out front, a healthy dose of UT Vols big orange paraphernalia. Tall Tales, with its stylized cryptid creatures, weird-but-true trivia, and its faintly mischievous voice, read as too modern and a shade too edgy for that shelf. She wasn't knocking the game, just its place on that particular shelf, and she had it right.

Most pitches end at the no. This one turned into a design brief. I'm a designer, so what I heard in her critique was an assignment. Instead of leaving I offered to build Cracker Barrel their own version of the game, and she was open to it, so I drove home and did it. Tall Tales Down Home Edition: artwork redrawn in a warmer, folksier register, card content rewritten toward their audience, a "Cracker Barrel Exclusive" badge on the front of the box. I dropped the price from $12.95 to $9.95, with a $5.00 wholesale cost, to land where their shoppers expected an impulse buy to sit. The margin was painfully thin. Honestly, at those numbers we'd have run at a loss for a while, until the print quantities climbed enough to bring the unit cost down.

By the time I came back with the follow-up pitch, in November 2003, I'd changed the words around it too. The first time, I'd sold a game. Now I called it "family entertainment akin to your books on tape" — borrowing a category Cracker Barrel already stocked and understood, the audiobooks people bought for long drives. Same product. I'd just learned to describe it in their language. And it wasn't marketing B.S.; our game really was the perfect road trip game. Still is, actually.

The piece I was proudest of never ran. I designed table-topper playable ads, the little tent cards that stand between the salt and pepper and the peg board game, so a family eating biscuits waiting on their entrees could read about the game, play a sample card, and then grab a copy on the way out past the register. The placement was the whole idea: catch people in the idle fifteen minutes before the food arrives, in the exact building where the product is for sale. It seemed like a no-brainer.

Then it went the way these things sometimes go: without warning, the buyer pulled the plug. No drama, no explanation that made it into the file. Down Home went from "let's do this" to silence, and I never got the post-mortem. A budget, a reorg, a category reset, a champion who moved on — one of the ordinary ways a deal dies inside a big company. I'll never know which one it was.

The deal falling through stung, but deals fall through, and that's not the part that stayed with me. The design pivot did. Re-imagining Down Home as its own edition forced me to build a working model of a customer I'd never pictured — "the Cracker Barrel shopper" — and design backward from her. Where would she be standing the first time she saw the box? What price would feel like a treat instead of a decision she had to weigh? I was a kid doing brand strategy with none of the vocabulary for it, only because a buyer had told me no in a way specific enough to answer. I don't think I missed by much.

Oddly, all these years later, the Down Home Edition would still fit Cracker Barrel. The art still sits in the project folder, a few directories over from the edition that actually shipped — a whole game, tailored to a restaurant chain, that exists only as files. The box that almost was, parked next to the box that was. You win some, you lose some, you hopefully learn a little either way.

When the LLM Isn't the Product

Stalefish Labs — Tue, 21 Jul 2026 13:31:04 +0000

One morning in late June, the pipeline that builds the Citizen's Daily Brief generated an item calling the mayor of New York City "Zoe Mamdani." A few words later it called him "herself," with the same easy confidence it brings to everything.

The mayor of New York is Zohran Mamdani. He had not, in the intervening hours, changed his first name or his gender. The model had invented both and written them down without a flicker of doubt, in clean declarative prose, sitting inches from a structured data field that had his name spelled right the whole time.

I could tell you this is a story about an AI making a mistake. Yet another "don't trust the insane hallucinating machine" take. Most AI writing this year is, one way or another, a story about the AI: here's what ours can do, watch it generate and analyze and predict, look how smart it is. The model plays the lead.

I want to tell you the opposite story. The interesting thing about the Zoe incident is the field three inches away that was correct, and the unglamorous machinery that now compares the two before anything reaches you. That machinery is the product. The model is a part I could swap out.

The Citizen's Daily Brief uses Claude for every analytical step in its pipeline: clustering news sources, scoring significance, synthesizing assessments, generating weekly analyses. LLM inference is literally the most expensive line item in the budget, which is admittedly not saying much when everything else runs on free tiers. And yet if you ask me what the product actually is, the answer has nothing to do with AI.

The product is the format.

The Format Is the Innovation

The Citizen's Daily Brief is a finite daily artifact with a fixed structure. Five to nine items, each with a headline, a "what changed" section, a "why it matters" assessment, a "what's next" forward look, and an evidence panel showing sources, confidence, agreement, and the points where the sources disagree. Published once per day. Same brief for everyone. No personalization, no infinite scroll, no engagement optimization. I don't want your attention, I want you informed.

A single item, stripped to its bones, reads something like this:

EU fines AliExpress €550 million for counterfeit and illegal goods under the Digital Services Act
What changed: The European Commission issued a record €550 million fine against AliExpress, the Alibaba-owned platform, for failing to keep illegal, unsafe, and counterfeit goods off its marketplace.
Why it matters: It sets a concrete enforcement benchmark for the Digital Services Act: a signal that the EU will levy heavy penalties on large non-European platforms that don't police their own marketplaces.
What's next: Whether Alibaba appeals through the EU courts, and whether other big platforms tighten their moderation preemptively.
Evidence: 5 sources · confidence: moderate · sources broadly agree.

That's the product. Not "AI-powered news analysis." Not "intelligent news curation." A briefing document. A specific format borrowed from the intelligence community and adapted for public consumption.

The AI enables the format. It doesn't constitute the format. Swap out Claude for a team of human analysts and the product would be identical: same structure, same trust signals, same editorial voice. It would just cost a thousand times more, take longer, and apply the methodology less consistently. A human analyst has bad days. The pipeline runs the same rubric every morning at the same hour, in the same mood, which is no mood at all.

This framing — AI as infrastructure rather than product — inverts the typical narrative, and I think it's the more honest way to think about most AI applications. Once the novelty wears off, and the AI equivalents of all the early iOS fart apps have gone away, I suspect that this is what we'll be left with.

Infrastructure Means Invisible

When you use an app backed by PostgreSQL, nobody tells you about the database. You don't see "Powered by Postgres" in the footer. The product team doesn't write blog posts about their query optimizer. The database is infrastructure: essential, invisible, valued for staying up rather than for being clever.

That's how I think about the LLM in the CDB pipeline. It's a reasoning engine that sits between structured input and structured output, transforming data according to well-defined constraints. It's called via API, returns JSON, and is validated before its output reaches anyone. If it goes down, the pipeline retries once and then skips the day. If it produces garbage or inadvertently reassigns the mayor of New York a new first name and gender, the validator catches it.

The LLM doesn't talk to users. It doesn't have a chat interface. Readers never interact with it, never prompt it, never see its raw output. They see the formatted result of its work, wrapped in a structure that I designed and validated against rules that I wrote. The LLM provides the analytical reasoning. Everything else — what questions to ask, what format to require, what counts as valid output, how to present it — is product design.

How the System Learned People's Names

Back in March, that same pipeline referred to President Trump as President Biden.

My first fix was the obvious one. I handed the model a block of current officeholders — the president, the cabinet, a handful of world leaders — and injected it into every prompt. Here is who currently holds which office; do not get this wrong. It worked. It was also a hack, and I knew it while I was writing it. A hardcoded who's-who goes stale the moment a secretary resigns (or more likely in this case, is fired) and it only covers the names I thought to list.

So I tore it out. Instead of telling the model who's who, the pipeline now reads the day's own sources and extracts the (role → name) pairings itself, trusting one only when at least two independent sources corroborate it. I added a rule for a specific failure I kept seeing: a current and former holder of the same title getting swapped inside a single item, Pope Leo XIV becoming Pope Francis halfway through a paragraph. Two sources, grounded in the corpus, disambiguated by office. Cleaner. More general. I figured names were solved.

Then June, and Zoe.

What made the Zoe miss different is the part I keep coming back to. The model got the name right in the structured timeline field and wrong in the prose, in the same item, seconds apart. No amount of "here is who currently holds office" catches that, because the system already knew who he was. It just contradicted itself on the way out the door. It felt less like hallucination than like the machine forgetting, mid-sentence, something it had known a field ago.

The fix wasn't a smarter prompt. It was dumber than that, on purpose: a deterministic check, plain code, no model call, that reads every field of an item and flags any surname that appears with two different first names. If "Mamdani" shows up as both "Zohran" and "Zoe," the item never ships. I also let the prose-writing step see the structured timeline it was supposed to match, and added a weekly pass that re-checks every name against the week's own items.

That check, in its first version, was too eager. It started flagging ordinary words that happened to look like colliding names, and I spent a following evening teaching it the difference. The fix needed a fix. This is what maintaining infrastructure actually feels like — not a triumphant demo, but a series of small, specific, slightly embarrassing corrections that make the thing quietly harder to break.

What This Means for Trust

Here's where the infrastructure framing earns its keep.

When the AI is the product, users have to trust the AI. They have to believe the model is smart enough, unbiased enough, reliable enough. Every hallucination story and every "AI confidently wrong" headline chips at that faith, and the product is only ever as credible as the model behind it.

When the AI is infrastructure, trust shifts to the system around it. You don't have to believe the model never invents a name. From experience, it does. You have to believe that when it does, something boring and deterministic is standing between the mistake and your screen. The confidence levels, the agreement signals, the cited sources sitting right there under each item: those are all versions of the same promise. Not trust the model, but check the work — here's the work.

This is the intelligence community's oldest move. The President's Daily Brief doesn't say "trust us because we're smart." It says here's what we assessed, here's the evidence, here's our confidence, here's what we still don't know. Credibility comes from the shown reasoning. Zoe is the reason I believe that, and not just quote it.

Someone Already Read the Spread

There's a class of tools I admire that comes at this from the other end. Take one story, line up how outlets across the spectrum covered it, tag each source for bias and reliability, and surface the gaps — the piece the left led with and the right ignored. The promise is media literacy: here's the whole spread, now you can see the spin and decide for yourself.

The Brief points the same distrust of the single feed at the opposite workflow. Instead of handing you the spread, it reads the spread and hands you the assessment: one item, what changed, why it matters, how sure it is, where the sources fight, what's still unknown. The spectrum still does the work — significance scoring literally weights a story by how many distinct editorial perspectives are covering it — but that happens upstream, in the pipeline, so it never lands on your plate as twelve headlines to reconcile before breakfast.

These are peers aimed at the same disease from different directions. One says see everything and trust yourself; the other says here's the call, and here's the work behind it. I built the second because most mornings I don't want to run a media-bias seminar. I want the brief, and I want to be able to check why it says what it says.

Boring on Purpose

A product built to show off the model has a shelf life. It's thrilling in the demo and thinner every month after, because the novelty was doing the work, and novelty is the one ingredient guaranteed to spoil. When the trick stops being surprising, there has to be something left.

So the Daily Brief is boring on purpose. Nobody opens it and thinks "wow, an AI wrote this." They open it and think "what happened yesterday." The format is decades old, the content is just the world, and the whole thing is dressed to be trusted rather than to impress. There's no reveal to wear off, because there was never a reveal. If I've done my job right, the AI part of this project recedes to the background just like the Postgres database you don't care about.

This means the product doesn't need AI to get better over time for users to keep coming back. And it doesn't need to write flowery prose. All it really needs is for current events to keep happening, for the world to keep spinning with us on it, which is a reasonably safe bet. The AI really just needs to keep doing its job reliably — clustering, scoring, synthesizing, validating — the same way a database just needs to keep storing and retrieving data reliably.

So What IS the Product?

If the AI is infrastructure, the product is the answer to a design question: what format would make a busy person feel genuinely informed in ten minutes? Every decision in the app is downstream of that one sentence.

Five to nine items, because fewer than five misses something and more than nine feels like homework. Significance scoring, so the day sorts itself by weight instead of by whatever broke last. Confidence and agreement on every item, because a busy person deserves to know how sure the assessment is before they act on it. A "what's next" on every item, because knowing where a story is heading is half of being informed about it. One brief a day, and then nothing, because the second scroll of the morning has never once made anyone wiser. The AI executes all of this at a scale I couldn't touch by hand. The judgment underneath it — what to ask, what to require, what counts as good enough to ship — is mine, and it's the part that took the years.

So here's the test I'd hand any AI founder. Describe your product without saying "AI," and see if it still sounds like something a person would want.

Mine survives it: a daily briefing that tells you the handful of things that actually mattered yesterday, shows you how confident it is and what its sources fight about, and then leaves you alone until tomorrow. A think tank could produce that. A very dedicated journalist could produce that. The AI is how it gets produced cheaply enough to give away, which is the only reason it exists, but it's not why you'd read it. If your product only holds up while the AI is still a novelty, you don't have a product yet. You have a fart app with a subscription page.

That's not a modest role for the model to play. Databases don't get enough credit either. But it is an honest one.

The Citizen's Daily Brief is a free daily intelligence briefing from Stalefish Labs.

Pitching a Card Game to 70 Dead Retailers

Stalefish Labs — Tue, 07 Jul 2026 20:33:32 +0000

There's a folder sitting on my computer in the Tall Tales project named, with no imagination whatsoever, "Cover Letters." Inside are 113 of them, written across 2002 and 2003, most addressed by hand to a specific buyer at a specific retail chain I hoped would carry the game — about seventy retailers in all, since the bigger chains got more than one letter. I looked the addresses up one at a time and tailored every letter. Most of those companies are now dead.

Not struggling. Not pivoting. Gone.

Tower Records. KB Toys. Blockbuster. Hollywood Video. Borders. Zany Brainy. Musicland. The Discovery Channel Stores. I pitched all of them. FAO Schwarz, which has changed hands so many times since that the name now means more than the company does. Spencer Gifts, which mostly lives online and in the few malls that somehow outlasted the rest. Reading the list back is less a review of a sales campaign than a walk through a cemetery where I happen to know every name on the stones.

There's a shorter list that stings a little more: the retailers that are still standing and still said no. Walgreens. REI. Cabela's. Bass Pro. Hallmark. Barnes & Noble. Target. Caribou Coffee. Peet's. There's no era-ended excuse to soften those. No casket I can look at and delusionally think, "my game might've saved them." No, they're still out there selling things today. The thing they declined to sell was mine.

Partway through the campaign I decided the way to cut through was to write to people instead of companies, and those letters are the best thing in the folder. The idea was an end-around on the corporate buyers: drum up interest directly with people tied to the game — some named on its cards, some just kindred spirits — and with a few in the press who might talk it up.

I wrote to G. Gordon Liddy of Watergate infamy — the game had a card about him — and couldn't help adding a note: "Dancing Queen wasn't released until 1976, so you would've really been ahead of your time to have hummed it during the Watergate incident." I wrote to Penn & Teller, pitching Tall Tales as "a game in the same spirit as your show Bullshit!" I wrote to Terry Gross at Fresh Air with a line I still mostly believe: "we like to think we're resurrecting the lost art of storytelling."

None of the people answered. A few stores did.

That's the quietly brutal part. Out of 113 letters, the return was a thin scatter of form rejections and, mostly, silence. Two addresses turned into something real. Starbucks wrote back, evaluated the game, and passed — a near-miss with its own story. Cracker Barrel went further than any of them: I met the founder/CEO and designed a custom edition of the game before they ultimately decided to pass. That one earned its own story, too.

Here's what I couldn't see then and can't unsee now. In 2002, mailing 113 letters to toy buyers, music chains, outdoor outfitters, Watergate burglars, and magicians was a real distribution strategy. There were that many doors, and a small company with a clever product and a roll of stamps could plausibly reach a national shelf. Run the same campaign in 2026 and it falls apart on contact. Half the companies don't exist. The survivors buy through distributors and category managers stacked ten deep, and a cold letter from a one-person game company would reach a recycling bin, assuming it arrived at all. The road I was walking got paved over. That doesn't even touch the weirdness of mailing a physical letter to a celebrity now.

So the folder has become something other than a sales archive. It's a core sample of a specific American retail moment — the one just before big-box consolidation and the internet finished rearranging the shelves. 113 envelopes to seventy-odd retailers, a whole landscape of places you could once walk into and find a strange little card game. Most of those places are gone now.

The letters outlived the companies they were written to. I kept them anyway, the way I kept the games.

Guardrails, Not Gatekeepers

Stalefish Labs — Fri, 26 Jun 2026 05:04:47 +0000

The Citizen's Daily Brief has no human editor. No one reviews the assessments before publication. No one approves the significance rankings. No one checks whether the confidence levels feel right. The pipeline runs, the brief publishes, and readers see the output of an entirely automated system.

That sounds reckless. It isn't.

The Editorial Instinct

The first version of the pipeline had a manual human review step. After synthesis, the brief items were written to a staging table, and I'd review them each morning before flipping them to "published." It was comfortable. I could catch errors, adjust wording, add context. I felt like a responsible steward of the product.

It lasted three days. On day four, I realized the review step was doing two things: occasionally catching formatting issues (the LLM forgot a field, a headline was too long) and making me feel better. The formatting issues were mechanical — I was doing the same checks every time. And the "feeling better" part was actually the problem.

Because what I was really doing was applying editorial judgment to the output. Did this assessment feel right? Was the confidence level appropriate? Should this story really be ranked above that one? These are the exact kinds of subjective editorial decisions that the pipeline was designed to make transparent and systematic. By inserting myself as a reviewer, I was undermining the system's consistency and putting a human hand back in the output, one readers couldn't see and couldn't audit. That hand was the exact thing the CDB was built to remove.

So I replaced myself with a validator. Mechanical rules. No judgment, no feelings, no editorial instinct. Just constraints.

What the Validator Checks

The validator is a Python module that runs after synthesis and before publication. It checks every brief item against a set of structural rules, and it either passes or fails each item. There's no "close enough." There's no "use your best judgment." It's binary.

The first checks are structural. Every required field has to be present and non-empty: headline, what_changed, why_it_matters, confidence, agreement, all mandatory. (The what_to_watch field is nullable; some days there genuinely isn't a clear next step to watch for.) This catches the occasional LLM omission where a field comes back present but empty. Length limits sit alongside the schema. Headlines run under 200 characters, what_changed is held to one to three sentences, why_it_matters can't exceed a paragraph. The format is built for fast reading, and an LLM given room will happily write three paragraphs where one would do. The limit is "be concise" rewritten as something a machine can enforce.

Then the check that does the most work: trust signal consistency. High confidence requires two or more independent sources. You can't claim it from a single report. That's moderate at best, and the validator says so. "Broad agreement" works the same way; it takes multiple sources actually agreeing, and one source can't agree with itself. The rule exists because the LLM sometimes over-indexes on a single strong source. If the White House issues a clear, detailed statement, the model might reach for high confidence because the source is authoritative. Authoritative or not, single-source confidence is moderate by definition, full stop. The White House might be wrong, might be incomplete, might be framing strategically. High confidence requires independent confirmation.

The last shape rule the validator enforces is a floor. A valid brief needs at least three items; if fewer than three clear every other check, the whole brief is skipped, so a source outage or a quiet news day can't ship readers one or two items that don't add up to a picture of anything. There's a ceiling too — nine items — but the validator never checks it. That limit lives upstream, at selection, where the model is told to mark at most the nine most significant stories and to prefer fewer on a quiet day. The floor is a hard gate; the ceiling is a guideline the brief rarely reaches.

The "Publish Nothing" Principle

The validator's response to a failed check is simple. Nothing publishes. Better no item than an incomplete one.

If an individual item fails validation, it's dropped. The remaining items are renumbered and checked against the minimum count. If the brief still has three or more valid items, it publishes without the failed item. If it drops below three, the entire brief is skipped for the day.

This is the "publish nothing rather than publish garbage" principle, taken from intelligence analysis, where an assessment that can't meet the sourcing and confidence bar is held back rather than shipped with a hedge attached. A briefing that carries a wrong or weak call is worse than no briefing at all, because the bad call could get acted on. Better to skip a day and keep the trust contract intact than to publish something under the bar.

In practice, this has triggered twice during testing. Both times, a source outage produced an unusually thin input set (fewer than ten source records when the pipeline normally ingests twenty to thirty), and the resulting clusters didn't produce enough significant stories to fill a brief. Both times, skipping was the right call. A three-item brief based on a handful of sources wouldn't have met the product's standard.

Why Mechanical Beats Editorial

Once I decided high confidence takes two or more sources, that became true for every item, every day. A human editor would hold to it most mornings, and "most mornings" is exactly the gap. Say the only source on a Federal Reserve rate decision is the Fed itself — authoritative, detailed, the kind of source a careful editor waves through on instinct. The validator has no instinct. It counts sources, finds one, marks the confidence down to moderate.

This consistency is the point. If "high confidence" meant one thing on a Tuesday and another on a Friday, or one thing rested and another rushed, the term would be worth nothing. Mechanical validation is what keeps it worth something: every trust signal in every brief, measured against the same criteria.

The rule underneath all of this: an editorial decision you can write as code is one you make once, deliberately, and one a reader can audit later. If a quality criterion requires subjective judgment — "does this assessment feel balanced?" — it's not a criterion, it's a vibe. And vibes don't scale, don't reproduce, and don't earn trust. A constraint you can express as a Boolean check in Python is a constraint that readers can understand, evaluate, and trust. It still strikes me as odd, even having created this thing, that this is a decision system where the cold, binary logic of a machine is a better option than a careful, conscientious human.

Constraints as Design Decisions

Every rule in the validator started as a question I asked about quality, and the answer got encoded permanently.

Should a brief item be allowed to claim high confidence based on a single source? No. → Rule: if confidence == "high" and source_count < 2: fail

Should items be allowed to have empty "what changed" fields? No, because "what changed" is the most important field — it's the reason the item exists. → Rule: if not what_changed or len(what_changed.strip()) == 0: fail

Should headlines be allowed to be arbitrarily long? No, because long headlines aren't headlines — they're summaries wearing a headline costume. → Rule: if len(headline) > 200: fail

Should a brief with only two items be published? No, because two items doesn't give readers a meaningful picture of the day. → Rule: if len(valid_items) < 3: skip_brief()

Each of these is a judgment call. But they're judgment calls made once, deliberately, with time to think — not judgment calls made at 5 AM under time pressure while reviewing a specific brief's output. The validator is the accumulation of my best editorial thinking, frozen in code where it applies consistently forever.

What the Validator Can't Catch

The validator is not a fact-checker. It can't verify that the LLM's assessments are accurate. It can't determine whether "why it matters" is insightful or obvious. It can't judge whether the significance rankings reflect the day's actual priorities. And that's not its job.

These are real limitations. The system's defenses against analytical errors are different from validation: they're the constrained input (curated sources, not the open web), the structured prompts (tight field constraints that reduce the surface area for hallucination), and the trust signals (which give readers the tools to evaluate each assessment themselves).

The validator handles the structural layer. Did the output conform to the schema? Are the trust signals internally consistent? Are the field lengths within bounds? These are the questions that mechanical rules can answer, and answering them mechanically is more reliable than answering them editorially.

The analytical layer — is this assessment correct? — is ultimately a question for readers. The validator ensures they receive well-structured, internally consistent items. The evidence panel ensures they have the data to evaluate those items. The methodology page ensures they understand how the system works. Together, they hand the gatekeeping to readers themselves. No human stands in for them.

Guardrails, not gatekeepers. A gatekeeper makes calls no one else can see. A guardrail is a rule on the methodology page, in plain Python, applied the same way every morning, and any reader who doubts a call can pull it up and check it. The CDB has no editor. It also has nothing an editor would have kept off the page.

The Citizen's Daily Brief is a free daily intelligence briefing from Stalefish Labs.

Deliberately Boring by Design

Stalefish Labs — Fri, 26 Jun 2026 05:04:46 +0000

Every app I've built at Stalefish Labs has personality, and the underlying purpose of each has usually tilted toward fun. Ridewise transforms weather data into trail conditions to get you outside riding with friends. Muster in many ways acts as a session-based Instagram for helping people get together and share experiences. Even a smaller web experiment like the Jump Simulator, which is fundamentally a physics calculator, has ghost trails and animated motorcycles flying through the air. It's kind of a modern Fuji Hakayito that hopefully doesn't lead to epic jump fails in real life. What I'm saying is I like making things that are fun to use.

The Citizen's Daily Brief has none of that. And it's the most interesting design decision I've made.

The Anti-Pattern Pattern

Open the Daily Brief and you'll find a single column of text on a near-white background. Serif typeface. No hero images. No cards with rounded corners and subtle shadows. No gradient accents. No animated transitions. No skeleton loading screens. The whole thing looks like it was printed on government letterhead and scanned to PDF, except it's implemented as a website and iOS and Android apps.

The toned-down design wasn't laziness or a placeholder that stuck. Every element of the design is a conscious rejection of something.

No personalization. Everyone gets the same brief. Your brief is my brief is everyone's brief. There's no algorithm deciding you care more about tech than foreign policy, no engagement model learning that you linger on economic stories. One brief, one audience, one shared reality. No personalized information bubble.

No engagement optimization. Nothing is designed to keep you on the page. No related stories sidebar. No "you might also like" recommendations. No notifications begging you to come back and stay a while. The ideal user session is: open, read, close, go live your life.

No hero images. News images are editorial choices disguised as objectivity. A protest photo can frame the same event as righteous or chaotic depending on the shot. The brief has no images because images are opinions wearing the costume of documentation. Text forces you to engage with what happened rather than how a photo editor decided it should feel.

No infinite scroll. The brief has between five and seven items. You read them, and you're done. There is no "more content below the fold" because there is no fold. The brief is finite. There's one a day, and each one ends. That's the feature.

Why Boring Is the Point

The aesthetic isn't arbitrary. It's a big part of the idea.

The Citizen's Daily Brief is modeled on the President's Daily Brief, the intelligence document delivered to the U.S. President every morning. The PDB isn't designed to be engaging. It's designed to be trusted. It communicates through structure, precision, and restraint. It says: this is what we think you need to know, this is how confident we are, and this is what we don't know. The format is the credibility.

When I started designing the CDB, I prototyped a version with visual cards for a nicer layout. Each brief item was a styled card with a topic tag pill, a headline, expandable sections, and a colored confidence indicator. It looked like a modern news app. It looked great. And although it was pretty, it felt completely wrong.

The visual polish created an expectation of entertainment. I worried readers would approach it the way they approach any well-designed content feed — skimming for what catches their eye, looking for the most interesting card, treating it as a buffet. But the brief is a checklist. Every item is there because the system carefully determined it matters, and the order is the order of significance. Skimming defeats the purpose.

The institutional aesthetic solves this. When something looks like a government report, you read it like a government report. Top to bottom, item by item, with the implicit understanding that someone (or in this case, some thing) already did the work of deciding what matters and in what order. You're not browsing. You're being briefed.

Fonts for Comprehension

The typeface choice tells you everything about the intent. The body text is set in Georgia, a serif face that says "document" and "permanence." It's the typeface of printed reports, academic papers, and the kind of writing that expects to be taken seriously. Almost every modern app and news site has moved to sans-serif faces — Inter, SF Pro, Roboto — because they feel clean, fast, and contemporary.

Georgia feels slow. That's the point. You read Georgia at the speed of comprehension, not the speed of scrolling.

The metadata — topic tags, dates, confidence labels — uses a sans-serif. This creates a visual hierarchy that separates the institutional voice of the assessment from the mechanical voice of the system's metadata. The brief items speak in Georgia. The scaffolding speaks in sans-serif. When content is stripped bare, you process it differently without thinking about it.

The Color Non-Palette

The CDB uses exactly two colors: near-black text on a near-white background, with a single accent of slate blue for interactive elements and topic tags. Not pure black on pure white (that's actually harder to read), not the warm off-whites that lifestyle brands use, and certainly not a kaleidoscope of dopamine-grasping color. The CDB uses a cool, institutional near-white that reads as "official."

The slate blue (#2c4a6e) was chosen specifically because it's boring. It doesn't evoke tech (that would be a brighter blue), it doesn't evoke urgency (that would be red), and it doesn't evoke nature or wellness (that would be green or teal). And I'm a guy who can't get enough earth tones, but I wanted a "just the facts" look here. So it evokes... filing cabinets. Government websites. The blue of a seal on an official document. It's a color that communicates authority through its complete lack of personality.

There are no gradients. The brief items cast no shadows. No color-coded categories. The trust signal indicators use bars rather than color alone, because one of the accessibility rules I follow is never relying solely on color to convey information. But even without that rule, I'd have avoided it. Color-coding news categories is an editorial choice — it teaches readers that "politics" is red and "technology" is blue, creating categorical associations that the brief deliberately avoids.

What It Costs to Be Boring

Oddly enough, I learned that restraint is more work than expression. Every modern CSS framework, every component library, every design system is optimized for making things look polished and engaging. Building something that looks deliberately institutional means fighting your tools at every step.

I stripped the shadows off the brief items that carried them by default. I overrode the border-radius values that rounded the reading surface automatically. I resisted transition animations that made elements fade and slide. I kept links to a quiet treatment: slate blue, underlined on hover, with none of the sliding underline animations modern sites layer on. The short timeline of dated developments that runs under each brief item reads as plain monochrome dots, not the colored, animated progress rail the component shipped with.

The evidence panel — the expandable section under each brief item that shows its sources, how strongly they agree, and how each camp framed the story — was the hardest to keep boring. It's full of data that begs to be charted: confidence and agreement levels, source counts, a breakdown of framing across the spectrum. Every instinct says to make these visually rich. Instead, they're rendered in the same institutional style as everything else. Simple bars. Plain checklists. Labeled paragraphs. The data speaks for itself without visual embellishment telling you how to feel about it.

The Contrast Is the Brand

Here's the thing that makes all this work: the Citizen's Daily Brief exists in a portfolio alongside apps with personality. Open Wheelers has fantasy F1 animations and visual stats that show which drivers have scored you the most points and where your picks overlapped with rival managers. Muster has interactive in-or-out declarations and post-session media sharing and comments. The Ramp Designer has a 3D rendered skateboard ramp you can flip, spin, and explode. Sojourn paints a rich, layered bedtime storytelling experience complete with reader-triggered audio foley effects and subtle fireflies lingering in the interstitial animations. When someone discovers that the same studio made all of these things, the CDB's austerity becomes a statement rather than a limitation.

It says: we know how to make things engaging. We chose not to. And that choice is itself the most engaging thing about the product.

The design philosophy is countercultural. In an attention economy where every app fights to monetize your time, the CDB is designed to give your time back. Most products signal credibility through visual sophistication; this one earns it through the quality of its assessments and the transparency of its reasoning. The design world's highest compliment is "delight." The CDB aims for something rarer: trust.

Restraint is harder than flourish, and for a product asking to be trusted, it's the whole job. The brief shows up, tells you what it thinks you need to know, and gets out of the way. Then it waits until tomorrow.

The Citizen's Daily Brief is a free daily intelligence briefing from Stalefish Labs.

Using Fun to Repair the American Family

Stalefish Labs — Wed, 24 Jun 2026 13:30:42 +0000

Mama used to roll her hair, back before the central air. We'd sit outside and watch the stars at night. She'd tell me to make a wish, and I'd wish we both could fly. Don't think she's seen the sky, since we got the satellite dish.
— James McMurtry, "Levelland"

The Decline of the American Front Porch

Prior to World War II, the front porch represented the American ideal of family. The porch, in essence, was an outdoor living room, where the family could retire after the activities of a long day. In the evenings, as the outdoor air provided a cool alternative to the stuffy indoor temperatures, the entire family would move to the front porch. The children might play in the front yard or the friendly confines of the neighborhood, while the parents rocked in their chairs, dismissing the arduous labors and tasks of the day into relaxation and comfort. Stories might be told, advice garnered, or songs sung. What the family room of post World War II America would become, existed first as the front porch.

The porch did something else as well, something easy to overlook now that the porches are mostly gone. It faced the street. A porch was a room with one wall left open, and a whole block of them turned an ordinary street into something larger than a row of houses. Neighbors passing on the sidewalk were in plain view and near enough to greet; a wave could slow into a conversation, and a conversation could end with someone climbing the steps to sit a while. News and gossip and small kindnesses moved house to house in the evening air. Children roamed the block under the loose, shared attention of every adult sitting out, all of whom knew whose child was whose. So the front porch did more than move a family outdoors for the evening. Every household sat in view of every other, night after night, and out of that ordinary visibility a neighborhood held itself together.

In the period immediately after World War II, the American front porch became a relic of the past, an architectural feature and cultural symbol no longer important to Americans. The primary technological change that spurred this abandonment of the front porch was the proliferation of the American automobile. The new technological development of air conditioning further aided in the decline of the front porch. Providing a cool(er) environment indoors, the front porch was no longer needed as a cool shaded area during the day or as a place to enjoy the cool night air. Families remained indoors comfortably, and a primary use of the front porch was no longer needed. Air conditioning, in a sense, also contributed to another technological development which would affect the front porch: the television. The television, which could exist only inside, provided endless hours of entertainment indoors. As a result, family life shifted from the porch to a family room or television room, where families could watch the evening news, sporting events, or the early sitcoms, all while enjoying the newly invented "television dinner." No longer would families relax outside on the front porch.

America had become overtly more individualistic and less community oriented during this period. At the same time, the traditional American importance given to the family had declined. Familial structure and relations had changed, lending to less family interaction and family time. While this connection to the decline of the front porch is a stretch, it certainly may have played a role.

By the 1960's, the front porch had disappeared in the new architectural forms and houses sweeping the country. Technological and cultural forces had pushed porches to the back or side yard, or had eliminated them altogether. American society had changed, and with this change the front porch no longer stood as an American cultural symbol. Few Americans noticed this change, and the front porch disappeared into the realm of American memory. In many ways, family interaction disappeared along with front porches.

We don't say any of this to wish the era back. That world was, for a great many people, a worse one to live in, and its neighborly streets were never equally open to everyone who might have walked down them. What disappeared that we'd actually want returned is narrow: the plain habit of being in easy view of other people, evening after evening. That habit belongs to no particular decade, which is the only reason we think it can be had again.

Bringing Families Back Together

So, is the solution to the problem of lost family interaction to lead a porch building campaign across the country? Probably not. America has permanently changed since the days when the front porch served as the glue holding our communities together. However, this doesn't mean that the fight to restore interaction to families has been lost. The challenge is to figure out ways to work with and around technology to bring people together in different ways.

Technology really isn't a bad thing, we just need to figure out when and where it is the most beneficial in our lives. It isn't too hard to see that a family that sits in front of the television every night will be less connected than a family that communicates around a dinner table. Or more to the point, a family that plays a social game together will have shared more and grown closer than a family that goes to watch a movie.

America is a highly entertainment driven culture, and we don't aim to change that. In fact, we're all for entertainment. What we're suggesting is that people entertain themselves in ways that help enrich the relationships they have with other people. We've found that one of the best forms of entertainment for fostering relationships is traditional games such as board games, trivia games, scavenger hunts, and the like. We regularly play such games at gatherings with friends and family. We've found that people are pleasantly surprised at how much fun it can be to connect with other people socially in the context of a game.

The fact of the matter is that you really don't need a front porch to become a part of your community or get closer to your family and friends. You just need to make an effort to interact with them, preferably in a fun setting.

It's a Vital Part of Growing Up

Watch a child play a game. It looks like nothing — like time being pleasantly killed. It isn't. The six-year-old losing at Candy Land is learning that the world doesn't always break her way, and that you stay at the table anyway. The boy fidgeting through someone else's turn is practicing the single hardest thing a small person ever has to do, which is wait. Kids at a game are settling rules, catching each other cheating, arguing out what counts as fair, and reading the face across the board to decide whether a bluff is real. None of that is printed on the box. All of it is the point.

Play is how people learn to be people. It is the first safe place a child gets to try on cooperation and competition and get them wrong without anything real breaking. You can lose at checkers and the sun still comes up the next morning. You can win and discover, fast, that gloating costs you the next invitation. The stakes are small enough to risk and big enough to teach — which happens to be exactly the size of stakes a person grows on.

We never stop needing that. A family around a card table is doing the same work the children are: a teenager and a grandfather made briefly equal, both at the mercy of the same rules and the same rotten luck of the draw. A couple can learn more about each other over a board on a quiet Tuesday than over a month of sitting side by side facing the same screen. The reunion that might have been an afternoon of careful small talk turns instead into a tournament nobody shuts up about for the next ten years. A good game hands people a reason to stay in the same room and something to do once they're in it. For anyone who has ever run dry of things to say to someone they love, that is no small gift.

This is the part the front porch used to handle without anyone naming it. The porch wasn't magic. It was a place that made staying together easy and gave people something to do while they did it. Take away the porch and the need stays right where it was. What's gone is the easy way of meeting it, so the need goes looking for somewhere else to land.

Why We Build Games

Here is what we are for. We make games because a good one does something almost nothing else does this cheaply or this well: it gets people to look at each other. Set a deck of cards down between two people who have run out of things to say, and watch them find something. That is the entire business we are in. It is also, as it happens, why a company that wants to repair the American family would start by making a game rather than building a porch.

We have nothing against the television, or the automobile, or the cool dry air pouring out of the vents. They won. They were never really the enemy, and we have no interest in fighting a war we'd lose and shouldn't win. What we'd like to fix is smaller and a lot closer to home: the ordinary evening that quietly dissolves into everyone alone in the same house. There's a cure for that, and you can hold it in two hands and set it on a table.

You don't need a porch. You need a table, a few people you'd like to know a little better, and a reason to stay a while longer. We intend to spend our years making the reason. Pull up a chair.

A note, added much later. We drafted this in our founding year, when the screen we worried about was the one in the living room. There are more screens now, and they are far better company than any television ever managed to be — in your pocket, tuned to you, refreshed without end, and lately able to answer back when you talk to it. The first social network in this country ran on front porches, open to the street and refreshed each evening by whoever happened to walk past. We have spent the decades since rebuilding it indoors, behind glass. None of that softens the argument. It sharpens it. The question we started with is the one still on the table: when, and where, does the technology actually carry you toward the people in the room instead of away from them? We began as a game company and grew into something wider, a studio for whatever seems worth making — from that first printed deck to a skate ramp you design on a screen and then go build, to a jump simulator, to apps and odd little web experiments that have nothing to do with cards. The form keeps changing; the job underneath it hasn't. Get people into the same room, the same yard, the same patch of real ground. That is still the porch's old work, and still the wager behind everything we make.

Thirty-Four Feeds and a Philosophy

Stalefish Labs — Tue, 23 Jun 2026 21:00:39 +0000

The Citizen's Daily Brief ingests news from thirty-four RSS feeds. That number started at twenty-seven, and grew incrementally during testing. It grew because the original list had a gap that would have undermined credibility: it didn't include enough sources from across the political spectrum to claim it was seeing the full picture. The CDB isn't a political product — it's apolitical by design, and keeping it that way meant expanding the source feeds.

The source strategy is one of the most opinionated decisions in the project, and it's worth explaining not just what the sources are but why the list looks the way it does, and what changed when I realized the initial philosophy was incomplete.

The List

The thirty-four feeds fall into three tiers based on what kind of content they provide:

Tier 1: Full-text, free access sources. These are outlets where the RSS feed provides substantial content — headlines, summaries, and often full article text — without requiring a subscription or scraping. (No scraping anywhere in the pipeline, by the way — more on that later.) This tier includes government sources (White House, Federal Reserve, Congress.gov), international outlets (BBC World and BBC US/Canada, The Guardian US and World editions, Al Jazeera), public broadcasting and national news (NPR, PBS NewsHour, ABC News, CBS News), specialist publications (SCOTUSblog, ProPublica, Defense One, STAT News, Carbon Brief), and tech (Ars Technica).

Tier 2: Metadata via Google News filters and direct feeds. For wire services and outlets that don't offer rich RSS feeds, the pipeline pulls metadata — headlines, publication timestamps, and short summaries — through Google News topic filters or direct RSS. This covers AP, Reuters, Financial Times, Wall Street Journal, The Hill, Politico, War on the Rocks, The Verge, Fox News, New York Post, Washington Examiner, Daily Wire, Breitbart, National Review, and MSNBC.

Tier 3: Breadth signal. Google News Top Stories serves as a general-purpose signal for what the broader media landscape considers significant. It's not a primary source for any assessment, but it helps the clustering algorithm identify stories that are getting widespread attention even if they're not covered by the Tier 1 sources. Keep in mind that's a key requirement of the CDB: actually figuring out what qualifies as legit news you need to be aware of, separating signal from noise.

That's it. Thirty-four feeds, publicly disclosed, using only RSS and public APIs. No scraping, no expensive subscriptions, no API keys to news providers, no behind-the-scenes data deals.

Ingest Broadly, Weight by Diversity

The original version of the CDB ingested from twenty-seven sources. The list was carefully curated but had a structural blind spot: it included no explicitly partisan outlets from either side. Early on I thought that might be a benefit, but I later came to view it as a fail. No Fox News, no Breitbart, no MSNBC. The reasoning was sound on its face — opinion-primary outlets add editorial framing that complicates the clustering step, and excluding them kept the input clean.

The problem became clear when I thought about what happens downstream. The CDB claims to tell you "the most significant things that happened today." But if the source pool doesn't include outlets that millions of Americans actually read, the system can't detect stories that those outlets emphasize. A story that Fox News, the Washington Examiner, and the Daily Wire all lead with — but that NPR and the Guardian ignore — is invisible to a pipeline that only ingests NPR and the Guardian. That's not a clean input set. That's a blind spot. And a key motivator of the CDB from the outset was to pierce the information bubbles we all too easily live inside.

So the principle shifted: ingest broadly, weight by editorial diversity.

Partisan sources belong in the ingestion pool. They help the pipeline see stories that only one side of the spectrum covers. But significance should not be inflated by volume from a single editorial perspective. When five outlets that share the same editorial stance all cover the same story, that's not five independent signals — it's one signal amplified five times.

This is where editorial perspectives come in.

Editorial Perspectives

Every source in the CDB's feed list is tagged with an editorial_perspective — a label that identifies which editorial grouping the outlet belongs to. These aren't bias labels, even though a few of them do reflect bias. They're structural groupings based on observable editorial positioning and the kinds of stories each outlet tends to emphasize.

The twelve perspective groups are:

wire — AP, Reuters. Factual, non-editorial wire services focused on who/what/when/where.
public_media — NPR, PBS NewsHour. US publicly funded outlets with a mandate for balanced coverage.
broadcast — ABC News, CBS News. US commercial broadcast networks.
left_leaning — The Guardian, ProPublica, MSNBC. Outlets with left-of-center editorial positioning.
right_leaning — Fox News, New York Post, Washington Examiner, Daily Wire, Breitbart, National Review. Outlets with right-of-center editorial positioning.
business — Wall Street Journal, Financial Times. Business and financial press with market-oriented framing.
international — BBC, Al Jazeera. Non-US headquartered international outlets.
political_trade — The Hill, Politico. DC insider and political trade press.
official — White House, Federal Reserve, Congress.gov. Government primary sources.
specialist — SCOTUSblog, STAT News, Defense One, Carbon Brief, War on the Rocks. Domain-specific expert outlets.
tech — Ars Technica, The Verge. Technology-focused outlets.
aggregator — Google News Top Stories. Algorithm-curated, not counted as a perspective.

One thing worth flagging: the perspective list groups by outlet, but the "thirty-four feeds" count is by feed. A few outlets — BBC and The Guardian, for example — contribute multiple regional feeds, which is why the math doesn't line up exactly if you start counting rows.

The significance scoring system uses these perspective groups to measure editorial diversity. A story covered by four sources across four different perspectives (say, wire + right_leaning + public_media + business) is genuinely more significant than one covered by five sources that all share the same perspective (say, five right_leaning outlets). The pipeline counts distinct perspectives, not distinct URLs.

Even the most well-intentioned "I read everything" reader can't realistically aggregate this breadth manually, let alone weight stories by perspective distinction on top of it. This is one of those places where AI has a real, structural advantage over a human trying to do the same job. Most of us who proudly claim to "listen to all sides" are quietly outmatched.

Why This Matters

Consider a story about a proposed regulation. If it's covered by AP (wire), NPR (public_media), Fox News (right_leaning), and the Wall Street Journal (business), that's four editorial perspectives. The story has cross-spectrum significance. Different kinds of outlets, with different audiences and different editorial priorities, all judged it worth covering.

Now consider a different story covered by Fox News, the Daily Wire, Breitbart, the New York Post, and the Washington Examiner. That's five outlets but one editorial perspective: right_leaning. The story might be genuinely important — or it might be amplified within one editorial ecosystem without resonating across the broader media landscape.

The old system would have scored the second story higher (five sources beats four). The new system scores the first story higher (four perspectives beats one). This is the correct behavior for a product that claims to assess significance rather than measure attention. The CDB isn't concerned with attention — it's concerned with significance, which (in theory at least) makes it pretty unique as an aggregated information source.

Wire Service Syndication

There's a subtlety worth naming in how wire services interact with the perspective counting: syndication. Without accounting for it, a single AP story republished by every outlet in the country would look like the most diverse coverage in the world. When AP publishes a story, multiple outlets routinely republish AP's copy, sometimes with their own byline, sometimes crediting AP explicitly. If NPR runs an AP story and CBS runs the same AP story, the pipeline shouldn't count those as three perspectives (wire + public_media + broadcast). It's one perspective (wire) with two republications, not three independent voices.

The pipeline detects wire service syndication through two methods: explicit wire credits in titles, summaries, or bylines ("[AP]", "(Reuters)", "By Associated Press"), and title similarity matching against known wire articles. Articles identified as syndicated wire copy are tagged so the perspective counter attributes them to the wire perspective rather than their republishing outlet's perspective.

This prevents the most common source of inflated independence scores: widely syndicated wire copy being counted as independent editorial coverage from each outlet that ran it.

What's Not in the List

The absences are as deliberate as the inclusions.

Paywalled sources as signals only. The Wall Street Journal and Financial Times are included as Tier 2 sources via Google News metadata. Their feeds provide headlines and short summaries — enough for the clustering algorithm to register that a story is getting business and financial coverage, but not enough for the pipeline to build an assessment on their reporting alone. In other words, they can contribute to whether a story counts as significant (via the business perspective), but not to what the assessment actually says. The New York Times and Washington Post remain excluded. The principle stands: the CDB's assessments should be built on information that readers can independently verify.

No social media. Twitter, Reddit, and other social platforms are excluded entirely. There's a real cost here — social media is genuinely useful for early signal on breaking stories, and the CDB will sometimes be later to a story than someone scrolling X would be. But for a product whose contract with the reader is confidence and verification, that ambiguity is disqualifying. A trending topic on social media might be genuinely significant, or it might be algorithmically amplified noise, and the CDB's trust contract can't accommodate sources where that distinction is unresolvable.

No aggregators beyond the breadth signal. Aside from the Google News Tier 3 feed, no aggregation services are included. Aggregators are redistributors, not sources. Including them would inflate source counts without adding genuine perspective diversity. Sources only — aggregating aggregators doesn't add information, it just adds noise that looks like signal.

The RSS Constraint

The entire ingestion layer runs on RSS feeds and public APIs. No scraping. This is a philosophical choice as much as a technical one.

Scraping creates a legal and ethical gray area that undermines the CDB's credibility. If the product is built on the premise of transparency and trust, building it on scraped data contradicts that premise. RSS feeds are an explicit invitation to consume content programmatically. Scraping is taking content that wasn't offered for that purpose.

The RSS constraint also keeps the pipeline simple and reliable. RSS feeds are standardized, well-supported, and rarely change their format. Scrapers break constantly — every time a website redesigns, every time a class name changes, every time a CDN configuration shifts. A pipeline that depends on scraping is a pipeline that requires constant maintenance. A pipeline that depends on RSS feeds runs unattended for months.

Evolving the List

You might be wondering at this point: how flexible is the source list? It certainly isn't fixed. It grew from twenty-seven to thirty-four when the need for cross-spectrum coverage became clear, and it may grow again. But additions follow the same principles: maximize diversity across editorial perspectives, prefer full-text over metadata-only, prefer RSS over scraping, and keep the total count manageable enough that full disclosure remains meaningful.

The most likely future additions are non-English international sources (through translated feeds) and government sources from other major democracies. As sources evolve, each addition will be documented publicly as part of the methodology.

What won't change is the core principle, the one that took a rewrite to actually land: ingest broadly so no perspective is invisible. Weight by editorial diversity so no single perspective dominates. Thirty-four feeds, twelve perspective groups (eleven of which count toward significance), each one chosen for a reason. That's the source strategy.

The Citizen's Daily Brief is a free daily intelligence briefing from Stalefish Labs.

Three Products, One Pipeline

Stalefish Labs — Fri, 19 Jun 2026 14:30:35 +0000

The Citizen's Daily Brief ships three products: a daily briefing, a weekly assessment, and an occasional fictional intelligence dossier. They share the same data, the same Supabase backend, and the same editorial philosophy. They're also three genuinely different things — different artifacts, different schedules, and in one case a different idea of what "production" even means.

Two of them are written by language models on a clock. The third is written by a person, when the news earns it. Getting the relationships among the three right was one of the more interesting design problems in the project.

Daily: What Changed Today

The Daily Brief answers a simple question: what are the five to nine most significant things that happened in the last 24 hours? It runs Monday through Saturday, ingests from thirty-four RSS news feeds spanning the political spectrum, clusters and scores stories by editorial perspective diversity, and synthesizes structured assessments with trust signals.

Claude Sonnet handles all the daily analytical work — clustering, significance scoring, and synthesis. Sonnet is fast, cost-effective, and excellent at following structured output constraints. For the daily brief, those qualities matter more than raw analytical depth because the task is well-defined: take these sources, group them, score them, assess the top clusters. The prompt is precise, the output schema is strict, and the validation layer catches anything that slips through.

The daily brief is a snapshot. It tells you what the world looks like this morning. It's designed to be read in under ten minutes, and each item stands alone. You can read item three without reading items one and two. The items are ordered by significance, but they're not narratively connected. The main thing the items share is enough weighted importance to make the cut for a given day.

Weekly: What Does the Week Mean?

The Weekly Assessment is a different animal entirely. It runs late every Saturday for Sunday consumption, takes the entire week's daily items as input — typically thirty to forty-two assessments from Monday through Saturday — and produces a long-form analytical document. Four to six thousand words. Fifteen to twenty minutes of reading.

And it runs on Claude Opus.

The model choice isn't arbitrary. The weekly assessment asks the LLM to do something qualitatively different from the daily work. Instead of assessing individual stories against their sources, it's analyzing the week as a whole — looking for narrative arcs, cross-domain connections, developing situations, shifts in confidence, and how trends and trajectories varied, interconnected, and resolved across that week's briefs.

These are harder analytical tasks. Tracing how a trade policy story connects to a labor market story connects to a consumer confidence story requires holding multiple complex assessments in context simultaneously and reasoning about their relationships. Noticing that Monday's "developing confidence" item resolved to "high confidence" by Thursday, and what that trajectory implies, requires a kind of meta-analytical thinking that benefits from Opus's deeper reasoning capabilities.

The cost difference is substantial on a per-call basis — Opus is significantly more expensive than Sonnet. But the weekly assessment runs once per week. At that frequency, the cost difference amounts to a few extra dollars per month. The analytical upgrade is worth every penny.

The Relationship: Meta-Analysis, Not Re-Ingestion

Here's the design decision that matters most: the weekly assessment doesn't go back to the raw sources. It doesn't re-ingest RSS feeds from the past seven days and start from scratch. It receives the already-synthesized daily brief items — complete with their headlines, assessments, trust signals, confidence levels, and source attributions — and builds on top of them. So in this way the data builds on itself, which helps a great deal on consistency and reliability.

This is meta-analysis. The weekly assessment analyzes analyses.

There are two reasons this works better than re-ingesting raw sources.

First, it preserves the daily assessments' integrity. Each daily item went through clustering, significance scoring, synthesis, and validation. Those trust signals — confidence levels, agreement indicators, source counts — were calibrated against the sources available on that specific day. If the weekly assessment re-ingested raw sources, it would lose that daily context. Was this a high-confidence assessment on Tuesday or a developing-confidence one? That distinction matters for understanding how a story evolved.

Second, it enables pattern detection that raw sources can't provide. The weekly assessment can see that four daily briefs across the week each included an item touching on supply chain disruption, even though each individual item was about a different specific event (port delays, chip shortages, agricultural export restrictions, shipping route changes). No single day's sources would reveal that pattern. But the structured daily assessments, with their topic tags and significance scores, make it visible.

The weekly prompt explicitly asks Opus to do several things the daily pipeline can't:

Week in Review — A narrative arc of how the week unfolded. Not a list of things that happened, but a story about how the week's events connect and build on each other. Three to five paragraphs that give you the shape of the week.

Deeper Dives — Two or three stories that deserve more than the daily brief's compressed format. Six hundred to a thousand words each, with room for alternative interpretations, historical context, and cross-story connections that a daily assessment can't explore.

Trend Analysis — Patterns across the week's items that were invisible in any single edition. The supply chain example above is one pattern type. Others include: escalation sequences (where each day's story was slightly more severe than the last), convergence patterns (where stories from different domains started pointing in the same direction), and reversal patterns (where Monday's assessment was contradicted by Friday's developments).

Developing Situations — Ongoing stories that are building toward something but haven't produced a decisive event yet. These are explicitly forward-looking and explicitly uncertain. The weekly assessment says "this is developing" in a way the daily brief can't, because the daily brief is optimized for "this happened."

Corrections and Shifts — Where the week's confidence and agreement levels changed. If a story was "developing confidence" on Monday and "high confidence" by Thursday, what changed? If agreement shifted from "broad" to "disputed," what new information caused the disagreement? These shifts are the most analytically valuable part of the weekly assessment because they show how understanding evolved, not just what happened. They're my favorite piece of the weekly assessment puzzle because they show how purely focusing on one day at a time without prior or future context can lead you astray.

Dossiers: What Could Happen

The third product breaks the rhythm the first two establish. The daily brief and the weekly assessment are both automated, and based on current known information — a model takes structured input on a schedule and returns a structured artifact. A FICINT dossier works nothing like that. No model decides when one ships, what it argues, or how it reads. A person does. Usually me. And it's not about what we currently know, it's about what we don't.

FICINT stands for Fictional Intelligence, and a dossier is exactly that: a fictional case file, built to look like a declassified intelligence packet. A cover page with a classification bar and a case number. A sequence of artifacts in distinct documentary voices: an incident report, a quality-review memo, a parent's kitchen-table testimony, a hearing transcript. Each one anchors on a real pattern in the news and projects it three structural moves out, to the specific, non-obvious consequence the daily brief can name but never dramatize. It attempts to answer the question, "now what?"

Where the daily and weekly run on a clock, dossiers run on a threshold. Four themes (for now) sit on a watchlist — Anti-AI Fracture, Autonomy Gap, Legitimacy Vacuum, State Capacity Atrophy — each tied to a historical blueprint. The daily pipeline ranks every story it clusters, not just the handful it publishes, and keeps the full list. That list feeds a tracker watching for real events that cross the line a given theme is built around. When a theme trips its threshold, it becomes eligible for a dossier. Filing one discharges the threshold, and the theme goes quiet until fresh events trip it again. The discipline is the entire point: a dossier lands maybe once a month at most, often less, and only when reality has earned it. That restraint is the most editorial decision in the whole system, and it's the one I'd never hand to a model.

The production path shares almost nothing with the other two. The automated products emit JSON against a strict schema, validated and poured into a fixed template. For those, the human is deliberately out of the loop. A dossier is hand-authored, assembled from custom artifact components — one for the incident-report register, one for testimony, one for the federal-document voice — each styled to read like the real document it imitates. The automated products are judged on schema conformance. A dossier is judged on whether a mother's testimony earns its weight on the page. Different craft, different failure modes.

And yet it ships on the same rails. Same Supabase tables for storage and metadata. Same push infrastructure to put it in front of readers. Same web codebase to render it. The pipeline built to move a brief and an assessment from output to reader turned out to move a hand-built fiction package just as well. That is the payoff I didn't plan for: the infrastructure turned out general enough that a third product, built a completely different way, could join without a rebuild.

The Same Data, Differently

The elegance of this architecture is that each product is a real artifact in its own right. The daily brief is an assessment of today's events. The weekly assessment is an assessment of the week's assessments. The dossier is a disciplined fiction about where a pattern in those assessments could lead. Three artifacts, three cognitive jobs, one body of data underneath. All three together provide a fuller picture of what's going on in the world than any one of them in isolation.

The daily brief answers: "What should I know this morning?"

The weekly assessment answers: "What does this week mean, and what should I be watching?"

The dossier answers: "If this keeps going, what does it look like from the inside and what might it lead to?"

You can read any one without the others. Daily-only readers get a practical, finite morning briefing. Weekly-only readers get a deep analytical document that stands on its own. Readers of both get something neither product provides alone: the experience of watching a structured analytical process unfold over time, with the weekly assessment explicitly building on the daily foundation. And a dossier often runs the other way — it's a stranger's first contact with the project, the fiction arriving before the brief that grounds it.

Matching the Tool to the Task

There's a fair question here: why not just use Opus for everything? The daily brief would be even better with Opus's analytical depth, right?

Honestly, maybe marginally. But the daily brief's quality is constrained more by format than by model capability. Each item has tight field limits — "what changed" is one to three sentences, "why it matters" is a short paragraph, "what to watch" is a sentence or two. Within those constraints, Sonnet produces assessments that are clear, accurate, and well-structured. Opus might produce slightly more nuanced assessments, but the nuance would be compressed into the same small fields, and the practical difference for readers would be minimal.

The weekly assessment has room for nuance. A thousand-word deeper dive can contain the kind of multi-perspective analysis that benefits from Opus's reasoning. A trend analysis section can draw connections that require holding a week's worth of complex assessments in context. The format allows the model's capabilities to shine in a way the daily format's constraints don't.

Matching model capability to format requirements is more cost-effective and produces a better product than using the most powerful model everywhere. Use Sonnet where the format is tight and the task is well-defined. Use Opus where the format is expansive and the task is open-ended. The daily brief is the first. The weekly assessment is the second.

That logic reaches past the choice between models. The daily and the weekly both ask which model fits the format. The dossier asks an earlier question: should this be automated at all? For a case file whose whole value is behavioral truth — whether a fictional triage nurse sounds like a real one under oath — the honest answer is no. A dossier is commissioned, authored, and edited by a person. A model might help draft a line, but nothing about it ships on a schedule a model controls. What it argues, which historical blueprint it leans on, whether it has earned its black swan: that is editorial judgment, and the pipeline exists to let a human exercise it. Sonnet where the format is tight. Opus where the format is open. An editor where the truth is behavioral.

All that said, I constantly experiment with generation options, trying out newer models as they come and go, so this model arrangement is subject to change as things continue to evolve.

The Business Model

I wanted the CDB for myself, to satisfy my desire for a daily brief as untethered as possible from news bias. I originally had plans for it to be under a subscription model, with daily briefs free and weekly assessments behind a paywall. But the more I used it, the more I realized it shouldn't be pay gated, so it's entirely free: the briefs, the weekly assessments, even the hand-curated FICINT dossiers.

That doesn't mean I can't use help, so there's always the option to support the CDB with voluntary contributions to help pay the robot and hosting bills. But it's not a requirement — I'd rather more people have access to it than try to make it some kind of profit center. It's not. It's a utility I built for myself, and I hope you find it useful.

Three products, one pipeline, one commitment to assessed information over raw content. The same rails carry a daily brief, a weekly assessment, and an occasional dossier without tripling the engineering. Two of them choose a model to fit the format. The third sets the models aside and hands the page to an editor.

The Citizen's Daily Brief is a free daily intelligence briefing from Stalefish Labs.

How Tall Tales Got Designed (in Letters)

Stalefish Labs — Sat, 30 May 2026 04:06:54 +0000

In January 2002 I dropped an envelope in the mail addressed to my brother Steve. Even in 2002, mailing a letter to a sibling was unusual — but these weren't usual circumstances, and the address wasn't his usual one. He was, in the letter's own phrasing, in a "new temporary environment" — incarcerated, briefly, in one of the not-good stretches that bracketed the good ones.

The first article in this series covered the good stretch right before this one: the Starbucks evenings of fall 2001, with my brother sober and focused on recovery. This letter was written into the chapter after. It calls his situation "on holiday," in scare quotes, throughout — the laugh-to-keep-from-crying register my family relied on when things got hard.

The envelope I mailed Steve was thick, six or seven typed pages. It probably looked like any other mail-from-home letter, but it was not a mail-from-home letter at all. It was a design document.

The first paragraph said this:

Steve,

I hope you're doing OK and adjusting to your new temporary environment. Believe it or not, I have several things I want you to help me accomplish while you're "on holiday." For right now, I'd like to focus on figuring out the details of my Tall Tales game.

It was my attempt to keep a relationship going by focusing on a task that could be carried out in letters, and that's the moment Tall Tales started being designed by mail. Incarceration aside, my brother was the person in the world I most trusted when it came to comedy and engineering fun. I had a brain to bounce ideas off, several weeks of his undivided attention, and — for that brief window — a postal address he could reliably be reached at. So I sent him the design and asked for his help.

The State of the Game in January 2002

The first article in this series described how the Starbucks evenings of the previous fall had quietly redesigned Tall Tales into a lounge game — a card game small enough to fit on a coffee shop's outdoor table. What that article skipped over is what the actual design was at that moment. The lounge form factor had landed. The mechanics had not.

In the January letter, the game had three question types:

Fact-or-Fiction — True/False questions about urban myths and weird facts.
Tall Tales — multiple-choice "news of the weird" questions, where I had to invent two plausible-but-wrong answers Balderdash-style.
Urban Legends — pure Balderdash, where players wrote made-up endings to bizarre stories and voted on the best one.

I mention Balderdash because it was a family favorite, and my brother tended to dominate at the creative bluffing part of the game. One of his notable wins was tricking us into believing one of the random names in the game was "the inventor of the V-neck collar." It seemed too ridiculously specific to be a bluff...I had the right person to help with Tall Tales.

To give Steve a feel for the Fact-or-Fiction tone, I reproduced eight sample questions in the letter:

The Great Wall of China can be seen with the naked eye from the moon.

Hamburgers and frankfurters are named after cities in Germany.

A man by the name of Thomas Crapper invented the flush toilet.

More cases of spousal abuse are recorded on Super Bowl Sunday than any other day of the year.

Hair and nails continue to grow on corpses after death.

No two snowflakes are alike.

Coca-Cola originally contained cocaine.

The cast of the sitcom Green Acres ate the show's pig character, Arnold Ziffel, after the show's final episode.

Answers, in order: F, T, F, F, F, F, T, F. The Great Wall one is the most-repeated lie in the bunch.

There was also a scoring system I was proud of: instead of points, players would collect Creature Cards that built up a picture of Bigfoot, the Loch Ness Monster, or an alien, one third at a time — head, body, legs. The first complete creature won the game. I'd already worked out a fast-game variant where you could win with a hybrid creature, mixing body parts across the three monsters. The artwork was deliberately going to allow Bigfoot's head on Nessie's body on alien feet.

The Topper Problem

Hidden inside the letter was the actual design question I was wrestling with. I had a different game on the side, called Topper — a one-upmanship game where each player wrote down their answer to a prompt ("the most dangerous animal you've met in the wild"), and the goal was to give the wildest answer the other players would still believe. You could tell the truth or you could bluff. Other players could challenge a winning answer; if you'd lied and got caught, you lost a point.

The question I put to Steve was whether Topper should stay as its own game or get folded into Tall Tales as a third question type, replacing the Urban Legends Balderdash mechanic — which, even then, I suspected was too much writing for a lounge game.

I also told him the truth about why I was being so thorough on paper:

It's not a huge issue, but we've learned with the game business that it helps to document everything you do in case someone ever tries to claim they had an idea first. I've read lots of stories of the game/toy industry being quite dirty in terms of idea theft, so I'm trying to create a paper trail as I refine this idea.

Of all the lines in that letter that have aged in interesting ways, that one has aged the most. A 2002 indie toy designer earnestly fortifying his correspondence with his incarcerated brother against future intellectual-property litigation. I love that guy. Two decades on, the lesson is: ideas matter, but execution matters way more.

What Steve Sent Back

The reply came on the back of the pages I'd sent — signed at the bottom, as I'd asked. I don't have it in front of me anymore; it left the file at some point in the next twenty-four years. But the second letter I sent him, six weeks later, opens with the sentence that captures what he'd done:

I really like your ideas for Tall Tales, and I'm definitely going more in your direction with the game. In fact, I like everything you've suggested except I'm still a little concerned about doing the Tall Tales one-at-a-time.

That single sentence is the design-decision pivot of Tall Tales. Topper was in. The Urban Legends Balderdash mechanic was out. The third question type would be a one-upping storytelling game where you could bluff or tell the truth, and where other players could challenge you. The bluffing — the texture of bluffing, where you might be lying and might not, and the other players had to weigh whether to risk a challenge — became the defining flavor of the game.

The 3-2-1 Die

The second letter contains one more design move worth pulling out, the kind of thing only a designer working against a manufacturing budget would invent:

We use an oversized traditional 6-sided die that is color coded for each of the different card types. However, instead of having the colors evenly distributed across the 6 sides, there are 3 Myth sides, 2 Urban Legend sides, and only 1 Tall Tale side.

Three sides for the trivia. Two sides for the multiple-choice questions. One side for Topper — the bluffing-storytelling layer that had just been folded in. Roll the die, draw the matching card. The distribution of question types in the game was being controlled by the geometry of the die, not by shuffled deck order or rules-text instruction. It was a manufacturing trick disguised as a mechanic, and it gave the game its rhythm: the lighter, faster trivia came up most of the time, with occasional multiple-choice changes of pace, and a storytelling round only every sixth roll or so — rare enough to feel like an event when it landed.

Knowing the on-table ratio was 3-2-1, I scaled the deck the same way. Three hundred trivia cards, two hundred multiple-choice, one hundred Topper. Six hundred cards total, the deck a six-times scale model of the die.

What Shipped (and What Didn't)

There's a complication to the design diary I've just laid out. The mechanics in those two letters were the spec for the Full Edition of Tall Tales — die, Creature Cards, 600-card deck, separate rule sheet, full-sized box, the works. The Full Edition never shipped.

What shipped at the American International Toy Fair in February 2003 was the Pocket Edition, a radical scaling-down of all of it. No die. No Creature Cards. No rule sheet. A single box of cards, with the entire ruleset printed on the back of the box itself. Players drew cards directly from the box; the first to ten points won.

The reason the Pocket Edition became the only edition is the same reason the first article in this series gave for the lounge-game pivot: the Starbucks-table form factor turned out to be the shape the game wanted, not just the box. As I tuned the mechanics to fit that table over the course of 2002, half the apparatus from the Full Edition spec fell away. The 3-2-1 ratio lived more cleanly inside the shuffled deck than it did on the face of a die. The Creature-Card puzzle wanted a longer game than the table wanted. The rule sheet wanted a setup ritual the table didn't have time for.

What survived was the part Steve had touched. The three question types and their proportions. The Topper bluffing layer, lifted whole from his letter as the third category. The decision to drop the Urban Legends Balderdash mechanic and use the slot for storytelling instead — his call, in his reply on the back of the pages. The category names wandered along the way (in his letter they were Myth questions; on the shipped Pocket Edition box they were Humdingers), but the categories themselves held, and so did their ratio.

The lounge-game thesis came from the constrained space of the Starbucks tables. The category structure that filled the lounge form came from a one-month correspondence with a brother on "holiday." The mechanical apparatus around that structure — die, creature puzzle, rule sheet — got stripped out before print, and the two letters are now the only place that apparatus survives. The decision in the design, the one my brother catalyzed, made it all the way to the printed box.

I never told this story when the game went out to retailers, because it would have read as a sob story attached to a product spec, and the product spec was supposed to stand on its own.

It does stand on its own. Steve died a few years ago — the first article in this series tells that part of the story, and I won't retell it here. But I want the design diary to exist, somewhere, in a form he would recognize as accurate. He helped design this game. He signed the back of the pages.

Building an Automated Analyst

Stalefish Labs — Wed, 27 May 2026 18:31:06 +0000

The Citizen's Daily Brief is a daily brief for the people, modeled after a similar intelligence brief that has been delivered to the U.S. President since 1946. Like the PDB, the CDB isn't a news aggregator. It doesn't summarize articles. It doesn't curate links. It produces assessments — structured analytical judgments about what happened in the world, what it means, how confident we are, and what to watch next. That distinction sounds like marketing copy, but it's actually the architectural decision that shaped every line of code in the CDB pipeline. And it's a specific decision given that this project deliberately leans into the strengths of AI.

So why the big distinction between summary and analysis? A summarizer asks: "What does this article say?" An analyst asks: "Given everything we're seeing across all sources, what's actually happening, and how sure should we be?" That second question is the one I personally found hard to answer by just bouncing around news feeds each day trying to learn what's going on in the world. But I wanted that daily assessment, the citizen's version of what the U.S. President gets each day. Building the news analyst turned out to be a fundamentally different engineering problem than building a summarizer.

The Five Stages

The automated CDB information pipeline runs five stages, Monday through Saturday, completing before most Americans wake up. Here's what each one does and why it exists.

Stage 1: Ingestion

Every morning, there's an automated news fetcher that pulls from thirty-four curated RSS feeds spanning government sources, international outlets, wire services, specialist publications, and outlets from across the political spectrum. It grabs headlines, metadata, and summaries for anything published in the last 28 hours (overlapping with the previous cycle to catch late-publishing sources). The idea is to span enough disparate news sources to get a feel for what's truly notable and worth assessing.

The 28-hour window is deliberate. Different outlets publish on different schedules. Wire services update continuously. Government sources often publish late in the afternoon. International outlets operate on different time zones. A 24-hour window would miss stories that broke at the boundary. The overlap means some stories appear twice in the raw input, but deduplication handles that downstream.

The fetcher normalizes everything into a common record format: headline, outlet name, outlet type, editorial perspective, publication timestamp, summary text, and source URL. Each source carries an editorial perspective label, which is a structural grouping that identifies whether the outlet operates from a wire, public media, broadcast, left-leaning, right-leaning, business, international, specialist, or other editorial position. I thought a lot about this piece, and wavered mightily on the left/right leaning part in particular. But the perspective identification is what allows the rest of the pipeline to not know or even care whether a record came from a BBC RSS feed or a Fox News Google News filter. It just sees structured records with perspective metadata.

After normalization, the fetcher runs a wire syndication detection pass. When AP or Reuters publishes a story, other outlets frequently republish the same wire copy, sometimes verbatim, sometimes with minor modifications. You'd be surprised at how much news is duplicated across sources. The fetcher identifies likely syndicated wire articles through byline credit patterns ("(AP)", "By Associated Press", etc.) and title similarity matching against known wire headlines. It's worth identifying and tagging syndicated articles so that downstream perspective counting doesn't inflate independence scores.

Stage 2: Clustering and Significance Scoring

Stage 2 is where things get interesting and the analysis piece kicks in. It's also really the most novel facet of the CDB architecturally. The normalized records are sent to Claude Sonnet with a prompt that asks it to do two things: group related stories into clusters, and score each cluster's significance across five dimensions. The end result is a composite significance score that provides a means of whittling down daily news into what makes the brief.

Source volume — How many outlets are reporting this? A story covered by twelve sources is likely more significant than one covered by two, though not always.

Source diversity — How many distinct editorial perspectives cover this story? This is the most important dimension and carries the most weight in the composite score. A story reported by AP (wire), Fox News (right_leaning), NPR (public_media), and the Wall Street Journal (business) has four perspectives — genuinely cross-spectrum significance. A story reported by Fox News, the Daily Wire, Breitbart, the New York Post, and the Washington Examiner has five outlets but one perspective. The pipeline counts perspectives, not URLs.

Official action — Did an institution actually do something? A bill was signed, a rate decision was announced, a court ruling was issued — these are actions with concrete consequences, not just stories about stories.

Breadth of impact — How many people does this affect? A trade policy affecting global supply chains scores higher than a local regulatory change, even if the local change is more dramatic. There's a balance here, and admittedly since the CDB is patterned on the PDB, it deliberately skews American, at least initially.

Novelty — Is this genuinely new, or is it the latest increment of an ongoing story? Novelty matters because the brief should tell you what changed today, not re-litigate what's been developing for weeks.

Each dimension gets a sub-score from one to ten. The composite significance score combines the five sub-scores using a weighted formula: source diversity at 30%, official action at 25%, breadth of impact at 25%, source volume at 10%, and novelty at 10%. The weighting is deliberate — editorial diversity is the strongest signal of genuine significance, followed by institutional action and breadth of impact. Raw source volume is intentionally the lowest weight because volume without diversity can just mean amplification within a single editorial ecosystem.

The LLM returns all identified clusters, not just the top selections. Each cluster is marked as selected or unselected, with the top five to nine clusters selected for the brief. The full ranked list, including stories that didn't make the cut, is preserved and published separately. This wider list exists because downstream consumers may need access to the complete significance-ranked picture, not just the curated top nine. A good example of this is the FICINT Fictional Intelligence feature, which uses the full ranked list of news stories to track if/when a theme tips into requiring a dossier addition.

That full ranked list of stories is important because it effectively provides "receipts" to validate why a story made the brief. The LLM provides analytical judgment within a framework, but the framework provides consistency. The sub-scores are visible. The weighting formula is documented. The full cluster list is preserved. If you want to audit why a story made the brief and another didn't, the data is there. The CDB is all about "showing our work" — there's nothing hidden, no ulterior motives.

Stage 3: Synthesis

For each selected cluster, Claude Sonnet writes the structured brief item. This is where the "assessment, not summary" distinction becomes concrete. The prompt asks for:

Headline — What happened, in one line
What changed — The specific new development (not background, not context, just the delta)
Why it matters — Analytical judgment about significance and implications
What to watch — Forward-looking: what would confirm or challenge this assessment
Why this made the brief — A structured receipt explaining inclusion: how many sources, how many editorial perspectives, which perspectives, and what triggered the significance score

And then there's the trust infrastructure:

Common ground — Facts that all sources agree on (the verified baseline)
Key disagreements — For stories where sources disagree, the specific points of disagreement (not vague "sources differ" but "wire services report X while government sources cite Y")
Open questions — Things we don't know yet (explicit uncertainty)
Timeline — The sequence of events as reported across sources, including when a prolonged news story began
Source attributions — Which sources contributed what, with citation roles (primary, supporting, analysis, context, contradicting)

The prompt constraints are tight. Each field has length limits. "What changed" must be one to three sentences describing only the new development. "Why it matters" can't restate the headline. "What to watch" must be forward-looking and specific, not vague ("watch for developments" is banned). The "why this made the brief" field follows a mandatory format: "Covered by N sources across M editorial perspectives ([list]). [Trigger sentence]. Significance rank: X of Y stories identified." These constraints force the LLM to be precise rather than expansive, and make the inclusion rationale auditable. If you've spent much time with AI, you may have gathered by now that this isn't just "ask ChatGPT to summarize today's news." The CDB is essentially a sophisticated, highly-tuned prompt engine that focuses on a very specific way to filter and analyze news.

Stage 4: Validation

Not every step in the process is AI-driven. Every synthesized item passes through a validator before publication. This is mechanical, not LLM-based — it's Python code checking structural requirements:

All required fields present and non-empty
Field lengths within bounds (headline under 200 characters, etc.)
Trust signals internally consistent (high confidence requires 2+ sources — you can't be highly confident based on a single report)
JSON schema conformance

If an item fails validation, it's dropped. If fewer than three items pass, the entire brief is skipped for that day. This is the "publish nothing rather than publish garbage" principle encoded in code. It has triggered exactly twice in testing — both times because a source outage produced an unusually thin input set. Both times, skipping was the right call. Again, we'd much rather have no brief than a sketchy brief — this project lives and dies by its trustworthiness.

Stage 5: Publication

Items that pass validation are written to the database. A brief record is created, source records are inserted (deduplicated by URL), brief items are linked to their sources through a junction table with citation roles and display order. The brief status flips to "published" and the website regenerates.

The full cluster list, including unselected stories, is also persisted to a separate table. This creates a complete record of what the pipeline saw, how it ranked everything, and what it chose to include or exclude. The independent_source_count field on each brief item reflects the number of distinct editorial perspectives, not the raw number of source URLs.

The whole pipeline runs in about twenty minutes. Most of that time is LLM inference — one clustering call that sees all source records at once, then individual synthesis calls for each of the five to nine selected clusters. The Python code itself executes in seconds.

Why Not Just Summarize?

I keep emphasizing the assessment-versus-summary distinction because it's the single decision that shaped everything else. If the CDB summarized articles, the pipeline would be trivially simple: ingest, concatenate, send to LLM with "summarize this," publish the result. No clustering. No significance scoring. No trust signals. No validation. And honestly, no need for a web site or app, just ask the AI yourself.

Summaries answer "what did these articles say?" Assessments answer "what is happening in the world today and how confident should you be about it?" The second question requires comparing sources against each other, identifying agreement and disagreement, scoring significance across multiple dimensions, and being explicit about uncertainty. This approach presents a more interesting software engineering challenge, but in doing so it gets at the heart of what we really want to know as citizens: what happened in the world, and why should I care?

That's what the pipeline does. Each stage exists because assessment demands it. Clustering exists because you can't assess a story without first identifying that twelve different articles are about the same story. Significance scoring exists because you need to decide what's worth assessing. The editorial perspective system exists because significance should reflect genuine editorial diversity, not volume from a single perspective. Validation exists because an assessment with inconsistent trust signals is worse than no assessment at all.

The Weekly Assessment

In addition to the Monday-Saturday briefs, there's a deeper Weekly Assessment that publishes on Sundays. The weekly assessment runs on Claude Opus, and is a different beast than the briefs. It receives an entire week's worth of already-synthesized daily items — typically thirty to forty-two items — and produces a four-to-six-thousand-word analytical document. This is long enough that streaming the response matters for both reliability and cost management.

The weekly prompt asks Opus to do things that Sonnet's daily work can't: trace narrative arcs across the week, identify cross-domain connections (how a trade policy story connects to a labor market story connects to a consumer confidence story), flag developing situations that no single daily brief captured, and note where confidence or agreement shifted between Monday and Saturday.

This is meta-analysis. The LLM isn't working with raw sources; it's working with already-assessed, trust-scored daily items. Uncertainties roll up cleanly, meaning if a daily item was flagged as "developing" confidence, the weekly assessment can note whether that uncertainty resolved or deepened as the week progressed.

The Structured Output Contract

Every LLM call in the pipeline uses structured output, which means the response must conform to a defined JSON schema. This isn't just a nice-to-have; it's what makes the pipeline reliable enough to run unattended.

The clustering prompt specifies exactly what fields each cluster should have: a label, source indices, sub-scores for each of the five significance dimensions, a composite score, editorial perspectives present, and selection status. The synthesis prompt specifies the brief item schema down to field types and nullable flags. The LLM doesn't get to decide the shape of its output, only the content within a predetermined structure.

This is a lesson I've learned across multiple projects: LLMs are most reliable when you constrain their output format and give them freedom within those constraints. Tell them what to produce and let them decide what to say. The alternative, free-form text that you parse afterward, is fragile, inconsistent, and a debugging nightmare.

Bias Auditing

The pipeline includes a longitudinal bias detection system that audits historical output for systematic skew. That's a fancy way of saying we try really, really hard to be unbiased. The bias detection system checks topic tag distribution (are certain topics consistently over- or underrepresented?), editorial perspective coverage (are stories from certain perspectives systematically excluded?), selection bias (do unselected clusters skew toward particular perspectives?), trust signal patterns (do certain topics consistently receive lower confidence?), and perspective diversity per story (are most stories seen through only one editorial lens?).

This isn't a one-time check. It runs periodically against the accumulating output data, flagging any patterns that suggest the pipeline's analytical judgments are drifting in a systematic direction. The flags are quantitative — threshold-based, not vibes-based. If right-leaning perspectives appear in clusters but those clusters get selected at a significantly lower rate than the baseline, that's a flag. If a topic tag that should appear weekly is absent for two consecutive weeks, that's a flag.

The bias auditor can't prove the pipeline is unbiased — that's an impossible standard. But it can detect systematic drift, which is the actionable concern. A pipeline that gradually skews over time can be corrected. A pipeline that's never audited for skew will eventually drift without anyone noticing.

Error Handling: Fail Loud, Fail Safe

The pipeline has exactly one retry. If any stage fails, the system waits fifteen minutes and tries the entire pipeline again from the beginning. If the retry fails, the brief is skipped for that day.

There are no fallbacks. No "use yesterday's brief with an updated date." No "publish a partial brief with whatever succeeded." The brief is either a complete, validated, internally consistent assessment — or it doesn't exist for that day.

This philosophy is borrowed directly from the intelligence community. A briefing document that's wrong is worse than no briefing document at all. The real PDB is occasionally late. It is never sloppy.

The GitHub Actions workflow that runs the pipeline sends no notification on success (success is the default state) and alerts on failure. The system is designed to be boring when it works, which is the kind of boring I'm happy to build.

And speaking of boring, if my tone seemed a bit more clinical in this article, it's because this project occupies a unique slot in the Stalefish Labs portfolio. Building a daily news brief for citizens is serious business, so I've left most of the fun and games aside while working on this project. I want you to be able to trust it the same way I do. Feel free to reach out if you have any questions, suggestions, etc.

The Citizen's Daily Brief is a free daily intelligence briefing from Stalefish Labs.