DEV Community: 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.

The Cell Phone of Games: Notes from Toy Fair 2003

Stalefish Labs — Tue, 26 May 2026 22:03:05 +0000

In February 2003, a blizzard later known as the President's Day Storm shut down most of Manhattan and made it nearly impossible to get to the Jacob Javits Center, where the American International Toy Fair was set up that week. I was supposed to be at booth #6250 in the Specialty Source section on the 1st floor, debuting Tall Tales Pocket Edition. I made it. So did most of the other indie game makers — on foot, dragging suitcases of inventory through snow that was deeper than the wheels on the suitcases. It was my first Toy Fair, my first time designing a custom trade show booth, my first experience learning the ins and outs of NYC union labor...check with an electrician before you plug or unplug ANYTHING!

The booth itself was pretty modest: a 10-foot fabric pop-up mural with the three creatures from the game (Bigfoot, the Loch Ness Monster, and our take on the Roswell alien) wrapped around a counter covered in stacks of game boxes. Toy Fair is strange theater. The big toy companies take over entire halls; indie game makers like Stalefish Labs were tucked into a corner of one floor, hawking our wares to whoever wandered by. The buyers from major retailers had appointments scheduled with Hasbro and Mattel in private suites in entirely other buildings. We had whoever was curious enough to walk past Specialty Source.

"The Cell Phone of Games"

A reporter from Fox 5 News in New York stopped at the booth midway through the show. He was doing one of those "let's roam Toy Fair and see what's interesting" segments. He picked up the Pocket Edition box, asked what made it different, and I gave him the spiel: no board, no dice, no writing, fits in a coat pocket. He turned to the camera and said, on tape, "It's so compact and mobile — it's the cell phone of games!"

I have used that quote in approximately every pitch letter, sell sheet, and product description I've written since. Or at least until the term lost its lustre. It captures something real about the design: I had been trying to make the smallest, most portable game I could. The 2003 cell phone — flip-style, pocket-sized, ubiquitous — was the right shape comparison. The iPhone wouldn't ship for another four years; in 2003, "cell phone" still meant a thing you could close and forget about. Over the next decade the comparison aged in a funny way, but it did its job.

Two People from Pixar

The other thing that happened, which I've thought about a lot since, was a quiet conversation at the booth with two people from Pixar.

I don't remember either of their exact titles. I remember that they came by, picked up the cards, and asked thoughtful questions about the artwork. The three creatures had been drawn deliberately stylized as cartoons rather than realistic depictions, and the Pixar people were curious about the design choices: why the alien was shaped the way it was, why Bigfoot stood the way he did.

The artwork was Micah Laaker's. He had designed all three characters — Bigfoot, Nessie, and the Roswell alien — working out of Iguana Studios in New York. Micah had already won a Gold Award from the London International Advertising Awards in 2002 for the redesign of BattleBots.com, done in collaboration with Adobe Systems. He would go on to lead UX teams at Yahoo and, eventually, direct product design at Google. The Pixar scouts had good instincts.

They asked if we'd ever thought about doing the characters as an animated property: a TV show, a short film. I said we'd thought about it and had worked on some ideas but didn't have any of the relationships to pursue it seriously. Hint, hint.

One of them said something I've never forgotten: that his team was working on a movie at the moment, couldn't say much about it, except that it involved cars. This was February 2003. Cars was released in June 2006. I don't know if the people I was talking to were on the Cars team specifically, or if they were at Pixar in some adjacent role and happened to mention a project that everyone in the building was talking about. I never followed up. They never followed up. I don't know who they were.

There is, however, a contemporaneous record of the conversation in our files. A cover letter I sent to a buyer at Barnes & Noble, dated February 25, 2003, six days after Toy Fair ended, says, verbatim:

At Toy Fair we also caught the eye of several media producers, including a representative from Pixar, who thought the characters that appear in the game's artwork have potential for an animated television series or movie. We are in the process of entering discussions with those people now.

That "process" was more blind ambition; we never spoke with Pixar again. That letter is the exact sort of dressed-up look who else is interested! name-drop that a plucky indie game maker writes to retail buyers in the hope of getting picked up. But the encounter itself was real, they really were intrigued by the Tall Tales characters, and the cars detail is the part I remember sharpest.

Five Years Later

Fast-forward five years to October 2008: Pixar premiered a series of animated shorts on Toon Disney called Mater's Tall Tales — Cars Toons starring the tow-truck character Mater telling whoppers about his life.

