From the lab | Stalefish Labs

Building an Automated Analyst

Michael Morrison — Tue, 12 May 2026 00:00:00 -0700

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

Michael Morrison — Tue, 05 May 2026 00:00:00 -0700

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?

Michael Morrison — Sun, 03 May 2026 00:00:00 -0700

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

Michael Morrison — Fri, 01 May 2026 00:00:00 -0700

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 where we lived 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.

Cranium and the third place

The most-played new 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.

Three letters to Seattle

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.

Why I’m telling this now

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

Michael Morrison — Thu, 02 Apr 2026 00:00:00 -0700

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.

The Group Chat Had It Right: Why I Un-Fixed Visible Picks

Michael Morrison — Tue, 31 Mar 2026 00:00:00 -0700

In a previous article, I wrote about how moving our F1 fantasy game from a text thread to an app unlocked pick categories that were too tedious to score by hand. The Overtaker pick replaced Fastest Lap in the app, and made the game better by doing things the group chat couldn’t.

This article is about the opposite: a case where building the app made me worse at game design, because I reflexively added a restriction that the group chat never needed. It was a lesson in not always doing things just because you can.

How it worked in the text thread

Our original game was dead simple. A group of friends who enjoy watching Formula One making lightweight fantasy picks for each race. It was all managed in a text thread and in Notes on my phone. You texted your picks to the group before the race started. Everyone saw everyone’s picks the moment they hit the chat. You could change your mind as many times as you wanted, right up until the formation lap. Nobody really tracked or enforced a hard deadline because the gentleman’s agreement was enough.

And here’s the thing we mostly took for granted but everyone enjoyed: you could see what your rivals picked. If you were trailing in the standings and neck-and-neck with someone, you might deliberately wait to see what they picked, and then pick a different driver for the podium to create a scoring differential. If you were leading, you might mirror a rival’s picks to protect your gap. It wasn’t chess, but it was a real layer of strategy on top of “who do you think finishes on the podium.”

Yet during several years of playing this way, almost nobody actually changed their picks strategically after submitting. The option was always there, but people mostly picked and moved on. What I learned the hard way is the strategic value wasn’t in last-second switching. It was in the information: knowing what you were up against.

What I did when I built the app

When I sat down to build Open Wheelers the app, I did what felt obvious: hide everyone’s picks until they lock. Blind picks. You submit yours, you see a checkmark next to your leaguemates’ names confirming they’ve picked, but you don’t see what they picked until the window closes and picks lock (the race start). Standard fantasy app behavior. The app suddenly gave me the power to enforce a new rule (blind picks), so why not do it?

I didn’t even really think about it too deeply. Every fantasy platform I’d ever used worked this way. Draft picks are secret. Lineup changes are private. Why would you show your poker hand a moment sooner than required? The whole model assumes that seeing someone else’s choices gives you an unfair advantage, so the system prevents it. It’s such a default assumption that I never questioned whether it was actually right for this game. And this is even given the knowledge that I deliberately set out to build a contrarian fantasy game!

What I lost

During initial testing of the appified game, something felt off. The picks phase was… quiet. You’d open the app, make your picks, close it, and wait. There was nothing to talk about until the race started and picks were revealed. The group text thread used to buzz with reactions to each other’s picks. Hot takes. Trash talk. “Lewis is struggling with Ferrari but you just can’t quit him, eh?” That energy was gone, replaced by a sterile, sealed-envelope experience.

Worse, I’d killed the strategic layer entirely. You couldn’t differentiate from a rival because you didn’t know what they picked. You couldn’t mirror someone to protect a lead because their picks were invisible. Every decision was made in a vacuum, which sounds fair but actually just makes the game shallower. Pure prediction skill is fine, but prediction skill plus situational awareness is more interesting. Indeed, sometimes ultimate fairness loses out to quality of life.

The irony is that I’d written a whole article about how the app should unlock more depth, not less. And here I was, having voluntarily removed a dimension of gameplay that the text thread gave us for free. Indeed, sometimes less is more.

The “because I could” trap

This is the trap, and I think it’s common in software: when you move something analog to digital, you inherit assumptions from existing digital products instead of examining what actually worked about the original. I looked at other fantasy apps and copied their pick visibility model without asking whether it fit our game. Which is admittedly funny because up to this point I literally looked at nothing else in fantasy F1 apps because I wanted Open Wheelers to be its own unique thing.

The group chat didn’t hide picks because it was good game design, it literally couldn’t. Messages are visible to everyone. But that constraint turned out to be a feature. It created a social, strategic experience that I then engineered away because I had the power to build walls that a text thread couldn’t.

Sometimes “because I could” is the right answer. The Overtaker category exists because the app can compute grid-to-finish deltas automatically. That’s a genuine improvement, and the gains were felt immediately. But hiding picks? That was me solving a problem that didn’t exist, importing a convention from games with different dynamics, and making the experience worse in the process. I went with effectively the software default when in reality the low-tech constraint was a winner all along.

What I changed

The fix was almost embarrassingly simple. Picks are now visible to your leaguemates the moment they’re submitted. You can still change yours freely until they lock at the start of the race, just like the text thread. No countdown timers, no change limits, no special mechanics. Just open information and the freedom to act on it.

Will some people wait to see what others pick before committing? Maybe. Will there be occasional last-minute switches and skulduggery? Probably. But years of running the text thread game proved that this mostly doesn’t happen, and when it does, it’s fun. It’s a feature, not a bug. “Did you see that she switched her podium pick 30 seconds before lights out?” is exactly the kind of story a fantasy game should generate.

The design principle

Last time, with the Overtaker change, the lesson was that the best mechanics are often the ones too complicated to run by hand. This time it’s the complement: not every analog constraint is a problem to solve. Some constraints are load-bearing walls disguised as limitations.

When you’re digitizing a game, or really any experience, the hard part isn’t adding capabilities. It’s knowing which rough edges to preserve. The text thread’s visible picks felt like a limitation of the medium. They were actually a core part of the game.

Build the features that were impossible before. But before you “fix” something that wasn’t broken, go back and play the original. The group chat might know something you forgot. Box, box.

Open Wheelers is a casual F1 and IndyCar fantasy game for friends, built by Stalefish Labs.

Building Confidence Into Uncertain Verdicts

Michael Morrison — Fri, 27 Mar 2026 00:00:00 -0700

This is the final article in the Building a Weather Decision Engine series. The previous articles covered the drying model, multi-app architecture, edge cases, and the Yardwise inversion. This last one is about the output side, how the engine communicates decisions to people who just want to know if they should go ride.

Why Not a Percentage?

The first version of the engine returned a moisture percentage. Users hated it. To be honest I kinda hated it too but it was the first logical thing to represent as meaningful output.

“Your trail is at 47% moisture” sounds precise. But what do you do with that? Is 47% rideable? It depends on the surface, your tolerance for mud, whether you care about trail damage, and how far you’re willing to drive for a “maybe.” The percentage outsources the decision to the user, which is the entire thing the app was supposed to handle. Besides, I have no idea what percentage tips me one way or the other toward making a real life ride decision.

A percentage also implies false precision. The engine’s moisture model is a reasonable approximation, not a soil sensor reading. Presenting a number with two significant digits suggests an accuracy that doesn’t exist, so it’s misleading. The difference between 47% and 49% is noise, not signal.

Three states (Yes, Maybe, No) work because they match how people actually think about the decision. You’re either going (Yes), not going (No), or weighing it (Maybe). The engine’s job is to put you in the right decision bucket, not to give you a homework problem.

The Maybe State Is the Product

The Yes and No verdicts are straightforward. The real design challenge is Maybe.

Maybe exists for conditions where reasonable people would disagree. A wetness score of 0.4 on a dirt trail means it’s damp but not muddy. Some riders would go. Others would wait. A veteran on a hardtail who likes playing the drift might like the extra challenge of some surprise slip here and there. A flowier rider on a full-suspension with less tire clearance might not want to bother and risk the occasional wet low spot. There’s also some variance in trails opening and closing based on conditions, which is another facet of where local knowledge would tip a Maybe verdict one way or the other.

The engine can’t make that call for you. What it can do is tell you why conditions are borderline, so you can apply your own judgment.

Rationale: The Why Behind the Verdict

Every assessment includes a structured rationale:

struct GroundwiseRationale {
 let headline: HeadlineReason
 let decisiveFactor: DecisiveFactor
 let headlineContext: HeadlineContext
 let details: [DetailReason]
 let values: RationaleValues
}

The headline is the one-line summary: “Light rain still drying” or “Strong drying clearing moisture” or “Frozen conditions — ice hazard.” It’s what the user reads first.

The decisive factor identifies the single most important reason for the verdict. This is the tie-breaker — the one variable that, if changed, would flip the result. “Recent heavy rain” or “weak drying conditions” or “surface sensitivity.”

The details array provides up to six contributing factors, each describing how a specific weather element is affecting conditions, either positively or negatively. Temperature is helping. Humidity is slowing things down. Wind is moderate. These aren’t ranked by importance, they’re presented as a set of forces that the user can scan to build their own picture, with the verdict-supporting forces appearing first.

The engine deliberately avoids showing the raw numbers in the rationale. Users don’t need to know that drying strength is 0.53 or that the wetness score is 0.38. They need to know “drying conditions are moderate — warm but humid.” The rationale translates numbers into plain language.

Confidence: Admitting What You Don’t Know

Each verdict has a confidence level — Low, Medium, or High. Don’t forget that we’re highly dependent on the weather source, and can’t control the occasional hiccup where a piece of key data is missing. That’s where Confidence enters the picture, and it starts at High and gets reduced by specific factors:

Missing timing data → Low confidence. If the engine doesn’t know when rain ended (the minutesSinceRainEnded value is nil), it can’t model the timing decay that’s central to the wetness calculation. It defaults to a 0.5 timing score (assume moderate concern) and drops confidence to Low. The verdict might be right, but the engine is guessing about a critical input.

Patchy rain → Medium confidence. When the weather source indicates precipitation has been spotty and inconsistent (patchyRainLikely), the actual conditions at the user’s spot might differ from what the nearest weather station recorded. The engine can’t know whether the rain hit your trail or the parking lot a mile away. These are unknown unknowns, well maybe they’re known unknowns…either way we don’t know!

Near-threshold conditions → Medium confidence. If the wetness score lands within 0.05 of a verdict boundary (0.25-0.35 near the Yes/Maybe line, or 0.55-0.65 near the Maybe/No line), the engine reduces confidence because a small change in any input could flip the result. This is the engine saying “I’m calling it Maybe, but it could easily be Yes.”

The confidence level affects how the UI presents the verdict. A High-confidence No is “Don’t ride — conditions are poor.” A Low-confidence Maybe is “Conditions are uncertain — check conditions on the ground.” Same verdict structure, different emphasis.

What I Didn’t Do With Confidence

I considered making confidence a continuous value (0-1) or adding more levels. I didn’t, for the same reason I use three verdict states instead of a percentage: more granularity creates more decisions for the user without adding useful information. The whole point here is to simplify decision making.

The three levels map to three communication strategies:

High: Trust the verdict
Medium: The verdict is our best call, but conditions might surprise you
Low: We’re short on data, verify on the ground

That’s enough to calibrate expectations without overwhelming.

Recovery Outlook: “So When Will It Be Good?”

The natural follow-up to a No or Maybe verdict is “when will conditions improve?” I was initially skeptical about including this but it has turned out to be extremely valuable because as is often the case, I’m actually not looking at the app to ride right this moment, I’m typically planning ahead for “later today.” The engine provides a recovery outlook, a qualitative time estimate, to attempt to answer.

The outlook is a simple 2D lookup: wetness score vs. drying strength.

Wetness / Drying	Strong	Moderate	Weak
Low (< 0.4)	Within hours	A few hours	Maybe later today
Medium (0.4-0.6)	A few hours	Later today	Maybe later today
High (≥ 0.6)	Later today	Maybe later today	Unlikely today

The categories are deliberately vague. “Within hours” means 1-2 hours. “Later today” means afternoon or evening. “Unlikely today” means tomorrow at the earliest. The engine doesn’t say “rideable at 2:47 PM” because that precision doesn’t exist in the model and it would be ridiculous to pretend that level of accuracy.

The “maybe later today” bucket is the uncertainty hedge — conditions might improve, but the engine isn’t confident enough to commit. It’s the recovery equivalent of the Maybe verdict.

There’s also a “may worsen” outlook for cases where the forecast indicates more precipitation. If the next few hours include rain, the engine won’t tell you things are improving, even if current drying conditions are strong. This prevents the frustrating experience of waiting for conditions to improve only to get rained on again. And this is fairly common on days where I’m pretty sure the trail is day right now but less sure of how the afternoon is going to go. In this regard, the engine isn’t just a past weather + surface conditions evaluator, it’s also taking a peek into the future (forecast) to give you a sense of if things are trending better, worse, or more of the same.

Risk Categories: More Than Just “Wet”

It occurred to me fairly quickly when building Ridewise that what we’re dealing with here isn’t just the ability to ride, as in muddy or not muddy, but also the risk implications. I’m using risk here as a two-way term depending on activity: risk to the user and in some cases risk to the surface. For a concrete skatepark, it’s entirely user risk, but for a mountain bike trail or sod soccer field, it’s risk to the surface. Actually the mountain bike example might cut both ways but you get the idea. And there’s the quality of the activity that I decided was also effectively a risk. So beyond the binary wet/dry question, the engine evaluates three distinct risk categories:

Surface damage — Will using this surface in current conditions cause lasting harm? This matters most for natural grass athletic fields (0.9 sensitivity), newly seeded lawns (up to 1.0 with establishment boost), and clay courts (0.85). It matters least for artificial turf (0.05), metal (0.05), and compost (0.3).

Activity safety — Is the surface dangerous to use? Wet metal has the highest safety sensitivity (0.95) because it becomes extremely slippery. Composite ramp surfaces like Skatelite and Ramp Armor are also high (0.85), along with metal and concrete. Artificial turf and potting mix are low (0.4) because their textures maintain grip even when wet. Indeed nobody skates on potting mix, but this illustrates how one engine can serve three different apps if you’re very careful about the design.

