Automated Trading Pipeline
System Architecture

Every deliverable in this document is assigned to a primary owner. Colour coding is used consistently throughout.

One pipeline, five layers. A validated signal flows from detection through construction, execution, management, and close — with every event logged to a shared data backbone. The loop closes by feeding trade outcomes back into signal quality scoring.

Build Status Overview

The system is now tracked as a single Linear migration project with supporting technical subprojects. This section maps the hosted spec to the operational project board and the workstreams that matter for implementation.

Current Board Snapshot

The single most important infrastructure piece. Every layer reads from and writes to it. Build this before any other layer.

Core Schema

Infrastructure Stack

Event Flow — Full Pipeline Example

VCSE engine computes daily PSV(t)
  → writes to vcse_snapshots table
  → detects inflection window (P_inflection > 0.65)
  → writes to signals table  { source: "vcse", confidence: 0.78, direction: "short" }
  → emits event: "signal_created"

L2 listener picks up "signal_created"
  → scores confluence across all inputs
  → writes to validated_signals  { score: 0.84, recommendation: "high_conviction" }
  → emits event: "signal_validated"

L3 listener picks up "signal_validated"
  → queries portfolio_state (available capital, open exposure)
  → constructs trade plan  { instrument: "perp", exchange: "binance", size: $12k, lev: 3x }
  → writes to trade_plans
  → emits event: "trade_plan_ready"

→ TODAY: Sam reviews on dashboard and approves
→ FUTURE: auto-approve if score > 0.80 and within bankroll limits

L4 OMS sends orders to exchange
  → writes to orders table (status: "pending")
  → monitors fills → updates orders (status: "filled")
  → writes to positions table
  → updates portfolio_state and Redis cache

L5 detects position close event
  → writes to pnl_attribution with full attribution
  → computes signal source accuracy
  → updates VCSE signal quality score in signals table
  → loop feeds back into L1 confidence calibration

A quantitative ML framework treating planetary positions as a structured, deterministic feature space. Not a metaphysical system — a correlational and empirical one. As of V0.5, VCSE is moving from research artifact into an L1 production component: daily snapshots, model diagnostics, feature QA, and signal-contract emission are the active engineering focus.

What Is Financial Astrology?

Financial astrology is the practice of correlating planetary cycles with market behaviour. It has been documented in academic and practitioner research for over a century — not as a mystical claim, but as the observation that planetary cycles produce measurable, recurring periodicities that overlap with cycles in human sentiment and economic activity. The mechanism hypothesis is straightforward: markets are driven by collective human psychology, and if planetary cycles correlate with recurring shifts in that psychology, they carry statistical signal regardless of the reason.

The field was formalised in the 20th century by researchers including W.D. Gann, who embedded cycle analysis into his trading methodology, and has since been extended quantitatively by Merriman, Pesavento, and Adkins, who documented statistically significant correlations between specific planetary configurations and commodity price extremes across multi-decade datasets. The VCSE is a modern, ML-native continuation of this lineage — replacing manual interpretation with a calibrated probabilistic model trained on the full history of Bitcoin.

Astrological Concepts — Engineering Primer

For engineers without an astrology background, these are the core structural concepts the system encodes:

Why This Edge Is Structurally Defensible

Three properties make planetary data unusual as a feature set and difficult to arbitrage away:

• Zero look-ahead bias. Planetary positions are computed from orbital mechanics and can be calculated for any future date without reference to price data. There is no data leakage by construction — the feature space is fully separable from the target variable.
• Long cycle periods. Saturn's 29.5-year orbit means there are only ~1–2 full cycles of Bitcoin data available for training. The signal, if it exists, operates on a timescale that cannot be rapidly discovered and arb'd away by high-frequency participants.
• Low adoption. Systematic, ML-native financial astrology is a niche practised by a small number of quant funds globally. The signal is not crowded. As the framework matures and expands to multi-asset validation, the edge becomes more defensible, not less.

Why Planetary Data Works as a Feature Set

Unlike price-derived indicators (RSI, moving averages), planetary positions are computed from orbital mechanics and carry zero look-ahead bias — they can be calculated for any future date without reference to price data. This eliminates the feature leakage that plagues most technical indicator models and provides genuine forward-looking predictive power. The feature space is also fully deterministic and reproducible: given the same date, every engineer running the pipeline will compute identical features via the Swiss Ephemeris (pyswisseph), the same VSOP87-based astronomical engine used by professional observatories.

