Observe
Read public Coinbase candles and open Kalshi markets.
FROM MATHEMATICAL IDEA TO RELIABLE SOFTWARE
Build the lab.
Protect the experiment.
In Lesson 01, observations became signals. Now we study how one small Python project turns a BTC 15-minute Strong Momentum signal into a testable paper system—and how careful engineering keeps live execution behind multiple gates.
OPEN THE STUDENT REPOSITORY ↗PUBLIC SOURCE · PAPER BY DEFAULT
01 / THE ENGINEERING MISSION
Make the right thing easy—and the dangerous thing difficult.
A model is only one part of a trading system. Reliable software must collect data, reject stale inputs, avoid duplicate work, record decisions, reconcile actual fills, settle positions, enforce limits, and fail safely.
The student repository deliberately contains one strategy: BTC 15-minute Strong Momentum. Its small size makes the whole system understandable.
02 / REPOSITORY MAP
A small project with clear responsibilities.
btc-15-minute-prediction-model/VIEW SOURCE ↗
scripts/btc_bot.pySignal, paper/live cycles, persistence, authentication, commands
scripts/report.pyRead-only results and performance summaries
tests/test_btc_bot.pyProof for signals, limits, fills, and safe defaults
tests/test_report.pyChecks reporting without changing the ledger
automation/btc-15m.timerRequests one cycle each minute
automation/btc-15m.serviceDefines the isolated background process
LIVE_TRADING.mdHuman checklist for the dangerous transition
.env.exampleEmpty credential names—never real secrets
Decide
Run deterministic filters and rank qualified candidates.
Remember
Use SQLite to preserve scans, trades, mode, losses, and P/L.
Explain
Report what happened without inventing missing results.
03 / STRONG MOMENTUM
The 15-minute trigger is a falsifiable rule.
The bot scans once per minute. It does not trade merely because BTC moved; candidates must satisfy time, price, movement, direction, freshness, liquidity, concentration, and estimated-value tests.
ABOUT THESE NUMBERSThese thresholds belong to the public student repository linked above, a deliberately simplified teaching implementation. They are close to, but not identical with, the internal Strong Momentum research variant running in our production system. Read code, don't assume — the two are related lessons in the same idea, not the same file.
Direction agreement
The movement from the window reference and latest three-minute movement must point toward the proposed outcome.
WINDOW MOVE+3-MIN MOVE=SAME SIDE
Side-balance alarm
If at least 80% of the last ten signals already chose the proposed side, the bot pauses that side.
candidate = (
2 <= minutes_left <= 12
and 0.20 <= ask_price <= 0.85
and spread <= 0.05
and abs(window_move) >= 0.0012
and window_and_3m_directions_agree
and candle_age_seconds <= 120
and estimated_edge >= required_edge
)04 / ONE SIGNAL, TWO EXECUTORS
Paper first. Live only by ceremony.
DISCOVER_CANDIDATE()ONE DETERMINISTIC SIGNAL
The strategy logic does not change with mode.
DEFAULT
Paper executor
- Simulates the displayed entry
- Uses a separate paper ledger
- Needs no credentials
- Cannot place a real order
LOCKED
Live executor
- Requires credentials and explicit gate
- Checks account exposure
- Uses actual exchange fills and fees
- Maintains separate live records
THE INVARIANTAdding an API key does not enable live trading. A fresh database, setup run, restart, or timer installation remains paper-only.
05 / DEFENSE IN DEPTH
No single switch should carry all the safety.
Paper default
Every new ledger starts with enabled = false.
Secret separation
The repository stores credential names, never populated keys.
Read-only preflight
Status, balance, candidate, and exposure can be inspected without ordering.
Exact confirmation
Activation requires a deliberate command and exact phrase.
Per-order guards
Positions, orders, balance, debit, and limits are checked again.
Untracked-order kill switch
An unknown executed KXBTC15M order disables future trading.
Fill reconciliation
Actual count, cost, and fees come from the exchange response.
Automatic session stop
Two losses or a $5 session loss disables live mode.
LIVE CEILINGS IN THE STUDENT REPO
Limits are code, not intentions.
MAX CONTRACTS1
MAX DEBIT$5
MAX LOSSES2
SESSION LOSS$5
06 / STUDENT WORKSHOP
Learn by asking, tracing, testing, and explaining.
Map the machine
Clone the repository, read its instructions, and draw the path from public data to report.
git clone https://github.com/preceptress/btc-15-minute-prediction-model.git
cd btc-15-minute-prediction-model
./setup.shRun paper mode
Perform a scan, inspect status, and explain why zero trades can be correct.
./venv/bin/python scripts/btc_bot.py cycle
./venv/bin/python scripts/btc_bot.py status
./venv/bin/python scripts/report.pyRead tests as specifications
Find the test proving new ledgers are paper-only. Predict failures before running them.
./venv/bin/python -m unittest discover -s testsExplain rejection reasons
Trace one rejected candidate: observation, threshold, Boolean expression, decision.
“Inspect recent scan rejection reasons. Do not alter the filters.”
Propose, don’t promote
Create a paper-only hypothesis. Explain how it could help, hurt, and be falsified.
“Review my proposed change and add tests. Keep live mode disabled.”
Threat-model the system
Imagine stale data, duplicate timers, partial fills, failures, leaked secrets, and manual activity.
“Identify every safeguard separating paper and live trading.”
07 / CAPSTONE
Earn confidence with evidence.
Teams present a bot that is understandable, reproducible, tested, observable, and safe by default. Live readiness is a review outcome—not a deadline.
Definition of done
THE ENGINEER'S QUESTION
“How will this fail—and will it fail safely?”
A strong model is interesting. A strong system is trustworthy.