01
Three hazard-related classes
The release distinguishes fire, smoke, and extinguishers.
Class-aware handling can support different downstream rules, but each class needs local examples, hard negatives, and an explicit response policy.
Internal ProductPublic research release
Innomium Ember
A compact fire, smoke, and extinguisher detector built for edge evaluation.
Outdoor fire and smoke detection skill — public demo and edge-oriented ONNX packaging.
Inspectable artifactProtocol-specific evidenceIndependent validation required
Evidence posture
Public artifact · Clear provenance · Stated limitations
~90% (protocol)
Reported accuracy
Reported for the published release; validate independently.
~9.8 MB
Artifact size
Reported for the published release; validate independently.
ONNX
Format
Reported for the published release; validate independently.
What this release is
Public evidence designed to be questioned.
Ember is an Innomium internal product and public technical demonstration focused on three hazard-related classes: fire, smoke, and fire extinguisher. Its public Space documents browser-local inference, a ~9.8 MB ONNX footprint, class-aware post-processing, and a stated 90% accuracy figure.
Why it matters
Visual hazard detection can add useful attention to a safety workflow, but the cost of both misses and false alerts is high. Fire appearance changes with distance, fuel, weather, lighting, camera exposure, reflections, haze, steam, and smoke color. Ember is therefore best understood as a concrete research artifact to evaluate—not a replacement for certified safety systems.
Technical anatomy
Inspect the layers behind the headline.
Each module below separates what is publicly observable from what still requires reproduction, local evaluation, and production engineering.
02
Class-aware post-processing
The public demo describes per-class suppression, smoke merging, and confidence controls.
These techniques help shape noisy detections into more useful outputs. They remain tunable components whose behavior must be evaluated on representative scenes.
03
Browser-local inference
The demonstration runs the model in the browser without uploading frames.
Local execution is useful for privacy-conscious evaluation and edge feasibility. A production camera pipeline still needs hardware profiling, update control, telemetry, and recovery.
04
Compact ONNX footprint
The public artifact reports a model size of approximately 9.8 MB.
That footprint creates deployment options, but file size alone does not establish frame rate, thermal stability, recall, or complete system reliability.
Evaluation interpretation
A metric is useful only when the protocol survives scrutiny.
Read public figures as a reason to investigate—not a reason to skip acceptance testing.
01
Interpret 90% within the stated protocol.
The public release states 90% accuracy. A responsible evaluation should identify the split, class balance, thresholds, confusion patterns, and performance on a held-out set from the intended environment.
02
Build a serious hard-negative library.
Steam, clouds, glare, orange lighting, welding, reflections, dust, and ordinary exhaust may resemble hazards. These cases should be represented deliberately.
03
Test alert behavior, not only boxes.
Measure time-to-signal, repeated alerts, temporal confirmation, escalation, operator load, connectivity loss, and model health as part of the acceptance plan.
Application hypotheses
Where this artifact may create leverage.
These are potential application patterns, not claims of completed client deployments. Each requires its own technical and operational evidence.
HYPOTHESIS 01
Industrial monitoring research
Explore an additional visual signal for warehouses, production areas, loading zones, or remote perimeters alongside established safety controls.
HYPOTHESIS 02
Outdoor smoke and flame evaluation
Investigate camera viewpoints and environmental conditions where visual cues may support earlier attention, subject to extensive local validation.
HYPOTHESIS 03
Extinguisher visibility experiments
Evaluate whether camera-based presence checks can complement—never replace—formal inspection and compliance processes.
Responsible boundaries
Know what the release does not establish.
Technical confidence grows when limitations are explicit and testable.
Not a certified alarm system
Ember must not be represented as a substitute for required detectors, alarms, inspections, or emergency procedures.
Not a universal hazard guarantee
Visual appearance and camera conditions vary substantially. Local evidence, redundancy, and accountable human response remain essential.
Not complete without operations
Monitoring, escalation, maintenance, audit, incident review, and failure recovery are part of the product—not optional deployment details.
From artifact to adoption
Earn confidence one gate at a time.
The exact path depends on the release and intended use. The discipline remains the same: inspect, reproduce, evaluate, and only then integrate.
Inspect
Use the public browser demo to understand the output classes and quickly collect obvious successes and failures.
Stress-test
Evaluate representative hazards and hard negatives under varied distance, lighting, weather, and camera quality.
Design safeguards
Define temporal confirmation, redundancy, escalation, human review, monitoring, and the role of existing safety systems.
Pilot responsibly
Run a bounded, observable pilot with safety leadership, documented acceptance criteria, and a clear stop condition.
Inspectable artifacts
Follow the evidence to its source.
Ember’s public Space is useful for inspecting the artifact and its browser-local execution. Any operational use must preserve required safety systems and undergo site-specific technical, legal, and safety review.
Evidence label
Innomium Ember is labeled as internal product. It is not presented as an approved client case study. Published metrics follow the release’s stated or Innomium protocols and require validation in the intended environment.
Evaluate Innomium Ember against the environment that matters.
Request a consultation for reproduction, domain evaluation, adaptation, integration, or a production-readiness decision grounded in your data and operating constraints.