Weapon Authorization & Fire-Control System

The brief

The client needed centralized control over when a registered weapon can fire, and a record of what happened when it did. A policy in a binder is not a lock.

Authorization had to be decided from a live camera frame against a template the command side had already approved - not from a toggle that anyone on the ground could flip.

The challenge

A lock that is easy to bypass is theatre. A lock that fails closed in the field needs hardware, vision and operations to agree.

• A physical lock driven by a servo, defaulting to closed
• Frame capture on the device and a similarity check against the authorized template
• Roles that separate command, audit, training and the operator holding the weapon
• Logs that survive an argument later: who, when, which weapon, which frame, what decision

How we approached it

The device captures a frame and asks the platform whether that frame is close enough to the template on file. Only then does the servo release. The comparison lives on the server so templates and thresholds can change without flashing every unit.

Weapons, devices and operators are separate records. Assignment is explicit. A unit that goes offline is visible as offline, not silently trusted.

What we built

An operations console for weapons, devices, templates and roles; an API the ESP32 camera-and-lock unit talks to; and analytics over fire events, misfires and operator behaviour.

The same platform is designed to extend - without claiming these were all in the first cut - into magazine and round counting, geofenced authorization, a distinct training-range mode, armory checkout and chain of custody, tamper alerts on the lock, and after-action packs for audit. Those are scoped pieces, not a free bundle.

Results

The engagement is under NDA. We do not publish the force, unit, or any operational statistics.

In use

The system is operated by the client's own command and audit roles. Hardware, templates and access rules stay under their control.