Illustration — a steady hand resting over a glowing control dial, hills beyond
Illustration — a steady hand resting over a glowing control dial, hills beyond

The short version

  • Automatic systems re-check the world every minute. Without care, the STOP you just pressed gets overridden on the very next check.
  • FireShield records which fire you declined, so the decision holds against that fire.
  • It holds for that fire only. A different ignition arms the system normally — your STOP was never a disarm.
  • If the declined fire closes in — half the distance, or a mile nearer, whichever comes first — the decision is spent and the system activates.
  • There is a twenty-four hour backstop for a fire that simply parks nearby.

An automatic wildfire system is a loop. Every sixty seconds it asks the same question: is there a fire inside the distance this property cares about? If yes, act.

That loop is the whole product. It is also, if you are not careful, a machine for ignoring its owner.

Picture it. The system starts on its own because a fire crossed your line. You are standing in your driveway and you can see the situation — wrong side of the ridge, wind blowing away from you, crews already on it. You open the app and press STOP. The valves close.

Sixty seconds later the loop runs again. The fire is still there. It is still inside your distance. The condition that started the system is still true.

So it starts again.

You press STOP again. Sixty seconds later, again. You are now in an argument with a cron job, and the cron job does not get tired.

The fix is not the obvious one

The obvious fix is a snooze: ignore automatic activation for the next hour. It is obvious, it is easy to build, and it is dangerous — because it does not just ignore the fire you declined. It ignores every fire. Including the one that starts in the next street twenty minutes later.

You wanted to say "not this fire". The snooze heard "not any fire". That gap is where houses get lost.

FireShield does it differently. When you stop an automatic activation, the system writes down which fire you were declining, how far away it was, and when. That record scopes the decision to that fire and nothing else.

A new ignition is a new decision. Declining a fire six miles out on the far ridge is not consent to ignore a fire in the next street, and the system does not treat it as one.

Three ways the decision expires — all of them automatic

A decision that never expires is as bad as one that never holds. The window ends on its own terms, three ways:

  1. The fire closes in. Re-arm at half the distance you stopped at, or a full mile nearer, whichever the fire reaches first. Stopping at 5.8 miles is not consent at 4.7.
  2. A different fire. Your decision was about one fire. Another ignition is judged on its own merits, immediately.
  3. Twenty-four hours. A backstop for the awkward case: a fire that parks nearby, neither advancing nor going away, while conditions around it change.

Three exits, none of which need you to remember anything.

The detail that shows whether a system was built or assembled

There is a subtle failure here that is worth explaining, because how a company handles it tells you a lot.

"The closest fire" is not a stable thing. It flaps. A distant fire can top the list for a single cycle when a boundary is redrawn. A data feed can hiccup and return nothing at all for a minute.

If the system treated "closest fire is no longer the one you declined" as "your decision is spent", then a one-minute data wobble would quietly erase it — and the fire you actually declined would re-activate your system the moment it came back to the top of the list. You would be back in the argument with the cron job, with no idea why.

FireShield holds the decision through that. Another fire briefly ranking closest does not block anything for that other fire, and it does not erase your decision either. A feed blanking out does not erase it. The window clears only on its own terms: the fire closing in, or the twenty-four hours running out.

That is the difference between a feature that works in a demo and one that works in a bad week of smoke and patchy data.

A system that can be stopped but not kept stopped has not really given you control. It has given you a button.

Stop, mute, or schedule — three different tools

These are easy to confuse, so:

  • STOP during an activation declines this fire, now. It lasts up to twenty-four hours and ends early if the fire closes in.
  • Mute a fire is the considered, longer-lived version: a fire you have assessed and set aside, with no time limit but the same geometry override.
  • Schedule a start is the opposite direction — telling the system to run at a time you choose, before anything has crossed your line.

All three exist because "the fire is X miles away" is not enough information to make every decision, and the person standing in the driveway usually has the rest of it.

What to ask

  • If I stop an automatic activation, what stops it starting again a minute later?
  • Does stopping one fire leave me armed against a different one?
  • What brings the system back if the fire I declined starts moving towards me?
  • Do I have to remember to re-arm it?

The last one matters most. Any safety feature that depends on the owner remembering something during an evacuation is not a safety feature.