The connection between that series and our 2003 conversation is, almost certainly, none. "Tall tales" is a stock phrase. Mater is a character explicitly built around exaggerated storytelling. A Pixar scout chatting up a stranger at a toy fair five years before a series airs is not a chain of causation. But it is, at minimum, a strange coincidence, a Pixar team at the booth of a card game called Tall Tales, talking about animated characters and a project involving cars, and Pixar later releasing a series of cars-character shorts called Tall Tales.

I think about it the way you think about a near-miss in a parking lot. Nothing happened. But you noticed.

A Few Other Notes

The snowstorm got bad enough that the Tall Tales Times, the in-character mock newspaper we made for promotional purposes, has a Q1 2003 issue with a story headlined "The Search for Matching Snowflakes Continues," reporting that "the biggest snowstorm in New York history prompted a massive search for two identical snowflakes by visitors to the Stalefish Labs booth at Toy Fair, where the old story about no two snowflakes being alike was debunked."

A reviewer for Parent Magazine stopped by, played a quick game, and offered an unsolicited blurb that has followed the game ever since: "I usually don't find games that I like, but I really like this one."

We sold a respectable number of games at the booth, mostly to buyers from independent toy and game stores. The big retailers passed. Tall Tales never broke through the way we'd hoped. The cell phone of games turned out to be more Blackberry than iPhone, and in many ways was the right metaphor for the wrong moment...the social-card-game category would eventually emerge, with games like Cards Against Humanity, Codenames, and Werewolf dominating dinner tables a decade later. Turns out Tall Tales was a bit early to that party in 2003. It was trying to be the next Cranium in a more compact form factor for a more casual environment, but it was aimed at a niche that hadn't yet been invented.

The remaining copies of Tall Tales Pocket Edition are here.

Who Briefs the Public?

Stalefish Labs — Mon, 04 May 2026 04:30:15 +0000

I need to start with an honest admission: I thought this project was too ambitious. I assumed I was being naive and borderline arrogant to even consider it. There, I said it.

The President's Daily Brief is arguably the most consequential document produced daily by the United States government. I had heard of it but didn't know a lot about it, so embarked on a little research project. It's assembled by thousands of analysts across the intelligence community, drawing on classified sources, satellite imagery, signals intelligence, and human networks spanning the globe. It's been delivered to the President every morning since the Kennedy administration, its origins even dating back further to President Truman. Its purpose is singular and weighty: give the most powerful decision-maker in the world a shared understanding of reality so they can make consequential choices.

And I thought: I should make a public version of that. Entirely automated by AI. And I should be fully transparent in doing so, meaning not even the slightest pretense that this is anything but the robots providing public intelligence.

Yeah. I know how that sounds. Stick with me, please.

The Gap

The PDB exists because of a specific insight: the person making the most consequential decisions needs more than news. They need assessed information grounded in reality. Not "here's what happened" but "here's what we think it means, how confident we are, and what we don't know." The format, structured assessment with explicit confidence levels, shown reasoning, and disclosed sources...isn't a luxury. It's a requirement for making good decisions under uncertainty. And don't forget the "grounded in reality" part because that's really the main thing that got me thinking about this project: escaping information bubbles.

And that led to the thinking that the insight of the PDB doesn't apply only to the President. It applies to all of us.

Every day, we make decisions that are shaped by our understanding of the world. How we vote. How we invest. Where we live. How we talk to our kids about what's happening. Whether we're worried or reassured about the economy, about geopolitics, about the systems that affect our daily lives. These decisions are consequential, if not at the scale of a presidential decision, then certainly at the scale of a life. And summed together, our personal decisions on these matters do eventually impact every facet of the world for better or worse. Maybe not to the same immediate degree as the President, but our individual assessment of the world indeed shapes the world. And ultimately, the sum of our individual assessments circles back to the president because we collectively elect them.

So what do we have to inform those individual decisions? An algorithmically curated stream of content optimized to keep us engaged, to reinforce each of our precious belief bubbles. Outlet-specific framing where the same event reads as triumph or catastrophe depending on where we encounter it. A media landscape so fractured that two thoughtful, well-informed people can have completely incompatible understandings of the same week. And that's really how this idea came to be.

I had a confrontational discussion with a friend where we struggled about basic facts. I quickly realized it was impossible to have a constructive, meaningful, or even remotely honest conversation if we didn't at least have some baseline shared reality of what is happening in the world. In many ways our modern ad-based, attention-craving news model is failing us. This is one admittedly ambitious attempt to correct that.

I realized as individuals with wide-ranging preferences and beliefs, we don't have anything resembling a common briefing. And I think that's a problem worth trying to solve, even naively.

The Naivety Problem