Current Engineering Stature — V0.5

The 10 Planetary Bodies

The Planetary State Vector PSV(t)

At any bar, all 10 bodies are encoded as a structured feature vector. The concatenation of all per-planet features plus aspect and aggregate dimensions produces 200+ features total.

PSV(t) = [ f_Sun(t), f_Moon(t), f_Mercury(t), ... , f_Pluto(t), A(t), E(t) ]

where:
  f_p(t)  = per-planet feature sub-vector (sign, dignity, position, speed, retrograde)
  A(t)    = 45-pair aspect matrix (all C(10,2) unique planet pairs)
  E(t)    = elemental & modal aggregate statistics

Per-Planet Feature Set (×10 planets each)

The Aspect Matrix A(t) — 45 Planetary Pairs

Beyond sign placement, planets form angular relationships that carry independent predictive signals. At every bar, all C(10,2) = 45 unique planet pairs are evaluated for active aspects across 13 aspect types: conjunction (0°), opposition (180°), trine (120°), square (90°), sextile (60°), and 8 minor aspects. Each pair encodes orb, applying/separating direction, and orb-as-percentage-of-max.

Ingress Events as Regime Transitions

A planetary ingress — the moment a planet crosses a 30° zodiac boundary — is treated as a discrete regime transition event. Empirically, ingresses by Saturn, Jupiter, and Mars into dignity-relevant signs (domicile or fall) show statistically elevated MFE and MAE in BTC backtests. The PineScript Ingress Indicator already built for this framework provides the full historical dataset of all ingress events with per-transit returns, MFE, MAE, retrograde status, and dignity context — forming the labelled training set for supervised models.

Validated example: Saturn ingressed Capricorn (domicile — maximum dignity) on December 17, 2017. This coincided with the exact BTC all-time high of that cycle. Used as an ephemeris validation checkpoint.

Elemental & Modal Aggregate Features

Model Architecture — Three Stages

Backtesting: Walk-Forward Validation

Standard k-fold cross-validation violates the temporal structure of financial data. The VCSE uses expanding-window walk-forward validation with a 90-day purging embargo between each training cutoff and test period — preventing leakage through overlapping multi-day return windows (López de Prado, 2018).

Evaluation Metrics

The Three Signal Outputs

All outputs are calibrated probabilities or continuous scores — not binary buy/sell signals. This supports position-sizing decisions in L3 and bankroll management in L4.

Worked Signal Example

Data Pipeline

Multi-Asset Expansion Roadmap

The pipeline is asset-agnostic — only the OHLCV source changes. Expanding to additional assets both validates the cross-market hypothesis and dramatically increases statistical power for slow-planet features where BTC history alone provides insufficient cycles.

Four L1 signal sources producing a unified output format. Each fires independently; confluence scoring happens in L2. All signals are written to the signals table on the shared event store. June 2026 priority is getting L1 production-grade: VCSE snapshots, scanner normalisation, public-data Vol Engine signals, and volatility surface anomaly detection must all emit comparable signals.

June 2026 L1 Development Tasks

Unified Signal Schema

{
  id:          "sig_20260417_vcse_001",
  timestamp:   "2026-04-17T00:00:00Z",
  source:      "vcse" | "scanner" | "vol_engine" | "surface_anomaly" | "manual",
  type:        "inflection" | "breakout" | "divergence" | "vol_regime" | "surface_anomaly" | "funding_extreme",
  asset:       "BTC" | "ETH" | ...,
  direction:   "long" | "short" | "neutral",
  timeframe:   "4h" | "1d" | "1w",
  confidence:  0.0 – 1.0,         // calibrated probability from model
  metadata: {
    // VCSE: P_inflection, B(t), V(t), active aspects, dignity sum, jup_sat_angle
    // Scanner: pattern type, key levels, volume context
    // Vol: IV percentile, skew, term structure shape, premium dislocation
    // Surface anomaly: anomaly score, expiry bucket, strike band, data quality flag
  },
  expires_at:  "2026-04-19T00:00:00Z"  // signals have a validity window
}

