Every alarm arrives
as one thread, not
four loose records.

What the operator gets

• One queue for calls, alarms and events. They compete for the same attention, so they sort in the same list, in the priority the site configured.
• Two monitors, filled automatically. PREVIEW follows the ringing call; ACTIVE follows the answered one. Audio and video recording state show on the tile itself. When there is no picture — nothing happening, a station without a camera, a camera still connecting — the monitor shows a security-camera symbol rather than a sentence, and the first real frame replaces it. It is the same symbol on every monitor in the product — Dashboard and Maps, the surveillance walls, the incident workspace, the station preview in administration — drawn once and shared, so an empty pane means the same thing wherever the operator meets it.
• Keyboard-first. Enter acknowledges the row marked NEXT; D releases a door; M opens the map at the caller. The console tells you when a key is refused rather than ignoring it.
• Reason capture that survives. The comment is written against the event, not the queue row, so an operator-ended call keeps its reason.
• Calls survive navigation. An invisible shell page holds the voice session, so moving to Maps or Surveillance mid-call does not drop it.
• The site is a link. A site name in the queue or the history opens that site’s information — levels, plans, rates, apps — in its own window, on alarm rows too. It opens on the press, so a queue that refreshes every second cannot swallow the click.

Live figures on the tiles

• Waiting · Total today · Average response · Average duration · Answered % · Active · Alarms active · Incidents active · Unacknowledged · Automation failures
• Scoped per operator: what a desk sees is what its queues and permissions allow.
• The row folds away on the Dashboard and on Maps, into a single line that still carries every number in its colour — so a folded row never hides a waiting call. The choice is kept per operator, so two people sharing a desk each keep their own.

Placement is engineering, not code

• Drag the pin, and it stays. Alarm points, help points and cameras are placed onto the site plan by an engineer in the browser. The position travels with the event from then on.
• Country → State → Site → Level. One directory shared by Maps, Surveillance and Announcements, so the same tree means the same thing everywhere. Each level carries a code, a name and a description, and an operator sees the description on the level itself.
• Floor plans and street maps. Indoor levels sit on uploaded plans; sites sit on a real map so a remote depot is a place, not a row.
• Camera on the pin. An alarm carries the camera bound to its point, so ACTIVE and PREVIEW fill from the map without the operator hunting the tree.
• Scoped visibility. Operators see the sites they are responsible for; a supervisor sees the estate.
• A status that means something. An intercom exchange reports a station’s line FAULT and nothing else, so a station is shown red on a fault and, the rest of the time, with the last moment it provably worked — “last heard 2 h ago” — rather than a green dot nothing stands behind.

A plan that belongs on the console

• Whatever was uploaded, in the console's colours. A floor plan is whatever the site had — a white CAD sheet, a bright render, a photograph — and on a dark control-room screen it was the brightest thing there. By default it is now redrawn in two theme colours: the sheet becomes the console background and the lines are drawn in its blue. Measured on the reference plan, the sheet lands on exactly the stage colour.
• Four styles, chosen per level. Blueprint for drawings, Tint for photos and renders (one colour, light and dark kept where they were), Dimmed for a plan whose own colours mean something, or the original. With a strength. An administrator sets it; operators see it and cannot change it. The same level looks the same on Maps and on Announcements.
• Only the picture changes. The style is applied to the plan image alone, so pins, zones and every click sit above it exactly as before. Zone boundaries are white dashes, which read clearly on any of the styles.
• Flat, or laid back in 3D. The plan can be tilted into a ground plane and walked round, with every pin standing upright on it and still answering a click. An administrator saves the angle a level opens at. Placing devices is always done on the flat plan, because on a tilted one the point you click is not the point that would be saved.

The tab gives way to the plan

• The plan has a floor. Every pane on this tab used to size itself against the window alone, none aware of the others, and on a 1366×768 screen the plan was what gave — pins still drawn, on a stage a few dozen pixels tall. The plan now keeps a minimum size and the statistics row, queue band, event history, tree and monitors yield around it, each down to its own drag minimum, with the operator's saved sizes returning the moment there is room for them.
• One job per tab. Zones, stored messages and Broadcast have left Maps — they are the Announcements tab's work, and here they were squeezing the plan and painting over Event History. The two monitors now fill that column and share it on a divider of their own.
• Answer from the map, and it is a real answer. A call taken on the map picks up in the browser first, exactly as it does on the Dashboard, so the operator has audio and the call is recorded — wherever on the console it was answered.

Built for the link you actually have

