Detect shrink-relevant events from transaction and sensor data, hold each observation in an internal queue with its frames and its confidence, and leave every approach to the loss-prevention manager.
Ingest point-of-sale exceptions, sensor events and camera observations from supported retail and video sources.
02
Keep every observation about the event itself, with no identity attached and no watchlist consulted.
Reason
03
Score the event against the shrink patterns configured for that store, and rank the review queue.
04
Attach the frames, the model version, the threshold and the measured error rate to each observation.
05
Hold the observation inside the retailer's own systems, in an internal queue, and nowhere beyond it.
Decide
06
Suppress its own alerting where image quality, confidence or cohort variance breaches its configured limits.
07
Route every observation to the certified loss-prevention manager, who decides whether anyone is approached.
Out
08
Retain the observation, its frames, its retention clock and the reviewer who closed it.
09
Execute write actions only inside the approval boundaries agreed during implementation.
→Product statement
The agent describes an event; the loss-prevention manager forms the suspicion, decides any approach, and answers for it.
Example workflow
One observation, event to review
AgentHuman
1Event receivedPoint-of-sale exception, sensor event, camera observation or an inventory variance
2Signals gatheredTransaction lines, the frames either side of the event, store layout and the retention clock
3Observation scoredEvent description, frames, measured error rate and confidence
4Suppression checks runIdentity-free checks, retention limits, cohort-variance limits and the confidence threshold
No human action required
Every stage before the confidence gate runs unaided, and nobody is approached at any of them — the agent is observing, and the manager's lane opens at the gate.
5DecisionBranches at the review threshold
Low ambiguity
Goes to the loss-prevention manager to review.
High ambiguity
Stays in the queue for later review.
Manager review
The observation is held with its frames, its measured error rate and the confidence.
Close · Investigate · Send to legal
Reviewed — closed or escalated▼
6Case systems updatedOnly where write access and approval policy allow it
7Case evaluatedUnfounded observations, reviewer closures, cohort variance and complaints received
Dismissals
Every reviewer closure is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Authorising an approach, stop, question or detention.
Confirming a match as the identification of a person.
Creating or sharing a suspect record beyond the retailer.
Contacting police or furnishing an identity to them.
Automation boundaryAgent acts unaided
✓Detect and log a shrink-relevant event to an internal for the named owner.
✓Run transaction-exception analytics with no person into the review queue.
✓Flag an inventory-to-sales variance for a human.
✓Suppress its own alerting when quality.
Any write happens inside the boundaries agreed at implementation, never ahead of the manager's review.
Issuing a trespass notice, a ban or a court petition.
Enrolling anyone into a biometric or watchlist database.
Changing a threshold, a model version or a camera location.
Resolving a complaint, dispute or reinvestigation request.
Example output
One observation, annotated
Everything the agent reports is attached to the event it was drawn from.
Observation output · single eventIllustrative example
Event
What was observed
Subject
Source of record
Confidence
Where it went
Self-checkout lane
An item crossed the scanner unscanned and was bagged, in the frames either side
Not identified
Lane log and lane camera
74%
Internal review queue
As receivedTaken from the lane log and the frames around the event — nothing on this side is decided by the agent.
Evidence usedTransaction lineFrames either sideLane exception history
Why this is an observationIt says what happened at the lane, not who did it and a person still decides.
ActionCloseInvestigateSend to legal
What the score decidesBelow the configured threshold the observation stays in the queue instead of reaching.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Every eventFrom the lane and the sensor
03Observation
Describe the event
Draw on the transaction log, the frames around the event and the patterns configured for that store — never on a biometric template.
01Approved path
Look at events, not people
Routine exception analytics arrive already scored and already queued.
02Human review
Send review to what could reach
Under a biometric statute a shopper can sue on collection alone, and the count follows the footfall — so observations stay identity-free and the manager's read starts where the harm sits.
04Build an evidence trail
Every observation keeps its frame, its retention clock and its reviewer.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Exception and shrink analyticsSensormatic Shrink Analyzer Zebra Workcloud Actionable Intelligence
Integration availability depends on the client's existing systems and API access.
Agent controls
Six layers between the model and a person
Every layer wraps the next, and the map below names its blind spot.
L6 · Outermost — last line of defenceInward → L1 · closest to the model
L6Rollback / safe modeStop scoring and hold the queue when evaluation, image quality or cohort variance degrades.Roll back
L5Version monitoringTrack model, firmware, threshold and camera-location changes.Track
L4TraceabilityRecord the frames, the model version, the measured error rate and the reviewer.Record
L3Manager reviewHold observations for the certified loss-prevention manager; an alert is not reasonable suspicion, and only a person forms that.Gate
L2Policy guardrailsTest observations against the identity-free rule, the retention limits and the variance limits; a failure holds the observation.Restrict
L1Confidence thresholdsKeep low-confidence observations in the queue rather than in front of a reviewer.Require review
Model coreObservation produced — event description, frames, measured error rate and confidence
L1 – L2Test whether an observation may stand
L3Puts the decision in a trained reviewer's hands
L4 – L5Preserve the frame, its clock and its reviewer
L6Stops scoring and holds the queue
How Nestack evaluates it
Evaluate the whole observation path — not only the score at the end of it.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — what the reviewer is shown
Depth of coverage ▼
E1Final-output evaluationDid the observation describe an event a reviewer found had actually happened?
E2Step-level evaluationDid the agent read the right transaction, the right frames and the right store configuration?
E3Tool evaluationDid it write to the correct store, the correct queue, and nowhere outside it?
E4Confidence calibrationDo low-confidence observations actually close unfounded more often?
E5Slice evaluationHow does the unfounded rate change across specific shopper cohorts?
E6Business outcomeHow many observations closed unfounded, and how many drew a complaint?
Floor — the person who gets approached
Failure modes
Where each failure originates in the agent
Seven modes, from detection to review.
Agent lifecycleDirection of processing →
01 · Retrieval1 mode
ZK-03
Wrong frames attached
Frames from another lane or another minute are bound to the event.
Stage gathersTransaction logs, frames, with the source each came from
02 · Reasoning2 modes
ZK-04
Assistive movement read as concealment
A mobility aid, a carer's bag or a garment becomes a concealment signal.
ZK-06
Unrelated events linked
Separate events are joined into one pattern on a weak signal.
Stage proposesEvent description, frames and confidence
03 · Tool / write2 modes
ZK-02
Record written outward
An observation reaches a system outside the retailer before a reviewer read it.
ZK-05
Alert lands on the floor
An observation reaches a handset near the shopper instead of the review queue.
Stage writesOnly where write access and approval policy allow it
04 · Output1 mode
ZK-01
Score read as certainty
A ranked observation is read as though it had named someone.
Stage returnsThe observation the manager reads before deciding
05 · Change / Version1 mode
ZK-07
Threshold moves unannounced
An update shifts the threshold, and the rise lands on one cohort first.
Stage tracksModel, firmware, thresholds and camera locations
Sev-1 · a held act performed by the agentSev-2 · an unfounded observation reachesSev-3 · image quality degrades
An aggregate unfounded rate can look tolerable while one cohort of shoppers carries several times it and another barely registers. Read as a lift on the all-event baseline.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Darker-skinned shoppers
9.7%
2.7×
Review
Shoppers using mobility aids
7.6%
2.1×
Review
Parents, carers and large-bag shoppers
4.7%
1.3×
Watch
Lone adult shoppers, clear lit aisle
1.8%
0.5×
Normal
Bar: unfounded-observation lift vs. the all-event baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
Nothing here closes on an apology
Nothing is closed until the miss can be re-run against the next release and fails it That suite is what the following detection is measured against..
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Unfounded observations rise in one shopper cohort.
02Diagnose
Which of them moved — the threshold, the camera, the image quality, or how the frames were read?
03Improve
Version, reviewer and the frames behind the change stay together.
04Verify
The gate is the case, not the reviewer — a fail holds it.
05Learn
The case sticks, and the review threshold moves with it.
Learn → DetectThe return edge. The next detection is measured against a suite this cycle lengthened.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, observation workflow, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Store and event-type discovery and boundary definition.
02Transaction and camera-source assessment.
03Threshold, retention and variance-limit mapping.
04Event ingestion and identity-free.
05Scoring logic and frame binding.
06Confidence scoring and reviewer routing.
07Loss-prevention review.
08Case-system and video integration.
09Paired-frame cases.
10Guardrails and approach controls.
11Observation-trail instrumentation.
12Deployment, documentation and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
Capability✓ in scope · — not at this tierPilotOne store, one event typeProductionProduction store estateAdvancedMultiple banners / regions
Introduced at Pilot
Observation against your own patterns✓✓✓
Manager review✓✓✓
False-positive baseline✓✓✓
Introduced at Production
Reporting by site—✓✓
Reviewer workflow in your systems—✓✓
Approved internal write-back—✓✓
Case-system integration—✓✓
Introduced at Advanced
Multi-jurisdiction retention rules——✓
Multi-stage loss-prevention approvals——✓
High event volume——✓
Enterprise retention controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, transaction volume, approval controls and deployment requirements.
Separate from buildBuild pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bringWe build with it
01Your event types and store configurations→Event ingestion and identity-free normalisationWeek 1
02Representative events already reviewed→Observation baseline and frame bindingWeek 2
03Your retention clocks and variance limits→Retention and variance-limit mapping, and automation-boundary definitionWeek 1
04Access to relevant APIs, feeds or exports→Transaction, sensor and video-source assessment, then integration setupWeek 2
05Approaches that were wrong→Paired-frame cases and the evaluation suiteWeek 4
06What an observation must reach before anyone acts→Review thresholds, approach routing and controlsWeek 3
07A named loss-prevention lead to review events→Loss-prevention review workflow, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Phases land on real weeks, so the fifth carries evaluation and pilot together rather than in sequence.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Event-type discovery, retention mapping and the automation boundaryW2Sensor and transaction feeds in placeW3Scoring logic, confidence scoring and review controlsW4Paired-frame testing and approach guardrailsW5Case-system integration, pilot stores and targeted correctionsW6A month of observations reviewed by loss prevention, then handover
Reading the bandBars are the workstreams, not a smoothing. Week 5 holds two.
At the end of W6Sign-off against real observations, then Agent Care monitors.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Retail AI agent
Build a shrink-detection agent around the manager who forms the suspicion.
Show us your event types, your camera estate and who is certified to approach a shopper. A stop that should not have happened cannot be withdrawn, and a false accusation of theft is defamation and unfair-practices exposure the moment it is made — so we set what an observation must reach first, and leave whether a shared suspect record is a consumer report to your counsel, because that question is unresolved.
