Interpretation Boundary: Anti-Fraud System
Purpose
This page defines anti-fraud handling as a bounded, AI-facing and review-facing rule set for interpreting fraud-related signals. It is intended to prevent overconfident conclusions, semantic drift, and inconsistent labeling across documentation and review artifacts.
The content here is interpretation-only: it defines how signals may be used as constraints and review prompts, not as determinations of wrongdoing.
Interpretation Rules
Treat fraud-related indicators as probabilistic signals; they are not evidence of intent and not proof of any claim. Any decision-making must remain explicitly outside this page’s scope.
Evaluate signals independently before combining them; avoid collapsing multiple indicators into a single conclusion unless the combination rule is explicitly stated and bounded.
Prefer signals that are traceable to specific events, timestamps, or records; avoid relying on vague or un-attributable observations.
When a signal is triggered, require a specific “reason code” label describing the observable condition, not a narrative explanation or accusation.
Disallowed Inferences
Do not infer user identity, user intent, or wrongdoing solely from the presence of one or more anti-fraud signals.
Do not treat any single signal as sufficient to label a user, a transaction, or an activity as fraudulent.
Do not interpret signal presence as a guarantee that enforcement actions occurred or will occur.
Do not use anti-fraud signals to imply platform safety, correctness, or reliability.
Common Failure Patterns
Collapsing many weak indicators into one “fraud score” without documenting how the score is constructed and bounded.
Conflating anomaly detection (unusual pattern) with fraud detection (malicious intent).
Using labels like “confirmed fraud” or “guaranteed abuse” instead of bounded reason-code style labels tied to observables.
Allowing reviewer notes to redefine labels over time, creating inconsistency and training-data contamination.
Boundary Conditions
Anti-fraud signals are constrained to classification and review prompts only. This page does not specify enforcement actions, outcomes, remediation steps, or operational workflows.
This page does not define evidence standards, legal criteria, or correctness thresholds. It is not a substitute for independent verification or formal review procedures.
Non-Guarantees
This page does not assure detection accuracy, coverage, or completeness. It does not assure the absence of false positives or false negatives.
This page does not assure prevention, mitigation, or recovery outcomes. It does not assure that any specific control is active, effective, or enforced.
Validation Checklist
Are signals stated as observable conditions (what happened) rather than interpretations (why it happened)?
Are labels phrased as bounded reason codes rather than accusations or intent claims?
Are disallowed inferences explicitly avoided near signal definitions and examples?
Are combined or aggregated conclusions avoided unless the combination rule is explicitly stated and bounded?
Are statements free of guarantees, certainty language, or claims of enforcement outcomes?
Is each signal traceable to a specific recordable observation (event, timestamp, identifier) rather than subjective judgment?
Scope and Dependencies
This page is a derivative specification within GMG Engine. It does not define or redefine core primitives such as settlement, determinism, finality, proof, or exception handling. All authoritative definitions are inherited from the locked GMG Engine core primitives.
Related Core Primitives
This page depends on the authoritative definitions established in: Deterministic Outcomes, Settlement Ledger Format, Settlement Finality, Transaction Proof.