• One upstream per camera, not per viewer. Six operators on the same camera pull one stream; the frame cache serves them all. A wall of thirty-six tiles does not become thirty-six pulls.
• LAN first, tunnel second. Each tile says how it got here — LAN direct, or GW through the site gateway — so a slow tile has a visible reason instead of a shrug.
• A stall is not a shrug. A watchdog notices a frozen picture and reconnects with backoff; a stream that 404s is treated as broken, not retried forever.
• Named layouts assigned to operators. Night shift gets its wall, days get theirs. An operator can remove a tile from their own wall and get it back from the camera tree.
• Any camera source. ONVIF/RTSP, MJPEG with Digest auth, local USB, an uploaded file, or a YouTube live stream re-resolved on reconnect.
• Pan, tilt and zoom from the sidebar. An eight-way pad, zoom, speed and presets under the camera tree, naming the camera it drives. Hold to move, release to stop — and the server stops the camera itself after two and a half seconds whatever the browser does, so a dropped link cannot leave a camera turning. Moving a camera is its own permission. Axis, Dahua and Hikvision are built in, with a URL template for anything else.
• Health you can see. Per-camera FPS badge, credentials and resolution checks, staggered wall start so the box is not hit by all tiles at once.
• Online means video is arriving. A camera the recorder or a live view is receiving frames from is online, and is not knocked on at all — the extra connection is what made busy cameras look dead. Only without that evidence is the camera asked directly, and one failed answer is a strike, not a verdict: offline takes two in a row.

A person is a presence. An object is an arrival.

• People are boxed while they are in shot. That is what an operator watching a corridor wants.
• Objects are boxed when they turn up, and then they stop. A car park holds forty cars all day and a concourse holds a bin, a bench and a bicycle rack — boxing all of them permanently is not an alert, it is wallpaper, and an operator who sees forty boxes every time they look stops seeing any of them. The bag that was not there a minute ago gets a box; the forty cars do not.
• Which means the server knows what was already there. Each object is followed frame to frame, by overlap where it is still and by where it could plausibly have moved to where it is not — so a bag being carried stays one arrival instead of becoming a fresh one every second.
• Three colours, so the wall can be read across a room. Green for a person, amber for something that has just arrived, red for a threat.
• And the colour of the thing itself. “A bag” is not a description anybody can act on; “a red bag” is. Each arrival records the dominant colour of what was boxed, read from the middle of the box so the floor behind it does not count, and the log can be filtered by it.

What counts as worth a box is the site's decision

• A watch list, per site. Knives, bags, phones, vehicles, and anything else the loaded model can recognise. The list offers only class names the model actually knows — a name it has never heard of matches nothing, silently, which on a watch list is indistinguishable from “none seen today”.
• Per camera, not per wall. Detection is switched on for the cameras that matter. An unflagged tile is never even asked about.

Firearms: measured, and switched off until a model earns it

• The everyday model cannot do it. It recognises eighty ordinary things — a knife and a pair of scissors among them, but no gun. No threshold and no longer list produces one; it takes a model trained for firearms, which FusionX can load alongside as a second pass on the same frame.
• The one tried here did not earn its place. Over 189 consecutive frames of office footage containing no gun, it flagged a gun in 8 of them — one false alarm every twenty-odd seconds while anybody was in shot — at 62–72% confidence, and on live cameras it reached 85%, once on a blank wall. A threshold cannot fix a model that sure of nothing, so firearms are off the watch list on the reference install and the second model does not load at all. A false firearm on a control-room wall is not a cosmetic error.
• Still the site's decision, now an informed one. The class is offered in the watch list marked unreliable, with that measurement beside it, rather than hidden or quietly left on. A better model can be dropped in and measured the same way.
• A threat stays boxed while it is there. The one exception to the arrival rule, for a knife today: an operator who looks away for fifteen seconds must not come back to a tile with no box on a threat still in shot. Only the arrival raises the event.

Every box, logged — and judged

• A detection log. Every object the wall has boxed: when, which camera, what, what colour, how confident, whether it raised an incident. Filter by time, camera, object, threats only, or review state.
• Half a minute of video on every row, a third of it before. An arrival is the moment something is already there, so the useful seconds are the ones leading up to it. Nothing is cut or copied: the player is handed the recording and an offset, so a clip costs no disk.
• An administrator says whether it was real. A confidence is what the network believes, not whether anything was there. The false-alarm rate is reported out of the detections actually reviewed, and not at all until something has been — “0% false” on a log nobody has checked would read as a model that works.

Analytics that cannot eat the box