Activity quality — Even if it’s safe, will the experience be poor? Mud on a dirt trail (0.7 quality sensitivity) makes for a miserable ride. A damp skatepark (0.6) is more debatable, and can range from totally fine (squeegee the ramp and it may dry out) to a complete no-go.

These three risks are calculated independently and presented alongside the verdict. A Maybe verdict might come with low safety risk but high damage risk — meaning “you’d be fine riding, but you’d rut up the trail.” That distinction helps the user make an informed call.

Putting It All Together

The full assessment output:

struct GroundwiseAssessment {
 let verdict: Verdict // Yes / Maybe / No
 let confidence: Confidence // Low / Medium / High
 let rationale: GroundwiseRationale // Why
 let riskSurfaceDamage: RiskLevel // Harm to surface
 let riskActivitySafety: RiskLevel // Danger to user
 let riskActivityQuality: RiskLevel// Experience quality
 let recoveryOutlook: RecoveryOutlook? // When will it improve
}

The verdict is the headline. Confidence tells you how much to trust it. The rationale explains why. Risk levels add nuance. Recovery outlook answers “when?”

None of these fields exist in isolation. Together, they give the user a complete picture in a few seconds of scanning — enough information to make a confident decision without reading a weather report.

The Design Principle

The engine’s output design follows one principle: make the decision for the user, then show your work.

Most users will see the verdict color, read the headline, and decide. That’s the 80% case, and it should take three seconds. The rationale, risk levels, and recovery outlook are there for the 20% who want to understand why, or who are in a borderline situation where the details matter. And yes, I want wildly overboard on the proving your work part because I wanted it to be crystal clear that this isn’t a pretty veneer over what is essentially a weather app — the Groundwise engine is doing sophisticated modeling in service of a “simple” yet nuanced and challenging question about rideability/playability/vulnerability (plant vulnerability in Yardwise).

This is the opposite of how most weather apps work. They give you all the data and expect you to synthesize it into a decision. The Groundwise engine synthesizes first, then offers the data for verification. The user’s default is to trust the verdict and act on it. The detail is available but not required.

That’s what made three states better than a percentage. A percentage demands interpretation. A verdict offers a recommendation. The supporting detail is opt-in, not mandatory.

Thanks for Reading

This series covered a lot of ground, from the core concept through the drying math, multi-app architecture, winter edge cases, the Yardwise inversion, and now the verdict UX. If you’ve built something that turns noisy data into human decisions, I’d love to hear about your approach. The threshold and confidence problems are universal.

The Groundwise engine powers Ridewise, Fieldwise, and Yardwise — all available for iOS from Stalefish Labs. Find us on Bluesky.

Flipping the Question: From 'Is It Too Wet?' to 'Is It Too Dry?'

Michael Morrison — Wed, 25 Mar 2026 00:00:00 -0700

When I first built the Groundwise engine for the Ridewise app, it answered one question: is it too wet to ride? Low wetness meant good conditions. High wetness meant stay home. Exactly what I needed for mountain biking, skateboarding, and other outdoor wheeled activities where surface conditions impacted by weather mattered.

Then I started thinking about my garden.

I have raised beds, a few containers on the patio, and a lawn that I’d like to keep alive without drowning it. I don’t get obsessive about it, and to be honest my lawn is far from impressive. I’m not one of those people who try to maintain golf course grass, far from it. But I’ve still regularly done that assessment where I look at the sky, vaguely remember whether it rained, and make the same kind of gut call on watering that I used to make about trails. The variables were familiar: recent rain, temperature, sun exposure, how fast things dry. I was running the same mental model, just asking the opposite question.

That realization is what turned one app into three. If the engine could quantify moisture on a surface, it could answer both “is it too wet to ride?” and “is it too dry, should I water?”

The Inversion

The engine always calculates a wetness score from 0 (bone dry) to 1 (saturated). The EngineMode enum controls what that score means:

Wetness concern (Ridewise, Fieldwise): Low wetness = Yes (go ride or play). High wetness = No (too wet).

Dryness concern (Yardwise): Low wetness = Yes (water today). High wetness = No (skip watering).

The verdict is the same enum, Yes, Maybe, No, but the interpretation flips. This means the consuming app doesn’t need to know which mode produced the result. It renders green for Yes, orange for Maybe, red for No, regardless.

The thresholds shift too:

	Yes	Maybe	No
Wetness concern	< 0.30	0.30 – 0.60	≥ 0.60
Dryness concern	< 0.15	0.15 – 0.45	≥ 0.45

Yardwise thresholds are lower because the stakes are asymmetric. This wasn’t immediately obvious until testing early versions of the app, when I realized that missing a watering day rarely if ever harms established plants. Riding a muddy trail damages the surface. So Yardwise is more lenient than the other apps, and leans toward “maybe check the soil” rather than “definitely water” — this makes the verdict less alarming. The reality is that the cost of a false positive (unnecessary watering) is real (overwatering causes its own problems), while the cost of a false negative (skipping one day) is usually trivial.

Manual Watering: Tracking What the Weather Doesn’t Know

Here’s where Yardwise diverges from Ridewise and Fieldwise most sharply. The weather API knows about rain. It doesn’t know that you ran the sprinkler for 20 minutes yesterday evening.

Yardwise lets users log manual watering events with timestamps. The engine converts these into precipitation equivalents that then get added to the rain score alongside actual precipitation, with the same time-weighted decay:

0-24 hours ago: 0.7x weight (70% contribution)
24-48 hours ago: 0.2x weight
48-72 hours ago: 0.1x weight

A watering yesterday contributes about 0.175 inches to the effective precipitation (0.25 × 0.7). That’s enough to shift a borderline “water today” verdict to “check soil” or even “skip.”

The decay is important. A watering three days ago shouldn’t prevent the engine from recommending water today, the moisture is long gone, especially in containers with fast-draining potting mix. The time-weighted model handles this naturally.

Cold Weather Extends Watering Memory

One wrinkle: cold weather slows evapotranspiration. A watering event that would normally decay in 48 hours can remain relevant for up to 96 hours during cold weather. The engine extends the effective window based on the same cold factor used for dormancy:

wateringWindow = 48 + 48 × coldFactor

At 34°F, the cold factor is about 0.62, giving a window of roughly 78 hours. At 45°F, it’s about 56 hours. This prevents the engine from recommending watering when yesterday’s water is still sitting in cold, slowly-evaporating soil. Keep in mind that winter watering is pretty rare, reserved almost exclusively for new plantings (trees, shrubs, etc.) and only during an unusual dry spell.

Establishment Sensitivity: Protecting Young Plants

Newly seeded lawns and recently transplanted plants need more water than established ones, and they’re far more susceptible to drought. The engine handles this through an establishment sensitivity boost that layers on top of the surface type’s base damage sensitivity.

Establishment	Sensitivity Boost
Established	+0.0 (default)
Newly planted	+0.2
Newly seeded	+0.5

This boost affects the sensitivity veto, the mechanism that pushes borderline verdicts toward protection. With a newly seeded lawn (base sensitivity 0.4 + boost 0.5 = 0.9 effective sensitivity), a Maybe verdict with wetness below 0.3 gets overridden to Yes: water those seeds.

For established plants with no boost, the same borderline conditions stay as Maybe: check the soil yourself. The engine doesn’t push you to water unless there’s a fragile surface that genuinely needs protection.

This is the same sensitivity veto that Fieldwise uses to protect natural grass athletic fields from being played on when borderline wet. Same mechanism, opposite direction. In wetness-concern mode, high sensitivity + borderline conditions → No (protect from use). In dryness-concern mode, high sensitivity + borderline conditions → Yes (protect from drought).

Dormancy and Evaporative Demand

Two Yardwise-specific wetness modifiers that were covered in the edge cases article deserve a brief recap in the context of the inversion:

Cold-weather dormancy injects additional wetness into the score when temperatures drop below 55°F. This suppresses watering recommendations by pushing the score toward the “skip” zone because dormant plants don’t benefit from watering and the moisture promotes root rot and fungal growth.

From the engine’s perspective, dormancy is saying: “the soil might technically be dry, but the plant doesn’t need water right now, so act as if conditions are wetter than they are.”

Low evaporative demand does something similar on cool, overcast, humid days. Even if the soil surface looks dry, the plant isn’t losing much water through transpiration when there’s no sun and the air is already saturated. A small wetness boost (up to 0.25) prevents unnecessary watering recommendations.

Both modifiers only activate in dryness-concern mode. They don’t make sense for riders or field sports, cold weather doesn’t make a trail less muddy, and overcast skies don’t affect whether the ground is rideable or a football field is playable.

Yardwise Surface Types

The Groundwise family shares a surface type system, but Yardwise introduces types that don’t exist in the riding or sports world:

Potting mix (containers) dries at 2.0x — the same rate as concrete. This isn’t a coincidence. Potting mix is engineered for drainage, just like concrete. Containers are also typically exposed to wind on all sides, which accelerates drying considerably. The result: containers often need daily watering in summer, even after rain. The engine captures this naturally because the high drying multiplier clears moisture quickly.

Amended soil with mulch dries at 0.7x — the slowest rate in the system, tied with clay. Mulch deliberately slows evaporation. A mulched garden bed after rain stays moist for days. The engine’s residual wetness model (which only activates for absorbent surfaces above 0.25 inches of rain) extends this further, keeping the score in “skip watering” territory well after a good rain.

Fresh seed has the highest effective damage sensitivity in the system: base 0.8 plus an establishment boost of 0.5, capped at 1.0. The engine is maximally protective of newly seeded areas, pushing any borderline verdict toward “water.”

Compost is the most forgiving surface: 1.2x drying multiplier and only 0.3 damage sensitivity. Compost generates internal heat from decomposition, which drives some of its own drying. And it’s hard to damage, overwatering a compost pile isn’t really a concern. The engine mostly stays out of the way for compost, skewing toward “skip” unless conditions are genuinely dry.

The Insight That Made It Work

The hardest part of building Yardwise wasn’t the code, it was convincing myself that the inversion was valid. Every instinct I’d built while developing Ridewise and Fieldwise said “wet = bad.” Retraining my thinking to “wet = good (for gardening)” took effort.

What made it click was realizing that the engine isn’t really about wet or dry. It’s about moisture state relative to the ideal for a given surface and activity. For a trail, the ideal is dry. For a garden bed, the ideal is moist (not soaked!). The engine measures distance from ideal in both directions.

Once I saw it that way, the inversion was mechanical. Same measurements, same model, same pipeline. Just a different definition of “good.”

Next in the Series

The final article covers the verdict UX, why three states beat a percentage, how the engine communicates uncertainty through confidence levels and contributing factors, and the role of the recovery outlook in managing expectations.

Yardwise is available for iOS from Stalefish Labs. Same engine as Ridewise and Fieldwise, different question.

Edge Cases That Break Your Weather Model

Michael Morrison — Mon, 23 Mar 2026 00:00:00 -0700

This is a continuation of a deep-dive into the weather engine that drives our Groundwise apps. Last we looked into the core drying model, which handles most days well. Sun, wind, time, surface type — combine them sensibly and you get a reasonable verdict most of the time.

Then winter arrives and everything breaks. Interestingly, the engine was developed during the epic ice storm of 2026 that absolutely decimated parts of the southeastern U.S., including Nashville, TN where we’re based. So I got to experience first-hand a very real edge case as I was building the engine, and literally each day presented new challenges to clarify for example how long it actually takes a trail to recover from a prolonged frozen period.

This article covers the edge cases that forced the most complex logic in the Groundwise engine, the scenarios where the simple model produces confidently wrong answers.

Freeze/Thaw: 360 Lines of Humility

The frozen conditions check is the single largest block of code in the engine. It runs first, before any moisture modeling, because frozen ground is a fundamentally different hazard than wet ground.

The naive approach would be simple: if the temperature is below 32°F, say No. But that misses almost everything that matters.

Hard Surfaces vs. Ground: Different Failure Modes

A frozen concrete skatepark and a frozen dirt trail are dangerous for completely different reasons, and they recover at completely different speeds.

Concrete and asphalt develop ice when moisture freezes on the surface. It’s a thin layer — dangerous because it’s invisible, but it clears relatively quickly once temperatures rise. At 55°F, a frozen skatepark is typically safe within 6 hours. At 50°F, give it 12. At 45°F, 24 hours, or just wait until 3 days after the last rain when there’s simply no moisture left to freeze.

Dirt and natural grass hold moisture internally. When they freeze, the ice is in the ground, not just on top of it. Thawing releases that moisture all at once, creating a slurry that’s worse than the original wet conditions. A ground trail at 45°F needs 72 hours to fully recover from a freeze — not because ice persists that long, but because the thaw creates its own wetness event. It’s worth noting that one thing the engine does not attempt to factor in is the counterintuitive scenario where frozen mountain bike trails are sometimes more rideable when fully frozen due to the combo of frost heave breaking up the surface tread and then a deep freeze solidifying that oatmeal-like top layer into a grippy crunch. If you bundle up, some of the best winter riding here is when a trail fully heaves and freezes, but that seemed like a special enough case to not factor in (at least not yet!), especially when you factor in ride comfort.

The engine models the concrete/asphalt vs. dirt/grass freeze issue with separate escape conditions for draining vs. absorbent surfaces:

Temperature	Hard Surface Recovery	Ground Recovery
≥ 55°F	6 hours	24 hours
≥ 50°F	12 hours	48 hours
≥ 45°F	24 hours (or 3+ days since rain)	72 hours
< 45°F	Still frozen	Still frozen

The Near-Freezing Zone

32°F isn’t a magic line. Ice can persist on surfaces at 34°F, especially in shade. And moisture can pose a freeze risk at 38°F if temperatures are dropping. Throw in wind and it’s pretty evident that a simple 32°F freeze check isn’t sufficient.

The engine treats 32-38°F as a caution zone. If there’s been recent precipitation (last 24 hours) and the temperature is in this range, the verdict is No with medium confidence. Not because ice is definitely present, but because the risk isn’t worth it.

Overnight Freeze, Currently Above Freezing

This is the most common winter scenario and the hardest to get right, especially in a moderate climate like the southeast where it can freeze overnight and then rise to sunny and 50s during the day. So an overnight freeze that changes to 52°F mid-day…is the trail rideable?

