An LP analyst closes an incident report: $600 in consumer electronics, one suspect, store camera footage attached, case marked resolved. Three weeks later, a detective two counties over calls asking about a vehicle description that matches the same report almost exactly. Nobody made the connection, because the two incidents lived in two different systems, each one measuring its own closed case rather than the entity that ran through both of them.

That gap isn’t a failure of vigilance. It’s a design choice built into how most loss prevention data gets structured, and it’s worth examining directly.

The Metrics Most Teams Already Track

Most LP programs already know how to build a dashboard: shrink by SKU, average loss per incident, resale value of frequently targeted categories, time to case closure. These numbers are useful. They tell a store, or a district, what happened inside its own boundary during a given period.

What they weren’t built to answer is a different question entirely: does the person who hit this store last Tuesday show up in a report from a store forty miles away, filed under a different case number, closed by a different analyst who has no reason to ever see the first report?

Why the Boundary Is the Actual Problem

Organized retail crime rarely respects the boundary a case management system draws around it. A crew working a regional circuit generates a trail of individually unremarkable incidents: a $50 test run at one location, a mid-value theft at another, a return-fraud attempt somewhere else entirely. Each incident, viewed alone, looks like ordinary shrink. The pattern only becomes visible when someone deliberately connects location, timing, suspect description, and resale channel across cases that were never designed to talk to each other.

This is a structural issue, not a staffing issue. Even a well-staffed LP team, working diligently inside its own case queue, will not surface a cross-jurisdiction pattern unless the data architecture makes that connection possible before a human has to go looking for it. Repeat-offender identification depends on connecting behavioral patterns across time, location, and incident type. If the system’s unit of analysis is the case, and the case ends at the store’s front door, the network the case belongs to stays invisible by default.

What Happens When the Boundary Gets Removed

The evidence for what changes is not hypothetical. In 2024, Philadelphia faced a 33% year-over-year rise in retail theft. The response that produced arrests wasn’t a new detection tool; it was structural, additional detectives assigned specifically to ORC, mug shots and case details published to create a visible deterrent, and data sharing between retailers and police that let investigators follow a suspect across incidents that had previously been filed separately.

In Northern California, a coalition of retailers and law enforcement agencies formed a working group specifically because individual incident reports weren’t revealing the coordinated theft pattern hitting high-value categories like perfume and alcohol along the coast. Sharing surveillance footage and incident detail across organizations let investigators see that thefts attributed to different stores, different weeks, and different case files were the same operation moving through multiple points.

In both cases, the technology mattered less than the decision to treat the case boundary as something that could be crossed.

The Harder Question: Is This a Data Problem or an Incentive Problem

It’s worth asking directly whether the constraint is really technological. Most LP teams could, in principle, share more incident detail with neighboring jurisdictions today. Many don’t, and not always because the tools are missing.

A store’s KPIs are usually built around cases that store resolves. There’s rarely a metric that rewards a loss prevention manager for contributing the data point that let a different jurisdiction close a case somewhere else. If the system that measures performance stops at the same boundary as the case file, there’s no organizational incentive to invest time flagging a pattern that will be credited to someone else’s dashboard.

That means the fix isn’t only architectural. It’s also a question of whether “resolution” gets redefined to include contributing to a network-level pattern, not just closing a local file.

What a Connected Analytics Model Looks Like in Practice

A few characteristics separate teams that actually see the network from teams that only see their own cases:

Cross-referenced product and location data, so a theft in-store and a resale listing online are treated as one signal rather than two unrelated events tracked by different departments.

Suspect and MO tracking that persists across incidents and locations by default, rather than requiring an analyst to manually search for a match after the fact.

Dynamic reporting that can be filtered and re-filtered as new information arrives, rather than static monthly summaries that lock in a view of the data before the pattern has fully formed.

A working relationship with law enforcement built on structured data exchange, not one-off calls after an analyst happens to notice a coincidence.

This is the kind of environment Hubstream is built to support: pulling structured and unstructured signals, store incidents, resale listings, suspect descriptions, prior case history, into a single investigative view where the entity, not the case number, is what gets tracked over time.

Questions Worth Asking About Your Own Program

Before assuming the gap is a technology gap, it’s worth testing a few things directly. When a case closes, does anything in the workflow ask whether the same MO appears in another store’s file? Would your team even know if it did? Are your performance metrics structured in a way that rewards contributing to someone else’s case, or only closing your own? And if a detective in another jurisdiction called about a pattern that touched your stores, how long would it take your systems to confirm the overlap?

The Network Rarely Stops at Your Own Footprint

Connecting data across your own stores solves one version of this problem. It doesn’t solve the harder one: the same crew that hit your electronics section this month may be running an identical playbook against three competitors, cycling through resale platforms that none of your internal data touches at all.

Closing the gap inside your own four walls is necessary. It is also, most likely, only the first boundary worth questioning.