A protective rule can harm legitimate users when a signal that looks suspicious actually reflects a normal route, redirect, or work pattern.
The practical check
Ask what the signal truly measures, who is affected by a false positive, and what evidence distinguishes abuse from normal use.
Where AI fits
AI can group events, identify patterns, and prepare false-positive candidates for review.
The human decision
People set protection policy and decide how to handle exceptions without weakening the real safeguard.
The lesson
A false positive is a reason to validate what a signal measures before treating it as proof of abuse, not a reason to weaken a needed safeguard without evidence.
The Build Log companion follows the contextual review that separates a suspicious-looking signal from normal use.
AI Skills
Use this lesson with the AI assistant you already use
Create a signal, context, false-positive evidence, and policy-owner table.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
Optional: for a visual report and saved memory, run /dxdev first.
Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.
dxdev LESSON · paste into your AI agent
LESSON: Check a Security Signal Before Acting
WHAT TO SHARE:
A de-identified description of the work, current evidence, and the decision you are considering.
ASK YOUR AGENT TO:
1. Separate confirmed facts from assumptions and unanswered questions.
2. Create a signal, context, false-positive evidence, and policy-owner table.
3. Identify the narrowest useful next review step.
RETURN:
A short table with the evidence, uncertainty, human-owned decision, and next action.
BOUNDARY: Do not change records, contact anyone, route work, publish content, or act in an external system. A person must review the evidence and approve every consequential step.
