Interpretable and documented
Aspect 6 of 10. If nobody in your AP team can explain how a video analytics alert or an ORC match was generated, and nothing is written down, the organization cannot defend a case, improve the tool, or safely hand it off to the next investigator.
What you will be able to do
- Tell the difference between how a detection model works and why a specific alert fired.
- Set an explanation standard that matches what is at stake for the person flagged.
- Build the minimum documentation set for a deployed AP system.
- Give an accused shopper, associate, or store leader an answer they can act on.
Two different questions
Interpretability is about the system: what camera feeds and POS data it uses, what it weighs, and how it behaves across stores.
Explanation is about a single outcome: why this shopper was matched to a person-of-interest list, why this self-checkout transaction was flagged as a loss event, why this employee's till was escalated for review.
AP leaders are rarely asked the first question. They are asked the second one constantly, usually by a store manager, an accused individual, or legal counsel.
Match the explanation to the stakes
- Low stakes. A daily shrink summary or a suggested exception report needs little more than a note that AI was involved.
- Medium stakes. Prioritizing which self-checkout exceptions or POS void patterns get reviewed needs the main factors and a way to request a second look.
- High stakes. A facial recognition match against a person-of-interest list, a detainment recommendation, or an employee termination based on exception reporting needs the specific reasons, the data used, the human reviewer, and a documented appeal path.
A working test
Could the accused person repeat your explanation to a lawyer or a regulator and use it to challenge the outcome? If not, it is not an explanation.
"The vendor will not tell us"
You will meet video analytics, facial recognition, and shrink analytics platforms whose internals are proprietary. That does not remove your obligation, and it does not have to end the deployment.
- Ask for the input features, the training data description, and known limitations in writing.
- Ask for documented match accuracy across the demographics of your customer and employee base.
- Test the behavior yourself: run known non-matches through the person-of-interest list and record what triggers a hit.
- Keep a case management log so patterns are visible even when the model is not.
If a vendor will not describe what its facial recognition engine uses to generate a match, that answer is itself the finding, and it belongs in your risk record.
A scenario
A regional retailer uses a video analytics platform to flag suspected organized retail crime activity across stores. A district AP manager asks why one store's stops disproportionately involve a particular demographic. Nobody can answer. The vendor calls the matching logic proprietary, the sensitivity settings were configured by an LP analyst who left, and no one recorded the original thresholds.
What went wrong
The system was probably working as configured. The failure is that the configuration was never documented, so a fair question could not be answered and the pattern could not be corrected before it became a legal and reputational exposure.
The minimum documentation set
- Purpose. What the system is for (e.g., ORC detection, self-checkout loss prevention), and what it must never be used for.
- Inputs and sources. What camera feeds, POS data, or biometric templates it sees and where they come from.
- Configuration. Match thresholds, alert sensitivity, watchlist criteria, and who approved them.
- Human role. Who reviews an alert before action is taken, who can authorize a stop or detainment, and how often that happens.
- Performance. What a good match rate looks like, and what has been measured in your stores.
- Limitations. Known failure cases, such as lower accuracy in poor lighting or across certain demographic groups.
- Change history. Every software version, watchlist update, or vendor change, with dates.
Written once, kept current, and stored where an auditor, regulator, or your successor as AP director can find it.
Documentation is a handoff to the next person
Two moments prove whether your documentation was real: when the LP analyst who configured the system leaves, and when a regulator, plaintiff's attorney, or insurer asks what happened on a specific incident date.
Write for that reader. Short, dated, specific, and free of internal shorthand that nobody outside the AP team understands.
What to do in your own deployment
- Classify each AP system by stakes (shrink analytics vs. facial recognition matching) and set the explanation standard to match.
- Write a one-page system card for every AI tool used in loss prevention, from video analytics to case management.
- Require vendors to supply documentation as a contract deliverable.
- Log alerts, matches, and overrides in your case management system so patterns can be examined later.
- Give store-level associates and investigators a script for explaining an AI-assisted stop or flag.
- Review the documentation on a set schedule and after every material change, such as a new watchlist source.
Recap
- Interpretability explains the system, explanation covers a single alert or match, and you owe both.
- The level of explanation should rise with what the outcome costs the person, from a shrink report to a detainment.
- Vendor opacity around facial recognition or analytics logic is a risk to record and manage.
- Documentation earns its keep at handoff and under legal scrutiny, so write it for that moment.