Let me address this head-on: an LLM reading RSS feeds cannot replicate the intelligence community. It can't access classified information. It can't run human intelligence networks. It can't task satellites. The analytical depth of a thousand trained intelligence professionals working across sixteen agencies is not reproducible by a Python script running on GitHub Actions. Period.

But here's what I learned when I actually built the thing: the PDB's genius isn't omniscience. It's discipline.

The PDB format imposes a structure on information that transforms how it's consumed. Structured assessment instead of narrative reporting. Explicit confidence levels instead of implied certainty. Shown reasoning instead of assertions. Disclosed sources instead of anonymous authority. A finite daily artifact instead of an infinite stream.

That discipline is exactly what you can encode in an automated pipeline. And it's exactly what LLMs are good at.

The first time the pipeline produced a complete daily brief, I expected it to read like a news summary, a cleaned-up version of whatever the RSS feeds contained. It didn't. It read like a briefing document. The items had the shape of assessments, not summaries. They told me what happened, then what it meant, then how confident the system was, then what to watch for next. The evidence panel showed me which sources agreed and disagreed and what questions remained open. After reading the Day One CDB even in its most rudimentary form, I was hooked. Somehow it worked.

It turns out the distinction between "what happened" and "what it means, how sure we are, and what to watch" was a prompt engineering problem with a real answer. Not a perfect answer. But a real one.

What's Missing from Public Information

I want to be specific about the gap the CDB tries to fill, because "news is broken" is a tired take and I don't think it's quite right. News isn't broken. Reporting in many ways is as good as it's ever been. Individual articles from good outlets are well-sourced, carefully written, and factually rigorous. What's broken is the layer above reporting, the synthesis layer that takes all that reporting and says: "Given everything, here's what's actually happening."

That layer used to exist implicitly. When there were three TV networks and a handful of national newspapers, the nightly news served as a rough common briefing. Not because Walter Cronkite's delivery was inherently more truthful or unbiased, but because it was shared. Everyone got the same information in the same format at the same time. You could flip between those three stations and for the most part see a consistent framing of events. That shared baseline, imperfect as it was, enabled a kind of common understanding that we've lost.

The CDB tries to rebuild that layer. Not by pretending to be unbiased (the methodology page explains exactly how significance is scored and what the trust signals mean), but by being assessed in a way that's transparent and shared.

Here's what that looks like in practice:

Explicit confidence levels. Every item says "high confidence," "moderate confidence," or "developing." These aren't feelings. "High" means multiple independent sources confirm the key facts. "Moderate" means credible sources but limited independent confirmation. "Developing" means the situation is fluid and key facts may change. You know exactly what the system thinks it knows and how sure it is.

Agreement signals. Separately from confidence, every item indicates whether sources broadly agree, have mixed interpretations, or are actively disputed. Confidence and agreement are orthogonal, meaning you can have high confidence in the facts but mixed agreement about what they mean. That's OK because encoding both gives readers something rare: a structured way to understand not just what happened but how the information landscape looks. It doesn't mean the facts differ, it means the interpretations of the facts vary.

Why it matters. Every item articulates its significance directly: what the development means for the broader picture, who is affected, and why it deserves your attention today. This is the analytical "so what?" that good reporting often leaves implied. Forcing the system to make that judgment explicit separates news from noise, and gives you something to weigh rather than just absorb.

What's next. Every item lists what the system assesses may be coming next, which is also revealing what the system doesn't yet know. This is the most countercultural feature. News rarely says "we don't know." The CDB says it on every item, explicitly, as a structured field. Not knowing is information. Please read that last sentence again, it's important.

Common ground. The facts that all sources agree on, listed as a checklist. This is the verified baseline, the floor of shared reality beneath any disagreements about interpretation.

When It Stopped Feeling Naive

It happened faster than I expected. The first complete pipeline run produced something that genuinely read like a briefing document, not a news summary. The items had a shape and a voice that I hadn't explicitly designed, they emerged from the structural constraints I'd imposed.

The "what changed" field forced the LLM to identify the specific new development, not the background. The "why it matters" field forced analytical judgment, not description. The "what's next" field forced forward-looking assessment, not recap. The trust signals, confidence and source agreement, forced transparency about what the system knows and where reasonable readers might still disagree. Together, these constraints produced something that reads the way an analyst thinks: event, significance, confidence, outlook.

I started reading the CDB's output the way I read well-made analytical documents, with the trust signals informing how I weighted each assessment. An item with high confidence and broad agreement gets filed differently in my mind than one with developing confidence and disputed agreement. Not because one is more important, but because they require different kinds of attention.

