Xiaosen Info System Overview
1. Project Introduction
The Xiaosen Info System is a rebound quantitative trading system for the A-share market, focused on the daily loop of "stock picking → ML scoring → in-depth per-stock analysis → report → sync", covering the Shanghai Main Board / STAR Market / Shenzhen Main Board / ChiNext four markets.
The system is built on real, full-volume market data, combining multiple machine learning algorithms and factor combinations to evaluate candidates from multiple dimensions, and completes daily stock selection, analysis and report generation through an automated workflow.
Online Access
- Project site: https://www.astock.com.cn/
- Daily positions: https://www.astock.com.cn/tracker/positions (currently in cash, no positions displayed)
- Historical profit records: https://www.astock.com.cn/tracker/history
Core Principles
- Data integrity: All conclusions are based on full real data; sampling is strictly prohibited as a substitute for full validation.
- Clear system boundaries: Subsystems run independently and reference each other read-only to avoid coupled modifications.
2. Data Foundation
The system uses locally stored CSV K-line data as the single source of truth, covering both daily and minute-level data, organized by market directory.
| Data type | Markets covered | Purpose |
|---|---|---|
| Daily K-line | Shanghai Main Board, STAR, Shenzhen Main Board, ChiNext | Medium/long-term trend judgment and strategy backtesting |
| Minute K-line | Shanghai Main Board, STAR, Shenzhen Main Board, ChiNext | Intraday high-frequency feature extraction and ML scoring |
The data columns are uniformly date, open, high, low, close, volume, amount, with automatic recognition of Chinese and English column names. A unified data-routing module dispatches by stock code prefix to the corresponding market sub-directory, ensuring consistency and auditability.
3. Subsystems
The system consists of multiple independent subsystems, each with its own role, working together to complete the full chain from stock selection to selling.
| Subsystem | Role |
|---|---|
| Rebound strategy engine | Strategy backtesting, algorithm evaluation and parameter optimization, outputting the best algorithm configuration per market |
| Minute-level ML analysis | Multi-interval resampling and multi-model ensemble for buy-success-rate scoring of holdings |
| Sell tracking system | Real-time quotes integrated, four sell-condition alerts with differentiated parameters per board |
| Per-stock multi-dimensional analysis | Full algorithm/factor combination evaluation of each holding with daily and minute data combined |
| Intraday timing analysis | Historical buy/sell timing win-rate statistics for smart intraday reminders |
| Position management | JSON-based position CRUD and trade history |
| Real-time quotes tooling | Market data interface wrapper with price query and network diagnostics |
4. System Runtime Architecture
4.1 Architecture Source
The following architecture information was generated by Archify from real source-code analysis of the project repository. Every module maps to a real source file, giving the diagram a verifiable, explainable code-to-diagram correspondence.
- Full interactive architecture diagram (Archify HTML output): Open architecture diagram
Interactive diagram notes
Open the link above to view the full interactive architecture diagram, supporting node search, route tracing, semantic views, theme switching, zoom/pan and presentation playback.
4.2 Architecture Overview
4.3 Core Components
| Component | Type | Role | Source files |
|---|---|---|---|
| Browser / Mobile | External | UI client | frontend/src/App.vue |
| Vue 3 Frontend | Frontend | UI + routing | frontend/src/main.ts, frontend/src/App.vue |
| FastAPI Backend | Backend | REST API + app entry | app/main.py, app/routers/api_v1.py |
| Data Sync Service | Backend | GitHub pull + local refresh | app/services/data_sync_service.py, app/services/github_service.py |
| Price Monitor Service | Backend | price checks + alerts | app/services/monitor_service.py, app/services/price_service.py |
| GitHub Source | External | position feed | app/services/github_service.py |
| Local Data & Snapshot | Database | cache + closing snapshot | app/services/cache.py, config.yaml |
| Scheduler / Cron Jobs | Backend | trade-day automation | app/services/scheduler_service.py |
4.4 Data Flow and Connections
| Connection | Direction | Description |
|---|---|---|
| HTTPS | Browser / Mobile → Vue 3 Frontend | User entry point, emphasis link |
| REST API | Vue 3 Frontend → FastAPI Backend | Frontend calls backend APIs |
| sync trigger | FastAPI Backend → Data Sync Service | Triggers data sync |
| fetch positions | Data Sync Service → GitHub Source | Fetches positions from upstream |
| price checks | FastAPI Backend → Price Monitor Service | Launches price-check tasks |
| snapshot + cache | Price Monitor Service → Local Data & Snapshot | Writes snapshots and cache |
| heartbeat | Scheduler → FastAPI Backend | Periodic health probe |
| daily reset | Scheduler → Data Sync Service | Data reset after the trading day |
4.5 Three Operational Perspectives
User Entry
- Browser loads the Vue frontend and calls the API surface.
- Frontend requests are centered on the FastAPI backend for positions, alerts, and monitoring.
Data Path
- The GitHub source is the upstream position feed for the app.
- Backend services refresh the local state and persist closing snapshots for low-latency reads.
Operational Rhythm
- Scheduler jobs align the app with trade-day windows and daily reset behavior.
- Sync and monitor services work together to keep the system fresh and resilient.
The diagram includes two views: Primary runtime flow (user-facing requests pass through the Vue frontend, FastAPI backend, GitHub sync inputs, and local state snapshots) and Scheduling and maintenance (scheduler-driven jobs keep price checks, GitHub refreshes, and local snapshot maintenance aligned with market rhythm).
5. Algorithms and Factors
5.1 Daily Strategy Algorithms
The daily pipeline uses a multi-algorithm fusion architecture. Candidate algorithms include:
- Momentum: based on moving-average crossovers, volume trends, multi-period momentum and other features
- PriceVolume: based on volume ratio, OBV change rate, amplitude average, up-volume ratio and other features
- Sentiment: based on down-day ratio, lower-shadow ratio, recovery rate, gap frequency and other behavioral signals
Fusion supports single-algorithm, two-algorithm weighted and three-algorithm voting combinations, with the best configuration per market selected through full backtesting.
5.2 Minute-level ML Models
The minute-level analysis system uses 8 ML models with weighted ensembling:
| Model type | Specific models |
|---|---|
| Tree models | LightGBM, XGBoost, CatBoost, RandomForest, ExtraTrees |
| Linear models | Logistic Regression, Ridge Regression |
| SVM | Linear SVC |
Multi-interval resampling of 1-minute raw K-lines generates rich time-series features, which are then scored by the ensemble.
5.3 Feature Engineering
The system builds a multi-layer feature system:
- Base features: price, volume, technical indicators, volatility, intraday patterns, multi-time-scales — 6 groups
- TA-Lib standard features: common technical analysis indicators
- Derived features: price patterns, volume anomalies, volatility structure, trend strength, momentum decay, statistical distributions — 7 categories
Three factor classes (momentum / price-volume / sentiment) are cross-combined with multiple ML algorithms to form a complete test matrix for selecting the best factor × algorithm pairings.
5.4 Validation Methodology
All strategies and parameters go through strict quantitative validation:
- Full data: all listed stocks across four markets, no sampling
- Time-series split: training and validation sets strictly split by time to avoid future information leakage
- Bayesian validation: Normal-Normal conjugate posterior significance tests on key parameters with multi-tier acceptance thresholds
6. Uptime and Stability
The system has been running for about 255 days since its first release on 2025-12-19, through 8 major version iterations. The server host has been running 106 days without reboot, the backend container 32 days with zero crash-restarts, and 0 ERROR entries in the last 7 days of logs.
6.1 Version Evolution
| Time | Version/Event |
|---|---|
| 2025-12-19 | v1.1.0 first release |
| 2025-12-19 ~ 2025-12-30 | v1.1.1 ~ v1.2.8 rapid iteration (index calculation, snapshot mechanism, server optimization) |
| 2026-01-05 ~ 2026-04-30 | v1.3.0 ~ v1.4.0 (independent price refresh, batch racing, hot-mount deployment) |
| 2026-05-16 | Nginx security upgrade (vulnerability fixed same day) |
| 2026-08-31 | Financial news source fix (same day) |
6.2 Key Stability Metrics
| Metric | Value | Rating |
|---|---|---|
| Project uptime | ~255 days | Long-term stable |
| Server host continuous run | 106 days (no reboot) | Long-term stable |
| Backend container continuous run | 32 days (0 crash-restarts) | Stable |
| Logs ERROR in last 7 days | 0 / 33,196 lines | Healthy |
| Response time | backend 1.7ms / news 123ms / home 88ms | Good |
6.3 Stability Safeguards
- Multi-tier data degradation: quote interfaces race across servers → local cache → close snapshot, automatic degradation on failure
- Multi-day snapshot persistence: stocks 5 days, indices 3 days, data still available on market holidays
- Bidirectional sync fault tolerance: local-first strategy, remote anomalies don't affect displayed data
- Cache self-healing: automatic fallback to cache on fetch failure, no blank pages
- Container health checks: Docker health probes + auto-restart policy
- Smart incremental checks: hourly remote-update checks during trading hours
6.4 Historical Fault Handling
Major recorded faults over 255 days were all caused by external dependency changes (third-party API adjustments, security patches, etc.), all located and fixed the same day, with no long service interruptions.
7. Daily Workflow
The system provides a one-click automation script that runs stock-picking scans, position ML analysis, per-stock deep analysis, report generation and sync in sequence, and can also be triggered automatically after market close on weekdays via scheduled tasks.
The manual workflow has 6 steps: parameter optimization → full-market stock picking → ML score filtering → timing analysis → local export → watchlist file generation. Each step can run and be debugged independently.
8. Security & Compliance
- Data security: production repository pushes require explicit confirmation; default is local export only
- Data integrity: all benchmark tests must use the full stock universe and complete date ranges
- System boundaries: cross-system customization must be implemented inside the caller; modifying called-system code is prohibited
This document is the public introduction of the Xiaosen Info System, focusing on architecture, algorithm system and validation methodology. Specific strategy parameters and backtest results are internal research materials and are not displayed here.
