Purpose
Convert connected-accounts analytics — linkage signals, abuse-network patterns, and historical enforcement outcomes — into defensible, tiered enforcement thresholds with explicit false-positive tolerances and evasion resistance built in. Replaces gut-feel threshold-setting ("ban at 3 accounts") with data-backed guardrails a policy manager can defend to legal, appeals, and leadership.
When to Use
Invoke this skill when the user asks to:
- Set or revise enforcement thresholds for linked/connected accounts
- Design ban-evasion or re-registration detection policy
- Recommend how many linkage signals should trigger an action
- Translate abuse analytics into a tiered enforcement ladder
- Balance false positives against abuse capture for a multi-account policy
- Build a defensible rationale for an enforcement threshold decision
Inputs Required
Before starting, collect:
- Abuse type: What connected-accounts behavior this covers (ban evasion, coordinated inauthentic behavior, fake account rings, credential-shared abuse, review manipulation, etc.)
- Available linkage signals: What the platform can observe (device ID, IP, payment instrument, cookie/fingerprint, behavioral similarity, shared PII, referral graph, etc.) and reliability of each if known
- Historical enforcement data: Prior action volume, appeal/overturn rate, known false-positive incidents, catch rate on confirmed rings
- Current threshold (if any): The existing rule being revised, and why it's inadequate
- Enforcement actions available: The action menu (warning, feature limit, temporary suspension, permanent ban, network-wide takedown, human review)
- Risk posture: How the platform weighs missed abuse vs. wrongly-actioned legitimate users (regulatory exposure, brand sensitivity, user harm severity)
- Volume constraints: Human-review capacity and acceptable manual-review queue size
If historical overturn rate or signal reliability is unknown, use industry-conservative defaults and flag every point where the recommendation depends on that assumption.
Instructions
Step 1: Signal Reliability Classification
Rank each available linkage signal by strength and false-positive risk. Legitimate users share infrastructure constantly — the recommendation lives or dies on this classification.
- Strong signals (low false-positive risk): Shared payment instrument, matching hard PII (SSN/verified ID), device hardware ID with limited sharing history
- Moderate signals: Cookie/browser fingerprint, sustained behavioral similarity, referral-graph proximity
- Weak signals (high false-positive risk): Shared IP (households, offices, mobile carrier NAT, VPNs, universities), shared coarse geolocation, same device model
- For each signal, note its legitimate-overlap scenarios — the innocent reasons two accounts share it. This is the primary source of false positives and must be documented.
Step 2: Composite Threshold Logic
Recommend how signals combine to trigger action — single signals rarely justify enforcement.
- Define a signal-scoring model: assign weights (e.g., strong = 3, moderate = 2, weak = 1) and set a trigger score, OR
- Define combination rules (e.g., "1 strong + 1 moderate" or "2 moderate + confirmed prior violation")
- State explicitly what a weak signal alone should NOT do — shared IP alone should never trigger a ban
- Add corroboration requirements: which combinations demand human review before automated action
Step 3: Tiered Enforcement Ladder
Map confidence bands to graduated actions. Higher confidence → harsher automated action; lower confidence → softer action or human review.
- Tier 1 — High confidence (strong composite score, confirmed prior abuse in network): direct enforcement matching the primary account's status
- Tier 2 — Medium confidence: feature limits, friction (re-verification challenge), or shadow-monitoring
- Tier 3 — Low confidence / weak-signal-only: monitor-and-log, no user-facing action
- For each tier specify: trigger condition, action taken, whether it is automated or human-reviewed, and appeal path availability.
Step 4: False-Positive Tolerance Band
Set an explicit acceptable false-positive rate and tie it to the risk posture from intake.
- Recommend a target overturn-rate ceiling per tier (e.g., Tier 1 automated actions should sustain overturn rate under a stated %)
- Identify the highest-risk false-positive population for this abuse type (e.g., families, shared workplaces, developing-market shared-device users, VPN users) and recommend carve-outs or elevated review for them
- State the tradeoff explicitly: what abuse capture is sacrificed by keeping the threshold conservative, and vice versa
Step 5: Evasion Resistance Analysis
Assume the adversary knows the threshold. Stress-test it.
- Identify the cheapest evasion move against the proposed threshold (rotate one weak signal, use a new payment method, etc.) and its cost to the abuser
- Recommend which signals to keep opaque vs. which are already known to abusers
- Add anti-gaming provisions: velocity checks, cross-signal consistency checks, or dormancy patterns that catch deliberate signal-spoofing
- Flag where a threshold is trivially evadable and should not be relied on as the sole trigger
Step 6: Rollout & Monitoring Plan
Ship the threshold safely.
- Shadow mode first: run the threshold in log-only mode for a stated period; measure would-be action volume and overturn projections before going live
- Staged activation: enable Tier 3 monitoring → Tier 2 friction → Tier 1 enforcement in sequence
- Kill-switch criteria: the specific overturn rate or volume spike that triggers rollback
- Monitoring metrics: catch rate, overturn/appeal rate by tier, review-queue volume, evasion-recurrence rate
- Review cadence: when to re-tune (recommend a fixed interval plus event-triggered review after any evasion campaign)
Output Format
- Structure: Six labeled sections following the steps; signal classification and enforcement ladder presented as tables; threshold logic and rollout as structured lists
- Length: 1,000–1,400 words
- Format: Structured policy document — tables for signal classification and the enforcement ladder, prose for rationale, checklists for rollout
- Sections: Signal Reliability Classification → Composite Threshold Logic → Tiered Enforcement Ladder → False-Positive Tolerance Band → Evasion Resistance Analysis → Rollout & Monitoring Plan
- Tone: Trust & Safety policy lead — analytical, precise, defensible; every threshold accompanied by its rationale and its tradeoff, never a bare number
Quality Checklist
Before delivering output, verify:
- [ ] Every available signal is classified as strong/moderate/weak with at least one documented legitimate-overlap scenario
- [ ] No enforcement action is triggered by a single weak signal alone
- [ ] The enforcement ladder has at least three tiers, each mapping a confidence band to a specific action and review path
- [ ] A numeric false-positive tolerance ceiling is stated per tier and tied to the stated risk posture
- [ ] The evasion analysis names the cheapest evasion move and states its cost to the abuser
- [ ] The rollout plan includes a shadow-mode phase and an explicit kill-switch criterion
- [ ] Every threshold value is accompanied by its rationale and the abuse-capture tradeoff it implies
Notes
- Shared IP is the single largest source of connected-accounts false positives — treat any IP-only threshold as a monitoring signal, never an enforcement trigger, especially in markets with heavy carrier NAT or shared devices.
- The most defensible thresholds are graduated: they let confidence, not a hard count, decide severity. A flat "N accounts = ban" rule is both over-inclusive for legitimate multi-account users and trivially evadable by abusers.
- Always recommend shadow mode before live enforcement — projected overturn rate on real traffic is the only reliable way to validate a threshold, and it converts a policy debate into a data question.
- Re-tune after every observed evasion campaign; a threshold that was optimal at launch decays as adversaries adapt to it.
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills