Police equipment lifecycle — three tiers and one state trail per item

The situation

A public-security equipment department is responsible for kit held by three levels of the same organisation: the provincial headquarters, the detachments beneath it, and the teams beneath those. Equipment is bought centrally, issued downward, moved between units, repaired under warranty, and eventually retired or converted to another use. Before the system, each level tracked its own part of that life in spreadsheets, which meant that no level could see the state of the others.

The straightforward request is an asset register: one row per item, with its current holder and its current status. That is what most asset systems are, and in a three-tier force it answers almost none of the questions that actually arise.

The call we made

Record every item’s state history, not just its current state. An asset register tells you where an item is today. It cannot tell you who signed for it, when the transfer happened, whether the receiving unit confirmed it, or whether its warranty runs from purchase or from issue. In a force those are the substance of equipment management, because accountability is personal and historical. So state changes are recorded as events — stocked, transferred, received, fault reported, repaired, warranty claimed, retirement requested — and the current state is a projection of that trail rather than a field that someone overwrites. When an inventory check turns up a discrepancy, the trail is the evidence.

Two-stage approval for retirement and conversion. Retiring equipment is irreversible, and in a force it is also an accounting act: the item leaves the books, and the number has to be justified. One approval is not enough, because the officer who can physically inspect the item is not the officer who can authorise the write-off. Retirement and conversion therefore pass two stages — the detachment staff officer first, then the provincial headquarters — and both are recorded. We could have collapsed this into a single approval to save clicks; that would have moved the risk out of the software and into an audit.

Stock warning belongs to a department and an equipment type, not to the equipment. “Low stock” is not a global property. A team’s minimum for one item and a detachment’s minimum for another are different numbers set by different people. The threshold is therefore a property of the pair, and the warning fires against it.

A fourth decision was about adoption rather than design: opening balances had to arrive by Excel. A force starting with existing inventory will not type thousands of records into a new system, and if the first weeks are manual entry the system is abandoned before it is useful. Template download and bulk import were treated as core features, and printing was kept because the inventory process still ends on paper even when the record starts digital.

What we built

Three-tier structure, with equipment passed between levels and receipt confirmed by the receiving unit.
Registration by equipment number, with template download, Excel import and printing.
Transfers from headquarters to detachment and from detachment to team, each with a receiving step.
Fault and incident recording, with handling and query across the force.
Warranty handling tied to the item’s recorded history.
Retirement and conversion with two-stage approval and a recorded reason.
Firearms and ammunition managed alongside general equipment, with the stricter handling that implies.
Stock warnings set per department and equipment type, raised automatically against the threshold.
Dictionary maintenance and role-based authorisation, so that access follows the post, not the person.

Result

The department can answer, for any item, where it is, who holds it and how it got there. At inventory time the question changes from “do the sheets agree” to “which link in the chain is unconfirmed”, which is a much shorter conversation and one with an answer.

The discipline the two-stage approval imposed is the part that outlasted the project. Every retirement now carries two named approvals and a recorded reason, so the annual figures can be defended without reconstructing the reasoning from memory.

For a force, the value is not that the system is a database of equipment. It is that accountability is traceable at the level where it is enforced — the detachment and the team — while the headquarters keeps the aggregate view it is answerable for.

If your equipment lives in more than one level of an organisation, a flat register will tell you what you own. It will not tell you who is answerable for it.

Screens from this system are not published. It runs on client infrastructure with client data, so we show it live instead: a short screen-share walkthrough under NDA, on a system we demonstrate rather than a screenshot we sanitised. Ask for it in the first call.

Technology

Stack	Vue 3 · Element Plus · Spring Boot · MySQL
Delivery model	On-premise delivery
Client	A public-security equipment department (name withheld)
Status	Delivered

What we cannot show

Force structure, equipment quantities, firearm and ammunition records and current inventory levels are operational data and are not published. Interface screens from the delivered system are not shown.