tsauditor currently supports domain="finance" and domain="sensor",
each with their own default thresholds (e.g. audit_frequency's max gap
of 5 calendar days for finance, audit_point_anomalies's wider z-score
threshold for finance vs sensor). Cryptocurrency data has different
characteristics from traditional equities — it trades 24/7 with no
weekend gaps, and has historically had higher volatility, meaning a
finance-tuned threshold may over- or under-flag for crypto data.
**What's needed:** a proposal (can be the PR itself, or an issue discussion
first if you want to align before writing code) for what
domain="crypto" should set differently across the modules that branch on
domain — at minimum profiler/frequency.py (since crypto has no
weekend gap, "irregular frequency" means something different) and
anomaly/point.py (volatility threshold). Each proposed default should
come with a short justification, similar to how the finance vs sensor
thresholds were reasoned through.
**Why this is approachable:** you're not inventing new detection logic,
just proposing and wiring through new default parameter values — the
if domain == "finance": ... elif domain == "sensor": ... pattern already
exists in each relevant module; this just adds one more branch.
**A note on rigor:** this project holds a higher bar for the leakage/
module specifically, since that's the core research contribution — a new
domain preset for leakage/ thresholds (e.g. binary/continuous AUC
cutoffs) would need real reasoning about why crypto targets behave
differently, not just a different number picked by feel. Starting with
profiler/ and anomaly/ first is the easier path in.
tsauditor currently supports domain="finance" and domain="sensor",
each with their own default thresholds (e.g. audit_frequency's max gap
of 5 calendar days for finance, audit_point_anomalies's wider z-score
threshold for finance vs sensor). Cryptocurrency data has different
characteristics from traditional equities — it trades 24/7 with no
weekend gaps, and has historically had higher volatility, meaning a
finance-tuned threshold may over- or under-flag for crypto data.
**What's needed:**a proposal (can be the PR itself, or an issue discussionfirst if you want to align before writing code) for what
domain="crypto" should set differently across the modules that branch on
domain — at minimum profiler/frequency.py (since crypto has no
weekend gap, "irregular frequency" means something different) and
anomaly/point.py (volatility threshold). Each proposed default should
come with a short justification, similar to how the finance vs sensor
thresholds were reasoned through.
**Why this is approachable:**you're not inventing new detection logic,just proposing and wiring through new default parameter values — the
if domain == "finance": ... elif domain == "sensor": ... pattern already
exists in each relevant module; this just adds one more branch.
**A note on rigor:**this project holds a higher bar for the leakage/module specifically, since that's the core research contribution — a new
domain preset for leakage/ thresholds (e.g. binary/continuous AUC
cutoffs) would need real reasoning about why crypto targets behave
differently, not just a different number picked by feel. Starting with
profiler/ and anomaly/ first is the easier path in.