It depends on:

How long it’s been above freezing — just crossed 32°F an hour ago? Still frozen. Been above freezing since 9am and it’s now 2pm? Probably thawed.
What surface you’re on — concrete sheds faster than dirt.
Whether there’s recent precipitation — dry freeze is different from wet freeze.
Humidity — above 70% humidity with a recent overnight freeze means possible frost even on surfaces that look dry.

The engine tracks hoursBelowFreezing and hoursSinceThawBegan to model this progression. A surface that was frozen for 48 hours takes longer to fully thaw than one that dipped below freezing for 4 hours overnight.

Extended Freeze With No Recent Rain

It gets even trickier when you remove precipitation for a while. Here’s a counterintuitive case: it’s been below freezing for three days, but it hasn’t rained or snowed in a week. Is it safe?

For hard surfaces: probably yes. No moisture means nothing to freeze. The engine still checks humidity (frost can form from humid air alone), but without recent precipitation, hard surfaces are likely clear.

For ground surfaces: still no. Even without recent rain, ground retains moisture from weeks of accumulated precipitation. A multi-day freeze locks that moisture in. When thaw comes, it releases.

Snow Melt: A Bell Curve, Not a Line

Snow melt seems simple — snow melts, things get wet, then they dry. But the wetness injection from melting snow follows a curve that’s nothing like the linear decay used for rain timing.

The engine models thaw wetness on a bell curve based on melt progress:

Melt Progress	Wetness Factor	Why
< 5%	0.7 → 1.0	Starting to melt, moisture building
5-40%	1.0	Peak wetness, active melt, ground saturated
40-70%	1.0 → 0.4	Most snow gone, drainage beginning
70%+	0.4 → 0.2	Residual moisture, mostly clear

Melt progress is estimated from hours since thaw began, with the assumption that most accumulations take about 48 hours to fully melt. Temperature above freezing drives the rate, warmer means faster.

The peak wetness window (5-40% melted) is deliberately wide. During active melt, the ground is receiving a continuous supply of water. Unlike rain, which dumps water and stops, snow melt is a slow, sustained event that can keep surfaces saturated for hours.

Snow accumulation matters too. Did you know that on average, 10 inches of snow is equivalent to 1 inch of liquid rain (a 10:1 ratio). However, this ratio varies significantly based on temperature, ranging from 5 inches (wet snow) to over 20 inches (dry, powdery snow) of snow for every 1 inch of liquid. But what we really care about is how much snow results in complete saturation. Here’s how the engine scales the initial wetness injection for snow:

snowFactor = clamp(0.5 + snowAccumulation / 4.0, 0, 1)

Half an inch gives a snowFactor of 0.625. Four inches saturates at 1.0. This prevents a light dusting from being treated the same as a significant snowfall.

When There’s No Tracked Snow

Sometimes the engine knows there was a freeze/thaw cycle but doesn’t have explicit snow accumulation data. In that case, it falls back to estimating initial moisture from freeze severity:

initialMoisture = 0.3 + 0.3 × freezeSeverity

Where freeze severity scales from 0.3 (24 hours below freezing) to 0.6 (4+ days below freezing). Longer freezes lock more ground moisture, producing more wetness when thaw arrives.

The decay uses a half-life model, a baseline of 48 hours, stretched dramatically when overnight temperatures keep dropping below freezing. A thaw that refreezes each night can keep surfaces problematic for over a week, because each night arrests the drying process and each morning restarts the moisture release.

Precipitation Intensity: Same Amount, Different Impact

The drying model article covered the rain pattern multiplier (0.7x for light, 1.1x for steady, 1.5x for downpour), but intensity creates edge cases beyond just the multiplier.

A quarter inch of light rain over four hours soaks into absorbent surfaces gradually. The ground absorbs it progressively, and drainage keeps up. Surface water is minimal. This is the kind of rain you hear gardeners, landscapers, and farmers wishing for as it’s the best watering rain for plants, slow and steady.

A quarter inch dumped in 20 minutes, on the other hand, overwhelms drainage. Water pools on the surface, runs off trails causing erosion, and saturates the top layer before it can percolate down. The surface is wetter even though the total precipitation is identical.

The 1.5x downpour multiplier captures this, but it’s an approximation. In reality, the impact depends heavily on the surface’s infiltration rate, slope, and drainage design — none of which the engine models directly. And it doesn’t try.

This is one of the spots where the engine’s approximation is “good enough for most cases” rather than trying to be physically accurate to the extreme. A purpose-built trail with water bars and crowned surfaces handles a downpour better than a flat trail in a natural depression. The engine treats both as dirt with a 1.0x drying multiplier, which is imprecise but still more useful than ignoring intensity entirely. This is also worth flagging where often a Maybe verdict is truly the best answer because it tells you conditions are borderline, and your own local knowledge may tip the final ride decision. Yes, the app is attempting to assist in the human intuition of weather conditions, but not replace it entirely.

Cold-Weather Dormancy: Protecting Plants From Themselves

This edge case is Yardwise-specific, but it’s one of my favorites because it’s a case where the “right” answer is counterintuitive.

When temperatures drop below 55°F, most plants enter dormancy. Their water uptake drops dramatically. Watering dormant plants typically doesn’t help them, it can all too easily create conditions for root rot and fungal disease. In this scenario the engine needs to suppress watering recommendations even when the soil looks dry.

The dormancy calculation uses a non-linear curve:

coldFactor = pow((55 - temperature) / 23, 0.6)

Why pow(x, 0.6) instead of linear? Because the suppression should be strong even at moderate cold. At 45°F (10 degrees below the 55°F threshold), a linear model gives a cold factor of 0.43. The power curve gives 0.56, which is meaningfully stronger. The difference matters because 45°F is genuinely cold enough to suppress plant activity, and the engine should reflect that.

The dormancy score gets amplified by:

Freeze history — if it’s been below 32°F for 24+ hours recently, plants are deeply dormant. Add 0.25 × coldFactor.
Recent cold-weather watering — if the user watered during cold weather, that water persists much longer because evapotranspiration is minimal. The residual window extends from 48 hours to up to 96 hours. And yes, evapotranspiration is a real word…I couldn’t resist using it.

But there’s a warm-day dampener too. If the daytime high reaches 65°F even though it’s cold right now, the suppression eases. This handles the classic spring pattern: cold mornings, warm afternoons. Plants are still somewhat active on those warm afternoon hours, and a warm day drives real evaporation.

warmDampening = clamp((warmerTemp - 65) / 30, 0, 0.5)
dormancyMoisture *= (1.0 - warmDampening)

At 80°F daytime highs, the dampening cuts dormancy suppression in half. At 95°F, it’s fully halved. The cold mornings still matter, but the warm afternoons are doing real drying work.

Low Evaporative Demand: When Dry Isn’t Thirsty

Another Yardwise-specific edge case: on overcast, humid days with moderate temperatures, the soil might technically be “dry” by the engine’s moisture model, but the plants aren’t actually losing much water because evaporative demand is low.

Cloudy skies reduce solar radiation. High humidity reduces the vapor pressure gradient that drives transpiration. If both conditions are present and the temperature is under 85°F, the engine injects a small wetness boost (up to 0.25) to push borderline “water today” verdicts toward “check soil” or “skip.”

cloudFactor = clamp((cloudCover - 0.3) / 0.7, 0, 1)
humidityFactor = clamp((humidity - 0.4) / 0.5, 0, 1)
demandReduction = cloudFactor × 0.55 + humidityFactor × 0.45
boost = demandReduction × 0.25

The guard at 85°F is important. Hot weather drives real water demand regardless of clouds or humidity. Above that threshold, evaporative demand is high enough that the boost doesn’t apply.

This is a small adjustment, 0.25 at maximum, but it prevents the engine from recommending watering on days when the lawn genuinely doesn’t need it. Overwatering is a real problem, especially for casual gardeners who might not realize that a cool, overcast day means their yard is fine.

The Meta-Lesson

Every one of these edge cases started as a wrong verdict. A friend texted me “your app said Yes but the trail was iced over.” A beta tester reported “it’s telling me to water but it’s 40 degrees.” More personally, I’m literally looking at my skateboard ramp covered in ice and the app telling me it’s shred-ready. Nope.

The temptation each time was to add a quick patch, an if statement for the specific scenario. What I tried to do instead was understand why the model was wrong and fix the underlying assumption. Usually the answer was: the model was treating something as a smooth continuum when reality has phase transitions and state changes.

Water doesn’t gradually become less liquid as it gets colder. It freezes. Plants don’t linearly reduce water uptake as temperature drops. They go dormant. Snow doesn’t dry like rain. It melts.

The edge cases are where the domain expertise lives. The drying model is arithmetic. The freeze/thaw logic is hard-won knowledge about how the physical world actually works.

Next in the Series

The next article covers the Yardwise inversion, how the engine flips from “is it too wet?” to “is it too dry?” and the additional features (manual watering tracking, establishment sensitivity) that make gardening a distinct problem from riding and field sports.

The Groundwise engine powers Ridewise, Fieldwise, and Yardwise — all available for iOS from Stalefish Labs.

One Engine, Three Apps: Sharing a Swift Decision Engine Across Products

Michael Morrison — Fri, 20 Mar 2026 00:00:00 -0700

In the previous articles I’ve covered what the Groundwise engine does and how the drying model works. This article is about the architectural decision that turned one app into three: sharing a single decision engine across Ridewise (trail conditions), Fieldwise (sports field conditions), and Yardwise (watering guidance).

The pitch sounds clean: “one engine, three apps.” The reality required some specific design choices to keep it from becoming a tangled mess of conditionals.

The Shape of the Problem

The initial problem was how to apply human intuition to map recent/current weather conditions onto different kinds of surfaces to assess “rideability,” the application being that I wanted a simple verdict on if a mountain bike trail or skateboard ramp was sufficiently dry to session. That’s it, weather inputs in and surface type in, rideability verdict out. And it worked, the app Ridewise solves the problem, and in building it I created a slick little software engine. The thing is, once you’ve built an engine, you start to think about other things it might solve. In this case I realized the Groundwise engine is really answering a question more general than mountain biking or skateboarding, it’s answering the fundamental question: what’s the moisture situation at this spot?

So the idea of three different apps started to coalesce, and their distinguishing characteristics began to emerge:

Cares about different surfaces (skateparks vs. soccer fields vs. herb gardens)
Has different thresholds for what counts as “too wet” or “too dry”
Interprets the engine verdict differently (wet is bad for riders, good for gardeners)
Needs app-specific logic (gardeners track manual watering, riders don’t)
Uses different language in the rationale (“trail might be muddy” vs. “field may hold water” vs. “soil has enough moisture”)

The question was whether to fork the engine into three copies, or keep one engine and parameterize the differences. I went with parameterization, and the key that made it work was keeping the customization surface small. As you’ll see, this was a key design decision early that paid off big later.

EngineMode: Flipping the Perspective

One of the most key types in the Groundwise engine is what allows it to pivot between caring about dryness or caring about wetness:

enum EngineMode {
 case wetnessConcern // Ridewise, Fieldwise
 case drynessConcern // Yardwise
}

The engine always calculates a wetness score from 0 (bone dry) to 1 (saturated). EngineMode controls what that score means:

Wetness concern: Low score = Yes (go ride), high score = No (too wet)
Dryness concern: Low score = Yes (water your plants), high score = No (skip watering)

The verdict enum is the same in both modes (Yes, Maybe, No) but the interpretation inverts. This is a deliberate choice. The consuming app doesn’t need to know which mode produced the verdict. It just renders appropriate app-specific colors/symbols for Yes, Maybe, and No.

SiteType: A Unified Wrapper

Each app has its own domain vocabulary. Ridewise has “spots” (trails, skateparks), Fieldwise has “fields” (baseball diamonds, tennis courts), Yardwise has “areas” (lawns, raised beds). Rather than making the engine accept three different input types, they’re wrapped in a single enum:

enum SiteType {
 case spot(SpotType) // Ridewise: trail, skatepark, bikeJumps, pumpTrack...
 case field(FieldType) // Fieldwise: baseball, soccer, tennis, rugby...
 case area(AreaType) // Yardwise: lawn, raisedBed, container, compost...
}

The key thing we’re trying to arrive at for wetness/dryness purposes is a surface type. Each case in this enum maps to a SurfaceType, the thing the engine actually cares about. A SpotType.skatepark maps to SurfaceType.concrete. A FieldType.baseball maps to SurfaceType.naturalGrass. A AreaType.container maps to SurfaceType.pottingMix.

The engine never branches on SpotType or FieldType directly. It resolves the surface type up front, then works exclusively with surface properties. This is what keeps the core logic free of app-specific conditionals, and ultimately what enables engine reuse across apps with different concerns.

Surface Types: The Parameterization Layer

The apps currently have seventeen surface types to encode the physical properties that actually matter for moisture modeling:

// Each surface type defines:
var dryingMultiplier: Double // 0.7 (clay) to 2.8 (metal)
var damageSensitivity: Double // 0.0 to 1.0
var isDrainingSurface: Bool // sheds water vs. absorbs
var isAbsorbentSurface: Bool // holds water in material
var safetySensitivity: Double // slip risk when wet
var qualitySensitivity: Double // quality degradation when wet

The engine uses these properties, never the surface type identity, to modulate its calculations. Drying multiplier scales how fast moisture clears. Damage sensitivity controls the sensitivity veto (should the engine push borderline verdicts toward protection?). Draining vs. absorbent determines whether residual wetness applies.

This means adding a new surface type is a data change, not a logic change. If someone wanted to add “packed gravel” for Ridewise, they’d define its properties and it would flow through the existing pipeline.

Also notice a few perhaps surprising things that entered the data model: safety and quality sensititivies. When you think about it, rideability isn’t just about “too muddy” or “has puddles,” there’s also a safety concern and a quality of ride concern. Skateparks are notably impossible to ride with any standing moisture, while mountain bike trails have a fairly wide range of acceptance that sometimes comes down to local rules (is it open?) and personal tolerance (how much mud is just annoying?). So the wet skatepark scenario is truly a safety risk, while the mountain bike scenario is more about am I damaging the trail and am I open to a mud ride.