That shift, from "reading the news" to "processing a briefing," is what convinced me the project wasn't naive. It might be incomplete, imperfect, and limited by its sources. But the format itself does something that no news feed, no social media timeline, and no cable news broadcast does: it tells you what the system thinks, how confident it is, and what it doesn't know, in a structure designed for decision-making rather than engagement.

Another note on the naivete: I'm not a journalist or a political analyst, and I'm not pretending to be. But I've spent a significant portion of my career reading, writing, and analyzing dense technical documents: I wrote computer books for over a decade and authored or contributed to more than 50 titles. That's not a flex; it's an acknowledgment that processing structured information for a reader is a skill I've practiced. Far from the best person to attempt this, but also far from the worst.

The Honest Version

Last thing, I could've written this as a polished origin story, and in some ways so far it is. "I identified a gap in the information ecosystem and built a solution." But that's not what happened.

What happened is I was frustrated. I'd read four different outlets' coverage of the same event and come away with four incompatible understandings. Not because the reporting was bad, it wasn't, but because each outlet framed the same facts through a different lens, and none of them told me how confident I should be in any of it. I wanted someone to just brief me. To say: "Here's what happened, here's what it means, here's what we know and what we don't."

Then I realized: the format that does exactly this has existed since 1961. It's the President's Daily Brief. And while I can't replicate the intelligence community's capabilities, I can replicate the format, the discipline of structured assessment with explicit confidence and shown reasoning.

And once I realized the format existed, the other critical piece fell into place: AI. Even if this project was undertaken by humans, which I'm sure a few critical readers will suggest, do you really think a human is going to beat a machine at precisely what machines are good at? IBM's Deep Blue settled this debate back in 1996 when a machine first beat a human in chess. Strategic information processing sits squarely in the wheelhouse of LLMs.

So I built an LLM-based pipeline. And the first output was better than I expected. Not because the AI was smarter than I thought, but because the format was more powerful than I'd appreciated. Structured assessment with trust signals turns out to be a genuinely different experience from reading news, regardless of who (or what) produces it. I had sorta stumbled into a use case that absolutely played to the strengths of AI.

The gap between "this feels arrogant to attempt" and "but who else is doing it?" is exactly where the CDB lives. It's a Lab project in the truest sense, an experiment built to test whether a format borrowed from the intelligence community can serve the public. The hypothesis is that what's missing from public information isn't more reporting, better algorithms, or less bias. It's discipline. Structured assessment. Shown reasoning. Honest uncertainty.

That's what the PDB gives the President every morning. The Citizen's Daily Brief is an attempt to give it to everyone else. Let me know what you think, the web version is live now at citizensdailybrief.org, with mobile apps coming soon.

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

How Tall Tales Almost Ended Up in Starbucks

Stalefish Labs — Fri, 01 May 2026 19:04:19 +0000

In the fall of 2001, I was deep into creating a trivia/storytelling game called Tall Tales. I started meeting my brother Steve at a Starbucks near our house in Nashville, after his AA meetings let out. It was one of the "good periods" with my brother, when he was focused on recovery and we could have a reasonably normal relationship. We had ups and downs over the years, and this stretch would prove to be the most meaningful one we shared. Often a few of his sober friends came along for our nightly coffee sessions, and it being summer and nighttime, we'd typically sit outside. The tables were small, maybe twenty-four inches across, and we'd push two together to get four or five chairs around. The conversation ranged wildly and there was a variety of interesting characters from night to night, and periodically I'd pull a half-finished prototype of my game out of the car to playtest.

Like most indie games, Tall Tales was a side project, and I had been working on it for about four years at that point. The constraint of those little patio Starbucks tables, room for about two coffees and a pastry in the middle (cheese danish!), is the reason Tall Tales is shaped the way it is. I didn't know that when I started bringing it. I figured it out around the third or fourth evening, when I noticed I'd been quietly redesigning the game to fit that particular surface.

The most-played new trivia game in America at that point was Cranium. It had launched in 1998, the work of two ex-Microsoft colleagues, and become a phenomenon largely on the back of an unusual distribution deal: it was sold in Starbucks stores. Howard Schultz's "third place" thesis, Starbucks as the place between home and work, was at its rhetorical peak. The third place was supposed to have games in it, and Cranium had won the slot. And Schultz was right, Starbucks was precisely that third place for me, my brother, and his friends.

I was a fan of Cranium, but got frustrated every time we tried to play it at a Starbucks. The board didn't fit on the tables. Its design drew from traditional board games — it was built for a dining room table. We'd push two café tables together and the board would still hang off the edge, and someone would inevitably bump it knocking pieces around. The mechanic and the venue weren't aligned. Turns out Cranium was better designed for your first place, not your third place.

