The technical page.
This page exists so anyone with an hour can audit what we publish. If you are here for the daily read, you do not need any of this — start with About. If you are a skeptic, a journalist, or an ex-quant: welcome, the receipts are below.
What's in a brief
Every weekday morning the system emits one JSON object per asset (BTC, ETH, SOL spot). Each object carries:
- Posture — ACT, WATCH, or AVOID — computed deterministically from the regime classifier + risk gates.
- Regime label — one of ten regime classes (trending bullish, range-bound, high volatility, etc.).
- Volatility band — a 5-day p10–p90 forecast interval. This is the only forecast we make that has historically beaten naive baselines out-of-sample.
- Direction lean — long, short, or neutral. On out-of-sample tests this is, by our own measurement, a coin flip. We publish it for transparency, not as a claim.
- Conviction score — 0 to 100, calibrated against historical signal_outcomes via triple-barrier labeling.
- Trigger — what would move the posture.
Data sources
The engine consumes a single market data feed: Hyperliquid spot OHLCV + open interest + funding rates at 15-minute primary timeframe, with derived 1h / 4h / 1d / 1w views. No social media inputs. No on-chain alpha-source inputs. No paid data feeds.
We previously evaluated a Binance futures feed; the WebSocket is geo-data-blocked from our infrastructure region, so we switched to Hyperliquid. Status page shows the live feed health.
How each brief is timestamped
Two anchors, used together:
V1 — content hash + git history
Each daily brief is serialized to canonical JSON (sorted keys, no whitespace) and hashed with SHA-256. The (date, hash, git commit short SHA) triple is appended to data/proof-log.jsonl. The full immutable per-day archive lives at data/proofs/brief-YYYY-MM-DD.json.
To swap a past brief, an attacker would have to rewrite this repo's public git history on GitHub — detectable via signed-commit infrastructure and any cloned mirror.
V2 — Bitcoin OpenTimestamps
Each per-day archive's hash is also submitted to OpenTimestamps calendar servers. The resulting .ots file (alongside the archive in data/proofs/) is verifiable against the calendars immediately, and gets upgraded to a full Bitcoin merkle proof within hours once BTC confirms the calendar's aggregation root. After that, the proof is verifiable against any Bitcoin node — no GitHub trust required.
How to verify a brief independently
- Install the OTS client:
pip install opentimestamps-client - Download the archive and proof for the date, e.g. 2026-06-02:
- Run
ots verify brief-2026-06-02.json.ots. Output shows the Bitcoin block height + timestamp where the hash was confirmed. If the brief was edited after publication, verification fails.
How the posture is computed
Three deterministic stages, in order:
- Regime classification. A trained classifier reads the multi-timeframe market state and emits a regime label + confidence. Persisted to Redis on every primary-timeframe bar close.
- Risk gates. If any hard gate trips (unstable regime, cascade risk, conflicting multi-timeframe, etc.), the posture defaults to AVOID regardless of the directional read. These gates only ever tighten — they never loosen.
- Posture mapping. Surviving signals are mapped to ACT (qualifying setup), WATCH (criteria not met yet), or AVOID (hostile environment).
Posture is not a discretionary call. Two engineers reading the same raw inputs through the same code would compute the same posture for the same bar.
What gets tested before a hypothesis becomes a feature
Every claim of edge is logged on the hypotheses page with a metric, a direction, a confidence weight, and a deteriorating flag. The flag flips to true the moment the live data trends against the claim. We do not wait for the post-mortem.
Six edge candidates have already been formally retired after out-of-sample testing — directional alpha was not among them. Volatility-interval forecasts (the 5-day band) beat naive baselines OOS on every asset we tested. That is the only edge we currently believe in, and we don't claim it as a directional advantage.
Cross-checks running every 15 minutes
Four monitor services watch the primary engine in parallel: regime, momentum, risk, volatility. When two of them disagree on the same bar, the disagreement is logged with severity and surfaced publicly on the track record. Dozens of disagreements are logged per week and surfaced on the track record; each one widens the conviction interval before sizing.
Frozen-engine window
The signal engine's source is publicly frozen at a specific git commit during each window. While the window is open, the operator commits to not modifying any code path that influences a published call — regime classifier, posture mapping, gate thresholds, or the snapshot exporter. The outputs you read during the window are downstream of code you can audit right now.
The freeze is a Numerai-tournament-style commitment: the model's spec is frozen, the operator gives up the ability to revise mid-window, and any required emergency fix is publicly logged on this page within 24 hours. Read the raw manifest at /data/engine-freeze.json.
Operating model
The site, the engine, the snapshot exporter, the watchdog, and the OTS upgrade cron all run on a single Mac mini. The static site is published to Cloudflare; the engine talks to Hyperliquid; nothing about this product requires our infrastructure to be reachable to verify what was already published.
Outages and incidents are surfaced on the status page as they happen.
What we do not run
No machine-learning auto-execution. No reader capital is managed by us. No counterparty risk to us — readers never deposit anything to use the brief.
Source code & data
The static site, snapshot exporter, watchdog, OTS upgrade cron, and per-day brief archives are public at github.com/DailyProfitAI/swing-profit-AI. The signal engine is closed-source — its open release would let bad actors game the adaptive thresholds. The sealed-binary replay reproducer is on the roadmap.