Owned by Senior Quant. The goal is not noise filtering — it's scoring the strength of agreement across all signal sources so L3 knows how aggressively to size and structure the trade. Implementation should remain contract-driven from L1 signal schemas so VCSE, scanner, and Vol Engine sources can be added without rewiring the scoring model.

Confluence Scoring Model

Validated Signal Output Schema

{
  signal_id:         "sig_20260417_vcse_001",
  confluence_score:  0.84,
  recommendation:    "high_conviction",  // high_conviction | standard | reduced | pass
  direction_consensus: "short",          // do sources agree on direction?
  conflict_flag:     false,              // true if sources disagree on direction

  components: {
    vcse_inflection: { score: 0.78, active: true,  note: "P_inflection=0.72, B=-0.41" },
    vcse_vol:        { score: 0.75, active: true,  note: "V=HIGH, tension_score=4.2" },
    scanner:         { score: 0.82, active: true,  note: "4H breakdown below support" },
    vol_signal:      { score: 0.60, active: true,  note: "Deribit public IV proxy active" },
    surface_anomaly: { score: 0.68, active: true,  note: "Skew kink in front expiry; quality flag clean" },
    funding:         { score: 0.70, active: true,  note: "Longs overfunded at 0.08%" },
    macro:           { score: 0.65, active: true,  note: "DXY strengthening" }
  },

  sizing_suggestion: "aggressive",       // aggressive | standard | reduced | skip
  trade_structure_hint: "perp_short"     // first-pass instrument suggestion for L3
}

Automation Phases

• Phase 1 (now): L2 scores run automatically, results displayed on dashboard for Sam to review. Sam approves or rejects before proceeding to L3.
• Phase 2: Signals scoring above 0.75 auto-advance to L3 for trade plan generation. Sam reviews and approves the trade plan (not the signal).
• Phase 3: High-conviction signals auto-execute within pre-set bankroll limits. Sam monitors via dashboard with kill switch available.

Given a validated signal, determine how to express the trade: which instrument, which exchange, what structure, what size. Instrument selection is driven by the VCSE V(t) regime, B(t) directional score, and available instruments per exchange.

Available Instruments

Trade Structure Decision Tree

validated_signal arrives { direction, confluence_score, V(t), B(t) }
│
├─ HIGH CONVICTION DIRECTIONAL  (score > 0.80, |B(t)| > 0.6)
│  ├─ V(t) = HIGH   → Perp (leveraged, 3–5x) + OTM option hedge (when Deribit live)
│  ├─ V(t) = MEDIUM → Perp (moderate leverage, 2–3x) + defined stops
│  └─ V(t) = LOW    → Perp (conservative, 1–2x) or spot directional
│
├─ STANDARD CONVICTION  (score 0.65–0.80)
│  ├─ Directional   → Perp (reduced leverage), tighter sizing from bankroll module
│  └─ Neutral       → Wait for stronger confluence or vol trade when Deribit live
│
├─ VOL PLAY  (V(t) signal strong, |B(t)| < 0.3)
│  ├─ Vol cheap (IV low percentile) → Long straddle / long gamma  [Deribit]
│  ├─ Vol rich (IV high percentile) → Short premium / iron condor  [Deribit]
│  └─ Skew dislocated              → Risk reversal / collar       [Deribit]
│
└─ FUNDING / BASIS PLAY  (funding rate extreme flag from L2)
   ├─ Funding positive extreme → Long spot + short perp (earn funding)
   └─ Funding negative extreme → Short spot + long perp (earn funding)

Position Sizing — Bankroll Integration

Before constructing the trade, L3 queries portfolio_state. No trade plan is generated unless bankroll rules are satisfied.

• Available capital: Total equity minus margin already deployed across all exchanges
• Risk budget: Max loss per trade defined as % of equity (e.g., 1.5%). Stop distance from entry determines size.
• Concentration check: No single position may exceed the concentration limit
• Correlation check: Existing BTC long + new ETH long = correlated exposure, treated as additive for sizing
• Confluence scaling: Size scales with confluence score — a 0.90 signal gets full allocation; 0.65 gets 50%

Trade Plan Output Schema