The thing I noticed at the third or fourth evening with Steve's crew was that the prototype I'd brought, by then a deck of cards, a die, a stack of creature-puzzle cards, and no board...fit. It fit on the table with two coffees and a slice of marble loaf (runner-up to cheese danish) still in play. We could actually play it there. And the game's social mechanics — bluffing, voting, telling whoppers about the worst date you'd ever been on — turned out to be exactly the kind of thing that worked in a coffee shop. A board game asks you to focus on the board. A storytelling game asks you to focus on each other. The Starbucks table, where you were already focused on each other, was the right venue. I wasn't adapting the game to the venue. The venue was telling me what the game already wanted to be. It took a while but I eventually listened.

I went home and rewrote the design pitch. It wasn't "a card-based trivia game" anymore. It was "a lounge game," and the entire spec started organizing itself around that idea. No board. No dice. No writing. Two minutes from picking up the box to playing the first card. A footprint that fit the smallest table you could realistically be sitting at. What's funny in retrospect is that I called this version of the game the Pocket Edition, with full plans to produce a full-size version later. It turned out the Pocket Edition became the game, because it was the size for which the content and game mechanics were naturally tuned.

I started writing pitch letters to Starbucks in September 2002.

There were three of them, to three different people inside the company — one to Orin Smith, who was then the CEO, one to Darren Huston, a senior VP, and a generic one to "Coffee Folks" at the corporate PO box, in case the more targeted ones bounced. They have aged about the way you'd expect a thirty-something's pitch letters to age: a little earnest, a little knowing, a little too proud of phrases like "die-hard Starbucks customers and Starbucks shareholders." I did own a little Starbucks stock at the time, so that was fully above-board, if not a bit cheeky. I cited the Cranium comp directly. Starbucks had figured out games could thrive in their setting; I had simply built the game that fit.

The letter to Darren Huston went further than the others. I told the actual story of why I'd designed the game the way I had — the evenings, the small tables, the support meetings, my brother. The pitch was that the design hadn't come from a market analysis of the third-place trend; it had come from being in the third place, week after week, watching what actually fit and what didn't. We'd already proved the use case before we knew it was a use case.

I made prototype cards in Starbucks-themed artwork. [Insert: detail crop from Prototype/StarbucksCards.ai.] The Illustrator file is still in the project folder. They were never delivered — by the time the first real response came back from Seattle, it was clear the answer was going to be no.

Starbucks evaluated the game and passed. They didn't say it wasn't good. They said it wasn't a fit. I assume the real answer was something more like "we already have Cranium and aren't looking to add a second game right now," which is a fair answer. Cranium had been a hit for them. Shelves are finite. Tall Tales went on to ship at the American International Toy Fair the following February without Starbucks distribution, found a small but enthusiastic following at independent toy and game stores, and never broke through the way we'd hoped. The lounge-game thesis turned out to be right. The retailer who would have validated it didn't bite.

I'm telling this story in 2026, as part of putting the last of the Tall Tales inventory up for sale on the Stalefish Labs site — which is a slightly strange context for it. But I've been carrying the inventory around for decades, and decided maybe it's time to tell the tale of how it came to be, and then let it go. One quiet thing before the link.

Steve died a few years ago, in an alcohol-related accident, years after any of this. He was sober during those evenings in 2001 and 2002. He was sober for long stretches in the years after. AA recidivism is all too real, recovery is not a clean arc, and his story is not the redemptive one I might have written if the game had succeeded and he had outlived us all. None of that makes Tall Tales a memorial. But the design philosophy that became the spine of the game came directly from sitting at a small table with my brother during one of his sober stretches, and pretending otherwise to sell a card game in 2026 would be dishonest. He's the reason the table-fit constraint exists. He's the reason "lounge game" is a phrase I made up. The work happened because he was at the table. He was an incredibly funny and articulate person, and I miss him.

The remaining copies of Tall Tales Pocket Edition are here.

If anyone in your life is in recovery and you think a card game might find a place at the table the way it did for us, reach out via the Stalefish contact page. I have a small stack set aside for that.

Of course I kept a few for myself for the personal memories.

Anatomy of a Skateboard Ramp: 3D Visualization and Materials Math

Stalefish Labs — Wed, 15 Apr 2026 20:02:19 +0000

I have a joke that if you ever meet a skateboarder over the age of 40, you're likely looking a reasonably accomplished amateur carpenter. It was historically a DIY sport, and many of us learned how to build ramps more or less on our own, with mixed results. Building a skateboard ramp isn't necessarily expert level carpentry, but there are important details and some common conventions that matter a great deal. For many of us, it was an exercise in optimism meeting carpentry. You start with a vision, a backyard quarterpipe or maybe a garage mini ramp, and quickly drown in questions. How tall, what radius, how many sheets of plywood? What about Skatelite or some other composite surface, even remotely in budget? What lumber lengths do I need? Will it actually look like the thing in my head?

