Context and ownership
Tangkapin connects CCTV weapon detection with reporting, evidence, verification, officer assignment, and field tracking. I owned the backend API and integration contract with the Python/PyTorch detection service.
The central engineering issue was trust: a model prediction, persisted report, human verification, and officer status are not equivalent facts.
Inference is evidence, not business truth
The Python service returns a bounded detection response through HTTP. The Node.js API consumes that output and can create/enrich report evidence, but model confidence does not directly complete the incident workflow.
Authorized human verification and persisted report transitions remain the operational authority. This prevents “model detected something” from silently becoming “incident confirmed.”
Service failure degrades narrowly
Inference runs in a separate process/container. If it is unavailable, automatic detection stops, but manual reporting and the rest of the incident lifecycle can remain available.
Timeouts and bounded retry are preferable to allowing an ML request to block operational API work indefinitely.
Realtime is delivery, not state
Pusher notifies Owner/Officer/Police clients of changes. The database/API remains canonical, so clients can recover current report state after a missed realtime event.
Tracking data has its own boundary: latitude/longitude update frequency affects privacy, bandwidth, storage, and battery. The project does not claim a production-grade dispatch or ETA system without those policies.
Result and limits
Tangkapin demonstrates a clear ML/product boundary: inference proposes evidence; persisted workflow and authorized actions own incident state.
Known limits are model-version/confidence provenance, role/transition regression tests, inference latency/drift telemetry, and a separately designed frame-ingestion pipeline if real CCTV throughput ever requires it. I do not claim the system measurably reduced response time because that was not instrumented.