Why this matters
Behavioral analytics is where most surveillance buyers first feel the gap between a slick demo and a deployed system that an operator can actually live with. The person specifying it is usually a security integrator, a facilities or operations lead, a retail or logistics manager, or a product owner who saw a tripwire fire cleanly in a vendor booth and now has to make it work across a real perimeter in wind, rain, headlights, and foot traffic. This article is written so a non-technical reader can understand three things that decide success: what each behavioral rule actually detects, why false alarms — not missed events — are the failure mode that sinks these systems, and where the rule stops being a simple geometry problem and becomes a privacy question. A senior video engineer will find the standards and accuracy framing precise; the writing serves the decision-maker first.
What "behavioral analytics" means — and what it does not
Start with a clean definition, because the word "behavioral" oversells what most of these systems do. Behavioral analytics, in surveillance, is a set of rules that turn an object's position and movement over time into an alert. It answers questions of geometry and timing: did something cross this line? enter this area? stay too long? gather into a crowd? get left behind? It does not, in its everyday form, understand intent, read emotion, or know who a person is. That distinction matters for both accuracy and law, and we will return to it.
It helps to separate behavioral analytics from its neighbors in the analytics catalogue. Object detection answers what is in the frame — a person, a vehicle, a bag. Object tracking answers where that thing goes over time by stitching detections into a path, called a track. Behavioral analytics is the layer on top: it applies a rule to those tracks. A track that crosses a drawn line triggers a line-crossing rule; a track that sits inside a drawn zone for thirty seconds triggers a loitering rule. So behavioral analytics is not a separate kind of AI — it is detection and tracking plus a geometry-and-timing rule. For where each analytic fits in the bigger picture, see the video-analytics map.
There are two ways to author the rule, and most real systems use the first. Rule-based (deterministic) analytics is you drawing a line or a polygon and setting a threshold — predictable, explainable, and the workhorse of this article. Learned (behavioral-anomaly) analytics instead learns what "normal" looks like in a scene and flags deviations without a hand-drawn rule; that is a different tool with a different accuracy-and-false-alarm profile, covered in anomaly detection in surveillance video. This article owns the rule-based family — the lines, the zones, the dwell timers, the counts — and the AI detection-and-tracking that now powers them.
The five behavioral rules you will actually use
Almost every behavioral deployment is built from a small set of rule types. Naming them plainly keeps expectations grounded.
Line crossing (a virtual tripwire). You draw a line across the scene; the rule fires when a tracked object crosses it, and you can require a direction — into the yard but not out of it. It is the cleanest behavioral rule because crossing a line is an unambiguous event. A direction-aware tripwire that only fires on a person entering is the standard way to watch a boundary without alarming on everyone walking past.
Intrusion / zone (a field). You draw a polygon — a protected area — and the rule fires when a tracked object enters, appears inside, or stays in it. This is the rule behind "no one should be on the loading dock after hours" or "this electrical substation is off-limits." Where a line catches a moment of crossing, a zone catches a state of being inside.
Loitering. A zone rule with a clock attached: the rule fires only when an object stays inside the area longer than a dwell time you set, commonly adjustable from a few seconds to several minutes. Loitering is how you separate a person walking through a doorway (fine) from a person lingering at it for two minutes (worth a look), without alarming on every passer-by.
Crowd density and occupancy counting. Instead of watching one object, these rules count or estimate how many objects are in an area — people in a plaza, vehicles in a lot — and alarm on a threshold ("more than 200 people," "lot is full"). Counting a handful of well-separated people is reliable; estimating a dense crowd is an approximation, a point we make precise in the accuracy section.
Object left behind (and its mirror, object removed). The rule watches for an item that becomes stationary and stays — a bag on a platform, a box in a corridor — or, in reverse, for a fixture that disappears. This is the hardest of the five to do well, because the system must hold a memory of the scene through people walking in front of the object, lighting changes, and the object being partly hidden.
Figure 1. The five behavioral rules you will actually use. Each is a geometry-and-timing rule applied to a tracked object: a line to cross, a zone to enter, a dwell clock for loitering, a count for crowds, and a stationarity timer for an object left behind. They differ in what they watch, not in the underlying detection and tracking.
How a behavioral rule actually works: scene description, then rule engine
Under the hood, a modern behavioral analytic is two parts working in sequence, and the ONVIF standard names them exactly this way. The first part is the analytics engine on the camera or server: it runs object detection and tracking and produces a scene description — a structured list of what is in the frame, where each object's box sits, its center of gravity, and its class label (person, vehicle, and so on). The second part is the rule engine: it reads that scene description and checks it against the geometric rules you authored — the lines that may not be crossed, the polygons that mark a protected area, the dwell timers (ONVIF, Analytics Service Specification). When a rule is satisfied, the engine emits an event.
This two-stage design is the single most important idea in the article, because it explains why modern behavioral analytics is so much more accurate than the motion detection it replaced. Old systems triggered on raw pixel change — any pixel that moved enough, from any cause. The new design triggers only when a classified, tracked object satisfies a geometric rule. A swaying branch produces pixel change but no "person" track crossing your line, so it never alarms. That is the whole game.
The practical consequence for whoever configures the system: authoring a behavioral rule in the Video Management System — the software that ingests and records many camera streams, called a VMS — is a short, repeatable recipe. You draw the geometry (the line or the polygon) on the camera's view. You attach an object-class filter so the rule only considers the classes you care about — fire on a person, ignore a cat. You set the parameters: a direction for a line, a dwell time for loitering, a count threshold for occupancy. You add a schedule so the rule is only live when it should be (the loading dock zone arms after hours). And you choose the response: raise an operator alert, start a recording, move a pan-tilt-zoom camera to the spot, or trigger an integration such as an alarm or a light. Get the geometry and the class filter right and the rest is tuning.
Figure 2. Scene description, then rule engine. The camera's analytics engine detects and tracks objects and outputs a scene description (boxes, classes, tracks); the rule engine checks that against your lines, zones, and timers and emits an event into the VMS. Because the rule fires on a classified, tracked object — not raw pixel motion — wind, shadows, and headlights stop being alarms.
False alarms are the real metric — and the real math
Here is the rule the whole analytics section is built on, applied to behavior: accuracy is a range tied to scene, lighting, angle, and tuning — never a single number, and never 100%. For behavioral analytics, the number that decides whether a system survives contact with reality is not the detection rate. It is the false-alarm rate, because behavioral systems are usually watching quiet scenes where almost nothing is a real event, and a flood of false alerts destroys them.
The mechanism is alert fatigue, and it is well documented in monitoring operations. When operators receive hundreds of irrelevant alerts per shift, their response rate to genuine alerts drops — they are conditioned to expect noise — and in the worst case they turn the analytics off entirely so they can do their jobs. In many camera deployments, the overwhelming majority of alerts are false; figures of 90–99% nuisance alerts are commonly cited for legacy setups. The whole point of behavioral analytics is to push that number down.
Walk the arithmetic out loud, because the comprehension is the point. Picture one outdoor perimeter camera.
- On legacy pixel-motion detection, the camera triggers on anything that moves: wind in trees, rain, headlights sweeping the fence, a cat. Say it produces 300 alerts a day, of which 95% are nuisance.
- 300 × 0.95 = 285 false alerts a day from one camera. An operator watching twenty such cameras drowns.
Now switch to a direction-aware tripwire with an object-class filter — fire only when a person crosses into the zone:
- The branch, the rain, the headlights, and the cat are all filtered out, because none is a person-track crossing the line in the armed direction.
- Industry experience with object-classified analytics is a 90% or greater cut in nuisance alarms, and well-tuned perimeter deployments report over 95% reductions. Take 90% as a conservative figure: 285 × (1 − 0.90) ≈ 29 false alerts a day, most of them now plausible.
That is the difference between a system an operator trusts and one they mute. A well-tuned AI behavioral system targets a false-positive rate in the low single digits, against the 80%+ of raw motion detection — but "well-tuned" is the load-bearing phrase, and tuning is a deployment activity, not a factory setting.
Figure 3. Why the rule engine pays for itself. Legacy pixel-motion detection alarms on wind, rain, light, and animals — commonly 80–95%+ nuisance. A direction-aware tripwire with a person-only class filter removes most of it: a ~90%+ cut takes ~285 false alerts/day on one camera toward ~29. The remaining work is tuning, not magic — and the rate is never zero.
What moves the number, in rough order: the object-class filter (the biggest single lever — fire on people, not animals or weather); the geometry (a line placed where only real crossings happen beats a zone that catches a busy walkway); the scene (rain, fog, strong shadows, and low light all degrade detection); the camera angle and distance (an object too small or too oblique is tracked poorly); and the thresholds (a dwell time set too short turns normal pauses into loitering alarms). Each is a tuning dial, and the honest vendor reports the false-alarm rate measured on your scene, not a lab number.
A common mistake to avoid
The costliest pattern we see is specifying on the demo and deploying onto the real scene. A tripwire that fired perfectly across a clean indoor floor behaves very differently across a tree-lined perimeter at dusk, and a system budgeted on the booth number will flood the operator on week one. The runner-up is drawing lazy geometry — a zone that overlaps a public footpath, a line where people routinely pass for innocent reasons — which manufactures false alarms no model can fix. The third is skipping the object-class filter, leaving the rule to fire on anything that moves and throwing away most of the accuracy the AI was supposed to buy. And the fourth, specific to object-left-behind: expecting it to work in a crowd, where occlusion and constant motion make a stationary item hard to hold in memory. Demand a field pilot on your real cameras, your real traffic, and your real weather, reported as a measured false-alarm rate with the conditions stated, before anyone calls a behavioral deployment "done."
How accurate is each behavioral rule?
Accuracy is not uniform across the five rules, and pretending otherwise misleads a buyer. Rank them roughly from most to least reliable.
Line crossing and zone intrusion are the most reliable, because the underlying event is crisp and the rule is simple: a tracked person either crossed the line or did not. With a good class filter and sensible geometry, these are the rules behind certified perimeter systems. The honest framing is still a range — detection degrades in bad weather and at distance, and there is always a residual false-alarm rate — but these two are the workhorses.
Loitering is reliable as a timer but sensitive to its threshold. The detection-and-track part is the same as a zone; the judgment is the dwell time. Set it too short and you alarm on people who paused to read a sign; too long and you miss the behavior you wanted. Loitering accuracy is mostly a tuning question, not a model question.
Crowd counting is an estimate, and you must treat it as one. Counting a handful of separated people is accurate; estimating a dense crowd is approximate, because heads occlude one another. Research crowd-counting models are measured by mean absolute error (MAE) — the average miscount — and on the standard ShanghaiTech benchmark, leading 2025 models report an MAE around 50 or more on dense scenes (Part A) and around 6–7 on sparse scenes (Part B). In plain terms: in a sparse scene the count is off by a handful; in a dense crowd it can be off by dozens. That is fine for a threshold ("is the plaza over 200 people?") or a trend, and wrong for anything that needs an exact headcount. Match the rule to the question.
Object left behind is the hardest, and the honest one to caveat. Detecting a static object while keeping false alarms low is a known difficult problem: the system must distinguish a truly abandoned bag from a person standing still, hold the object through people walking in front of it, and cope with lighting changes. It performs best on isolated objects in calmer scenes and degrades in crowds. The UK Home Office benchmark for exactly these scenarios — the Imagery Library for Intelligent Detection Systems (i-LIDS) — certifies analytics for sterile-zone monitoring and abandoned-baggage detection precisely because false-alarm performance under real conditions is hard enough to need a government test (UK Home Office CAST, i-LIDS). If a vendor claims object-left-behind in a busy concourse, ask for the i-LIDS result or an equivalent measured figure.
The thread through all five: behavioral analytics gives you a strong signal, not a verdict. The workflow must tolerate a missed or false event gracefully — a perimeter hit confirmed by an operator glancing at the clip, a crowd threshold treated as a prompt to look, not an automated lockdown.
The standard underneath: ONVIF's rule engine and Profile M
It is easy to assume behavioral analytics is a pile of proprietary vendor features. Much of the tuning is — but the core rule types are standardized, and knowing that protects you from lock-in. The ONVIF Analytics Service Specification defines a normative set of rules that a conformant device exposes and a client can configure: a Line Detector (a polyline that emits a "Crossed" event when an object crosses it in a set direction), a Field Detector (a polygon that reports which objects are inside it), a Loitering Detector, and line-crossing and occupancy counting rules (ONVIF, Analytics Service Specification, Annex A). The specification even names a "lost baggage detector" as an example processing chain. A VMS can ask a camera which rules it supports, create and modify those rules, and subscribe to their events — over a standard interface, across vendors.
ONVIF is the common language that lets cameras and software from different makers understand each other, and ONVIF Profile M is the profile built for analytics metadata and events. A behavioral event — a line crossed, a zone entered, a loitering timer expired — surfaces into a Profile M VMS as a standardized event, carried inside the video stream, through the ONVIF event service, or over the lightweight messaging protocol MQTT (ONVIF, Profile M). That standardized channel is why a behavioral alert from one vendor's camera can raise an alarm, start a recording, or fill a searchable event index in another vendor's VMS. The bridge between the camera's analytics and the VMS is covered in events, metadata, and the ONVIF analytics interface.
Here is the boundary that catches teams out, and it is the same one that governs every analytic. ONVIF standardizes the rule type and how the event is reported — not how accurate the rule is or how well it is tuned. The detection model, the tracking quality, the false-alarm rate, the clever logic that distinguishes a loiterer from a bus queue — those are the vendor's own, reached through their SDK, not guaranteed by ONVIF. ONVIF conformance is a baseline for interoperability, not a promise of feature parity or accuracy. Keep "ONVIF-conformant behavioral events" and "a behavioral system that actually works on your site" firmly separate. For the commercial overview of how the profiles fit security systems, Fora Soft's ONVIF profiles in security systems is the reference.
Where the rule runs — on the camera, on an on-site server, or in the cloud — is its own decision with its own latency and bandwidth profile. Behavioral rules are latency-sensitive (a perimeter alarm is worthless if it arrives after the intruder is gone), so they usually run at the edge, on the camera or a nearby box; the model internals of the detection and tracking that feed them live in the AI for Video Engineering section. The deployment tradeoff is covered in edge vs cloud video analytics.
Figure 4. What ONVIF standardizes, and what it does not. The Analytics Service Specification defines the rule types — Line Detector, Field Detector, Loitering Detector, counting — that a VMS configures and that surface as ONVIF Profile M events. Inside the boundary: the rule type and the event. Outside it, in the vendor SDK: the detection model, the tracking, and the tuning that decide the real false-alarm rate.
The privacy line: behavior is personal data, but usually not biometric
Behavioral analytics sits on the lighter side of surveillance privacy law — but "lighter" is not "none," and there is a line it can cross. Getting this right keeps you out of both over-caution and complacency.
Behavioral analytics processes personal data. Under the EU's General Data Protection Regulation, personal data is any information relating to an identified or identifiable person. A track of a person moving through a scene relates to that person even without a name, so behavioral analytics on identifiable people is processing of personal data: it needs a lawful basis, people must be told the system exists, and systematic monitoring of a publicly accessible area triggers a Data Protection Impact Assessment under GDPR Art. 35, as the European Data Protection Board's video-devices guidance spells out (GDPR, Reg. (EU) 2016/679, Art. 4(1) and Art. 35; EDPB Guidelines 3/2019).
But behavioral analytics is usually not biometric data. This is the crucial distinction from face recognition. Biometric data, in the GDPR's Article 9 sense, results from technical processing of a person's physical characteristics — a face, a fingerprint — to uniquely identify that person. A line-crossing rule, a loitering timer, and a crowd count do none of that: they measure where an anonymous object is and how long it stays, not who it is. The EDPB itself frames video analytics on a scale from less intrusive — its example is "simple counting algorithms" — to more intrusive biometric technologies (EDPB Guidelines 3/2019). Behavioral analytics lives at the less-intrusive end. So the special-category Article 9 regime, and the US biometric statutes built around it (Illinois BIPA, Texas CUBI) that gate face recognition, do not attach to a plain behavioral rule. That is a real and useful difference: a retailer can run a people-counter or a loitering rule where it could never run face recognition.
Where the line is crossed. Behavioral analytics tips into the heavier regime the moment it starts to identify or biometrically categorize individuals — linking a loiterer to a face-recognition watchlist, inferring emotion or intent from a person's behavior, or building a profile that singles out a specific person. Emotion and intent inference in particular carries extra weight: the EU AI Act restricts emotion-recognition systems in workplaces and education, and real-time remote biometric identification in public is heavily curtailed (EU AI Act, Reg. (EU) 2024/1689, Art. 5). The clean engineering rule: keep behavioral analytics anonymous by design. Count and detect behavior without identifying the person; where the use case truly needs identity, treat it as a face-recognition deployment with all the biometric law that brings, and run it past the privacy regime in GDPR for video surveillance. One privacy bonus falls out of the architecture: because the useful output is often a count or an event, not the video, you can keep raw footage local or discard it and surface only the metadata — privacy and bandwidth improving together.
Figure 5. The legal line for behavior. Counting, zones, line-crossing, and loitering measure where an anonymous object goes — personal data (GDPR: lawful basis, notice, DPIA for systematic monitoring), but not Article 9 biometric. The rule crosses into biometric/identity law only when it identifies a person or infers emotion (face watchlist, emotion recognition, EU AI Act Art. 5). Keep behavior anonymous by design.
Behavioral analytics at a glance
| Rule | Detects | Best at | Honest limit |
|---|---|---|---|
| Line crossing | A tracked object crossing a line, by direction | Clean boundary, direction control | Residual false rate; degrades in bad weather/distance |
| Intrusion / zone | An object inside a drawn polygon | After-hours protected areas | Lazy geometry over a footpath manufactures alarms |
| Loitering | An object staying past a dwell time | Separating lingering from passing | All in the threshold; pauses look like loitering |
| Crowd / occupancy | Count or density in an area | Thresholds and trends | An estimate (dense-scene MAE in the dozens), not an exact headcount |
| Object left behind | An item that becomes and stays static | Isolated objects, calmer scenes | Hard under occlusion/crowds; needs i-LIDS-grade proof |
Table 1. The five behavioral rules, what each is best at, and the limit a buyer should hold it to. All share the camera-to-event shape, the "never 100%" rule, and the fact that a measured false-alarm rate on your own scene beats any datasheet number.
Where Fora Soft fits in
Fora Soft has built real-time video, streaming, and computer-vision software since 2005, across 625+ shipped projects, and behavioral analytics is a place where the effort goes into the parts a demo hides: the geometry of the rule, the object-class filter, and the false-alarm rate measured on the client's own scene and weather. We lead with how the system behaves under real load first — the nuisance-alarm rate an operator will actually see, the dwell and direction thresholds tuned to the site, the graceful workflow for the inevitable false event, and an anonymous-by-design posture that keeps a counting or zone rule on the lighter side of privacy law — and only then the capability. A behavioral system that an operator trusts at 3 a.m. beats one that demoed perfectly and got muted in week one.
What to read next
- Anomaly detection in surveillance video
- Tuning analytics: false alarms, accuracy, and the operator's reality
- Perimeter and intrusion detection
Call to action
- Talk to a surveillance engineer — book a 30-minute scoping call to talk through your behavioral video analytics plan.
- See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
- Download the Behavioral Analytics (Loitering, Intrusion, Crowd, Zones) — One-Page Reference — What behavioral analytics is (geometry-and-timing rules on tracked objects, not identity), the five rules (line crossing, intrusion zone, loitering, crowd/occupancy counting, object left behind), the scene-description-then-rule-engine….
References
- ONVIF — "Analytics Service Specification" (defines the analytics architecture as a video analytics engine producing a scene description plus a rule engine that interprets it; Annex A normative "Specified Rules" includes the Line Detector — a non-intersecting polyline that emits a
RuleEngine/LineDetector/Crossedevent on a directional crossing — the Field Detector — a simple non-intersecting polygon reporting objects inside viaRuleEngine/FieldDetector/ObjectsInside— the Loitering Detector, and line-crossing and occupancy counting rules; a ClassFilter restricts a rule to object classes; rules are configured via GetSupportedRules / CreateRules / ModifyRules; "lost baggage detector" is named as an example processing chain — the standards basis for line crossing, intrusion zones, loitering, counting, and object-left-behind as standardized rule types). Primary (tier 1). https://www.onvif.org/specs/srv/analytics/ONVIF-Analytics-Service-Spec.pdf - ONVIF — "Profile M" (standardizes analytics metadata and events into a VMS; a device exposes analytics modules — motion, tamper, line-crossing, people counting, LPR, face — that a client can configure and subscribe to; events are carried over the metadata stream, the ONVIF event service, or MQTT; conformance is a baseline for interoperability, not a guarantee of accuracy — the standardized channel through which a behavioral event surfaces into the VMS). Primary (tier 1). https://www.onvif.org/profiles/profile-m/
- European Union — "GDPR, Regulation (EU) 2016/679, Art. 4(1) (personal data) and Art. 35 (Data Protection Impact Assessment)" (personal data is any information relating to an identifiable person; a track of an identifiable person is personal data; systematic monitoring of a large public area requires a DPIA — the basis for 'behavioral analytics is personal data, needs a lawful basis, notice, and a DPIA'). Primary (tier 1). https://eur-lex.europa.eu/eli/reg/2016/679/oj
- European Data Protection Board — "Guidelines 3/2019 on processing of personal data through video devices" (video processing of personal data needs a lawful basis and transparency; the EDPB ranks intelligent video analysis from less intrusive — its example is "simple counting algorithms" — to more intrusive biometric technologies, and footage in which individuals cannot be identified may fall outside the GDPR; systematic monitoring of a publicly accessible area triggers a DPIA under Art. 35 — the basis for the 'behavior is personal data but not biometric' line and the DPIA duty). Primary / issuing-body guidance (tier 1). https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-32019-processing-personal-data-through-video_en
- European Union — "Artificial Intelligence Act, Regulation (EU) 2024/1689, Art. 5 (prohibited practices)" (restricts emotion-recognition systems in the workplace and education and curtails real-time remote biometric identification in publicly accessible spaces — the basis for the line where behavioral analytics tips into the heavier regime when it infers emotion or identifies individuals). Primary (tier 1). https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- UK Home Office Centre for Applied Science and Technology (CAST) — "Imagery Library for Intelligent Detection Systems (i-LIDS): User Guide" (the UK government benchmark image library used to certify the detection and false-alarm performance of video content analytics; scenarios include sterile-zone monitoring, abandoned-baggage detection, parked-vehicle detection, and doorway surveillance, and distinguish primary-detection from event-recording use — the basis for the i-LIDS benchmark and the difficulty of object-left-behind / sterile-zone analytics). Primary / government benchmark (tier 1/2). https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/143875/ilids-user-guide.pdf
- Wang et al. — "A comprehensive survey of crowd density estimation and counting" (IET Image Processing, 2025) (crowd counting is measured by mean absolute error (MAE) and RMSE on benchmarks such as ShanghaiTech; leading methods report MAE around 50+ on dense Part A scenes and around 6–7 on sparse Part B scenes — the basis for the 'crowd counting is an estimate' accuracy framing). Institutional / academic (tier 5/6). https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/ipr2.13328
- Lumana / industry analyses of AI video analytics — "How AI video analytics cut false alarms by up to 90%" and related practitioner reports (legacy motion detection produces false-positive rates of roughly 80%+; 90–99% of camera alerts are nuisance in many deployments; well-tuned AI analytics target a false-positive rate in the low single digits; object-classified analytics cut nuisance alarms by 90%+ and well-tuned perimeter deployments by over 95% — the basis for the false-alarm arithmetic and alert-fatigue framing, presented as representative ranges, not measured constants). Institutional / analyst (tier 5). https://www.lumana.ai/blog/how-ai-powered-video-analytics-cut-false-alarms-by-up-to-90
- MDPI Sensors — "A System for Real-Time Detection of Abandoned Luggage" (2025) (abandoned-object detection must achieve high recall while keeping false alarms low; occlusion, lighting change, and crowd interaction are the main difficulties, and performance is best on isolated objects in less dynamic scenes — the basis for 'object left behind is the hardest rule'). Institutional / academic (tier 5/6). https://www.mdpi.com/1424-8220/25/9/2872
- IPVM / OpenEye / vendor analytics documentation — "Line Crossing, Loitering and Intrusion Analytics" and tripwire-vs-motion discussions (line-crossing and intrusion rules with object classification fire only on chosen classes and directions, dramatically reducing the false triggers of raw motion from shadows, animals, wind, and headlights; loitering dwell times are commonly configurable from a few seconds to several minutes — the basis for the rule-authoring recipe and the tripwire-beats-motion framing, used as vendor field references, not standards sources). Vendor engineering / analyst (tier 4/5). https://answers.openeye.net/Configure/Analytics/OpenEye_Web_Services_AI_Analytics/Line_Crossing,_Loitering_and_Intrusion_Analytics