After I had a friend lament having no clue how much his new dream ramp might cost, I thought wouldn't it be cool to have a little lightweight CAD'ish tool for visualizing and obtaining a materials list for skateboard ramps. I built the Ramp Designer to answer the tricky questions surrounding ramp design, and help my friend come up with a budget for his ramp. It's a free, browser-based tool that generates a real-time 3D model of your ramp and calculates a complete materials list, down to the screw count.

Why Ramp Design Is Harder Than It Looks

Before going any further, it's worth noting that I'm specifically talking about curved skateboard ramps where the curve follows a fixed radius. In skateparks you will no doubt find banks, ledges, slants, and maybe even curved ramps with elliptical (varying) transitions, but classic quarterpipes and halfpipes you see in backyards or X-Games Vert are the focus here. Given that, a wooden skateboard ramp follows a certain recipe to allow for the curve via a layered construction: plywood side templates cut to a precise arc profile (radius), structural ribs running across the width, a plywood deck at the top, two layers of surface plywood bent over the ribs, now days mercifully a specialized riding surface on top of that, and a steel coping pipe at the lip. Each layer has its own material, its own fastener requirements, and its own set of constraints. And by the way, I said mercifully about the top surface because modern skate-specific composite surfaces like Skatelike, Ramp Armor, and Gator Skins dramatically improve the safety and usability of ramps - no more rot, and no more splinters!

The curve itself, the transition, is what makes a ramp a ramp and not a wedge. A good transition follows a circular arc carefully matched to the height of the ramp, and the radius of that arc determines how the ramp feels to ride. A tight radius (small number) produces a quick, steep, snappy transition. A large radius creates a mellow, flowing curve. The relationship between height, radius, and the resulting arc length drives every other calculation in the build. And generally speaking there isn't entirely a right or wrong, just extremes. For example, an extremely tight radius is more like a backyard pool like you might've seen in the Dogtown and Z-Boys documentary.

The Arc: Circular Geometry in Practice

The transition profile is a circular arc. Given a ramp height h and a transition radius r, the arc sweeps from horizontal (the flat approach) to vertical (or near-vertical at the lip). The math is clean:

θ_max = acos(1 - h/r)    // when h ≤ r
arc_length = r × θ_max

For mini ramp transitions where the height is less than or equal to the radius, this produces a smooth curve from 0° to θ_max, meaning the curve never makes it to 90°, it never reaches vertical. But some ramps deliberately go vertical, the height exceeds the radius, and that makes them vert ramps. In that case, the curve is a full quarter circle (90°) plus a straight vertical section at the top:

// Vert ramp (h > r)
arc_length = r × π/2 + (h - r)

The simulator generates the arc as an array of coordinate pairs, sampling the curve at regular angular intervals. These points define the side template profile that gets cut from plywood, and they're the foundation for positioning every rib, surface sheet, and seam line in the 3D model.

Curve Offsetting for Layers

A ramp has ribs inset and flush to the transition curve with multiple layers stacked on top, typically two subsurface plywood layers, followed by a third riding surface layer. Each layer needs to follow the same curve, but offset outward by the material's thickness. It's worth noting some metal-framed ramps like Tony Hawk's famous portable warehouse ramp forego the two layers of subsurface and just go with one, but the ramp is engineered specifically to allow that.

To get the radius to straighten to vert involves offsetting the circular arc, which is straightforward in theory (just increase the radius), but the simulator handles it with a general-purpose offsetCurve() function that works on arbitrary point arrays. At each point, it computes the perpendicular normal using the slope between neighboring points, then shifts the point outward by the offset distance.

This approach handles the transition from arc to vertical extension seamlessly, without special-casing the geometry at the inflection point.

The Materials Engine

The materials calculator is where abstract geometry meets the lumber yard. Every dimension in the model maps to a real-world purchase decision, and the calculator accounts for constraints that CAD software ignores.

Lumber Length Rounding

You can't buy a 9-foot 2x6. Lumber comes in standard lengths: typically 8', 10', 12', 14', and 16'. The calculator rounds every piece up to the nearest available length. A rib that measures 8'3" in the model becomes a 10-footer on the shopping list. This is a small detail that prevents a lot of frustration at the lumber yard. It also helps you use the designer as a playground to experiment with materials sweet spots - wider is always better for skateboard ramps, and being able to know exactly the price difference between +4' and +8' in width is a big deal.

Sheet Goods Efficiency