{
  signal_id:     "sig_20260417_vcse_001",
  plan_id:       "plan_20260417_001",
  created_at:    "2026-04-17T08:15:00Z",
  instrument:    "perp",
  exchange:      "binance",
  asset:         "BTC",
  direction:     "short",
  leverage:      3.0,
  size_usd:      12000,
  entry_zone:    { low: 83500, high: 84200 },
  stop_loss:     85800,
  targets:       [
    { price: 79500, exit_pct: 50, note: "first target" },
    { price: 76000, exit_pct: 50, note: "full exit / VCSE window close" }
  ],
  risk_reward:   "1:2.6",
  max_loss_usd:  600,
  max_loss_pct:  1.5,
  confluence:    0.84,
  sizing_basis:  "confluence_scaled",
  expires_at:    "2026-04-19T00:00:00Z",
  status:        "pending_approval"   // → approved → executing → active
}

Three sub-systems: Order Management (OMS), active trade management, and bankroll management. Sam owns OMS infrastructure; Engineer 1 supports L4 order-routing implementation and exchange-specific routing work; Senior Quant owns the bankroll model.

4A — Order Management System (OMS)

4B — Active Trade Management

• Trailing stop adjustment: ATR-based or structure-based stop movement as price moves in favour
• Partial exits: Automated execution of TP levels from the trade plan at defined percentages
• Dynamic hedge adjustment: If vol spikes while position is open, adjust option hedge notional (when Deribit live)
• Signal degradation monitor: If VCSE inflection window closes while trade is open (P_inflection drops below threshold), tighten management rules automatically
• Time-based rules: If position hasn't moved toward target within N hours, apply tighter stop to avoid capital drag
• Exchange circuit breaker: If exchange API goes down, monitor-only mode with dashboard alert

4C — Bankroll Management

Closes positions, captures full PnL with fee and funding accounting, attributes performance to signal sources, and feeds results back into L1 and L2 to continuously improve signal quality and confluence weights.

Exit Triggers

PnL Attribution Schema

{
  trade_id:       "trade_20260417_001",
  signal_id:      "sig_20260417_vcse_001",
  plan_id:        "plan_20260417_001",

  // Execution data
  entry_price:    84050,
  avg_exit_price: 79800,
  size_usd:       12000,
  leverage:       3.0,
  exchange:       "binance",
  instrument:     "perp",
  direction:      "short",

  // Returns
  gross_pnl:      1530.00,
  exchange_fees:  -52.40,
  funding_paid:   -18.20,
  net_pnl:        1459.40,
  return_pct:     12.16,
  risk_adjusted:  2.43,      // net_pnl / max_adverse_excursion

  // Trade quality metrics
  hold_time_hrs:   31,
  max_favorable:   5.8,      // % max move in favour during trade
  max_adverse:    -1.4,      // % max drawdown during trade
  exit_reason:    "target_1_hit",
  entry_vs_plan:  "within_zone",

  // Attribution feedback
  confluence_at_entry: 0.84,
  vcse_p_inflection:   0.72,
  vcse_direction_correct: true,
  vcse_vol_correct:       true,
  scanner_correct:        true,
  signal_source_scores: {
    vcse:    { accurate: true,  contribution_est: 0.45 },
    scanner: { accurate: true,  contribution_est: 0.35 },
    funding: { accurate: true,  contribution_est: 0.20 }
  }
}

The Feedback Loop → L1 & L2

This is the highest long-term value component of the system. Every closed trade creates data that improves signal detection and confluence weighting:

• VCSE signal accuracy tracking: "When P_inflection > 0.70, what % of trades captured the predicted inflection?" Over hundreds of trades, this calibrates or recalibrates the model's threshold guidance.
• Per-source win rate: Track win rate and avg risk-adjusted return per source. L2 weights update empirically toward actual performance.
• Regime analysis: Which V(t) regime produces the best results? Which confluence score band? Refines L2 sizing suggestions.
• Confluence threshold optimisation: What minimum score produces positive expectancy? Adjust the auto-advance threshold in L2 accordingly.
• VCSE planetary feature importance: Closed trade outcomes feed back into the SHAP analysis, validating whether jup_sat_angle and saturn ingress features remain the top signals over time.

Built on the existing dashboard (React + Python + Node hybrid). Node serves the API/WebSocket layer to the frontend; Python handles all quantitative work, exchange connectivity, and ML.

Five phases tracked in Linear. Each phase produces a usable, integrated system that improves on the last. Do not start a phase until its dependencies are live.