Silent Sentinel

Security & surveillance · 2 builds

Two entirely separate builds inside a large security business — a virtual pre-sales engineer used company-wide, and SS-CameraUI, a full command-and-control platform for the Jaeger MK4 camera system.

Silent Sentinel pre-sales assistant — how a tender response is drafted, reviewed and signed off by an engineer
Build 01

Virtual Pre-Sales Engineer

AI assistant

A specialist pre-sales engineer's method, encoded — available to everyone in the business at once, with no interface of its own.

The challenge

Writing a full technical proposal — a 100-page document with detailed compliance analysis — took a specialist engineer roughly two weeks, and only a handful of people in the business could do it. Everyone else waited on them.

The knowledge that made those documents correct was scattered: detection-range modelling, sensor and platform specification, product selection rules, integration reference and field-maintenance procedure. Getting a consistent, compliant answer meant getting the right person.

What was built, and why it was built that way

A virtual pre-sales engineer — not a document search, but the engineer's method: a curated, versioned knowledge base covering the range models, the sensor and platform specifications, the selection rules, the integration reference and the maintenance procedures, driven by an instruction set that decides how each class of question is answered.

Thirteen answer modes, each with a fixed output shape, so a range study, a competitive comparison and a tender response always come back in the form the business expects. A hard rule set governs what it must never say — pricing never leaves it, and restriction rules on what can and cannot be configured together are load-bearing, not advisory.

Every change is versioned and has to clear a scripted regression and adversarial test suite — ninety-two scenarios, twenty-two of them hostile prompts written to make it break its own rules — before anyone approves it going live.

Three decisions shaped it, and two of them were constraints rather than choices. The platform it runs on accepts ten source documents and no more, so the knowledge could not simply be poured in — it had to be edited down to ten documents that between them answer the questions the business actually asks. That cap turned out to be useful: a curated set is checkable, and a dump is not.

The second was to make pricing a rule of the system rather than a habit of its users. Commercial figures are stripped from everything it produces, because a proposal assistant that can quote a number is one bad prompt away from committing the business to one.

The third was to keep a person in the loop at the point of release. The test rig runs against a staging copy, never the live assistant, and promoting a version is a deliberate act someone takes — so a regression can never reach the sales team because a pipeline was feeling confident.

What it meant

A two-week job became a ten-minute one, and it is now the go-to across the business.

People stopped computing the information and started verifying it — a fortnight's work ready before the meeting, and one specialist's judgement now reaching everyone who needs it.

Build 02

SS-CameraUI

C2 platform

A complete command-and-control platform for the Jaeger MK4 long-range thermal and daylight camera system — control, analytics, evidence and an AI layer that can take the watch.

The challenge

The camera is a long-range thermal and daylight system with a deep control surface — lens, stabilisation, detection, classification, platform geometry — reached through an on-board web panel, one camera at a time.

An operator running a live scene had no single place to do the job: watch both sensors, steer the camera, tune the picture for the conditions, work the detections, keep evidence and check the health of the hardware. That is a command-and-control problem, not a video-viewer problem.

Two properties of the hardware shaped everything that followed. The camera acknowledges commands it has not applied, so any interface that treats an acknowledgement as proof will show an operator a setting that never took. And the written protocol is wrong in places — some documented controls were never built, and the software had to be corrected against live hardware rather than against the specification.

The cameras are not uniform either. Different generations of the camera answer on different connection routes, expect different message framing, and expose their configuration in different shapes. An operator should never have to know which one is on the other end of the cable.

What was built, and why it was built that way

SS-CameraUI is a native Windows platform built for that job — one screen carrying live video, full camera command, on-frame analytics, evidence handling and maintenance, with an AI operator layer wired into all of it.

It has been built out across 390-plus versions with around 2,600 automated tests behind it, verified against real cameras rather than a simulator.

MAST built it as a desktop application that talks straight to the camera over the local network — no server, no browser, no cloud leg between an operator and a camera they are steering. A hosted console would have been faster to write and would have put a network hop and a third party inside a live control loop.

The settings screen is not a list the app decides in advance. On connect the console fetches the camera's own configuration off the unit and builds the screen from what it finds, so a camera on a different firmware generation gets a different and correct screen. The alternative — a hardcoded catalogue — is right on the day it is written and quietly wrong after the next firmware release.

Where the screen has to tell the truth about the hardware — stabilisation on, this profile selected, that overlay showing — the console confirms the change instead of assuming it. It sends the command, waits, reads the value back, and holds the interface at the old state if the camera never actually took it. Two shortcuts were tried and both were rejected: re-sending the write when the read-back disagreed hammered the camera and stuttered the live video to black frames, and trusting the acknowledgement made the interface lie about the state of the hardware. Writing once and then polling patiently is what survived.

At connect the console works out how to talk to the camera by trying the routes in order until one answers — and the one that answers also tells it which generation of hardware it has, which in turn selects the settings shape and the command paths it will use. The operator configures none of that. A retry gate separates "this route is wrong, try the next" from "the camera understood and refused", so a legitimate refusal never triggers a pointless re-detection sweep.