Plywood comes in 4×8 sheets. The calculator optimizes sheet counts by checking whether multiple pieces can be cut from a single sheet. For side templates, if the ramp height is 48" or less and the arc length fits within 96", two sides can be cut from one sheet. Taller vert ramps need a multiple sheets per side, and the 3D model shows the horizontal seam at 4 feet where the two pieces join.

Surface plywood is simpler: the calculator computes total surface area (arc length × width), divides by 32 square feet per sheet, and rounds up. Two layers are always used — the inner layer provides structural rigidity while the outer layer creates a smooth riding surface. Currently the tool forces 4x8 sheets, which is correct for plywood but specialty surfaces like Skatelite also come in larger dimensions up to 5x12 - that may be a future addition to the tool.

Rib Spacing and T-Ribs

Ribs are the structural backbone of the transition. They run perpendicular to the riding direction, spaced at regular intervals along the arc. The simulator offers three spacing options:

Spacing	Use Case
6" on center	Overbuilt — heavy but bomber
8" on center	Standard — recommended for most builds
12" on center	Budget — lighter, not ideal except for very small ramps

But ribs aren't uniform. And this is where some ramp builders diverge and have different techniques, but I like this one. Every 4 feet along the arc (where surface plywood sheets butt together), the simulator places a T-rib instead of a standard rib. A T-rib is constructed out of two ribs joined together to form a T, providing more surface for the plywood sheets to meet and form a seam. Think of it as a rib T having a cap perpendicular to the stem, creating a wider bearing surface at the sheet seam. This prevents the plywood edges from telegraphing through the riding surface over time.

The 3D model clearly renders T-ribs so builders can identify them during assembly. It's somewhat a matter of construction preference where you start the T's, as it has to do with where you start the plywood sheets. What's important is that the T's form a predictable pattern so that at least the first layer of plywood seams always meet on a T, for example every 4'.

Fastener Estimation

Screws are the most tedious part of a materials list. The calculator estimates counts based on fastener density per component:

