Suriyakumarvijayanayagam
dad04e8cda
Five components that ship as one product:
- behavision/ the recognition engine. RTSP ingest, YuNet detection, IoU
tracking, ArcFace embeddings, a FAISS/SQLite gallery, and a
FastAPI dashboard. Identity is decided once per TRACK from an
average of at least three embeddings, never per frame.
- agent/ the Go edge agent: supervises the engine, holds a durable
spool, and drains it to MQTT. Nothing is acked before the
broker confirms.
- desktop/ the shop PC application (Wails + React + tray).
- server/ the cloud API, MQTT consumer, reports and assistant.
- web/ platform.loyaly.ai, the head-office app, embedded in the
server binary.
The gallery stores 512-float embeddings and timestamps - no images unless
`app.store_faces` is switched on. Those embeddings are biometric personal
data under GDPR and India's DPDP: template inversion reconstructs a
recognisable face from an ArcFace vector, so data/behavision.db is treated
as a biometric database and DELETE /api/visitors/{id} is a real erasure.
CLAUDE.md carries the reasoning behind every non-obvious decision here,
including the ones that were measured and the ones that were wrong first.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HViLj9gYNRtSr7YVZmW5sn
45 lines
2.2 KiB
Markdown
45 lines
2.2 KiB
Markdown
# Behavision agent (Go)
|
|
|
|
The half of the edge install that touches the network. The Python engine keeps
|
|
the cameras and the models; this keeps the tray icon, the UI shell, the MQTT
|
|
connection and the offline queue.
|
|
|
|
┌─ agent (Go) ───────────────────┐ ┌─ engine (Python) ────────┐
|
|
│ tray icon + WebView2 window │ │ RTSP capture │
|
|
│ supervises the engine process │───────▶│ YuNet / ArcFace / FAISS │
|
|
│ MQTT publish + offline spool │◀───────│ SQLite (biometric) │
|
|
│ S3 handoff, tenant config │ local │ localhost API + events │
|
|
└────────────────────────────────┘ HTTP └──────────────────────────┘
|
|
|
|
## Why the split
|
|
|
|
Go cannot run ONNX, OpenCV or FAISS, so the engine stays Python and ships
|
|
frozen. Go is here for what it is actually better at: a durable queue that
|
|
survives a store's internet dropping, a supervised child process, and one
|
|
language shared with the server so the MQTT contract has a single definition.
|
|
|
|
## Why not a Windows service
|
|
|
|
A service runs in session 0 and **cannot draw a tray icon** — that is Windows
|
|
session isolation, not a library limitation. Since the product is "user starts
|
|
and stops it from the tray", the agent is a normal user-session process that
|
|
spawns the engine as a child. That also means it never needs elevation at
|
|
runtime: starting a child process does not, controlling a service does.
|
|
|
|
`internal/engine` is written so a service wrapper can be added later without
|
|
touching the supervision logic.
|
|
|
|
## Layout
|
|
|
|
main.go entry point, mode dispatch
|
|
internal/engine start/stop/supervise the Python engine, health polling
|
|
internal/spool durable event queue (survives restart and outage)
|
|
internal/mqtt broker client, publishes from the spool
|
|
internal/config tenant identity, broker settings, credentials
|
|
frontend/ React UI served into the WebView
|
|
|
|
## Build
|
|
|
|
go build ./... # agent alone
|
|
wails build # agent + frontend, once the UI is added
|