Stalefish Labs

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

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

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

Then I started thinking about my garden.

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

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

The Inversion

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

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

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

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

The thresholds shift too:

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

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

Manual Watering: Tracking What the Weather Doesn’t Know

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

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

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

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

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

Cold Weather Extends Watering Memory

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

wateringWindow = 48 + 48 × coldFactor

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

Establishment Sensitivity: Protecting Young Plants

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

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

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

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

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

Dormancy and Evaporative Demand

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

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

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

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

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

Yardwise Surface Types

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

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

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

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

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

The Insight That Made It Work

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

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

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

Next in the Series

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

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

Edge Cases That Break Your Weather Model

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

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

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

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

Freeze/Thaw: 360 Lines of Humility

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

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

Hard Surfaces vs. Ground: Different Failure Modes

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

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

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

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

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

The Near-Freezing Zone

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

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

Overnight Freeze, Currently Above Freezing

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

It depends on:

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

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

Extended Freeze With No Recent Rain

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

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

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

Snow Melt: A Bell Curve, Not a Line

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

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

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

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

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

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

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

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

When There’s No Tracked Snow

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

initialMoisture = 0.3 + 0.3 × freezeSeverity

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

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

Precipitation Intensity: Same Amount, Different Impact

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

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

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

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

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

Cold-Weather Dormancy: Protecting Plants From Themselves

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

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

The dormancy calculation uses a non-linear curve:

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

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

The dormancy score gets amplified by:

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

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

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

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

Low Evaporative Demand: When Dry Isn’t Thirsty

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

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

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

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

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

The Meta-Lesson

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

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

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

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

Next in the Series

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

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

Turning Raw Weather Into a Drying Model

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

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

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

Weighted Precipitation: Not All Rain Is Equal

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

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

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

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

Rain Score Normalization

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

rainScore = min(1.0, totalPrecip / 0.75)

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

Why Intensity Matters

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

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

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

Drying Strength: The Recovery Side

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

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

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

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

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

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

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

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

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

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

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

Exposure Matters

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

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

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

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

Drying Classification

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

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

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

Combining It All: The Wetness Score

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

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

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

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

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

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

A Worked Example

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

Rain score:

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

Timing score:

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

Drying strength:

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

Wetness:

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

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

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

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

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

Residual Wetness: The Ground Remembers

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

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

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

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

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

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

What This Model Doesn’t Do

A few things I intentionally left out:

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

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

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

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

Next in the Series

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

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

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

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

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

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

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

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

The Problem With “Did It Rain?”

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

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

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

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

From Weather Data to a Verdict

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

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

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

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

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

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

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

The Decision Pipeline

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

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

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

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

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

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

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

One Engine, Two Perspectives

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

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

Same math, opposite interpretation:

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

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

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

Why Not Just Show a Percentage?

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

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

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

What’s Coming in This Series

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

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

The Apps

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

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

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

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

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

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

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

This is sadly not an isolated occurrence.

The Gap Between Weather and Reality

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

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

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

So I Built an App

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

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

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

It’s Still an Inexact Science

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

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

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

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

What’s Next

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

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

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