The system is designed under the assumption that operators will attempt to disguise or fragment their infrastructure. Resilience is therefore treated as a first-order design constraint rather than a secondary feature.Documentation Index
Fetch the complete documentation index at: https://none-38c466ad.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
9.1 Threat Model
Actors are modeled along a spectrum of sophistication:- Superficial adaptation: surface-level edits such as image swaps, asset churn, or minor template changes
- Structured rotation: systematic replacement of trackers, endpoints, or providers
- Targeted evasion: advanced tactics including cloaking, client-fingerprint gating, and decoy deployments
9.2 Validation Philosophy
Resilience is validated by perturbing inputs and testing for cluster stability. For a given snapshot, selected signals are removed, altered, or randomized. Clusters are then recomputed and compared using bootstrap Jaccard similarity: Parameters omitted by design. High stability under perturbation demonstrates that linkages depend on consistent structural overlap, not on any single artifact.9.3 Design Invariants
Several invariants are enforced across all signal families:- Rarity-awareness prevents common artifacts from dominating correlation
- Cross-class diversity is required before edges are admitted, avoiding single-source dependence
- Temporal boundedness ensures stale evidence decays and only current behavior persists
- Negative evidence filters suppress known sources of artificial linkage
9.4 Baseline Contrast
Basic approaches collapse under trivial operator changes:- Static DOM matching breaks with minor edits
- URL-based asset correlation is defeated by cache-busting
- CDN commonality causes over-merging without rarity controls