As an aside, it’s worth noting that I ride a local private mountain bike trail that gets so little traffic that mud isn’t a damage concern at all. We tend to invert the normal ride season and ride that trail specifically in less than ideal conditions, so it provided a bit of a logic stress test for the app. Often for this particular trail I’ll take a Maybe verdict as a green light given its unique properties.

Threshold Calibration Per Mode

When it comes to actually rendering a verdict, the verdict thresholds differ between wetness concern and dryness concern:

	Yes	Maybe	No
Wetness concern	< 0.30	0.30 – 0.60	≥ 0.60
Dryness concern	< 0.15	0.15 – 0.45	≥ 0.45

Yardwise thresholds are shifted lower because the consequences are asymmetric. For a rider, going out on a borderline trail risks damaging the trail surface. For a gardener, missing one watering day rarely kills plants. The engine leans toward “maybe water” rather than “definitely water” because overwatering is its own problem.

The sensitivity veto also inverts:

Wetness concern: If a sensitive surface (like natural grass with 0.9 damage sensitivity) gets a Maybe verdict with wetness above 0.4, it’s pushed to No. Protect the surface.
Dryness concern: If a sensitive surface (like fresh seed with 0.95 effective sensitivity) gets a Maybe verdict with wetness below 0.3, it’s pushed to Yes. Water the fragile plants.

Same mechanism, opposite direction. And yet one line of mode-aware logic handles both cases.

App-Specific Features Without Conditionals

It’s worth pointing out that Yardwise has two features the other apps don’t: manual watering tracking and cold-weather dormancy suppression. Rather than branching on app identity, these are driven by the input data:

Manual watering is an array of WateringEvent values on the input struct. Ridewise and Fieldwise pass an empty array. The engine’s watering contribution calculation gracefully returns zero when there are no events, meaning no conditional needed.

Establishment sensitivity is a Double on the input (0.0 by default). Yardwise sets it to 0.5 for newly seeded areas and 0.2 for newly planted ones, boosting the surface’s damage sensitivity. Ridewise and Fieldwise leave it at 0.0. Again, no branching for the apps that don’t care, the math just works with a zero boost.

Cold-weather dormancy activates when the temperature drops below 55°F. It injects additional “wetness” into the Yardwise calculation, suppressing watering recommendations when plants are dormant. This is gated on EngineMode.drynessConcern because the concept doesn’t make sense for riders given that cold weather doesn’t make trails less wet.

This is the one place where I accepted a mode check in the engine, and it was a pragmatic call. Dormancy is fundamentally a gardening concept. Trying to abstract it into a mode-agnostic mechanism would have added complexity without clarity.

The Input Struct

On to the engine inputs, where everything flows through a single input type:

struct GroundwiseInputs {
 // Weather (required)
 let rain24hInches: Double
 let rain48hInches: Double
 let rain72hInches: Double
 let minutesSinceRainEnded: Int?
 let rainPattern: RainPattern
 let temperatureF: Double
 let sustainedWindMph: Double
 let cloudCoverFraction: Double

 // Weather (optional, improves accuracy)
 let gustsMph: Double?
 let dewPointF: Double?
 let relativeHumidity: Double?
 let overnightLowF: Double?
 let daysSinceLastRain: Int?

 // Freeze/thaw context
 let frozenSnowAccumulationInches: Double?
 let hoursSinceThawBegan: Int?
 let hoursBelowFreezing: Int?

 // Site context
 let siteType: SiteType
 let surfaceType: SurfaceType
 let exposureLevel: ExposureLevel

 // Mode and calibration
 let engineMode: EngineMode
 let establishmentSensitivityBoost: Double
 let isCurrentlyPrecipitating: Bool
 let hasThunderstorm: Bool

 // Yardwise-specific
 let manualWateringEvents: [WateringEvent]
}

Each app constructs this from its own domain model. Ridewise fills in the weather data and its spot’s surface type. Yardwise adds watering events and an establishment boost. The engine doesn’t know or care which app called it.

The Output: Same Structure, Different Meaning

The engine evaluates the inputs as a black box and generates an assessment in this form:

struct GroundwiseAssessment {
 let verdict: Verdict // .yes / .maybe / .no
 let confidence: Confidence // .low / .medium / .high
 let rationale: GroundwiseRationale
 let riskSurfaceDamage: RiskLevel
 let riskActivitySafety: RiskLevel
 let riskActivityQuality: RiskLevel
 let recoveryOutlook: RecoveryOutlook?
}

The consuming app interprets the verdict through its own lens. Ridewise renders Yes as “Dry — go ride.” Yardwise renders Yes as “Water today.” The engine provides the structured rationale (headline, decisive factor, contributing details), and each app’s UI formats it with domain-appropriate language.

Risk levels work the same way. Surface damage risk on a trail means erosion and ruts. Surface damage risk on a newly seeded lawn means killing the seed. Same risk level, different consequence, the app handles the framing.

What I’d Do Differently

The engine’s one-file structure (2,193 lines in GroundwiseEngine.swift) works but isn’t ideal. The frozen conditions check alone is 360 lines. If I were starting over, I’d break the pipeline into discrete stages: FreezeAssessor, PrecipitationAssessor, and DryingCalculator, VerdictResolver. And I’d make each of these a separate type with a clear protocol.

I’d also make the threshold constants configurable per surface type rather than per engine mode. Right now, all wetness-concern surfaces share the same 0.3/0.6 thresholds. But a clay tennis court arguably deserves tighter thresholds than an artificial turf field. The sensitivity veto partially handles this, but explicit per-surface thresholds would be cleaner.

That said, the current design has shipped and works. Premature refactoring is its own trap.

The Tradeoff

Sharing an engine across three apps means accepting constraints:

You can’t special-case easily. If Ridewise needs a trail-specific behavior that doesn’t generalize, you either make it general enough for the shared engine or handle it in the app layer.
Testing surface area grows. Every change to the engine needs to be validated against all three app contexts. A threshold tweak that improves Ridewise verdicts might break Yardwise scenarios.
Abstraction has a ceiling. Cold-weather dormancy proved that not everything generalizes cleanly. Knowing when to accept a mode check instead of over-abstracting is a judgment call.

The upside: every improvement to the drying model benefits all three apps simultaneously. When I improved the residual wetness calculation for trails, clay tennis courts and garden beds got more accurate too because they share the same underlying property (absorbent surfaces retain moisture).

For an indy developer maintaining three related apps, that leverage is worth the constraints.

Next in the Series

The next article digs into the edge cases that make weather modeling humbling: freeze/thaw cycles, precipitation intensity, snow melt, and cold-weather plant dormancy. Each one is a lesson in how simple models break when they meet the real world.

Ridewise, Fieldwise, and Yardwise are all available for iOS from Stalefish Labs. Built by one developer, powered by one engine.

Turning Raw Weather Into a Drying Model

Michael Morrison — Tue, 17 Mar 2026 00:00:00 -0700

In the first article about my foray into using weather data to assess surface conditions for riding activities, I introduced the Groundwise engine, a software decision system that turns weather data into a yes/maybe/no verdict for outdoor conditions. This article goes deeper into the core moisture model: how the engine takes raw weather observations and calculates a wetness score that drives the verdict. The hope is to show how a simple question such as “can I ride my mountain bike today?” spiraled into a fairly complex yet intriguing design challenge. Totally fair if you aren’t entranced by weather math, I get it, but I feel like there’s some value in pulling back the curtain to reveal how much goes into solving a seemingly simple problem.

The Groundwise model is relatively restrainted in scope, it isn’t trying to simulate soil physics. It’s trying to approximate what an experienced local would know instinctively — “it rained pretty hard yesterday, but it’s been warm and windy all morning, so the trails are probably fine.” The goal is to encode that intuition into something repeatable and surface-aware.

Weighted Precipitation: Not All Rain Is Equal

The engine tracks precipitation across three time windows: the last 24 hours, 24-48 hours ago, and 48-72 hours ago. But it doesn’t treat them equally. Here’s how they are weighted differently by the weather precipitation equation:

weatherPrecip = rain24h × 0.7 + (rain48h - rain24h) × 0.2 + (rain72h - rain48h) × 0.1

Recent rain dominates. An inch in the last 24 hours contributes seven times more to the score than an inch from two days ago. This matches real-world observation, where rain from three days ago has had significant time to drain and evaporate, while yesterday’s rain is still actively affecting conditions.

The subtraction matters too. rain48h is a cumulative total (it includes the last 24 hours), so the formula isolates each window’s unique contribution. A half an inch total over 48 hours where all of it fell in the last 24 tells a very different story than half an inch spread evenly.

Rain Score Normalization

A recent rain results in a raw precipitation value that gets normalized to a 0-1 scale, so effectively a percentage:

rainScore = min(1.0, totalPrecip / 0.75)

Three-quarters of an inch saturates the score (maximum value of 1, or 100%). Beyond that, more rain doesn’t make things more wet from the engine’s perspective — you’re already at maximum precipitation/saturation, which matches reality in that a trail, yard, or any other outdoor surface has a limit to how wet it can get. This prevents a 3-inch deluge from producing a wildly different result than a 1-inch soaking. Both are “very wet” — the distinction that matters is how long ago it happened and how fast things are drying.

Why Intensity Matters

The engine tracks rain pattern: light, steady, or downpour. It then applies a multiplier to the base wetness given one of those patterns:

Pattern	Multiplier	Why
Light	0.7x	Gentle rain soaks in gradually, less runoff, less surface pooling
Steady	1.1x	Sustained saturation, ground can’t keep up
Downpour	1.5x	Overwhelms drainage, causes pooling and surface flooding

A quarter inch of light rain over several hours is genuinely different from a quarter inch dumped in 20 minutes. The light rain absorbs more evenly. The downpour creates surface water, overwhelms drainage on absorbent surfaces, and can cause erosion on trails.

Drying Strength: The Recovery Side

Wetness is only half the picture. The other half is how aggressively conditions are drying things out. The engine calculates a composite drying strength from four weather factors:

drying = (tempFactor × 0.30) + (windFactor × 0.30) + (humidityFactor × 0.25) + (skyFactor × 0.15)

Temperature (30% weight): Warmer air holds more moisture and drives evaporation. The factor scales linearly from 0 at 50°F to 1.0 at 90°F. Below 50°F, evaporation slows dramatically. Above 90°F, you’re drying as fast as conditions allow.

tempFactor = clamp((tempF - 50) / 40, 0, 1)

Wind (30% weight): Moving air carries moisture away from surfaces. Scales linearly up to 20 mph, where the effect plateaus - going from 20 to 40 mph doesn’t double the drying rate.

windFactor = clamp(sustainedWindMph / 20, 0, 1)

Humidity (25% weight): Dry air absorbs moisture more readily. This is the inverse, where low humidity means strong drying.

humidityFactor = clamp(1.0 - effectiveHumidity, 0, 1)

When the weather API provides a dew point instead of relative humidity, the engine converts it using the Magnus formula. Dew point is actually the more reliable measurement — relative humidity fluctuates throughout the day even when actual moisture content stays constant.

Sky cover (15% weight): Clear skies mean solar radiation hitting surfaces directly, which drives evaporation. Clouds block that. This gets the lowest weight because its effect is real but smaller than the others.

skyFactor = clamp(1.0 - cloudCover, 0, 1)

Exposure Matters

All of this gets modified by where the surface actually sits. A trail under heavy tree canopy dries differently than an open field fully exposed to sunlight:

Exposure	Rain Multiplier	Drying Multiplier
Exposed	1.0x	1.0x
Shaded	0.7x	0.6x
Covered	0.0x	0.8x

Shaded spots get less rain (canopy intercepts 30%) but also dry 40% slower (less sun, less wind). Covered spots (under a roof or overhang) get no rain at all but still have air circulation for moderate drying.

This creates an interesting dynamic: a shaded trail might actually be drier than an exposed one after light rain (less water reached it) but wetter after heavy rain (the rain that got through takes longer to leave).

Drying Classification

The composite score maps to three tiers, each returning a fixed drying effectiveness value:

Score Range	Classification	Effectiveness
≥ 0.7	Strong	0.8
0.4 – 0.7	Moderate	0.5
< 0.4	Weak	0.2

I deliberately chose discrete tiers over a continuous curve. The difference between a 0.41 and a 0.69 drying score isn’t meaningful in practice — both represent “conditions are helping somewhat.” The tiers prevent false precision while still capturing the real distinction between “sunny and breezy” (strong), “overcast and mild” (moderate), and “cold, humid, and still” (weak).

Combining It All: The Wetness Score

I warned you this problem has more nuance that it would seem. But hang in there, we’re getting closer to arriving at some meaningful mathematical conclusions. For example, the wetness score blends precipitation and drying into a single 0-1 value:

baseWetness = rainScore × 0.5 + (rainScore × timingScore) × 0.6

This formula does something subtle. The first term (rainScore × 0.5) ensures that heavy rain always contributes some wetness regardless of timing. The second term (rainScore × timingScore) captures the interaction — recent heavy rain is much worse than old heavy rain. The timing score decays linearly from 1.0 (just stopped) to 0.0 (24+ hours ago).

After the base calculation, the rain pattern multiplier is applied (0.7x for light, 1.1x for steady, 1.5x for downpour), then drying reduces it:

dryingEffect = dryingScore × 0.3 × dryingEffectiveness
wetness = baseWetness × (1.0 - dryingEffect)

The dryingEffectiveness factor prevents drying from being too aggressive when rain just ended. If rain stopped 30 minutes ago, even strong drying conditions haven’t had time to do much yet. The factor scales up as time passes, so drying’s impact grows the longer it’s been since rain.

A Worked Example

To put all these equations into perspective, let’s trace through a real scenario to arrive at a Groundwise verdict: 0.4 inches of steady rain ended 8 hours ago. It’s 72°F, 12 mph wind, 45% humidity, 20% cloud cover. Exposed dirt trail.

Rain score:

weatherPrecip = 0.4 × 0.7 = 0.28 (all in last 24h)
rainScore = min(1.0, 0.28 / 0.75) = 0.37

Timing score:

hours = 480 min / 60 = 8
timingScore = max(0, 1.0 - 8/24) = 0.67

Drying strength:

temp = (72-50)/40 × 0.30 = 0.165
wind = 12/20 × 0.30 = 0.18
humidity = 0.55 × 0.25 = 0.1375
sky = 0.80 × 0.15 = 0.12
total = 0.60 → Moderate (effectiveness = 0.5)

Wetness:

base = 0.37 × 0.5 + (0.37 × 0.67) × 0.6 = 0.185 + 0.149 = 0.334
× steady pattern (1.1) = 0.367
dryingEffectiveness = max(0.2, 1.0 - 0.67 × 0.5) = 0.665
dryingEffect = 0.5 × 0.3 × 0.665 = 0.10
wetness = 0.367 × (1.0 - 0.10) = 0.33

Verdict: Maybe (0.33 is just above the 0.3 threshold). The trail is borderline — rideable but still damp. On a dirt trail (damage sensitivity 0.5), the sensitivity veto wouldn’t trigger. A reasonable call either way, and the engine goes with Maybe, giving the rider the opportunity to then weigh locale-specific details such as trail sensitivity to damage.

Now change one variable — make it 85°F instead of 72°F:

temp = (85-50)/40 × 0.30 = 0.2625
total drying = 0.70 → Strong (effectiveness = 0.8)
dryingEffect = 0.8 × 0.3 × 0.665 = 0.16
wetness = 0.367 × (1.0 - 0.16) = 0.308

Still Maybe, but barely. A bit more wind or another hour of drying and it flips to Yes. That matches intuition — a hot afternoon pulls moisture out fast.

Residual Wetness: The Ground Remembers

The timing-based model handles most scenarios well, but it has a blind spot: ground saturation after heavy rain on absorbent surfaces.

If it rained an inch on Monday and you’re checking the trail on Wednesday, the timing score says “it’s been 48 hours, moisture contribution is minimal.” But anyone who’s walked a clay trail two days after heavy rain knows that’s wrong. The ground is still holding water.

The engine adds a residual wetness component for absorbent surfaces (dirt, grass, clay, amended soil) when precipitation exceeded 0.25 inches:

volumeFactor = clamp((rain - 0.25) / 0.75, 0, 1)
decayFactor = based on hours since rain and drying strength
surfaceRetention = inverse of surface drying multiplier
dryingReduction = strength-based reduction
residualWetness = 0.55 × volumeFactor × decayFactor × surfaceRetention × (1.0 - dryingReduction)

The peak residual value of ~0.55 deliberately sits in the middle of the Maybe range. It’s not enough to trigger a hard No, but it keeps the engine from prematurely saying Yes on saturated ground.

Clay surfaces (drying multiplier 0.7x) retain the most residual moisture. Concrete and metal (2.0x+) don’t get residual wetness at all, they’re draining surfaces that hold little (concrete) to no (metal) water.

What This Model Doesn’t Do

A few things I intentionally left out:

Soil type modeling. Real evapotranspiration models account for soil composition, drainage rates, water table depth. The engine uses surface type as a proxy instead. A dirt trail in sandy Arizona soil dries differently than one in Georgia red clay, and the engine can’t distinguish them. The tradeoff is simplicity — asking users to classify their soil composition seemed like a bridge too far. If you disagree, let us know, but I decided to err on the side of simplicity at least in terms of user inputs.

Microclimate effects. Two spots a mile apart can have meaningfully different conditions. The engine uses a single weather observation for each saved location, which might come from a station several miles away. Elevation, valley effects, and urban heat islands aren’t modeled.

Drainage infrastructure. A well-designed trail with proper drainage handles rain better than a flat trail in a depression. An athletic field with subsurface drainage is ready for play sooner than one without. The engine doesn’t know about this. Surface type captures some of it (artificial turf implies drainage engineering), but it’s imperfect.

These are all real limitations, and I’d rather be transparent about them than pretend the model is more precise than it is. The engine targets “better than guessing” — not “better than walking over and checking yourself.”

Next in the Series

The next article covers how this engine is packaged as a shared Swift framework consumed by three different apps — each with its own surface library, threshold calibration, and verdict interpretation. Same core math, three different products. It’s a lesson in code reuse, and the benefits of solving a problem once in just a general enough way to apply that solution multiple times.

The drying model powers Ridewise, Fieldwise, and Yardwise — all available for iOS from Stalefish Labs.

The Pole Sitter Strategy: Fixing a Fantasy F1 Scoring Loophole

Michael Morrison — Fri, 13 Mar 2026 00:00:00 -0700

Before Open Wheelers was an app, it was a text thread. A group of friends, a shared note, picks submitted before qualifying. One of those friends figured out something the rest of us missed: you could win the whole league by making the same Podium pick every single week.

Her strategy was simple: wait for qualifying, pick whoever was in pole position, and move on to baking amazing cakes for F1 brunch. Seriously. No research, no gut feelings, no agonizing over race pace versus one-lap speed. Just, who’s P1 on the grid, and is this week feeling more strawberry or lemon? I won’t divulge any names, but hers rhymes with Sammy, although this year we just call her champ.

Because she won the league. And the rest of us were annoyed enough to wonder why.

The old scoring made it easy

Our original manual league used this scoring system:

Category	Points
Podium	5 for P1, 3 for P2, 1 for P3
DNF	3 for first retirement only
Fastest Lap	1 point

See the problem? The Podium category was worth up to 5 points while DNF maxed out at 3 and Fastest Lap was a throwaway single point. The game was structurally a Podium-picking contest with two minor side bets. If you could crack the Podium category, the other picks barely mattered.

And cracking the Podium category turns out to be remarkably easy when you just pick the pole sitter.

How often does pole become podium?

I looked at every F1 race from 2016 through 2024, the same decade of data used in the DNF analysis. Here’s how the pole sitter fared:

Season	Races	Pole wins	Pole P2	Pole P3	Pole on podium	Off podium
2016	21	13	3	1	17 (81%)	4
2017	20	11	4	1	16 (80%)	4
2018	21	10	3	2	15 (71%)	6
2019	21	8	4	2	14 (67%)	7
2020	17	10	3	1	14 (82%)	3
2021	22	11	3	2	16 (73%)	6
2022	22	9	4	2	15 (68%)	7
2023	22	14	3	2	19 (86%)	3
2024	24	11	5	2	18 (75%)	6

The pole sitter finishes on the podium roughly 75% of the time across the modern era. That’s not a strategy, that’s a cheat code.

The pole sitter under old scoring

Let’s see what “always pick the pole sitter” actually produced under the old 5-3-1 system. Take 2023, the best season for this strategy:

14 wins × 5 points = 70
3 runner-ups × 3 points = 9
2 third-place finishes × 1 point = 2
Season total: 81 points from Podium alone

Meanwhile, the maximum possible from the other two categories combined was about 66 points for DNF (3 × 22 races, if you nailed every single one) and 22 for Fastest Lap (1 × 22). Realistically, even a sharp player might score 25-30 across those categories, but in reality choosing first DNF turned out to be incredibly difficult (Fastest Lap wasn’t much better).

So our pole sitter friend was pulling in roughly 60-80 Podium points per season while everyone else scrambled to make up the gap with DNF and Fastest Lap picks that were worth a fraction as much. The scoring wasn’t balanced, it was broken. Our friend just noticed the breakage and exploited it while the rest of us picked (and lost!) with our hearts.

The fix: flatten the pyramid

When I built Open Wheelers as a proper app, I had a chance to redesign the scoring from scratch. The key change was simple: 3-2-1 across all three categories. I even named our underlying fantasy scoring engine Podium to highlight this design decision.

Category	Points
Podium	3 for P1, 2 for P2, 1 for P3
Overtaker	3 for most positions gained, 2 for 2nd, 1 for 3rd
DNF	3 for 1st retirement, 2 for 2nd, 1 for 3rd

Every category now has the same ceiling. No single pick dominates. Let’s rerun the pole sitter strategy under the new system.

The pole sitter under new scoring

Same 2023 season, same strategy, new math:

14 wins × 3 points = 42
3 runner-ups × 2 points = 6
2 third-place finishes × 1 point = 2
Season total: 50 points from Podium

Still solid, but now the Overtaker and DNF categories carry equal weight. A player who scores well across all three categories can absolutely overtake (pun intended) the pole-sitting, cake-baking rules anarchist.

Consider a well-rounded player who averages just 1.5 points per race across Overtaker and DNF, modest accuracy, not perfection. Over 22 races, that’s 33 points from those two categories alone. Add a reasonable Podium performance of, say, 35 points (less than the pole sitter, but making smarter individual picks), and you’re at 68 points total versus the pole sitter’s 50-plus-whatever-they-stumble-into on Overtaker and DNF.

The deeper fix: replacing Fastest Lap with Overtaker

The old system’s other problem was that two of the three categories, Podium and Fastest Lap, correlated heavily with the same thing: having the fastest car. The driver on pole was usually also the one most likely to set the fastest lap. If you picked the dominant driver for both, you were essentially making one pick and getting credit for two.

Overtaker breaks that correlation completely. The driver who gains the most positions is almost never the pole sitter — by definition, they started at the front with nowhere to climb. The Overtaker category rewards knowledge of the rest of the grid: who qualified poorly but has strong race pace, who’s taking engine penalties, which midfield team nailed their setup for the race even if qualifying didn’t go their way. It’s sort of the anti-qualifying pick, which makes it a fun bookend to the Podium pick, and also provides motivation to wade deeper into the grid for a pick.

This also means the pole sitter strategy now only helps you in one of three categories. The other two require completely different analysis. That’s a game with real strategic breadth.

Does the pole sitter strategy still work?

It’s still a good Podium pick, hitting the podium 75% of the time is nothing to sneeze at. But under balanced 3-2-1 scoring, it’s no longer a league-winning exploit. It’s a floor, not a ceiling.

The players who will win Open Wheelers leagues are the ones who can pick Podium finishers with similar accuracy to the pole sitter and identify the likely Overtaker and read the DNF tea leaves. That’s three distinct skills instead of one repeated shortcut.

Which is exactly what a fantasy game should reward: breadth of knowledge, not a single automatic insight applied 24 times.

Open Wheelers is a casual F1 and IndyCar fantasy game for friends, built by Stalefish Labs.

I Built a Weather Engine That Tells You When to Ride, Play, or Water

Michael Morrison — Thu, 12 Mar 2026 00:00:00 -0700

Every mountain biker knows the ritual. It rained last night. You check the radar, clear now. You check the trail association’s Facebook page, nobody’s posted. You text your riding buddy: “Think the trails are good?” They don’t know either. So you either stay home and miss a perfectly rideable day, or show up and chew through muddy trails that needed another six hours to dry.

I got tired of guessing so I built a weather decision engine that answers the question directly: is it too wet to ride?

Then I realized the same engine could answer two more questions: is this field playable? and does my garden need watering?

This is the story of the Groundwise engine, a single Swift package that powers three iOS apps by asking the same underlying question from different perspectives.

The Problem With “Did It Rain?”

Weather apps mostly tell you what will happen, and to a lesser degree they can tell you what happened. What they don’t tell you is what it means for the specific thing you want to do.

Half an inch of rain means completely different things depending on context:

On a concrete skatepark, it sheds in a couple hours. You’re probably fine by afternoon.
On a dirt trail, it might need 24 hours with good sun and wind. Or 48 hours or more if it’s overcast and cold.
On a clay tennis court, you might be waiting even longer, clay holds moisture and damages easily when wet.
In a container garden on a sunny patio, that half inch drained through the potting mix hours ago and your herbs might need water again tomorrow.

The answer isn’t just “how much rain,” it’s how much rain, on what surface, how long ago, and what the drying conditions have been since.

From Weather Data to a Verdict

So I built a weather analysis engine that takes in a handful of weather observations and produces a single categorical verdict regarding an action on a specific surface: Yes, Maybe, or No.

The inputs are straightforward, stuff you’d get from any weather API:

Precipitation totals (last 24, 48, and 72 hours)
How long since rain ended
Whether it was light, steady, or a downpour
Current temperature, wind speed, humidity, and cloud cover
Whether it’s actively raining right now

Plus one critical piece of context: what surface are you asking about?

The engine defines 17 surface types across three categories. Each has a drying multiplier that controls how fast moisture clears, for example:

Surface	Drying Speed	Notes
Metal skateboard ramps	2.8x	Fastest, sheds water, heats up quickly
Artificial turf	2.5x	Engineered to drain
Asphalt	2.2x	Dark surface, absorbs heat
Concrete	2.0x	Drains well, slower to heat than asphalt
Potting mix	2.0x	Loose, fast-draining soil
Compost	1.2x	Active decomposition generates some heat
Dirt/ground	1.0x	Baseline, absorbs and holds water
Natural grass	1.0x	Root systems retain moisture
Amended soil (mulched)	0.7x	Mulch deliberately slows evaporation
Clay	0.7x	Dense, holds water, slow to release

That 4x difference between metal and clay isn’t just a number, it’s the difference between “rideable in an hour” and “unplayable until tomorrow.”

The Decision Pipeline

The engine runs checks in a specific order, with the most critical conditions evaluated first:

1. Is the ground frozen? If there’s an ice or snow hazard, the verdict is No regardless of moisture. This check alone is about 360 lines of code, freeze/thaw cycles are surprisingly complex. A concrete skatepark clears ice in 6 hours at 55°F, but a dirt trail might need 72 hours at 45°F to fully thaw and dry.

2. Is it actively raining? Straightforward gate. If precipitation is falling, the answer is No (or Maybe for very light drizzle on a fast-draining surface with strong drying conditions).

3. Calculate a wetness score. This is where the real modeling happens. The engine combines:

A rain score weighted toward recent precipitation (70% from last 24h, 20% from 24-48h, 10% from 48-72h)
A timing score that decays linearly over 24 hours since rain ended
A drying strength composite that factors in temperature, wind, humidity, and cloud cover
Residual wetness for absorbent surfaces, heavy rain on dirt or clay retains moisture well beyond what the timing score captures

4. Apply the verdict thresholds. A wetness score below 0.3 means Yes (dry enough). Between 0.3 and 0.6 means Maybe (borderline). Above 0.6 means No (too wet).

