A compact person-detection release for testing dense-scene edge vision.
Compact person-detection skill for dense scenes — public ONNX package with a live browser demo.
Evidence posture
Public artifact · Clear provenance · Stated limitations
~92% (protocol)
Reported accuracy
Reported for the published release; validate independently.
19 MB
Artifact size
Reported for the published release; validate independently.
ONNX
Format
Reported for the published release; validate independently.
What this release is
Sentinel is an Innomium internal product and public technical artifact—not a client case study. It packages a person detector as an ONNX model with a browser-accessible demonstration, giving teams a concrete place to investigate scene fit, model footprint, threshold behavior, and the work between detection and an operational workflow.
Why it matters
Person detection is widely available, yet dependable performance is intensely local. Camera height, crowd density, object scale, occlusion, compression, lighting, motion, and privacy policy determine whether a generic detector is useful. Sentinel is most valuable as an inspectable baseline: a model that can be challenged against the actual scenes and consequences of a proposed use case.
Technical anatomy
Each module below separates what is publicly observable from what still requires reproduction, local evaluation, and production engineering.
Single-purpose person detection keeps the evaluation surface understandable.
A narrower class definition can simplify analysis, but it does not remove scene variation. Acceptance should still segment results by crowd density, distance, visibility, and camera viewpoint.
The published ONNX package is intended for practical runtime evaluation.
ONNX makes it possible to test CPU, edge, or browser-oriented paths without assuming the production device. Actual latency, memory, and compatibility must be measured on representative hardware.
The public demo makes qualitative inspection immediate.
A demo can expose obvious strengths and failure modes quickly. It cannot replace a held-out dataset, repeatable protocol, or privacy review for a real operating environment.
Detections can become inputs to occupancy, queue, or exception workflows.
A production system still needs temporal logic, zone rules, confidence policy, review, monitoring, and a documented response when the model is uncertain.
Evaluation interpretation
Read public figures as a reason to investigate—not a reason to skip acceptance testing.
The published figure reflects Innomium crowd evaluation splits. It should be treated as reported evidence for that setup, not a promise for a different camera estate or definition of correctness.
A single average can conceal the cases that matter most. Break results down by scale, occlusion, density, lighting, and scene, then weight errors by their operational consequence.
Model size is useful, but deployment decisions also require preprocessing, post-processing, frame rate, memory, warm-up, thermal behavior, and recovery testing.
Application hypotheses
These are potential application patterns, not claims of completed client deployments. Each requires its own technical and operational evidence.
Evaluate aggregate presence or flow where the organization has a legitimate purpose and a privacy-conscious architecture.
Use detections as one input to a time-based operational signal rather than treating each box as a final conclusion.
Test whether a compact person detector can fit the hardware, latency, and update model of a device or local application.
Responsible boundaries
Technical confidence grows when limitations are explicit and testable.
Sentinel is presented as person detection, not face recognition, identity resolution, demographic inference, or behavior judgment.
Acceptable use, notice, minimization, access, retention, and review require explicit organizational and legal decisions.
A deployment program must establish local evidence and a rollback path before operational reliance.
From artifact to adoption
The exact path depends on the release and intended use. The discipline remains the same: inspect, reproduce, evaluate, and only then integrate.
Run the public artifact and confirm the expected model, inputs, outputs, and runtime in a controlled environment.
Build a representative, permissioned scene set and investigate error patterns instead of tuning immediately.
Improve data, thresholds, post-processing, or weights only where the baseline evidence identifies a material gap.
Test the complete workflow with monitoring, human review, failure handling, and a defined acceptance decision.
Inspectable artifacts
Use the live demonstration for initial qualitative inspection. Before commercial or production use, review the applicable model card, license, dependencies, data handling, and local acceptance evidence.
Evidence label
Innomium Sentinel 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.
Request a consultation for reproduction, domain evaluation, adaptation, integration, or a production-readiness decision grounded in your data and operating constraints.
Built for accountable delivery
We begin with the operating constraint, agree on what success looks like, and build a delivery path your technical and business teams can review.
01
Scope, constraints, milestones, and decision owners before build work starts.
02
Evaluation plans, working artifacts, and reviewable technical decisions—not presentation-only progress.
03
Integration, observability, documentation, and an operating path for the teams who own the result.