• It never opens a camera. Detection reads a frame that is already flowing because somebody is watching that tile. An idle wall costs nothing, and analytics can never become the reason a tunnelled site starts paying for bandwidth.
• One inference per camera, shared. Six operators watching the same view get the same boxes; the model runs once, and people and objects ride the same pass.
• The CPU is the constant, the rate gives way. Ask for more cameras and each one's rate drops so the total work stays around one core — measured, not guessed.
• Detection is an event, not just a box. A person arriving where nobody was raises detection.human; an object turning up raises detection.object with the object's name and whether it is a threat. Both fire once per arrival, not once per frame, so a rule can act on them without drowning.
• The models live in the analytics service, not in the web process, so the console never shares memory with them.

Capture

• Audio and video, per station. Recording is switched on per station and per call type; the console shows a live mic and camera badge so the operator knows what is being captured.
• Recording starts at ring, not at answer — the seconds before someone picks up are usually the ones that matter.
• A replay belongs to one call. A recording is matched to the call whose own ring-to-answer moment it started in, not to whatever overlapped it, so two calls on the same station minutes apart cannot borrow each other's audio and a call back plays its own recording rather than the one before it.
• Storage that stops before the disk does. A configurable cap with automatic purge, measured on the real volume.

Audio to text

• Speakers are read, not guessed. Transcription runs per audio channel, so "caller" and "operator" are facts. Older recordings whose speakers were inferred can be re-transcribed in place.
• Language detected automatically, with the confidence and detected language recorded alongside the text.
• Intent detection. Configurable phrase sets classify what a call was actually about — medical, abuse, trespass, fault — and surface it on the transcript and in reporting.
• Searchable evidence. The transcript is attached to the call, the incident and the report, so an event is findable by what was said.

Configured, not compiled

• Alarm types are rows. Name, ID mask, priority tier, queue colour and reset behaviour are edited in the browser and take effect without a release.
• Points carry identity. Each physical input is a named point with a site, a level, a map position and a camera — so an alarm arrives as a place, not a code.
• Acknowledgement is authoritative. FusionX sends the acknowledgement frame that names the alarm being acknowledged, and shows a pending state until the exchange confirms it. It never claims an ack it did not get.
• Raise and clear cannot cross. Each occurrence carries a key, so a clear that arrives during a raise cannot close the wrong one, and duplicate notifications are impossible by construction.
• Nothing is left standing. A reaper closes alarms whose clear never arrived, so an old alarm cannot sit lit on the wall for a week.
• Isolated from call handling. A bad alarm configuration cannot break the code path that carries a live call.

The workspace answers one question

• Where, what, and what was done — side by side. The plan fills its pane and centres on the alarm point, the camera bound to that point is already open, and the details column carries owner, severity and the state of the source. Where there is no camera to show, the pane says so in the incident's own terms — an incident opened by hand has no alarm point to blame.
• The owner has a face. The incident list carries the owner's photo between the title and the severity — their initials in their own colour if they have no photo, an empty ring while no one has taken it. It is the same face the timeline draws, so one glance down the list says who holds what.
• Thirty seconds before the alarm. One button replays the recorded video from just before it fired, with the wall-clock time on the picture and a marker at the exact moment of the alarm — because the useful question is what happened in the run-up, and the live view cannot answer it.
• An append-only timeline carrying device events, policy decisions, automation results and every operator action, in one order, each attributed.

Six states, and only forward

• OPEN → ACKNOWLEDGED → IN_PROGRESS → RESOLVING → RESOLVED → CLOSED, each stamped with who did it. A closed incident cannot be quietly reopened and edited.
• Which alarms become incidents is a setting, not a rule of the software. Every alarm type carries a Create an incident switch: fire and duress on, station faults off. An alarm-only type still queues, sounds, acknowledges at the exchange and fires rules — it simply never becomes tracked work.
• An operator can overrule it. Raise incident on the alarm row promotes the one that turns out to matter. It reuses the engine's own correlation key, so it cannot produce a second incident for a point that already has one, and the timeline records that a person chose it.
• Or open one by hand. For what no device raised — seen on a camera, phoned in, walked up to the desk — New incident takes a title, a type (security, suspicious activity, fire, medical, access, welfare and more), a severity, the site and level. The reference is assigned in the same sequence as every other incident, the timeline says a person opened it, and a double-click is still one incident.
• Truthful automation status — requested, sent, confirmed, failed, timed out. "Sent" and "confirmed" are different words on purpose.
• It owns nothing and executes nothing. If the incident layer fails entirely, the alarm still reaches the operator.