Live picture
Thermal and daylight feeds side by side, a detachable second viewer window, per-feed overlays and one telemetry bar carrying bearing, zoom, focus and connection state.
Camera command
Continuous pan, tilt and zoom on a speed curve with a dead zone and a hard emergency stop; focus and autofocus; keyboard control; saved positions with recall; and a move-to-bearing command.
The whole settings surface
The console reads back and drives the camera's own control set — lens, stabilisation, digital zoom, contrast and defog, palettes, image flip, motion and change detection, classification, overlays and platform configuration — in plain-English form, with a change history, saved scenes and backup and restore.
Reading the camera efficiently
Three ways of reading the camera sit behind one screen, ranked by cost. The console asks for the whole set in a single request first, falls back to walking the rows one at a time when that returns nothing, and stops walking after a run of failures rather than storming a camera that is not answering. While the operator is watching the settings, only the handful of values that actually move — position, zoom, focus, stabilisation — are re-read on the tick.
Confirmations that reason about consequences
Before a write the operator cannot walk back, the console stops and says in plain words what is about to happen. The list is chosen by whether the change can be undone rather than by how technical it sounds: zeroing or resetting the motor controller, travel limits — because reverting one needs a number nobody wrote down — the setting that makes the platform ignore movement entirely, and one thermal interval only at the single value that switches its recalibration off. The dialog opens with Cancel selected.
What leaves the machine
Sensitive values are replaced before anything is written to the traffic log, the on-screen activity log or a support bundle, so a credential typed into a camera setting never lands in a file that goes anywhere. Saved connection details are encrypted at rest by the operating system's own keystore, scoped to the person who saved them.
Detection analytics
Camera-side detections are parsed and ranked by class, confidence and how central they are to the frame, then presented as a candidate rail the operator selects with a single key. Snapshots fire automatically on a classified detection, with per-track cooldowns and an hourly cap so a busy scene cannot storm the evidence folder.
Image science
Every frame is scored for sharpness, contrast, noise and exposure distribution. A scene classifier names the dominant condition — low light, haze, motion blur, high dynamic range — and offers a ranked set of enhancements the operator can apply and revert: contrast equalisation, dehaze, exposure fusion, tone mapping, and lucky-imaging frame selection that beats heat shimmer at long range by picking the sharpest frame out of a burst.
Visibility and range
The haze signal already computed for dehazing is turned into a visibility estimate in metres, so the operator has a number for the conditions rather than an impression. Target range is estimated from tilt geometry and mount height.
Situational awareness
A map showing the camera's position, live bearing and field-of-view wedge. Point at something and ask the assistant to mark it, and it fixes that target's position from the camera's location, the bearing it is looking down and the range. An automated sweep stitches a full cylindrical panorama of the scene, seam- and exposure-aligned.
Evidence handling
Snapshot bursts, a rolling clip buffer, and a recordings library with thumbnails. Every file is stamped in UTC and never overwritten — evidence integrity is a rule in the code, not a convention.
Maintenance and diagnostics
Cameras are discovered on the network; a health dashboard pulls processor load, temperature and error counts off the hardware; logs are retrieved on demand; support bundles are redacted before they leave the machine; and connection profiles are stored encrypted.
The AI layer
An assistant built into the console with around fifty tools wired directly to its own control surface. The operator types or speaks — "zoom tight", "move to bearing 120", "run autofocus", "mark that boat", "take the watch" — and the platform acts. It can look at the current frame and describe what is in it, propose and apply image improvements, and run an autonomous patrol across the saved positions, snapping frames and alerting the operator on a person detection until control is handed back.
SS-CameraUI showing live thermal and daylight feeds side by side with camera controls
Both sensors live in one view, with the command surface around them — steering, lens, detections and telemetry.
SS-CameraUI — lens and image controls open on both sensors, above a stitched cylindrical panorama of the whole scene
Zoom, focus, contrast and digital zoom driven live on each sensor — and beneath them the automated sweep's stitched panorama, which the operator clicks to slew the camera to that bearing.
SS-CameraUI camera settings surface — camera, lens, video tracker, stabilisation and digital zoom, each read back with its live values, per sensor and per pan-tilt head
The settings surface: the camera's control set — lens, tracker, stabilisation, digital zoom and the rest — read back in plain English with its current values, per sensor and per pan-tilt head.
What it meant

One operator, one screen, doing what previously meant several tools and a specialist's eye for the picture.

The camera can be commanded in plain language, tunes itself to the conditions on advice rather than guesswork, and can hold a watch on its own — handing control straight back the moment it is asked.

What the operator sees on screen is what the hardware actually did, because the console goes back and checks — and one build drives more than one generation of camera without anybody being told which is which.

The stack
Windows desktop (WinUI 3 / .NET 9)Live thermal + daylight videoCamera command protocolRead-back-verified writesSettings catalogue built at connectOn-frame analyticsImage-enhancement pipelineMapping + range estimationIn-app AI assistant (~50 tools)Voice commandKnowledge-base assistantCompliance analysis

Half an hour to see what an exacting fit looks like for your business.

Start a conversation
MAST
consulting
MAST Consulting · Applied AI for real workflows
matt@mastconsult.co.uk · MAST Consulting is a sole trader.