Rules & automation

Automation you can trust with an alarm

Today, WillowCreek runs a canonical escalation ladder that a customer cannot misconfigure into silence, shaped to each site by configuration. Everything is tested in an included lab before it goes anywhere near live operations.

What runs today

A ladder you cannot break, shaped by configuration

On most platforms, the escalation logic is whatever the last administrator left behind. WillowCreek takes a different position: the escalation ladder is canonical, and no customer can author it.

The canonical escalation ladder

Closed-loop, tiered escalation with an out-of-band failsafe: the same verified ladder at every deployment, gated by the life-safety assurance suite on every release. Its structure is not editable by any customer role, because a ladder a customer can misconfigure into silence is a hazard, not a feature.

Site-scoped configuration

What is yours to shape: who sits in each tier, which response groups exist, which zones mean what, which channels carry notifications and to whom. The behaviour that must never fail stays fixed. The knowledge of your site (people, places, vocabulary) is configuration.

Why we built it this way. An escalation ladder is the thing standing between a raised alarm and a person turning up. We would rather ship one ladder that cannot go quiet than a rules engine that lets every site invent its own way to fail. Authoring comes, but it comes with the guardrails described below, not before them.

Design position

Rules belong at the site

A rule is written in a site's own vocabulary or it is written wrongly. "When a duress fires in ED" means nothing at a site where the department is named Emergency, and everything at the one where it isn't. That is why the platform's design puts rules at the site, referencing the site's own zones, roles and names, with every change reporting upward to the estate rather than being imposed downward from it.

You can see the same principle running today: zone names, response groups and terminology are all site configuration, not platform code. Industry-agnostic by design starts here.

Design principle

Every rule must explain itself

The principle that governs all rule behaviour on this platform, present and future: a rule's plain-language explanation is generated from the rule body itself, never typed alongside it, so the explanation cannot drift from actual behaviour. There is no path by which a rule does one thing and claims another.

The lab · included today

Nothing meets live operations untested

A lab environment with every deployment

Every WillowCreek deployment includes a lab environment alongside the live platform. It's part of the service, not priced separately. The lab is where configuration is developed, scenarios are tested, integrations are exercised, staff are trained and upgrades are rehearsed before anything touches the system your responders depend on.

Simulation carries a hard guarantee: simulated events are incapable of reaching a real outbound channel. Not discouraged by convention. Incapable. You can run a full duress scenario end-to-end in the lab and no pager, handset or phone in your facility will ever hear about it.

Lab scenario testing training · rehearsal simulated duress upgrade rehearsal · adapter work no path across Live real incidents escalation ladder real outbound channels

Simulated events are incapable of reaching a real outbound channel. Incapable, not discouraged.

Acting on the world

Guarded outbound actions

Some automation reaches into the physical world: releasing a door, initiating a lockdown, resetting an alarm panel. The platform's rule for that class of action is strict, and it applies to every adapter that will ever carry one.

  1. Explicitly enabled, per site

    No outbound action that affects physical security or life safety exists at a site until someone switches it on there. Nothing arrives enabled.

  2. Permission-scoped and confirmed

    Invoking a guarded action requires the specific permission for it, and a confirmation: an operator states what they are about to do before it happens. A rule cannot invoke one unless it has been explicitly authorised to.

  3. Audited, every time

    Who invoked it, under what authority, against which incident. It all lands on the same tamper-evident audit chain as everything else the platform records.

  4. Never above the interlocks

    The platform never assumes authority over an external system's own safety interlocks. A door controller's fail-safe behaviour and a fire panel's own logic remain sovereign. WillowCreek asks; it does not override.

How external systems attach →

Test it in the lab before you trust it live

Every deployment includes a lab. Bring a scenario you actually worry about, and run it where nothing real can hear.