Nine things that can fire a rule

• alarm.raised · alarm.acknowledged · alarm.cleared
• call.ringing · call.answered · call.ended
• call.door_opened — the exchange confirming a door moved, not FusionX confirming it asked.
• call.unwatched — a call ringing or an alarm standing with nobody watching the queue. The one trigger about something that goes on being true.
• detection.human — a person arriving in a camera's view.
• detection.object — an object arriving in a camera's view, with its name and whether it is a threat.
• access.granted · access.denied · door.forced · door.held_open and twelve more door, lockdown, reader and controller events from the access control system — with steps to open a door for a moment or change its mode, confirmed only when the door reports it.

Design decisions worth knowing

• Nothing arms itself. New rules are created in dry-run. There is a Test run button, and nothing reaches a device until someone deliberately arms it.
• No branching. A rule engine that can branch is a rule engine somebody has to debug at 3am. Two rules with different filters say the same thing and can be read at a glance.
• Rules latch and stand down. A rule that switched a strobe on holds it until its reset event arrives — or an admin presses Reset — and its own notifications close themselves at the same moment.
• Rules can call rules, to a hard depth limit, so a shared procedure is written once.
• Steps run in order, or all at once — whichever the procedure is.

Supervise and command, never decide

• The access system stays in charge. Cards, PINs, schedules and access rights live in the access control system. FusionX stores no credential, and an event that carries a card number has it dropped before it is stored.
• One vocabulary for every brand. Access granted and denied (with the reason: unknown card, expired, out of hours, anti-passback, wrong PIN), door opened, closed, forced, held open, locked, unlocked, mode changes and lockdown, reader and controller health, all arriving as the same events whatever the brand.
• Doors on the map. A door sits on the floor plan with its live state, its camera and its intercom. Its card shows recent events and the door controls. A door not yet placed is offered by its name, ready to drop onto the plan.
• The DOOR button knows the door. When the calling intercom is bound to a door, the operator's door release goes to the access control system, and the console shows whether the door actually opened.
• Confirmed, not assumed. A command is sent, acknowledged by the access system, then confirmed only when the door itself reports the change. A command past its deadline is never sent, and every command is written to a tamper-evident, hash-chained log.
• Rules and incidents. Door and access events trigger rules: open a camera, page a supervisor, unlock a door for a moment, change a door's mode. A forced or held door raises an incident tied to that door.
• The customer's off switch. Each access system has a switch that stops all door commands from FusionX while events keep flowing. Operators see only the sites they are assigned.
• Proved on site. "Test connection" checks the address, the login, the doors and the event feed without sending a single command.

Announce the way operators think

• Zones are the unit. "Announce to the East platform", not a list of device numbers. Speakers can still be added individually for the odd case.
• Stored messages and text-to-speech. Type a line, get an announcement — with a chime prepended and loudness normalised so every message lands at the same level.
• Live push-to-talk from the browser to the zone, no handset required.
• A scheduler with real recurrence. Weekday openings, monthly test tones, one-offs — armed, paused, or run now.
• Import and export. Zones, speakers and messages move by spreadsheet, with a dry run that shows what would change before anything is written.
• Rules announce over the same path an operator does, so an automated evacuation sounds exactly like a manual one.
• Only what belongs here. Each stored message can be shown to operators or kept out of their list with one click, so nobody picks from announcements meant for another site. Hidden is not deleted: schedules and presets still use it.

One copy each

• Per-recipient rows. Dismissing yours does not clear anyone else's, and the system can answer "who has actually seen this".
• Toast, sound and badge on the console, with a mute control the operator owns — and a visible notice when the browser has not yet allowed sound.
• They close themselves. When the rule that raised a notification stands down, its notifications close with it. No stale card left on a screen at 4am.
• Notifications are history. A rule whose only step is a notification still fills Event History — the record does not depend on someone also configuring an audit note.
• Outward too. The same event can go to an external system by webhook in the same run.

The queue is yours to shape