5. Sensitivity veto. High-sensitivity surfaces (like newly seeded lawns or natural grass athletic fields) get pushed from Maybe toward a more protective verdict. The engine would rather tell you to wait than let you damage a surface that’s expensive to repair.

One Engine, Two Perspectives

If you’re wondering how the above, which is described in terms of using a surface, could possibly apply to a container garden, it’s a fair question. And this is where the engine morphed into serving a series of apps instead of just one:

The engine calculates a wetness score. For riders and athletes, high wetness is bad, you want dry conditions. For gardeners, high wetness is good, it means you can skip watering.

Same math, opposite interpretation:

Wetness Score	Rider/Athlete View	Gardener View
Low (< 0.3)	Yes, go ride!	Yes, water today
Medium (0.3-0.6)	Maybe, check conditions	Maybe, check soil
High (> 0.6)	No, too wet	No, skip watering

The engine calls this EngineMode, either wetnessConcern or drynessConcern. A single enum that flips the entire interpretation layer while keeping the underlying moisture model identical.

Yardwise (the gardening app) uses slightly shifted thresholds, 0.15 and 0.45 instead of 0.3 and 0.6, because the stakes of getting it wrong are lower. Missing a watering day is a mild inconvenience. Riding a muddy trail damages the trail. Playing softball on a muddy clay infield isn’t great. You get the idea.

Why Not Just Show a Percentage?

Early versions of the apps showed a moisture percentage, and it wasn’t good. I didn’t know what to do with “the trail is at 47% moisture.” Is that rideable? It depends on the surface, on your own risk/comfort tolerance, on whether you care about trail damage, etc. A percentage pushes the decision back onto the user, which is exactly the problem the app was supposed to solve.

The solution was to simplify down to three states: Yes/Maybe/No, with an explanation of why. The Maybe state exists specifically for conditions where reasonable people would disagree. I have near me both public and private mountain bike trails, and the tolerance for mud varies widely based on level of traffic, so Maybe is when deferring to rider’s judgement is actually correct. The engine shows you the contributing factors (temperature is helping, but humidity is holding things back, for example) so you can make the final call.

Each verdict also carries a confidence level (Low, Medium, High). Confidence drops when timing data is missing, when rain has been patchy and unpredictable, or when the wetness score lands right on a threshold boundary.

What’s Coming in This Series

If you find talk of drying multipliers and residual wetness scores riveting, then hold on to your butts! This is merely the first article in a series about building the Groundwise engine. Coming up:

Turning Raw Weather Into a Drying Model - The math behind drying strength, residual wetness, and why rain intensity matters as much as total accumulation
One Engine, Three Apps - How to structure a Swift package that serves multiple products with different surface libraries and threshold calibrations
Edge Cases That Break Your Weather Model - Freeze/thaw cycles, cold-weather plant dormancy, the surprising complexity of “is snow melting?”, and dispatches from the great Nashville ice storm of 2026
Flipping the Question - How the Yardwise inversion works, including manual watering tracking and evaporative demand suppression
Building Confidence Into Uncertain Verdicts - Why three states beat a percentage, and how to communicate uncertainty without creating anxiety

The Apps

The Groundwise engine powers three apps, all available for iOS:

Ridewise, ride conditions for trails, skateparks, bike parks, and pump tracks
Fieldwise, field conditions for rec league sports on grass, turf, clay, and hard courts
Yardwise, watering guidance for casual gardeners with lawns, beds, and containers

All three are built by Stalefish Labs, a small indie studio focused on simple tools for getting outside and doing things together.

If you’ve built something that turns raw data into human decisions, I’d love to hear how you approached the threshold and confidence problem. Drop a comment or find us on Bluesky.

Building a Better Kicker: The Physics Behind the Jump Simulator

Michael Morrison — Tue, 10 Mar 2026 00:00:00 -0700

Anyone who has ever flown through the air on two wheels can appreciate this: a rider staring at a jump and its gap, trying to picture the arc. How fast do I need to go? Will I clear it? Will the landing feel smooth or like a punch to the spine? The mental math is unreliable, the necessary intuition only gained with loads of experience, and the consequences of getting it wrong range from cuts and bruises to an ER visit and a stint on injured reserve.

We built the Jump Simulator to replace that guesswork with real physics. It’s a free, browser-based tool that lets BMX, MTB, and MX riders design gap jumps, simulate trajectories, and see exactly where (and how hard!) they’ll land before moving a single shovel of dirt.

The Problem with Gap Jump Design

Gap jumps are deceptively simple: a takeoff ramp, empty air, and a landing ramp. Three elements. But each one hides a web of variables. The takeoff angle determines how much speed converts to height versus distance. The lip height sets the launch point above the gap floor, and with the landing height establish if you’re working with doubles, a step-up, or an often dreaded step-down. The gap distance is the void you need to clear. The landing angle and height offset determine whether your wheels kiss the slope gently or slam into flat ground.

Change any one variable and the entire trajectory shifts. A 5-degree steeper takeoff lip at the same speed can turn a clean landing into a 4-foot overshoot. A 2 mph drop in approach speed can leave you dangling over the gap’s leading edge leading to a monster case.

Experienced riders develop intuition for this, but intuition fails at the margins, and the margins are exactly where crashes happen.

Projectile Motion, With Drag

At its core, the simulator solves a projectile motion problem, but not the textbook version. Once a rider leaves the lip, two forces act on them: gravity pulling them down, and air drag slowing them through the arc.

The launch velocities are straightforward:

vx = speed × cos(angle)
vy = speed × sin(angle)

Where gravity g = 9.81 m/s² and angle is the takeoff lip angle. In a vacuum, that’s all you need, horizontal velocity stays constant, vertical velocity decays linearly. But at real-world speeds, air drag matters, especially for motorcycles carrying hundreds of pounds through the air at 40+ mph.

The drag force at any instant is:

F_drag = ½ × ρ × CdA × v²

Where ρ is air density (1.225 kg/m³), CdA is the rider+vehicle’s drag area, and v is the current speed. The deceleration is F_drag / mass, applied opposite to the velocity vector. Math nerdery aside, a heavier vehicle feels less deceleration from the same drag force. Or to put it even clearer, a lighter-weight BMX setup loses speed faster than a motorcycle at the same velocity.

Because drag depends on velocity, which changes continuously, there’s no clean closed-form solution. The simulator uses Euler numerical integration with a 0.0005-second timestep, updating position and velocity at each step. This produces a trajectory that’s subtly different from a pure parabola, the arc is slightly asymmetric, with the descent steeper than the ascent. That’s how real jumps work.

What all this stuff is working toward, and where the complexity lies, is detecting where on the landing ramp the rider actually touches down.

Landing Detection: Slope Geometry

The landing ramp isn’t a point, it’s a sloped surface with a defined start, angle, and length. The simulator steps through the trajectory in 0.001-second increments, checking at each step whether the rider’s position has crossed below the landing ramp’s surface.

The ramp surface is defined as a line from the gap’s far edge, angled downward at the landing angle. At each timestep, the simulator compares the rider’s y-position against the ramp’s y-value at that x-position. When the rider crosses below the surface, we interpolate to find the precise landing point.

This discrete stepping approach is more robust than solving the intersection analytically, because it handles edge cases gracefully, riders that land past the ramp, riders that never reach it, and riders that graze the lip on the way down. Sadly the simulator doesn’t account for deliberate stylish nose taps at the lip on landing, but that doesn’t mean you shouldn’t do them!

The Verdict System

So to rule a jump successful (safe!), landing on the ramp is necessary but not sufficient. A rider who lands on the ramp at a 45-degree descent angle when the ramp slopes at 25 degrees is going to be in for a rough time. The angle mismatch means the bike slams into the surface rather than matching it.

The simulator classifies every jump into one of five verdicts:

Verdict	Condition
Clean	Lands on ramp, descent angle within 15° of ramp angle
Tight	Lands on ramp but very close to the start or end (ratio < 0.15 or > 0.85)
Hard Landing	Lands on ramp but descent angle mismatch exceeds 15°
Short	Lands before the ramp (didn’t clear the gap)
Long	Lands past the ramp (overshot)

The 15-degree tolerance is generous on purpose. Real-world suspension and body positioning absorb some mismatch. But beyond 15 degrees, even a skilled rider is going to feel it.

Impact G-Force

Beyond the verdict, the simulator estimates the G-force on landing. It calculates the component of the rider’s velocity perpendicular to the landing ramp surface, the part that your body and suspension have to absorb, and converts it to a G-force estimate assuming a short deceleration window.

This number is especially useful when comparing vehicle types. A motorcycle landing at the same trajectory angle as a BMX hits the ramp with more perpendicular velocity because of its higher approach speed, even if the descent angle matches the ramp perfectly. A “Clean” verdict with 4G of impact is a very different experience on a 25 pound BMX bike than on a 200+ pound dirt bike.

Three Vehicles, Three Physics Profiles

BMX, MTB, and motorcycles ride fundamentally differently. A 20-inch BMX bike at 15 mph feels fast. A 27.5- or 29-inch mountain bike at 15 mph feels moderate. A 250cc dirt bike at 15 mph is barely rolling. The vehicles have different wheelbases, different masses, different drag profiles, and different speed envelopes.

The simulator ships with three presets:

Parameter	BMX	MTB	Moto
Wheel diameter	20"	27.5"	21"
Wheelbase	37"	41"	58"
Mass (rider + vehicle)	90 kg	100 kg	190 kg
Drag area (CdA)	0.40 m²	0.45 m²	0.65 m²
Speed range	5–25 mph	8–30 mph	15–55 mph
Gap range	2–40 ft	2–60 ft	8–80 ft

Unlike a simple projectile calculator, the presets do change the physics. Mass determines how much air drag decelerates the vehicle mid-flight, a 190 kg motorcycle shrugs off drag that would noticeably slow a 90 kg BMX setup. The drag area (CdA) captures the vehicle’s frontal profile: a motorcycle with a seated rider presents a larger surface to the air than a tucked BMX rider. Together, mass and CdA produce meaningfully different trajectories at the same launch speed and angle.

And yes I do realize I’m being incredibly cavalier switching between metric and Imperial units of measurement, sorry I still think in terms of Imperial units, just can’t get the length of King Henry I’s foot out of my head. But physics is typically better done in metric units, so I’m using it mostly when discussing equations. The actual jump simulator tool allows you to switch between the two, and unlike me it is consistent throughout!

“Dial It In”: The Optimizer

The most useful feature isn’t the physics or the visualization. It’s a single button: Dial It In.

When a rider has set up their ramp geometry but can’t find a speed that yields a clean landing, the optimizer searches the full speed range for the current sport preset, evaluating the physics at each 0.5 mph increment. It collects every speed that produces a “Clean” verdict, then picks the one closest to the rider’s current speed setting.

If no speed in the range works, the ramp geometry is fundamentally incompatible, it goes further: adjusting the landing angle in 1-degree increments to find a viable configuration. The algorithm returns the smallest set of changes needed to make the jump work.

This is the feature that saves trips to the ER. A rider can set up their dream gap, hit Dial It In, and immediately know whether the jump is achievable and exactly what speed to target.

Rendering: Canvas 2D, Not WebGL

Anyone who ever played the old Stunt Cycle arcade game will appreciate this decision (yeah I’m aging myself, I know)…I deliberately chose Canvas 2D over Three.js or WebGL for this tool. The visualization is fundamentally two-dimensional, a side profile of the jump, and adding a third dimension would obscure the information riders actually need: trajectory shape, landing point, and angle matching.

The rendering system uses a dynamic coordinate transformation that maps real-world feet/meters to canvas pixels. The scene auto-scales to fit the jump geometry, keeping the takeoff lip as the origin point and expanding the viewport as the gap distance or peak height grows.

The Vehicle

Each vehicle is drawn procedurally. The bicycles get two wheels, a frame, handlebars, and a standing rider silhouette. The motorcycle gets thicker tires, a swing-arm, front fork, engine block, exhaust pipe, seat, fenders, and a seated rider with a helmet and visor, legs bent down to the pegs instead of standing on pedals. During flight, the vehicle rotates naturally using the actual descent angle at each point in the trajectory:

rotation = atan2(-vy, vx)

This produces the realistic nose-up-on-takeoff, level-at-peak, nose-down-into-landing motion that riders recognize from real footage.

Ghost Trails

Every time a rider changes a parameter, the previous trajectory is saved as a ghost trail, a semi-transparent dashed arc that lingers for 2 seconds before fading. Up to three trails are kept simultaneously.

Ghost trails are the key to iterative design. A rider can nudge the speed up by 1 mph and immediately see how the new arc compares to the old one. Without ghosts, each change exists in isolation. With them, the design process becomes visual diff.

The Animation State Machine

The simulator isn’t just a static trajectory plotter, it animates the full jump sequence. The animation runs through four phases:

Approach: The bike rolls up the kicker surface, following the curved ramp profile
Flight: Projectile motion through the air, following the calculated trajectory
Ride-off: On a clean landing, the bike eases down the landing ramp for 1 second
Crash: On a miss, the bike freezes at the impact point with a red crash indicator

Each phase transitions to the next based on position triggers, not timers. The approach phase ends when the bike reaches the lip. The flight phase ends when landing detection fires. The ride-off or crash phase runs for a fixed duration, then the animation holds on the final frame.

Playback speed is adjustable from 0.25x to 2x, which is useful for studying the critical moment when the bike meets the landing ramp.

Kicker Geometry: The Radius Problem

The takeoff ramp isn’t a straight slope, it’s a curved surface defined by a radius. The kicker radius determines how gradually the rider transitions from horizontal to the lip angle. A tight radius (small value) creates an abrupt, poppy kicker. A large radius creates a smooth, flowing ramp that’s easier to ride but requires more speed to clear a similar gap as its poppier cousin.

The simulator calculates the kicker radius automatically from the lip angle and lip height:

radius = height / (1 - cos(angle))

This is the same circular arc math used in skateboard ramp design, and it ensures the ramp profile matches real-world construction. The curve is rendered on the canvas as a series of line segments following the arc, giving riders an accurate picture of the ramp’s shape and size.

What We Learned Building It

So all the tech implementation details aside, we learned a few things while building this tool:

Landing angle matters more than distance. The early prototype only checked whether the rider cleared the gap. Testers kept asking “why does this feel wrong?”, the answer was always angle mismatch. Try jumping to flat in the real world and you’ll feel this mismatch in your teeth! Adding the 15-degree tolerance check and the “Hard Landing” verdict transformed the tool from a distance calculator into an actual design tool.

Ghost trails were an afterthought that became essential. Ghost trails became a need because the canvas flickered between parameter changes and revealed a lack of visual continuity. Once created, riders started using them to compare trajectories, and now they’re the primary way to iterate on jump designs.

The Dial It In optimizer needed to be conservative. Early versions would suggest radical changes, “increase speed by 12 mph and change the landing angle by 20 degrees.” That’s technically correct but useless. The final version minimizes the delta from the rider’s current settings, making suggestions that feel like refinements rather than redesigns.

Try It

The Jump Simulator runs entirely in your browser. No account, no install, no tracking. Pick your vehicle, dial in your ramp geometry, and simulate before you build. Let us know if it helps you, and feel free to recommend improvements. Send it!

The Jump Simulator is a free experiment from Stalefish Labs.

The None Trap: Game Theory & the Formula 1 DNF Pick

Michael Morrison — Mon, 09 Mar 2026 00:00:00 -0700

When designing the DNF pick category for our fantasy racing mobile app Open Wheelers, I included an option that felt generous: pick None. If you believe nobody will retire from the race, select None and collect 2 points if you’re right. Otherwise, pick a specific driver you think will be among the first three to retire, and earn 3, 2, or 1 points depending on how early they go out. We take our fantasy games seriously, I want them to be engaging and fun, and I care a lot about getting things right. So I decided to dig a bit deeper on this rule mechanic because it felt suspicious.

On the surface, None looks like the smart play. I even worried perhaps it would become the ONLY play and break the game; I thought maybe everyone would figure out that None is the no-brainer pick to beat the system. After all, modern F1 cars are absurdly reliable. Races where every car finishes make headlines now instead of being unthinkable. So why not make None your weekly lock and bank the free 2 points?

Because it’s a trap. And the data proves it despite my instinct toward the opposite.

A decade of Did-Not-Finishes

I looked at every F1 race from 2016 through 2024, 190 grands prix across nine seasons. Here’s the reality of how often “nobody retires” actually happens:

Season	Races	Avg DNFs per race	Zero-DNF races
2016	21	3.1	2
2017	20	3.0	0
2018	21	2.8	0
2019	21	2.6	1
2020	17	2.6	0
2021	22	2.1	3
2022	22	2.8	1
2023	22	2.3	3
2024	24	1.7	2

Across the entire dataset, roughly 12 out of 190 races had zero retirements. That’s about 6% of the time. Put another way, if you picked None for every race across a full decade, you’d be right once every 16 races. At 2 points per victorious pick, that means a steady None pick throughout an entire season would average a grand total of 3 points per season…yikes!

The math doesn’t lie

Let’s compare two hypothetical players over a 24-race season like 2024:

Player A: The “None” loyalist Picks None every single race. Correct twice. Season total: 4 points.

Player B: The student of unreliability Studies which teams are struggling with reliability or drivers who just seem to have a knack for finding the gravel, and targets those drivers. Even with modest accuracy, hitting a top-3 DNF just 5 times across 24 races, the floor is 5 points and the ceiling is 15 points depending on whether those picks land 1st, 2nd, or 3rd out.

And 5 hits isn’t ambitious. In 2023, Esteban Ocon and Logan Sargeant each retired from 7 of 22 races. In 2022, four different drivers, Zhou Guanyu, Valtteri Bottas, Carlos Sainz, and Fernando Alonso, hit 6 retirements each. If you identified any of those drivers early and kept picking them, you’d outscore None by a landslide.

But cars ARE getting more reliable

This is true, and it’s the one wrinkle worth watching. F1’s finishing rate has climbed steadily from about 86% in 2016 to over 91% in 2024. The sport saw its first-ever consecutive zero-DNF races to open the 2024 season in Bahrain and Saudi Arabia.

If that trend continues, and the 2026 regulations could easily reverse it, zero-DNF races might climb from 2-3 per season toward 4-5. Even at that rate, None at 2 points per hit would still max out at 8-10 points across a season, which a savvy driver picker can match by nailing just three or four retirements in the top-3 positions. It’s worth noting that the opening race of 2026 had not only three DNFs but also two DNSs and one Lance Stroll driving the race effectively for test purposes since he pitted multiple times and ultimately finished with only 43 laps (the leaders did 58 laps). DNSs and turning a real race into a test are almost unheard of…so it’s looking like 2026 may move us back toward the DNF mean instead of cementing a new age of reliability.

What this means for strategy

Back to the None pick, I verified it isn’t the safe move. It’s the passive move. It says “I don’t want to think about this category.” And passivity rarely wins in games with point differentials this tight.

The real edge in the DNF category comes from paying attention to things most fantasy players ignore: which teams are running new and untested power units, which drivers have a reputation for aggressive racing that invites contact, and which cars have been nursing recurring mechanical issues across practice sessions.

That’s the kind of knowledge that separates pub-league champions from the field. And it’s exactly the kind of informed, opinionated pick-making I built Open Wheelers around.

So go ahead and pick None if you genuinely believe every car is making it to the checkered flag. Just know that the odds are about 15-to-1 against you.

Open Wheelers is a casual F1 and IndyCar fantasy game for friends, built by Stalefish Labs.

Every Skateboarder's First Question, Answered With a Sticker

Michael Morrison — Sat, 07 Mar 2026 00:00:00 -0800

The first thing a skateboarder asks when they roll up to a new ramp is some variation of the same question: “What’s the tranny?”

Not far behind: “How tall is it?” Then “How wide?” Then “What’s the flat?” And if the ramp’s owner is around, they answer. Again. For the hundredth time. Sometimes they don’t remember the exact specs anymore. Sometimes they give a number that’s close enough. Sometimes they just shrug and say “ride it and find out.”

BMX riders do the same thing, just with different priorities. And the questions aren’t idle curiosity, they’re practical. The dimensions of a ramp fundamentally change how it rides. A 5-foot mini with 8.5 feet of transition rides completely differently than a 5-foot mini with 7 feet of transition. One will feel mellow and flowy, the other steep and snappy and make it easier to lock certain tricks. Same height, totally different experience. Width determines how long you can cruise grinds and slides, or in the case of a vert ramp how many times you can switch directions on airs. Flat bottom determines how much speed you carry between walls and how much time you have to think between tricks. Coping style determines how grinds feel and whether your wheels are going to hang up. Surface material tells you how slick a ramp is, and whether you’re about to have a smooth ride or a sketchy one.

These aren’t nerdy details. They’re the spec sheet for the experience you’re about to have.

The repetition problem

If you’ve ever built a ramp, in your backyard, at a DIY spot, or for a local park, you know the drill. People show up, they’re stoked, and they want to know what they’re riding. You tell them. Then the next crew shows up and you tell them again. Your buddy brings a friend the following weekend and you tell them too. You post a clip online and the first comment is “specs?”

It’s not annoying, exactly. It’s flattering that people care, and it’s a totally valid question. But it’s repetitive, and over time the numbers start to blur. Was the transition 7 feet or 7.5? Did you go with 14 feet of flat or 15? You built the thing three years ago and the napkin sketch is long gone.

Park owners and ramp builders face this at scale. A skatepark might have a dozen features, each with different dimensions that riders want to know. The information exists, someone measured and cut every piece of wood or formed every piece of concrete, but it lives in a set of plans that nobody can find, or in the builder’s head, or nowhere at all.

The nutrition label idea

The solution hit me because of how obvious it is: a nutrition facts label, but for ramps.

Everyone knows the format. You’ve seen it on every food package your entire life. It’s a clean, standardized layout that packs a lot of specs into a small space. It’s quickly scannable. It’s familiar. And most importantly, it solves the exact same problem: conveying a set of important specs to someone who needs them, in a format they already know how to read.

Instead of calories and protein, you get height and transition radius. Instead of serving size, you get rideable width. Instead of ingredients, you get surface material. Same structure, completely different domain, but the format transfers perfectly because the underlying need is the same: “tell me what I’m dealing with, quickly.”

Slap it up on the edge of the vert where nobody rides, or the side of the transition, even on the deck of the ramp by the coping. Now every skater who rolls up gets their questions answered before they even have to ask.

Building the generator

That’s the idea behind Transition Facts, a tool in our Experiments section. You punch in the specs of your ramp — height, transition radius, width, flat bottom, coping type and diameter, surface material, and platform depth — and it generates a nutrition facts-style label that you can print as a sticker or a PDF.

The design mimics the real FDA nutrition label closely enough that the format is instantly recognizable, but adapts the content entirely for ramp specs. The layout is intentionally dense in the way the original is — no wasted space, just the numbers that matter.

It’s a small tool. There’s no account to create, no app to download. Enter your specs, print your label, stick it on your ramp. Done.

Why it works

The reason a sticker works better than just telling people is the same reason nutrition labels work better than asking the cashier what’s in your food. The information is there, at the point of use, every time, for everyone, without requiring anyone’s time or memory.

A ramp owner doesn’t have to be present. A park doesn’t have to staff someone to answer questions. A visiting skater doesn’t have to feel weird asking. The specs are just on the ramp, the same way ingredients are just on the box.

And there’s a secondary benefit: it settles arguments. “You sure that’s only a foot and a half of vert?” “Feels more like 2 feet!” Now there’s a label. Discussion over. Ride the ramp.

Transition Facts is a free tool in the Stalefish Labs Experiments section. No account needed — just specs in, sticker out.

From Group Chat to App: How Going Digital Unlocked Better Fantasy Stats

Michael Morrison — Fri, 06 Mar 2026 00:00:00 -0800

Open Wheelers the app started life as a text thread. A group of friends with a love of Formula 1 just wanted a fun alternative to complex fantasy games with drafted teams, waivers, etc. So we played a manual game within a text thread, a gentleman’s agreement to get your picks in before the lights go out, and yours truly would manually tally results after each race, post the updated standings, and we’d argue about who was actually winning. It worked well enough for years. And it was completely holding the game back.

The thing about a manual game is that your pick categories are limited to whatever a human scorekeeper (me!) can reasonably verify after a race. Podium finish? Easy, check the top 3. DNF? Straightforward enough, the list of retirements is right there. Fastest lap? Easyish, one name, but F1 stopped publishing it clearly when they stopped awarding points to drivers in 2025, so it required a search each week.

So that’s what we were using: Podium, Fastest Lap, DNF. Three categories, three picks. Simple, fun, and perfectly adequate for a casual league among friends run out of a text thread. You may not think of the Messages app as a game engine, but it actually kinda worked.

But “adequate” and “kinda” are dangerous words for someone who obsesses over game design.

The problem with Fastest Lap

Turns out the mediocrity of our system had everything to do with the picks and points, and how they were born out of what was doable for a guy manually managing the stats. Take Fastest Lap, which sounds like an exciting stat. In practice, it’s one of the least interesting picks you can make, and here’s why: in today’s F1, the fastest lap is all too often just an index of the top cars in the race. It was actually a bit more interesting in the first years of our game when F1 actually gave out a point for Fastest Lap - then you’d sometimes see a driver deep in the pack pit late for fresh soft tires to try and snag a point. When F1 did away with that rule in 2025, Fastest Lap became a strategic afterthought, not a battle.

More importantly, it basically became a proxy pick for the Podium, a pick we already had. So we wanted something that rewarded paying attention to the actual racing. Something with real variance from week to week, where deep knowledge of the grid actually mattered. And maybe even something that could reward a bit of grit for that driver who battles throughout the race with hard driving even if it doesn’t necessarily net them podium glory. Think Lewis Hamilton struggling at Ferrari but in some races rage-passing half the field from a poor qualifying start.

Enter the Overtaker

The stat we really wanted was most positions gained: the driver who climbs the most spots from their starting position to their finishing position. In F1, this is sometimes called the “overtaker” award. It rewards the most dynamic racing of the afternoon: the recovery drives, the strategic masterstrokes, the scrappy midfield battles that don’t make the broadcast highlights but absolutely define the race.

It’s Fernando Alonso starting P17 after a qualifying penalty and slicing through to P7. Or a midfield driver nailing an alternate strategy to jump six cars on the undercut. Or someone surviving a chaotic wet start to gain a dozen spots while half the grid spins off. Yes, probably Max. You get the idea. These are the moments that make F1 worth watching, and the Overtaker pick puts a fantasy stake directly in them.

The problem? Try scoring that manually from a group chat.

To calculate positions gained, you need each driver’s starting grid position and their finishing position, then compute the delta for every classified finisher, then rank them. That’s 20 drivers, two data points each, every race. It’s not rocket science, but it’s exactly the kind of tedious bookkeeping that kills a casual game. No one’s going to maintain a spreadsheet for a fun side competition with friends. And if the scorekeeper gets it wrong, which I will, because grid penalties and post-race time penalties shift the numbers, the arguments start.

The app does the boring parts

This is the quiet superpower of moving a game from text to software. The app doesn’t just automate scoring, it unlocks categories that were impractical before. When results flow in digitally, computing positions-gained is trivial. Grid position minus finish position, sort descending, done. The app handles ties, accounts for DNS and DNF edge cases, and posts the answer the moment results are confirmed.

What took a motivated scorekeeper (me!) 15 minutes of cross-referencing now takes zero effort. And the pick itself, who’s going to gain the most positions, is infinitely more interesting than Fastest Lap. It asks you to think about:

Qualifying mismatches: Which fast cars are starting out of position due to grid penalties?
Race pace vs. one-lap speed: Who has a car that’s better in race trim than qualifying trim?
Strategy variance: Which teams might roll the dice on an alternate strategy that could leap them up the order?
Track characteristics: Is this a track where overtaking is physically possible, or will grid position mostly hold?

Every one of those questions requires genuine knowledge of the sport. That’s a pick category with depth.

The design principle

The lesson here isn’t specific to F1 or fantasy sports. It’s a broader game design idea: the best mechanics are often the ones that were too complicated to run by hand. When you move a game to software, don’t just digitize the existing rules. Ask what was impossible before and whether it’s interesting now.

