How starSignal Works

This page explains starSignal as a governed execution process from data intake to telemetry.

Process Overview

Each cycle follows a fixed chain:

1. Run preflight checks and acquire cycle lock.
2. Build runtime context from market, account and order state.
3. Refresh higher-timeframe context when live mode requires it.
4. Compute position economics and confluence state.
5. Apply safety validation before execution routing.
6. Route hold/buy/sell logic through lifecycle controls.
7. Publish telemetry, diagnostics and optional balance output.
8. Persist cycle state and release lock.

1) Data Intake and Preconditions

starSignal ingests live market and account data, including candles, orderbook context and current order state. If minimum data conditions are not met, the cycle exits without execution.

2) Confluence and Regime Layer

The strategy computes a confluence score using multiple signals and context features. This provides directional and quality context before trade actions are considered.

3) Trade-Style Behaviour Mapping

starSignal auto-maps timeframe behaviour to selected trade style (scalper, dayTrader, swingTrader, positionTrader). This is the core persona-based setup model and removes the need for ongoing manual tuning.

4) Position Economics and BEP Logic

Break-even and profitable-unit calculations are used to control re-entry behaviour and partial exits. This helps prevent undisciplined averaging and supports profit-taking governance.

5) Risk and Execution Gates

Before posting, starSignal applies:

• timer cooldown controls,
• depth and exposure controls,
• trend and behaviour constraints,
• venue minimum and order-mode checks.

6) Order Lifecycle Management

Orders are framed and managed through configured posting mode, orderbook positioning, refresh windows and stale-order cleanup. This supports deterministic execution behaviour.

7) Telemetry and Persistence

Each cycle updates runtime metrics and writes state to JSON files. This supports continuity across restarts and improves diagnostics during abnormal conditions.

Runtime Flow (Code-Mapped)

This flow is mapped to the live cycle orchestration in quanta_starsignal.js and shows execution control at the level used for operations and review.

flowchart TD
    A([Cycle Start]) --> B{"Preflight OK?"}
    B -- "No" --> B1["Skip cycle and log reason"] --> Z([Cycle End])
    B -- "Yes" --> C["Acquire cycle lock (runCycleBusy)"]

    C --> D["Build runtime context<br/>strategyVariables()"]
    D --> E{"Live mode?"}
    E -- "Yes" --> E1["Refresh higher-timeframe candles"]
    E -- "No" --> F
    E1 --> F["Compute position economics<br/>NPU and partial-sell basis"]

    F --> G["Generate confluence state<br/>signals, trend, regime, BEP and partial-sell gates"]
    G --> H{"Safety checks pass?"}
    H -- "No" --> H1["Abort execution path"] --> Y
    H -- "Yes" --> I["Execution Router (orderCentre)"]

    I --> I1{"Signal = Hold (0)?"}
    I1 -- "Yes" --> I2["Optional order cleanup (ORDER_KILL)"] --> J
    I1 -- "No" --> I3{"Signal = Buy (-1)<br/>or Sell (1)?"}

    I3 -- "Buy" --> K["Buy path<br/>choke window, depth/cancel rules, post buy if eligible"]
    I3 -- "Sell" --> L["Sell path<br/>choke window, depth/cancel rules, post sell if eligible"]
    K --> J
    L --> J

    J["Publish operator telemetry<br/>trade lines and sidebar diagnostics"] --> M{"BALANCE_OUTPUT enabled?"}
    M -- "Yes" --> M1["Write balance snapshot JSON"]
    M -- "No" --> N
    M1 --> N{"TRADE_STYLE changed?"}
    N -- "Yes" --> N1["Auto-adapt profile<br/>update PERIOD by TRADE_STYLE"]
    N -- "No" --> O
    N1 --> O["Persist cycle state<br/>trend, timing and controls"]

    O --> P{"Backtester mode?"}
    P -- "Yes" --> P1["Emit backtester summary"]
    P -- "No" --> Y
    P1 --> Y([Cycle Complete])

    Y --> R["Release cycle lock<br/>finally: runCycleBusy=false"]
    R --> Z

Strategic Outcome Mapping

starSignal’s operating model is designed to support:

• stronger signal quality discipline,
• tighter exposure and inventory control,
• deterministic execution behaviour,
• measurable runtime and decision transparency with low-touch operation.

These are design objectives, not guaranteed outcomes.