Stalefish Labs

Building Confidence Into Uncertain Verdicts

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

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

Why Not a Percentage?

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

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

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

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

The Maybe State Is the Product

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

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

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

Rationale: The Why Behind the Verdict

Every assessment includes a structured rationale:

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

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

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

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

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

Confidence: Admitting What You Don’t Know

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

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

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

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

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

What I Didn’t Do With Confidence

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

The three levels map to three communication strategies:

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

That’s enough to calibrate expectations without overwhelming.

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

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

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

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

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

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

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

Risk Categories: More Than Just “Wet”

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

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

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

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

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

Putting It All Together

The full assessment output:

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

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

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

The Design Principle

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

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

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

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

Thanks for Reading

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

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

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

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

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

Then I started thinking about my garden.

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

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

The Inversion

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

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

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

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

The thresholds shift too:

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

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

Manual Watering: Tracking What the Weather Doesn’t Know

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

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

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

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

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

Cold Weather Extends Watering Memory

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

wateringWindow = 48 + 48 × coldFactor

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

Establishment Sensitivity: Protecting Young Plants

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

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

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

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

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

Dormancy and Evaporative Demand

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

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

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

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

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

Yardwise Surface Types

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

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

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

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

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

The Insight That Made It Work

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

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

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

Next in the Series

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

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

Edge Cases That Break Your Weather Model

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

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

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

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

Freeze/Thaw: 360 Lines of Humility

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

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

Hard Surfaces vs. Ground: Different Failure Modes

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

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

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

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

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

The Near-Freezing Zone

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

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

Overnight Freeze, Currently Above Freezing

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

It depends on:

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

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

Extended Freeze With No Recent Rain

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

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

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

Snow Melt: A Bell Curve, Not a Line

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

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

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

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

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

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

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

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

When There’s No Tracked Snow

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

initialMoisture = 0.3 + 0.3 × freezeSeverity

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

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

Precipitation Intensity: Same Amount, Different Impact

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

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

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

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

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

Cold-Weather Dormancy: Protecting Plants From Themselves

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

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

The dormancy calculation uses a non-linear curve:

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

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

The dormancy score gets amplified by:

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

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

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

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

Low Evaporative Demand: When Dry Isn’t Thirsty

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

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

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

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

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

The Meta-Lesson

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

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

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

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

Next in the Series

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

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

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

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

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

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

The Shape of the Problem

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

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

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

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

EngineMode: Flipping the Perspective

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

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

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

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

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

SiteType: A Unified Wrapper

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

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

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

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

Surface Types: The Parameterization Layer

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

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

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

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

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

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

Threshold Calibration Per Mode

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

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

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

The sensitivity veto also inverts:

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

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

App-Specific Features Without Conditionals

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

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

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

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

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

The Input Struct

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

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

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

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

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

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

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

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

The Output: Same Structure, Different Meaning

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

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

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

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

What I’d Do Differently

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

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

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

The Tradeoff

Sharing an engine across three apps means accepting constraints:

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

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

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

Next in the Series

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

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

Turning Raw Weather Into a Drying Model

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

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

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

Weighted Precipitation: Not All Rain Is Equal

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

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

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

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

Rain Score Normalization

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

rainScore = min(1.0, totalPrecip / 0.75)

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

Why Intensity Matters

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

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

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

Drying Strength: The Recovery Side

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

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

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

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

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

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

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

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

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

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

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

Exposure Matters

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

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

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

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

Drying Classification

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

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

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

Combining It All: The Wetness Score

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

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

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

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

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

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

A Worked Example

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

Rain score:

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

Timing score:

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

Drying strength:

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

Wetness:

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

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

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

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

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

Residual Wetness: The Ground Remembers

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

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

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

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

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

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

What This Model Doesn’t Do

A few things I intentionally left out:

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

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

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

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

Next in the Series

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

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

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.