For Open Wheelers, Fastest Lap was a concession to manual scoring. Overtaker is the pick we always wanted but couldn’t practically support. The app didn’t just make the game easier to play, it made it a better game.

And if you think that’s an incremental difference, try picking the Overtaker for a rainy Interlagos. That’s not a checkbox. That’s a decision.

Open Wheelers is a casual F1 and IndyCar fantasy game for friends, built by Stalefish Labs.

The Weather Says Clear Skies. So Why Is the Trail a Swamp?

Michael Morrison — Thu, 05 Mar 2026 00:00:00 -0800

I love mountain biking. I love skateboarding. I love pretty much anything that involves wheels and dirt and concrete and the outdoors. What I don’t love is driving 30 minutes to a trailhead only to find the trail is a rutted, muddy mess, despite the forecast showing nothing but sunshine.

This is sadly not an isolated occurrence.

The Gap Between Weather and Reality

Weather apps are great at telling you what the weather is and often what it will be. Temperature, wind, humidity, chance of rain, it’s all there. What they don’t tell you is what last night’s rain did to the ground beneath your tires. That half inch at 2am? On a south-facing dirt trail with good drainage, it might be bone dry by noon. On a shaded clay singletrack in the woods? Come back Thursday. Or what about the concrete skatepark in direct sunlight vs. the shaded halfpipe layered in Skatelite? Not the same.

For years I did what every rider or skater does. I’d check the radar, look at the hourly history, maybe glance at the 48-hour precipitation total, and make a gut call. Sometimes I’d text a buddy: “You think Warner is rideable?” And they’d text back something equally scientific: “Probably?”

The variables are too fuzzy. How much did it rain? When did it stop? What’s the temperature now? Is the wind helping things dry? Is the trail in full sun or deep shade? Is the surface dirt, gravel, concrete, wood? Did it freeze overnight and is now thawing into a soupy mess? Each of these factors interacts with the others in ways that are genuinely hard to hold in your head all at once.

So I Built an App

I’m a developer, so naturally my response to this frustration was to write software. What started as a personal side project, just a quick tool to check if my local spots were rideable, turned into something much bigger once I realized how many people share this exact problem.

The app pulls real weather data, looks at recent precipitation, drying conditions, temperature trends, freeze-thaw cycles, surface type, sun exposure, all of it, and synthesizes it into a simple answer: Yes, Maybe, or No. It tells you whether conditions are likely suitable for riding right now, and gives you a seven-day outlook so you can plan ahead.

Building it forced me to formalize all of those gut-feel heuristics I’d been running in my head for years. How much rain is too much? How long does it take to dry? Does Ramp Armor dry faster than wood or metal? When does a freeze actually matter? Translating intuition into code is humbling, because it forces you to confront how much of your “expertise” is just vibes.

It’s Still an Inexact Science

Here’s the thing I want to be honest about: even with a carefully crafted and dedicated prediction engine running real weather data through a multi-phase algorithm, this is still an inexact science. Ground conditions are hyperlocal. Two trails a mile apart can behave completely differently based on soil composition, tree cover, elevation, and drainage. No amount of weather data can perfectly capture what’s happening at a specific spot on the earth’s surface.

The app gives you a well-informed estimate, and in my experience, it’s right far more often than my old gut-check method. But it’s not infallible, and I never want to pretend it is.

That honesty is actually baked into the product. Users can submit feedback when a verdict doesn’t match what they found on the ground. And behind the scenes, I use an LLM to process those reports, analyzing the weather conditions, the surface type, the user’s description of what they actually encountered, and then use that to identify patterns where the engine’s assumptions might be off. It’s a feedback loop that lets the prediction model evolve based on real-world ground truth from actual riders at actual spots.

I think that’s what makes this problem so interesting. It sits right at the intersection of atmospheric data, soil science, and lived experience. No model will ever be perfect, but a model that learns from the people using it every day can keep getting better.

What’s Next

In a future post, I plan to pull back the curtain on the prediction engine itself, how it evaluates moisture, what the drying model looks like, how freeze-thaw cycles are handled, and why certain surfaces behave so differently from others. It’s a surprisingly deep rabbit hole, and I think anyone who’s ever stared at a weather app trying to decide “is it rideable?” will find it interesting.

Until then, check the app, trust the verdict, and if it’s wrong, tell me. That’s how we make it better.

Ridewise is available now on the App Store, built by Stalefish Labs.

Bad Timing & Sticktoitiveness

Michael Morrison — Wed, 04 Jun 2025 00:00:00 -0700

Timing really is nearly everything. And what it isn’t, circumstance makes up for. — Steven Van Zandt

It was such a great plan, it really was. You know those success stories where lightning strikes someone with a genius idea, and then somehow stars align and they take their idea to fruition right when it’s needed most? Wild success ensues, and you get to read about the virtue of following your dreams, and how simply seizing opportunity is all that separates you from similar results. If I was really cheeky I’d give you a numbered list of steps to follow. Well this is not one of those stories, this is a tale of timing, really bad timing. This is a cautionary tale to show how even endless enthusiasm, diligent work, and careful planning can be hilariously mocked by the unforeseen.

My big idea was a software solution to the cat herding problem of figuring out who’s in and out when trying to get together with friends. I’m an old skateboarder (really old!) and it’s an activity that is generally less enjoyable and less safe alone. So skating with friends is a key part of the sport. We used text messaging to plan sessions and it sorta works but has a lot of failings like the first joke or unrelated comment can fully derail the in/out responses, the skate session invite scrolling off into oblivion. Seemed like a problem that could be perfectly solved with a mobile app.

Enter Muster, a mobile app for getting people together in the real world. I tend to play the long game, meaning my pet projects sometimes take a while but I don’t quit easily, so back in 2019 the app had been a project for going on a decade. The iOS version was finally nearing completion and the excitement of actually releasing this thing into the wild was getting real. What had started as a Minimum Viable Product very much morphed into a full-featured app, and the unwillingness to not ship something half-baked at least partially explains the ridiculously long development timeline. In tragedies there’s often a seed of self-destruction if you look deeply enough, and in the case of Muster the perfectionism of features caused the publish date to slip literally years and eventually land in early 2020. So I was wrapping up the final touches on this app for helping people get together…what could go wrong?

On February 20, 2020 I excitedly published my decade-plus long project to Apple’s App Store, the dream was now reality. Indeed, that dream of connecting the world one intimate event at a time was officially beginning. I celebrated with a drink and dessert (actual photo)…it was now time to sit back and wait for the world to adopt this can’t-miss new idea. I imagined finally doing away with clumsy antiquated texting to plan our skate sessions, and the app quickly growing beyond our skateboard crew as a solution for all informal RSVPs. Muster would be a force for good, bringing friend and foe together. Bullies and bullees burying the hatchet, dogs and cats living together in harmony, was peace on Earth finally within reach? I should’ve savored that dessert a bit more…probably a good general rule to live by.

The CDC Museum lists the official start of the COVID-19 pandemic as December 19, 2019, with the first U.S. case on January 20, 2020. But given that pro sports dominates much of American culture, it would be March 11, 2020 when things “got real,” as the NBA canceled the remainder of their season. So less than three weeks after the launch of the app that had been carefully designed to break with other forms of social media and put the focus on people being face-to-face with each other, we find out that being face-to-face with each other is literally life-threatening. Brutal.

I had managed to create a doomsday app purely through an accident of timing. Like catastrophic timing, some of the worst timing ever. How could you possibly spend ten years of your life creating something, only to release it within weeks of it becoming absolutely useless? Worse than useless, dangerous! That was a crushing, helpless feeling, sadly but mercifully overshadowed in some ways by the life and death consequences of the pandemic, which trivialized our individual pursuits in the wake of literal survival for many. Even so, we all knew there would eventually be a return to normalcy, just no clue how or when, and at what cost.

So yes in hindsight I should’ve been working on Zoom not Muster leading into 2020, but here’s the good news about horrific timing…eventually time heals most things, one way or another. You just have to hang on and not let the lows of the present erase the potential highs of the future. I can’t say I was bursting with such cool-headed stoicism in 2020, there was little pretense of calm or wisdom in the moment. Nevertheless, quitting wasn’t on the table, the newly released app languished unused during COVID, as did many of us, while we safe-distanced and waited to find out what happens next.

Then time marched on and eventually things got better. Even though Muster’s initial release was comically flawed, like on a Shakespearean level, it ultimately survived COVID, and is alive and well today. It continues to help me and my friends not skate alone, and it has remained a vibrant project that is still evolving and improving as I stumble to unravel the subtle social challenges of bringing humans together.

I guess the takeaway (in both tech projects and in life) is to realize that even the best attempts at planning can go horribly awry, and the only thing you can truly control is how much quit you have in you. I learned that sometimes the best laid plans will be thwarted by the unknown, where opportunities become problems that turn into predicaments. The only choice is to quit or press on, and if you believe in yourself and what you’re doing that choice is surprisingly easy to make.

Muster is available now on the App Store, built by Stalefish Labs.

Obsession & the Artistic Entrepreneur

Michael Morrison — Mon, 19 Aug 2024 00:00:00 -0700

Without obsession, life is nothing. — John Waters

I obsess over things. Once an idea takes hold, I’m at its mercy. It can arrive in an instant but linger for a very long time, in some cases years and even decades. It can be an obscure hobby (beekeeping), a high-risk activity outside of mainstream ball sports (skateboarding), or it can be an idea for a problem to be solved. Problem solvers are often thought of as entrepreneurs, and they certainly can be, but we’re really talking about two wildly different personalities and skill sets. Yet obsession can give one a false sense of the other.

I mention this because I’ve been obsessively working on a particular problem for quite some time, and as you learn more you might think the time, energy, and money I’ve spent on it makes me an entrepreneur. That’s what I thought too, and I was very wrong. Entrepreneurs are (or should be) serious about things like determining if there’s actually a market for their solution, how to properly reach that market, and just maybe how much it will cost, both financially and more importantly in time. They would do that BEFORE diving into the work, and they’d be right to do so. But that’s not me, and when aiming that laser focus of obsession at a problem, I’ve learned I’m really only solving it for myself.

Project myopia can be a wonderful thing for personal projects where you’re effectively doing pro bono work for yourself. Expectations typically line up pretty well with results when they live in the same person’s head. Or to put it in marketing terms, you don’t have to sell yourself on the benefits of your own idea. Thing is, you DO have to eventually sell others on your idea if part of your plan involves it solving their problems too. For example, a mobile app with a comically ambitious scope. I’m talking about Muster, which is attempting to evolve the concept of an RSVP for the mobile age and in doing so change how we get together with each other in the real world. I’ve been working on it for nearly 15 years, which is slow by almost any standard but insanely slow for tech (the iPhone itself has only been around since 2007). But I’m patient, and stubborn. And I understand that to do just about anything meaningful in life, you must exhibit dogged perseverance and cultivate a certain love for the process of creation itself, with a bright line separating effort from outcome.

So with Muster think an extremely informal evite with a hint of messaging, calendar, a touch of Instagram, even a dash of Strava. I know in marketing you aren’t supposed to define yourself in terms of your peers or competitors but it’s often the simplest way to convey an idea, and zero-sum thinking is usually counter-productive in a world large enough for multiple ideas to co-exist and serve unique purposes. Besides, referencing “the competition” is small potatoes when it comes to Muster and ignoring marketing best practices. Anyway, the idea grew out of the need to distill the communication for getting together down to two possibilities: in or out. Other interesting features evolved over time but that’s still the core of the app: let’s get together, are you in or out?

Seems simple enough, right? I naively thought so too way back in 2010. Turns out there’s a lot of subtlety in event planning, even informal events like meeting up with friends for a coffee. How do people find each other in the app, cultivated friend lists like Facebook? If we’re meeting on Friday in Atlanta (EST) but I create the invitation on Wednesday while in Nashville (CST), what time zone is used? Do you show that time zone in the app? To both people? Is location required or should it be optional, maybe inferred from the title like “Grilling at Our House?” And what about notifications, iPhone and Android users coming together, privacy concerns, etc.? It started to become clear why no other mobile apps have succeeded in solving this ostensibly simple problem, and why most planning is still done with clunky text threads. Enter an obsessive guy with technical skills, a problem to solve, an over-abundance of optimism, and zero regard for proper entrepreneurial decision-making.

Years go by. Then a few more. Plenty of roadblocks surfaced, including a shuttered software development tool (Parse) and a pandemic, among other challenges…but all those design problems mentioned got solved, and many more were identified and solved as well. Not only that, but real-world usage led to several significant enhancements such as event messages and media, invitee groups, plus-ones, co-hosts, min/max attendees, and more. The idea evolved but I stuck to my guns in building the app I wanted, not the app I guessed the world needed. Sure, tons of testing was done with friends and family, not to mention Muster being both a lead sponsor and planning tool for the world’s largest backyard skateboard contest. But at the end of the day every major decision came down to “what do I personally want this app to do?”

And here we get to the real issue at hand. I’ve heard it said that if Bob Dylan hadn’t become one of the greatest songwriters in history, he’d be sitting on a sidewalk somewhere playing the exact same music. That’s an artist. An artist creates because they can’t not do it, and the best artists create for themselves, regardless of whether they ultimately sell their art or perform it to make a living. With art, success lies in the creation itself, not in how it’s received by others — Vincent Van Gogh only sold one painting in his lifetime!

Business is in many ways the opposite of art, where success is necessarily defined by others voting with their wallet for a product by trading goods or money. App-making is certainly a business, I mean apps are literally published in an app STORE. So it’s difficult to make the “apps are art” argument with a straight face. Yet there’s an artist inside this engineer who is dutifully committed to creating the ultimate real world social app purely for myself. And at the same time publish it in a store where others get to decide if it also provides any value to them.

The irony that this ruthlessly individualized app depends on others for business success isn’t lost on the artist in me, yet I can’t not create it. The resulting conflict is real, and the jury is still out on whether this particular marriage of technology and liberal arts ultimately delivers on that famous Steve Jobs insight. In the meantime, if you ever stumble across a guy on a sidewalk sitting on a skateboard with a laptop coding away, consider downloading his app and inviting him for a coffee. I’m in!

Muster is available now on the App Store, built by Stalefish Labs.