A hiker's last known position, before anyone calls it in
SAR Helper records where a hiker has been walking. If they are reported
overdue, the responding team has a track instead of a car park and a description.
It never dispatches anyone, and it never contacts a
team. No alert, no pager, no email. It is a database that gets looked in once a
call has already arrived through the normal channels.
That is deliberate. A system that pages a volunteer team gets
switched off after the third false alarm. This one costs nothing until the day it helps.
The problem it addresses
Most people who get into difficulty in the backcountry are not certain they are in
difficulty. They are unsure. They wander, and they usually find the trail again — and because
they are unsure, they do not want to waste anybody's time. So they say nothing, for hours,
until it is dark and they are cold and now they are genuinely lost, several kilometres from
where the trouble started.
By then the useful information — where were they when things started going wrong, and
which way were they heading — is gone. A search begins with a trailhead and a
description.
SAR Helper tries to capture that earlier, by making the ordinary act of recording a
position cost the hiker nothing at all.
The flow, step by step
Each step shows what the hiker sees and, where there is one, what a responding
team would see afterwards.
Step 1 — at the trailhead
A hiker sees a SAR Helper QR code posted at a trailhead
What the hiker sees
A weatherproof sticker on the trailhead board, carrying a domain a person can
remember and a short code identifying that particular sign.
Scanning it is the only thing the hiker has to think of doing. There is no app to
have heard of beforehand and nothing to sign up for.
The domain is the largest line, so it can be recalled hours later
without the sign in front of them.
What SAR sees
Nothing yet — and one useful thing over time. Signs learn their own position from
the hikers who scan them, so nobody has to survey where they were installed.
A scan on its own records the code and the time. Not the phone, not an address,
nothing about who walked past.
Step 2 — immediately after scanning
The scan opens the app, or the website
What the hiker sees
If the app is installed It opens straight to a check-in screen for that
sign, offering to start sharing and to take a trip plan.
If it is not — the common case A page that loads on one bar of signal.
It offers the app, and a way to send a position without installing anything.
Nothing is sent until the hiker presses something. Scanning a poster out of
curiosity does not start transmitting a stranger's location.
What SAR sees
Still nothing. A hiker who scans and walks away has not entered the system.
Step 3 — setting off
The hiker checks in, and can leave a trip plan
What the hiker sees
A single form: a position, and an optional note. The note is where a trip plan goes
— where they are going, when they expect to be back, what they are wearing.
There is no account and no sign-up. Identity is a random id the phone generates for
that outing.
Checking in is phrased as routine, because it is.
What SAR sees
A track begins. The trip plan attaches to it and stays — it is the hiker's own words
about what they intended, which is often not where they ended up, and is
frequently the single most useful sentence in a search.
Step 4 — walking
The app records a position about once a minute
What the hiker sees
One screen with a map, and an unmistakable statement of whether the app is sharing
or not. A notification stays up the whole time it is running.
With no signal it keeps recording and sends the backlog when signal returns. The map
draws the hiker their own trail, so it doubles as a way back.
Two states, ever: sharing, or not sharing.
What SAR sees
A growing track — and, if the phone stops reporting for ten minutes, a
gone dark marker. That usually means a flat battery or a valley with
no coverage. Occasionally it means something else.
Someone who used the website instead sends one position and then nothing, and the
console says so rather than implying they are still being followed.
Step 5 — something feels wrong
The hiker marks that they may be lost
What the hiker sees
One step up from something they have already done. It sends the same kind of
position, flagged, and says plainly that nobody has been notified and no rescue has
been sent.
Standing down is always the other option on the screen, and it is always first.
The only route to an emergency call in the product, and it opens the
keypad rather than dialling.
What SAR sees
The track is marked, with whatever the hiker typed attached. A hiker who checked in
at noon and flagged at four has given a search two fixes and a
direction.
Keeping the two levels apart is the entire design. A hiker offered only "I am lost"
usually sends nothing, because pressing it feels like raising an alarm.
Every screen in the app says that nobody has been
notified. It is repeated to the point of monotony, because a hiker who believes a
rescue is already coming will sit still and wait for it.
What a responding team sees
Filter by status and time, or draw a polygon on the map and ask who has been
inside it.One hiker. Name, year of birth and the note are optional and typed by the hiker —
nothing is verified, and the console says so.The route walked, oldest to newest, and the exports: GPX, GeoJSON, CalTopo,
Google Maps. Coordinates copy in decimal degrees and in degrees-and-decimal-minutes — the
format that gets read over a radio.
How a callout would go
9:04 pm
A family member calls the RCMP: someone is
overdue from the Chief.
9:20 pm
The call reaches the team through the channels it always does.
SAR Helper has played no part so far.
9:25 pm
Someone with a console login searches the name, or draws a polygon
around the area.
9:26 pm
If the hiker used it: a track. Where they started, where they were
last heard from, which way they were walking, how much battery remained, and anything they
typed.
9:26 pm
If they did not: nothing, and the search proceeds exactly as it
would have.
The last row matters as much as the one above it. This is not a system anyone has to rely
on. It is a system that occasionally saves hours.
What a team would need to provide
Sign-in
Existing Google or Microsoft accounts, restricted to the team's
domain. No new passwords.
An area
A polygon for the ground the team is responsible for. It decides
which tracks they can see, and which hikers are told they are covered.
Nothing else
No integration, no radio work, no change to how the team is
dispatched, and no obligation to look at it.
Data, plainly
Kept for
7 days, then deleted. A safety net, not a
record.
Who can see it
Only teams whose area covers the position. Hikers outside any
registered area are told, in the app, that nobody is reading it.
Identity
None. A random id per outing. A name only if one is typed.
Residency
The intent is that data stays in the jurisdiction it was collected
in, and the design routes it that way. No residency guarantee will be claimed until there
is a contract behind it — if that matters to a team, it is one of the first things to
settle rather than something to take on trust from a web page.
At rest
Free text a hiker writes is intended to be encrypted, with the keys
held apart from the database, so that a stolen copy of the database is not a copy of
everyone's private circumstances. Access is by sign-in and area, with no key for a team to
install or lose. Planned, not yet built.
Where this actually is
The app and the console are built and working; the screenshots above
are of the real thing. The hosted service they would run on is not: today it is a single
server suitable for a pilot, the console sign-in is a development placeholder, and encryption
at rest is designed but unwritten.
Saying that is better than showing a page that implies otherwise.
If a team is interested, the first conversation is about what would have to be true before
they would put real callouts near it.
SAR Helper is free, carries no advertising, and collects
nothing it does not show. In an emergency, call 911 — this system cannot.
