Automated Trading Pipeline
System Architecture

The team now operates as four complementary workstreams. Sam concentrates on VCSE and system direction; Engineer 2 builds the L1–L3 contract chain; Engineer 1 and Senior Quant carry the options and volatility programme; Senior Quant also provides quantitative review across layer PRs and development cycles.

One system, five persistent ownership layers. The layers are stable architectural boundaries—not calendar phases—and can advance concurrently when their versioned contracts are explicit. Evidence flows from detection through validation and non-executing trade intent into risk/OMS, with outcomes returning through attribution and governed calibration.

Build Status Overview

Figma Strategy Universe → System Outputs

The Figma board’s 102-strategy universe is a consumer map for the layer architecture, not a mandate to turn every strategy into a VCSE objective. The canonical boundary is: VCSE emits calibrated evidence; L2 validates agreement; L3 chooses an expression; L4 alone owns venue and portfolio authority.

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 — August 16, 2026

The durable evidence and transport foundation shared by all layers. Its contracts allow work to proceed concurrently while preserving provenance, freshness, replay, and non-execution controls.

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. In v0.6, VCSE is Sam’s primary development focus: model evidence, calibrated outputs, repeatable training, and a governed L1 producer path are the active priorities.

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.6

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 governed producer families emit versioned evidence into a unified L1 contract. Engineer 2 owns the routing, validation-ready envelopes, operational checks, and durable handoff; Sam owns VCSE development; Engineer 1 and Senior Quant own the options/volatility producer programme.

Current L1 Development Responsibilities

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
}

Engineer 2 owns implementation of the L2 validation path, with Senior Quant directing normalization, calibration, deterministic fixtures, and quantitative review. L2 converts L1 evidence into explainable, provenance-complete decisions; it does not authorize execution.

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
}

Governance Progression

• Current: shadow validation is deterministic, explainable, and reviewable; conflict, stale, missing, and low-quality inputs fail closed.
• Next: canonical v4 emission may create governed L3 intake after acceptance criteria, replay, and production evidence are complete.
• Later: L5 may recommend weight changes with sample-size warnings. Production weight changes remain review-governed and reversible.

Engineer 2 owns the non-executing L3 compiler: convert governed L2 evidence into a typed candidate plan, proposed risk, and lifecycle intent. Sam supplies strategy and bankroll policy; Senior Quant reviews quantitative construction; Engineer 1 and Senior Quant own options-specific structures.

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_review",
  execution_authorized: false,        // invariant across every current L3 path
  policy_version: "l3.policy.v1"
}

Layer 4 owns authoritative portfolio and position state, risk arbitration, OMS behavior, venue interaction, reconciliation, and receipts. Current implementation is read-only or shadow-only. Sam owns the system boundary; Engineer 2 supports contracts and safety workflows; Engineer 1 contributes options/Deribit specifics.

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 persistent layers tracked in Linear. These are ownership and contract boundaries, not sequential calendar phases. Work may proceed concurrently against stable, versioned contracts; readiness is earned through each layer’s acceptance gate.