Quant Trading for Programmers 25: Add Production Checks To Paper Trading

Article 24 made the paper-trading account state saveable and restorable. One engineering gate is still missing: before and after a run, the system should check whether inputs and outputs are reasonable.

Article 25 adds production checks. They are not business risk controls. Their job is to keep obviously bad input out of the daily flow.

Production Checks Are Different From Risk Controls

Risk controls care about whether positions are too large or whether the cash buffer is sufficient.

Production checks care about more basic problems: whether cash is negative, whether market prices are missing, whether target weights exceed 100%, whether the daily report is empty, and whether the review record matches the snapshot.

This kind of check is closer to a readiness gate in an engineering system. It does not judge whether the strategy is good, and it does not decide whether the market is suitable for buying. It answers one question only: does today’s paper-trading flow meet the minimum conditions to continue and send an alert?

Check Inputs

Chapter 25 adds app/production_checks.py.

report = check_paper_cycle_inputs(
    account,
    last_prices={"000001.SZ": 10.0},
    target_weights={"000001.SZ": 0.4},
)

Input checks cover:

• Cash must not be negative.
• Stocks involved in positions and target weights must have market prices.
• Market prices must be greater than 0.
• Total target weight must not exceed 100%.
• A single target weight must not be negative.

Check Outputs

After the daily flow finishes, the result also needs to be checked:

report = check_paper_cycle_result(result)

The current checks are deliberately restrained: total equity must be greater than 0, the daily report body must not be empty, and the review record’s total equity must match the snapshot.

These rules are not complex, but they can block many low-level accidents.

Current Integrated Run

Article 25 also uses the paper-ops command for verification:

uv run python -m scripts.chapter_examples paper-ops

The command runs one check before the daily flow and one after it:

In this example, both input and output checks pass, while business risk control is still blocker. That is exactly the point: production checks and risk controls are not the same thing. Legal input and a complete flow do not mean account risk is low. High account risk does not mean the program itself failed to run correctly.

Chapter Update And Repository

This chapter adds:

• app/production_checks.py.
• Input checks for the paper-trading daily flow.
• Output checks for the daily flow result.
• An integrated paper-ops example showing pre-run input checks and post-run output checks.
• A clear boundary between production checks and business risk controls.
• tests/test_production_checks_paper.py, covering normal input, blocker issues, and valid daily flow results.
• A stage review for articles 21-25.

Repository:

https://github.com/ax2/zi-quant-platform

Code for this chapter:

git clone https://github.com/ax2/zi-quant-platform.git
cd zi-quant-platform
git checkout chapter-25
uv sync --extra dev
uv run pytest tests/test_production_checks_paper.py

Chapter 25 is commit 29f387a, tagged as chapter-25. The full test suite currently passes with 215 passed, with only existing FastAPI deprecation warnings.

Stage Review: Articles 21-25

The fifth group of five articles completes the transition from paper-trading state output to sustainable observation.

Article 21 compresses snapshots, risk controls, and rebalance plans into a recommendation summary, giving the system one clear daily action first.

Article 22 saves daily review records so equity changes, risk levels, and recommended actions can be compared over time.

Article 23 links the daily paper-trading flow, integrating snapshots, risk controls, rebalancing, recommendations, daily reports, and reviews into one entry point.

Article 24 implements JSON persistence for account state, allowing paper trading to recover after a program restart.

Article 25 adds production checks so obviously bad inputs and outputs do not enter the daily flow.

This group does not rush into real notification channels. Before alerts, the system first needs to explain itself, support reviews, recover state, and check its own inputs and outputs. Otherwise, notifications would only push unreliable results to people faster.

The main code path now also has a cross-chapter command:

uv run python -m scripts.chapter_examples paper-ops

It links articles 21-25 into one runnable demonstration. The output contains recommended actions, review summaries, state persistence, and production-check results. When notification channels are added later, the notification layer can consume this flow’s output instead of rebuilding business logic.

Summary

Production checks are the engineering baseline.

Article 25 writes the basic gates before and after a paper-trading run into code. The next group can continue on this steadier chain by adding notification channels, real scheduling, and more complete data inputs.

WeChat

Follow ZiCode on WeChat

If this post was useful, you can follow later updates on WeChat as well.

X / Twitter

Follow @ax2_zicode

Faster technical notes, short thoughts, and new-post alerts are posted on X.

X Open X Profile @ax2_zicode