The part of the platform that must never fail quietly
A duress-and-response safety runtime sits at the heart of WillowCreek: raise, route, escalate, with the person's position attached. This page is about the guarantees that runtime makes, and the engineering that makes them survivable.
Guarantees, not features
Features can be configured away. These cannot. Each one is an invariant of the platform, and several are enforced below the application, at the storage layer, so that no code path, however privileged, can sidestep them.
- Priority one at origination. Every duress is P1 from the instant it is raised. Not after triage, not after classification. There is no lower-priority duress.
- Nothing can downgrade it. No client field, rule, configuration, policy or administrative state is capable of reducing a P1 classification.
- No de-duplication, no inference in the alarm path. The platform never decides that two raises were "probably the same event" or that a raise was "probably accidental". Every raise reaches a human decision.
- Escalation never silently lapses. Ladders are closed-loop and tiered; every tier either resolves or hands on. An exhausted ladder triggers an out-of-band failsafe rather than going quiet.
- Acknowledge once, stand down everywhere. One acknowledgement stands the escalation down platform-wide: every recipient, every channel, immediately. Nobody responds to an alarm that is already in hand.
- Life-safety is never gated by commercial state. No licence, billing or subscription condition can touch a life-safety route. The exemption is enforced by a database constraint, so a policy that attempts to gate incident raising is refused at the storage layer.
A ladder that cannot go quiet
Closed-loop, tiered, with a floor under it
Escalation in WillowCreek is a closed loop: each tier notifies its recipients and then watches for acknowledgement against a deadline. No acknowledgement means the ladder advances to the next, wider tier. It never waits indefinitely, and it never stops early. If every tier is exhausted without a human taking the incident, the platform triggers an out-of-band failsafe on a separate path, because the one outcome the design refuses is silence.
The ladder itself is canonical, and it isn't customer-authorable. That's a safety position: a ladder a customer can misconfigure into silence is a hazard, not a feature.
How rules and the ladder are governed →Every tier resolves or hands on. An exhausted ladder triggers the failsafe, never silence.
Built for how danger actually arrives
Staged escalation from one device
A worker entering a risky situation primes their device with one action; if the situation turns, a single further action triggers the alarm. There's no time limit between prime and trigger. Risk doesn't run on a countdown, and neither does the platform.
Man-down
Where a device reports a fall or loss of movement, the raise enters the same alarm path as any other duress: priority one at origination, no inference layer deciding it was probably nothing, a human decision at the end of it.
Presence-independent evacuation
An evacuation broadcast warns the roster regardless of the location system's state. If positioning is degraded or a person's tag is silent, they are still warned. Presence data sharpens an evacuation, but never gates one.
An escalation that survives the machine it runs on
The hard question for any escalation engine is not "does it work?" but "what happens when the process dies half-way up the ladder?" WillowCreek's answer is structural.
- Deadlines live in the database, not in process timers. The escalation ladder is not a timer held in memory. Every tier deadline is a durable record, swept continuously, so a duress mid-escalation survives a process restart and resumes at the right tier. Nothing is lost, skipped or double-fired.
- Two machines cannot double-escalate. Advancing a tier is a conditional claim inside a transaction: exactly one instance wins it. Two instances can run at once (during failover that's the normal case, not an exotic one) without duplicating a single notification.
- Honest health. Liveness and readiness are distinct, and a health source that cannot be read returns unavailable, never a plausible zero. The platform tells you it is degraded rather than looking healthy while it isn't.
Redundancy at the server level is a software property before it is an infrastructure one. WillowCreek is restart-safe and two-instance-safe by construction, with automatic database failover proven by drill, and scheduled encrypted backups whose restore path has been exercised end to end, underneath. How the platform is deployed and kept alive →
Accepted and arrived are different claims
Five delivery states, and no optimistic ones
Most systems record an outbound notification as "sent" the moment a gateway returns success. WillowCreek refuses that optimism. Every outbound message is tracked through five states (unconfigured, queued, accepted, delivered, failed), and two rules are enforced in code: a success response that carries no channel reference is recorded as failed, and delivered is reachable only from a positive acknowledgement, never assumed.
The reason is written into the specification: accepted and arrived are different claims, and the gap between them is a person not turning up. Escalation consumes these states directly. A channel that cannot confirm is treated as failed, and the ladder advances instead of waiting on a hope.
Delivered is reachable only from a positive acknowledgement. Anything less honest records as failed.
The platform keeps its own liveness clock
Devices and feeds are supervised by the platform itself, independent of what any vendor reports about its own equipment. Every supervised source is Present, Stale or Lost, and the transition is the platform's judgement, not the vendor's.
Present
The source is reporting within its expected cadence. Nothing to see, which is the point of supervision.
Stale
The source has missed its cadence. Positions from it are age-marked, and quality gating stops a stale fix masquerading as a fresh one.
Lost
The source is gone. A feed going offline raises one infrastructure alarm, not an alarm per device. Operators see the real problem, not a storm of five hundred symptoms.
A release gate that has said no
Every promotion of the platform runs an executable life-safety assurance suite against the live system: the invariants on this page, exercised end-to-end, on every release. A failure does not raise a ticket; it automatically rolls the release back. The suite has already refused a real release and rolled it back, which is exactly what it is for.
The assurance suite is an engineering control. Formal life-safety certification of a deployment (redundancy testing, operational validation, a named responsible sign-off) is a separate step, performed per deployment.
Honest gaps, never plausible numbers. A capability without a backend shows a visible gap on the screen. On a life-safety product, a convincing invented figure is worse than a question. A gap prompts one; a fake number prevents one.
Raise one. Then try to make it go quiet.
This is a working model of the escalation ladder, including the part that matters most. Kill the process mid-escalation and watch it resume at the right tier, because the deadline is a committed row rather than a timer in memory.
- t+0sNearest responderpush and voice
- +30sTeam and supervisorpush and SMS
- +60sDuty managerall channels
- +120sSite broadcastbroadcast
no open deadline
Time runs six times faster here so the whole ladder is visible without a two minute wait. The tier timings shown are the real ones, and they are configurable per site. Only a human acknowledgement can stand an escalation down, which is why the acknowledge button is the only thing on this panel that ends it.
Watch the ladder refuse to go quiet
We will raise a duress in front of you, kill the process mid-escalation, and let you watch it resume at the right tier.