Structural screws (#10 × 3"): rib-to-side connections, framing joints, deck joists
Surface screws (#8 × 2"): plywood surface layers, riding surface material

Counts are rounded to the nearest 25 or 50 to match bulk packaging. For outdoor builds, the calculator specifies coated or stainless fasteners and adds a note about corrosion resistance. Screws are definitely the one part of the build where you can use your own judgement if you find something you like in a slightly different length. There's also debate over whether screws in the final riding surface should align hit ribs - manufacturers say yes, practical ramp builders sometimes say no.

The Full Shopping List

A complete materials list for a typical 4-foot tall, 8-foot wide quarterpipe might include:

Material	Quantity	Notes
3/4" Plywood (sides)	2 sheets	Side templates
3/8" Plywood (surface)	4 sheets	Two layers
2×6 × 8'	12	Ribs (includes T-ribs)
4×4 × 4'	4	Back support posts
2×4 × 8'	6	Deck joists, plates
2⅜" Steel pipe × 8'	1	Coping
Skatelite 4×8	2 sheets	Riding surface
#10 × 3" screws	150	Structural
#8 × 2" screws	200	Surface

The half pipe configuration doubles most of these quantities and adds flat bottom materials (joists, surface, framing).

The 3D Model: Eight Layers Deep

The 3D visualization is built with Three.js and renders the ramp as eight distinct layer groups:

Sides — 3/4" plywood transition templates (don't skimp and go thinner with these)
Ribs — 2×6 or 2×4 structural members following the arc
Back Frame — 4×4 posts and plates supporting the deck
Deck — 3/4" plywood platform with joists
Surface Layer 1 — 3/8" plywood
Surface Layer 2 — 3/8" plywood
Top Surface — Riding material (Skatelite, Masonite, etc.)
Coping — 2⅜" steel pipe at the lip

Each layer is a separate Three.js group, which enables the explode view, a slider that separates the layers vertically so builders can see the assembly order and understand how the pieces fit together.

Building the Side Templates

The side templates are the most complex geometry in the model. They're created as THREE.Shape objects, 2D profiles defined by the arc points, and then extruded to 3/4" thickness using ExtrudeGeometry. The profile includes the arc curve, a vertical edge at the back, a horizontal edge at the bottom, and the deck platform at the top.

For ramps taller than 4 feet, the model adds a horizontal seam line showing where two 4×8 plywood sheets would join. This is a visual reminder that tall side templates require multiple sheets and careful alignment during construction.

Positioning Ribs Along the Arc

Each rib is a rectangular box positioned at a point along the arc and rotated to match the curve's tangent angle at that point. The rotation is critical, a rib that's not rotated perfectly tangent won't square up to the plywood surface, providing far less structural support.

The tangent angle at any point on the arc is calculated from the slope between adjacent arc points. The rib is then rotated around its center to align perpendicular to the curve, ensuring full contact with the surface plywood.

Surface Sheet Seams

Real plywood sheets are 4×8 feet. The simulator renders individual sheets with visible seams between them:

Arc seams appear every 8 feet along the curve (where sheets butt end-to-end)
Width seams appear every 4 feet across the ramp (where sheets sit side by side)

These seams are rendered as thin dark lines on the outermost visible surface. They're not just cosmetic — they help builders plan sheet layout and understand where T-ribs need to be placed for support. I should add, one thing the tool doesn't do just yet is offset the seams on the plywood layers. In practice you would shift layers a fixed amount, say 2' in each dimension so that seams overlap and you don't risk future bumps in the ramp.

The Coping

The coping is a steel pipe rendered as a THREE.CylinderGeometry with metallic material properties (metalness: 0.7, roughness: 0.3). It sits at the lip of the transition, where the arc meets the deck. Getting the coping position right is critical — it's the last thing a skater touches before going airborne, and in the 3D model it helps verify that the transition profile looks correct.

The framing of how coping joins a ramp, or the coping pocket, is one of the trickiest aspects of ramp building, and varies widely from builder to builder. I choose a fairly straightforward approach here since the goal was more about visualizing the ramp and figuring out materials. I haven't ruled out a future coping pocket tool to break down how exactly to frame it and get the surface and deck pop dialed in.

Design Decisions That Mattered

Indoor vs. Outdoor Toggle

The environment toggle switches more than just material names. Outdoor builds use pressure-treated (PT) lumber, which is heavier, more expensive, and requires coated fasteners. The calculator updates every line item: PT 2×6 instead of 2×6, coated screws instead of standard, and adds notes about ground contact treatment for the bottom plates.

This is a single checkbox that changes 30+ line items in the materials list. Getting it wrong means either building an outdoor ramp with wood that will rot in two seasons, or spending 40% more than necessary on an indoor build.

Section Width: 4' vs. 8'

Section width determines how far apart the side templates are spaced. At 4-foot sections, a standard 8-foot-wide ramp has three side templates (both edges plus center) and two sections of ribs. At 8-foot sections, it has two templates (edges only) and one section of ribs. Some people like to overdo it structurally with narrower sections but 8-foot is pretty standard.

The 4-foot option is labeled "overbuilt" because it doubles the plywood cost for side templates and adds significant weight. The extra rigidity prevents the surface from developing a noticeable bounce between supports but at the expense that you have to cut and assemble a lot more transitions and perfectly align them.

The Explode View

The explode slider was inspired by technical illustrations in woodworking manuals. Dragging it from 0% to 100% lifts each layer progressively — sides stay at the bottom, coping rises to the top, and everything in between fans out proportionally.

The maximum separation scales with ramp height (2× the height), so a 4-foot mini ramp explodes to a manageable 8-foot spread while an 11-foot vert ramp expands to 22 feet. Surface sheets also spread apart laterally (along the z-axis) so individual sheets are visible even when multiple sheets span the width.

The Transition Facts Sticker

A small detail: the 3D model includes a procedurally generated "sticker" on the near side template, about 40% up the arc. It displays the ramp's key specs — height, radius, width, deck depth, surface material, coping presence — and an "Overall Vibe" rating based on the combination of specs.

It's whimsical, but it serves a purpose: it gives the 3D model a sense of personality and makes screenshots immediately informative when shared with friends or posted for feedback. And it is generated using another fun tool called Transition Facts. Try it out!

What Was Learned

Lumber math is surprisingly hard. The gap between theoretical geometry and real-world lumber is where most ramp builds go wrong. You can calculate a perfect radius in a spreadsheet, but if you don't account for lumber length standards, sheet goods sizes, and realistic fastener quantities, you'll make three trips to the hardware store instead of one.

Exploded views teach better than assembly diagrams. Static diagrams show you what a ramp looks like. Exploded views show you how it goes together. The slider interaction — dragging layers apart and watching them fan out — builds spatial understanding faster than any set of written instructions.

PDF export matters more than expected. I added PDF export as an afterthought. It turned out to be the most-requested feature in early testing. People want to take their ramp design to the lumber yard, and a phone-friendly PDF with the 3D view and materials list is exactly the format that works.

Try It

The Ramp Designer runs entirely in your browser. No account, no install, no tracking. Choose quarterpipe or half pipe, set your dimensions, and start designing.

The Ramp Designer is a free experiment from Stalefish Labs.