Forem: Stalefish Labs

Who Briefs the Public?

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

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

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

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

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

The Gap

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

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

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

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

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

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

The Naivety Problem

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

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

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

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

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

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

What's Missing from Public Information

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

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

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

Here's what that looks like in practice:

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

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

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

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

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

When It Stopped Feeling Naive

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

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

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

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

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

The Honest Version

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

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

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

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

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

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

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

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

How Tall Tales Almost Ended Up in Starbucks

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

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

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

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

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

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

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

I started writing pitch letters to Starbucks in September 2002.

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

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

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

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

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

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

The remaining copies of Tall Tales Pocket Edition are here.

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

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

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

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

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

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

Why Ramp Design Is Harder Than It Looks

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

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

The Arc: Circular Geometry in Practice

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

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

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

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

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

Curve Offsetting for Layers

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

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

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

The Materials Engine

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

Lumber Length Rounding

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

Sheet Goods Efficiency

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

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

Rib Spacing and T-Ribs

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

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

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

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

Fastener Estimation

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

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

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

The Full Shopping List

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

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

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

The 3D Model: Eight Layers Deep

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

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

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

Building the Side Templates

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

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

Positioning Ribs Along the Arc

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

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

Surface Sheet Seams

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

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

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

The Coping

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

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

Design Decisions That Mattered

Indoor vs. Outdoor Toggle

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

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

Section Width: 4' vs. 8'

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

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

The Explode View

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

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

The Transition Facts Sticker

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

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

What Was Learned

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

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

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

Try It

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

The Ramp Designer is a free experiment from Stalefish Labs.

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

Stalefish Labs — Wed, 01 Apr 2026 05:00:37 +0000

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

Stalefish Labs — Tue, 31 Mar 2026 19:31:40 +0000

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?'

Stalefish Labs — Fri, 27 Mar 2026 16:30:24 +0000

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

Stalefish Labs — Mon, 23 Mar 2026 18:31:28 +0000

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

Stalefish Labs — Fri, 20 Mar 2026 14:00:28 +0000

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

All three apps answer the same fundamental question: what's the moisture situation at this spot? But each app:

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 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.

EngineMode: Flipping the Perspective

The most important type in the engine might be the simplest:

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 green for Yes, orange for Maybe, red for 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...
}

Each case 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.

Surface Types: The Parameterization Layer

Seventeen surface types 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.

Threshold Calibration Per Mode

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. One line of mode-aware logic handles both cases.

App-Specific Features Without Conditionals

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 — 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 — 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 — 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

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 assessment comes back as:

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, DryingCalculator, VerdictResolver — each as 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 a solo 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 coming soon for iOS from Stalefish Labs. Built by one developer, powered by one engine.

Turning Raw Weather Into a Drying Model

Stalefish Labs — Tue, 17 Mar 2026 20:31:05 +0000

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 coming soon for iOS from Stalefish Labs.

The Pole Sitter Strategy: How We Fixed a Scoring Loophole

Stalefish Labs — Fri, 13 Mar 2026 17:02:26 +0000

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 laughably simple. Wait for qualifying, pick whoever was on 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?

We looked at every F1 race from 2016 through 2024 — the same decade of data we used in our 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 we built Open Wheelers as a proper app, we had a chance to redesign the scoring from scratch. The key change was simple: 3-2-1 across all three categories. We 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 lazy 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

Stalefish Labs — Fri, 13 Mar 2026 16:30:47 +0000

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

Stalefish Labs — Wed, 11 Mar 2026 05:00:30 +0000

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.

"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.