FireIQ
AI Fire & Smoke Monitoring for Faster Incident Response
FireIQ is a prototype built on Aparsoft's existing video AI infrastructure. It goes past raw detection — combining computer vision object detection inference, optional false-positive suppression, VLM-based scene reasoning, multi-channel alert fan-out, and a full evidence trail — into one demo-ready operator flow. The honest claim: detection alone was never the hard part. Building a coherent incident workflow around it is.
Detection is the beginning, not the product
Most fire monitoring demos stop at a bounding box on a frame. That is not a workflow. A facility team seeing a box on a screen still has to decide: is this real? How serious? Who do we call? What do we tell them? FireIQ was built to answer those questions inside the same system — not across five separate tools or a human chain. It runs a real event loop: ingest, detect, smooth, reason with a VLM, fan out the alert, and log the evidence. The prototype is honest about what it is — not a hardened production platform — but it proves the pipeline is sound and the next phase of engineering now has a concrete foundation to build from.
Main monitoring view with the live alert and an incident summary beside the feed
These screens show what an operator actually sees during and after an event: the live alert with severity, the VLM incident summary beside the feed, the alert fan-out options, and the downloadable alert history. The interface is functional demo UI — its job is to make the underlying workflow readable to a real team.
Fire detection without an incident workflow is still a gap
Facilities with camera coverage still face a core problem: detection is only the first step. What the operator sees, how the alert is held, where it goes, what evidence is saved, and whether the team can act on it in time — those are the questions a real system has to answer.
Visual context is missing from most alarms
A smoke alarm tells you something is wrong. It does not show you the feed, describe the scene, estimate severity, or suggest a first response. Control-room teams are often left guessing about scale and urgency.
The first response window is where visual context has the most impact — and that is exactly where most systems say the least.
Raw per-frame detection is too unstable to trust
A system that fires and clears alert state every few frames looks unreliable in front of a real team. If operators learn to ignore the flickering, the system stops being useful. Alert smoothing is not a cosmetic addition — it is the difference between a demo that builds confidence and one that erodes it.
Stable, held alert state is an operator trust problem before it is a detection accuracy problem.
Detection accuracy is not the only false-positive problem
Smoke is visually ambiguous. Dust, steam, glare, and backlit scenes all trigger detectors. A second-stage classifier that can say 'this looks normal despite the smoke detection' buys meaningful signal quality improvement without retraining the primary model.
Two layers of judgment are better than one — especially when false positives erode trust fast.
Incidents without evidence trails are hard to learn from
Without saved snapshots, event logs, and a VLM summary attached to each incident, teams are left with memory and verbal reporting after an event. Safety systems are about traceability, not only live alerting.
An evidence trail makes post-incident review possible and makes the next deployment conversation easier.
The value reads differently across buyer, operator, and integration partner
FireIQ is a prototype in a pilot-conversation phase. Different people in that conversation need different proof points.
Operational buyer
Facility and plant managers
Need to see a coherent incident story — not just that the AI detected something, but that the system can hold the alert, reason about severity, push it to the right team, and save what happened.
Daily operator
Security and control-room teams
Need alerts that are readable, steady, and easy to hand off. A box on a frame that flickers is not useful. A held alert with a severity score, a plain-language scene summary, and a snapshot attached to the incident record is.
Integration partner
System integrators and safety solution providers
Need to know the alert bus already speaks to external systems — LAN webhook, RS232, GPIO — and that the input side handles RTSP streams, not just demo video files.
Seven engineering decisions that make this more than an inference wrapper
The markdown for this prototype documents nine distinct implementation layers. Seven of them represent decisions a production engineering team would have to make anyway — and making them at prototype stage is exactly why this build reduces risk instead of deferring it.
Real monitoring loop across multiple input sources
The app runs a continuous event loop across RTSP streams, YouTube feeds, uploaded video files, and test footage from the same operator interface. This is not an offline batch script — it is a persistent monitoring session with start, pause, and event-state management.
That distinction matters because the loop behavior, not just the inference speed, determines whether the demo reads like a working product or a one-shot test.
Runtime class resolution — not locked to one checkpoint
Fire and smoke class IDs are resolved from model metadata at runtime, not hardcoded. The system can swap detection model checkpoints trained on different datasets without breaking the class lookup logic.
A small engineering detail with a large practical implication: the prototype is set up for continued model experimentation without manual rewiring.
Alert smoothing and held detection state
The system holds a fire or smoke alert state for a configurable window of missed frames before returning to normal. During that hold window, the last known detection boxes are reused on screen. This prevents the flickering behavior that makes raw per-frame detection look unstable in front of real teams.
Alert smoothing is one of the most important pieces of prototype engineering in the build — and one of the easiest things to skip when the goal is only to show a detection result.
Optional secondary classifier for false-positive suppression
A 3-class classifier (normal / fire / smoke) runs alongside the primary object detection model. When it strongly predicts a normal frame, it can veto a smoke-only detection before the alert state advances. The detector remains primary; the classifier is a quality filter, not a replacement.
This is an honest and practical second layer that reduces confidence-eroding false alerts without the overhead of a full primary model retraining cycle.
VLM-based scene reasoning on local GPU infrastructure
When an event triggers, a recent frame and detection context are sent to a vision-language model running on local GPU infrastructure. The response is parsed into five structured fields: scene description, probable cause, severity on a 1–5 scale, recommended actions, and evacuation guidance. A text-only fallback handles cases where vision mode is unavailable.
This changes the prototype from a detector into an incident interpretation system. The operator sees what the AI thinks is happening and what it recommends — not just a detection count.
Multi-channel alert fan-out via AlertBus
The AlertBus dispatches events to console output, LAN webhook, RS232 serial, and Jetson GPIO LED and buzzer. Each backend is independently configurable, fail-soft, and import-guarded so missing hardware does not crash the demo. Alerts are debounced to prevent fatigue during sustained events.
The fan-out design is the reason FireIQ can participate in a real integration conversation — the alert is already leaving the camera screen and reaching systems a facility team actually uses.
Evidence trail: snapshots, JSON sidecars, and CSV event logs
Every status transition is logged to a BEL-style CSV with timestamp, event type, confidence scores, severity, snapshot path, and model name. Alert snapshots are saved as JPEG files. VLM analysis results are saved as JSON sidecars alongside each snapshot.
Safety systems are not only about live alerting. Post-incident review and audit requirements depend on what was logged during the event — and all of that exists in the prototype.
From camera feed to evidence trail in five connected steps
The value of FireIQ is not any single step — it is the connection between all five. Detection flows into smoothing. Smoothing flows into VLM reasoning. Reasoning flows into alert fan-out. Fan-out is accompanied by evidence capture. These are not separate features. They are one incident lifecycle.
Detect and surface
Run object detection inference on each frame, resolve fire and smoke class IDs from model metadata, apply independent confidence thresholds, and render a domain-specific HUD with detection boxes, status banners, severity readout, timestamp, FPS, and a live fire/smoke/severity trend chart.
Why it matters: The HUD is functional operator UI — not generic boxes. A security team looking at the screen sees event status, severity, and trend. Class ID resolution from metadata means the app survives model swaps without breaking the display logic.
Outcome: Operators get a live monitoring view that communicates what the system thinks is happening — severity, class, and trend — not just whether something was detected this frame.
Smooth and hold the alert state
After a fire or smoke detection, maintain the alert state for a configurable hold window of missed frames before returning to normal. Reuse the last known detection boxes during the hold window so the display does not flicker. Run the optional secondary classifier to veto weak smoke-only signals.
Why it matters: Raw per-frame detection flickers — a held alert state feels like a system that is watching, not twitching. The optional classifier runs here: if it strongly predicts a normal frame on a smoke-only detection, it can soft-veto the alert before it escalates. Both mechanisms together produce a signal a real team can act on.
Outcome: Alert stability turns the demo from a jittery detection test into a steady incident-awareness view. Operators respond to what they see rather than learning to ignore false flicker.
Reason with VLM
Capture a recent frame alongside detection context — event type, confidence, severity estimate — and send it to a vision-language model running on local GPU infrastructure. Parse the structured response into five display fields and save a JSON sidecar alongside the snapshot.
Why it matters: A severity score from box counts is a rough heuristic. A VLM that describes the scene, names a probable cause, rates severity 1–5, and suggests specific first-response actions is a different kind of output. It is still model-generated interpretation — not certified fire safety analysis — but it shifts the operator's decision surface from 'something is detected' to 'here is what appears to be happening and what to do first'.
Outcome: Stakeholders see the system reasoning about the incident, not only flagging it. That shifts the conversation from detection accuracy to operational usefulness — which is the conversation that leads to a pilot.
Fan out the alert
When an event threshold is crossed, the AlertBus dispatches to all configured outputs in parallel: console log, LAN webhook to the lightweight Flask receiver dashboard, RS232 serial output, and Jetson GPIO LED and buzzer trigger. Each backend is independently fail-soft.
Why it matters: Console output is for demo visibility. LAN webhook proves the system can reach another local machine — the Flask receiver renders a browser dashboard with a flashing banner, recent alert count, and alarm sound. RS232 and GPIO show the integration path toward physical alarm hardware. Fail-soft backends mean missing hardware does not crash the session.
Outcome: The alert leaves the camera screen and arrives in the kinds of output channels a facility team actually uses. That is the integration conversation — and FireIQ can start it in a demo without requiring physical hardware on site.
Capture the evidence trail
For every status transition, save a JPEG snapshot, write a JSON sidecar with the full VLM analysis, and append a row to the BEL-style CSV event log with timestamp, event type, fire and smoke counts, confidence scores, severity, snapshot path, and model name.
Why it matters: Safety systems are about traceability, not only live alerting. Post-incident review, the next engineering decision, and any audit discussion depend on what was logged during the event. FireIQ builds this from the prototype stage — not as an afterthought to add before production.
Outcome: Teams can review what happened after the moment passes. Alert history is visible in the app and downloadable as CSV. That makes the post-demo conversation about what the logs showed, not about what someone remembers seeing on screen.
Five implementation layers that make the demo credible
A credible fire detection prototype is not measured by model accuracy alone. It is measured by how many of the real incident workflow questions it already answers — and how honestly it handles the ones it does not.
Quality gates
Alert hold window prevents flicker from single-frame detections — operators see a stable incident state, not twitching boxes.
Optional secondary classifier vetoes weak smoke-only signals when it strongly predicts a normal scene, reducing false-positive alert fatigue.
Runtime class resolution from model metadata survives checkpoint swaps without hardcoded assumptions about class order.
VLM falls back to text-only context analysis when vision mode is unavailable — the system degrades gracefully rather than failing silently.
Evidence logs capture timestamp, event type, confidence, severity, snapshot path, and model name — not just a detection count.
AlertBus backends are fail-soft and import-guarded, so missing RS232 or GPIO hardware does not prevent the demo from running.
Training scripts support two-stage warm-up (frozen backbone then unfreezing) and resume from checkpoint for continued model iteration.
Five useful things established before production engineering begins
FireIQ is still a prototype. The value of this stage is clarity — collapsing the ambiguous into the inspectable. These are the proof points the prototype can honestly defend.
Detection, smoothing, VLM reasoning, alert fan-out, and evidence capture work together in one continuous monitoring session — not as five separate demos.
Console, LAN webhook, RS232 serial, and GPIO outputs are all implemented, fail-soft tested, and ready for integration conversations on site.
Snapshots, JSON VLM sidecars, and BEL-style CSV logs are written for every event — post-incident review is possible without depending on live replay or human memory.
Operators get a structured read on scene seriousness — probable cause, severity, and first-response actions — from a local vision-language model, not a generic confidence score alone.
Object detection model, secondary classifier, and alternative detection architecture training scripts are included. The prototype is not frozen around one checkpoint — model iteration is a documented next step.
Because the event pipeline is exercised and its limits are visible, the engineering work to harden FireIQ for production has a concrete foundation instead of open-ended ambiguity.
The operator experience is the differentiator, not model accuracy alone
Most fire AI demos show a video with boxes on it. That is where they stop. FireIQ goes further — not because the models are more accurate, but because the prototype was designed around what a real operator and a real integration partner actually need to see.
Incident workflow, not inference script
The monitoring loop, alert hold state, VLM reasoning, alert fan-out, and evidence logging are all part of one coherent session — not five separate capabilities. That coherence is what separates a useful prototype from a detection test with a nice UI.
Alerting treated as an integration concern from the start
Console, LAN webhook, RS232, and GPIO outputs are implemented at prototype stage. That means the integration conversation with facility teams and system integrators can start from this demo, not from a whiteboard.
VLM reasoning changes the stakeholder conversation
When the system shows a severity score, a probable cause, and a plain-language recommendation alongside the detection, the buyer conversation shifts from 'how accurate is your model' to 'how useful is this for my team under pressure'. That is a better conversation.
Built on reusable Apar Drishti infrastructure
FireIQ reuses the existing video ingestion engine, model-selection logic, Streamlit demo structure, and logging patterns from Aparsoft's broader Apar Drishti platform. The domain-specific layer — fire class handling, HUD, alert bus, VLM prompt, training scripts — was added on top, not from an empty folder.
FireIQ is a capability proof, not only a fire safety demo
The FireIQ prototype matters at the company level because of what it demonstrates about how Aparsoft builds. The fire-and-smoke domain is specific. The engineering approach is not.
Existing infrastructure gets reused, not rebuilt
Aparsoft did not start FireIQ from an empty folder. It took the Apar Drishti video AI foundation and added the domain-specific layer on top. That is a deliberate company practice — shared infrastructure means faster domain adaptation and lower prototype cost.
Detection is the beginning of the system, not the product
The team built alert smoothing, VLM reasoning, multi-channel fan-out, and evidence logging at prototype stage — not as a future roadmap item. That reflects a consistent Aparsoft pattern: operational usefulness is designed in from the start, not added at the end.
Honest about prototype scope
This case study is explicit about what FireIQ is and is not. It is not a hardened production fire safety platform. It is a prototype that proves the pipeline, collapses ambiguity, and defines what production hardening would actually require. Aparsoft describes its work accurately.
Logging and evidence from day one
Snapshot saving and event CSV logging are in the prototype, not on a future roadmap. That reflects Aparsoft's understanding that safety systems are about traceability — not only live performance — and that building audit infrastructure late is more expensive than building it early.
Model iteration is an open path, not a closed checkpoint
Object detection model training, secondary classifier training, and alternative detection architecture training scripts are all included. The prototype is not frozen around one model experiment. Aparsoft builds prototypes that can keep improving — and documents the path for doing so.
