Docs
Declare, define, optimize, ship.
1. Declare the knobs
List the parameters and their ranges (int, float, log-scale, categorical). These are the magic numbers you want settled — TTLs, batch sizes, thresholds, learning rates, retries, timeouts.
2. Define the objective
Provide a function that runs your system with a given config and returns a score (throughput, cost, accuracy, P&L proxy — whatever you optimize). Tune treats it as a black box; your logic and data stay yours.
3. Optimize with OOS
Tune runs Bayesian/TPE search and validates every candidate on held-out data (time-split, k-fold, or your splitter). It reports the in-sample vs out-of-sample gap so an overfit winner is caught, not shipped.
4. Ship the config
Export the winning, validated config as JSON/YAML/env with its score and trial history. Commit it, deploy it, and schedule a drift-aware re-tune to keep it current.
What you can tune
| Domain | Examples |
|---|---|
| Backend / infra | cache TTL, batch size, connection-pool size, retry count, timeout, prefetch depth |
| ML / data | learning rate, regularization, tree depth, feature thresholds, ensemble weights |
| Pipelines / ops | concurrency, chunk size, debounce window, rate-limit, backoff factor |
| Decision thresholds | classification cutoffs, alert thresholds, score gates |
Secret-sauce boundary: Tune ships the search engine and the out-of-sample validation discipline. It optimizes against the objective you define on your data and does not contain — and will never share — our own parameters, thresholds, signal definitions, or models. Your objective code and data stay in your environment on on-prem plans. This is a methodology product, not a data product.