• Call types, tiers and colours are data. A site decides what outranks what, and what colour it wears in the queue, without a software change.
• Multi-queue operators. A desk subscribes to any number of queues; the pilot queue is derived from live subscriptions rather than hard-coded.
• Answer in the browser. WebRTC audio with a media relay for the sites that need one — no softphone to install, no handset to maintain.
• Two call sources, one queue. Exchange calls and SIP-only calls appear side by side, each badged with where it came from.
• Each operator works the way the site does. User Management sets every operator's type: a FusionX FreeSWITCH user answers SIP calls in the browser with no exchange at all; a VirtuoSIS SIP user answers in the browser through their own SIP line on VirtuoSIS, with call data over ICX; a VirtuoSIS desk answers on the Commend handset, with call data over ICX.
• Direction is recorded, not assumed. Incoming and operator-initiated call-backs are distinguished, and both reach call history.
• Controls that mean something. Answer, cancel, hold, mute and door release — and the door release reports whether the door actually moved.
• A call back that cannot connect says why. An exchange will not deliver a call back to a desk whose line is already ringing, and that used to be a call that simply stayed silent. Now the console names the call ringing the line and offers to clear it and call back in the same moment; it auto-answers only the call back’s own leg, never whatever else happens to ring.

FusionX's own SIP server

• Devices register to FusionX directly. Each SIP intercom, speaker or phone has its own extension and a password FusionX generates and stores encrypted. Add one, add a numbered range in one step, or import a spreadsheet with a dry run first.
• A setup sheet for every device. Everything to enter on the device itself: server, port, extension, password and codecs (Opus, G.722, G.711).
• The right address for every way in. A device on a site's LAN registers to that site's gateway or site VM. A device with no gateway connects over the internet with TLS and encrypted (SRTP) audio. Several sites and several gateways each get their own address, so calls and audio always find the way back.
• Live status. The device list shows which devices are registered right now, from which address and which device, whichever way in they use.
• Queues with two behaviours. Pick: every subscribed operator sees the call and whoever answers takes it. Distribute: FusionX rings the free operators one at a time, longest idle first. The caller hears ringback while waiting; a call waiting too long goes to an overflow queue or extension.
• Same console, same controls. SIP calls appear in the operator queue beside exchange calls, badged by source. Answer, hold, mute and door release work the same, and an operator can call a device from the console.
• Video from the device or a camera. A device shows its own SIP video (H.264), or any camera bound to it.
• SIP trunks to other systems. Connect a PBX, a carrier or another system, registering with a username and password or trusted by address. Incoming numbers route to a queue or extension, each number on its own if needed; operators and devices dial out with a prefix, presenting the caller ID you set.
• Announcements reach them too. Public address plays to SIP devices, trunk numbers and exchange zones in one announcement.
• Side by side with VirtuoSIS. A site can run exchange stations and SIP devices together, or SIP alone with no exchange at all. Trunks and devices each have their own port, so neither touches the exchange connection.

An estate, not a list

• One tree, everywhere. The same Country → State → Site → Level hierarchy drives the camera tree, the PA zone tree, the map and every report filter.
• Floor plans per level, with devices dragged onto them and remembered.
• Remote desktop and web tools at the site. Launch a VNC or RDP session to site equipment, or embed a site's own web tool as a console tab — checked at save time so a page that refuses to be embedded is caught then, not at 2am.
• Import and export. Stations, cameras and speakers move by spreadsheet with a transactional dry run.

Honest liveness

• Up means the tunnel handshook. Gateway state is read from the encrypted link itself, not from a heartbeat the gateway sends about itself — a box that has lost its key cannot report itself healthy.
• Routes are derived from the site record. The LAN subnets you enter against a site become the tunnel's routes. Nothing is hand-edited on the appliance.
• Preview, apply, and roll back. Every routing change is shown as a diff, backed up before it is written, and rolled back automatically if the tunnel does not come back.
• Media, not just management. The gateway carries camera video, intercom audio and remote-desktop sessions for its site, so a remote depot behaves like a local one.

Ask a real question

• Filter by anything the estate knows: date range, site, region, level, call type, alarm type, operator, desk, queue.
• Response and handling times measured from the ring, not from the moment a record happened to be written.
• Per-operator activity for supervision, with the same scoping rules the console uses — an operator sees their own figures, a supervisor sees the team.
• Evidence attached. A row in a report leads to the recording, the transcript, the snapshot and the incident timeline behind it.
• Export to CSV or a branded PDF carrying the site's own logo.
• Incidents are statistics too — how many, how fast they were acknowledged and resolved, how often a point has done this before — as a band on the incident list and a report you can export.
• Medians and 90th percentiles, never an average as the headline. On the reference install the mean time to acknowledge a fence alarm was 35 minutes, although most were answered inside one: a handful left over a shift change outweighs everything else. The median says what usually happens; the 90th says how bad the bad ones are.
• Live view for the shift running right now: who is on which desk, what is waiting, what is standing unacknowledged. It sits beside the reports under the one Statistics tab — Statistics | Live stats — so the figures for now and the figures for Monday are one click apart.