Scoping calculator

How big is the box?

Tell us your tags, your locators and what you are actually trying to achieve, and this works out the server you need and why. It shows the arithmetic rather than hiding it, and it tells you which of your answers is doing the most damage.

Before you start

Tag count and locator count are not the load

They are inventory. Two sites with an identical fleet can differ by more than ten times in the compute they need, and the difference is set by three things the inventory does not record.

How often tags report

A duress badge on the 1-second position path and a motion-gated asset tag are not the same device on our side of the wire, even though both are one line on a purchase order.

How many move at once

The busy-hour duty cycle. Six thousand tags where one in ten is moving is a different machine from six thousand tags where one in three is. This is the single most sensitive number in the model.

What you are trying to achieve

Asset visibility and staff duress carry the same fix rate and completely different obligations. The outcome does not multiply the load. It sets floors, and it does that in one step rather than gradually.

Locators barely touch the server, and we will never price you on them. WillowCreek receives resolved positions from your positioning engine, which does the multilateration itself. Double your locators to improve accuracy and our ingest rate does not move. What locator count drives is the device registry, the supervision clock and the health panel, and that load is negligible next to everything else. Sizing a server on locator count is a category error. Pricing on it would be worse, because it would charge you for improving your own accuracy.

The form

Your estate, on one page

Enter totals across the whole estate. One appliance serves the customer, with every site running as a tenant beneath it, so the estate is what gets sized. Start from one of the worked examples if it is easier.

The fleet

What reports, and how much of it. This is the load axis, and it sizes the processor and the memory.

The estate

Where it all sits. This is the inventory axis, and it drives the registry, the supervision clock and the map payloads.

The rules

The biggest lever in the whole model, and the one nobody expects. A rule bound to a zone is considered only when a fix lands in that zone. A rule with no zone is considered on every single fix, everywhere.

The outcome

This is the availability axis. It does not scale the load, it sets floors, and the step between tiers is a cliff rather than a gradient.

Nothing is sent anywhere. This runs entirely in your browser.
The method

What it is actually doing

Seven steps, in order. No lookup tables, and no number that cannot be checked by hand.

  1. Sustained fix rate

    Each class of tag contributes its count multiplied by its report rate multiplied by its busy-hour duty cycle. Fixed duress points contribute nothing here: they are event-only and have no steady position rate at all.

  2. Peak fix rate, and this is the one that sizes the box

    The sustained rate multiplied by the muster factor. A fire alarm sounds, every tag moves, every tag goes to its maximum rate at once. That is the correct design case for a life-safety platform, because it is the moment the platform is most needed and least able to shed anything.

  3. Rule evaluation rate

    Bound rules divide across your zones and cost almost nothing. Unbound rules multiply against every fix. This is where a site quietly destroys itself, and the calculator refuses to be quiet about it.

  4. Write rate and storage

    Storage runs off the sustained rate rather than the peak, because a muster burst lasts minutes and does not move the annual volume. Hot history, compressed warm history, a per-site baseline for floor plans and audit, and headroom for compression jobs and a restore in place.

  5. Supervision and registry

    Every tag and every locator is checked for liveness on a fixed clock. This is where locator count lands, and the point of showing it is how small it is.

  6. Live-map egress

    Seats multiplied by visible tags multiplied by the position update. Modest at a ward, and the tier that surprises people when a wallboard is configured to show an entire district.

  7. The band, floored by the outcome

    The band is whichever of those axes demands the most, and then the outcome tier raises the floor underneath it. A duress deployment gets a standby database at every size, because it is a duress system, not because a tier was purchased.

What this is not

A scoping aid, not a commitment

The structure of this model comes straight from our own governed architecture, and it is sound. The coefficients inside it are not yet measured. Report rates, busy-hour duty cycles, the muster burst factor and the per-core throughput figures are engineering estimates, and they are waiting on a load harness that drives synthetic fixes through the real ingest path until the 3-second duress budget breaks.

Until that harness has run, every band this page produces is a planning band. We could have printed confident numbers instead. On a life-safety product an invented number is worse than a visible gap, because a gap prompts a question and a fake number prevents one.

So use this to get within range, to see which of your own decisions is driving the cost, and to walk into a conversation already knowing what to ask. Then let us size it properly against your floor plans and your real device behaviour.

Have us size it properly How a deployment runs