How Athena Works

This page explains Athena as a governed decision system from data intake to execution and telemetry. The focus is operational clarity: what Athena evaluates, how it decides and where controls are enforced.

Process Overview

Each Athena cycle follows a fixed chain:

1. Run preflight checks and acquire cycle lock.
2. Build runtime context from spot, account and order state.
3. Refresh option-chain context and mark snapshots.
4. Build model outputs from Black-Scholes, parity and expected-move logic.
5. Compute confluence and volatility-regime execution stance.
6. Apply safety validation, then route buy/sell/hold execution.
7. Publish telemetry and optional balance output.
8. Persist cycle state and release lock.

1) Data Intake and Freshness Controls

Athena validates market and orderbook freshness before execution. If market state appears stale or invalid, the cycle exits early. This prevents posting decisions on degraded data quality.

2) Options and Probability Layer

Athena consumes call/put mark data and derived greeks to estimate risk structure around current spot. It uses Black-Scholes style calculations and expected-move rails to build context for positioning.

This layer is important because options flow can reflect institutional positioning earlier than spot-only signals. Athena uses that context to inform spot execution decisions with a potential first-mover information edge.

3) Parity and Structural Validation

Put-call parity checks are used as an additional structural lens. This helps Athena align spot decision context with option-implied relationships rather than relying on isolated spot movement.

4) Confluence and Regime Detection

Athena combines mark ratios, implied volatility skew and delta balance into confluence state. Regime classification (normal, high, extreme) then drives execution posture.

5) Adaptive Quote Framing

Based on regime and confluence, Athena adjusts:

• quote offsets,
• layer weights,
• refresh cadence.

In higher-volatility states, it can widen spacing and reduce aggressiveness to control execution risk.

6) Risk and Capital Governance

Before posting, Athena enforces:

• max capital constraints,
• break-even and behaviour toggles,
• timer cooldowns,
• minimum notional and venue constraints.

Orders are blocked when controls are not satisfied.

7) Execution, Telemetry and Persistence

When checks pass, Athena executes order logic and then updates telemetry and JSON state. Persisted state supports continuity across restarts and improves auditability.

Runtime Flow (Code-Mapped)

This flow is mapped to the live cycle orchestration in quanta_athena.js and reflects the decision and control path used in production.

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["Refresh options context<br/>strikes, call/put marks, IV snapshots"]
    E --> F["Model layer<br/>Black-Scholes, parity checks, expected-move rails"]
    F --> G["Confluence engine<br/>sentiment, volatility regime, execution bias"]

    G --> H{"Safety checks pass?"}
    H -- "No" --> H1["Abort execution path"] --> Y
    H -- "Yes" --> I["Execution Router (orderCentre)"]

    I --> I1{"Action signal?"}
    I1 -- "Buy" --> J["Buy path<br/>IV-aware quote framing, timer and capital gates"]
    I1 -- "Sell" --> K["Sell path<br/>IV-aware quote framing, timer and capital gates"]
    I1 -- "Hold" --> L
    J --> L
    K --> L

    L["Publish operator telemetry<br/>chart lines and sidebar diagnostics"] --> M{"BALANCE_OUTPUT enabled?"}
    M -- "Yes" --> M1["Write balance snapshot JSON"]
    M -- "No" --> N
    M1 --> N["Persist cycle state<br/>timing, mark snapshots, risk context"]

    N --> Y([Cycle Complete])
    Y --> R["Release cycle lock<br/>finally: runCycleBusy=false"]
    R --> Z

Strategic Outcome Mapping

Athena’s operating model is designed to support:

• structure-aware positioning,
• controlled capital deployment,
• volatility-adaptive execution quality,
• transparent verification through telemetry.

These are design objectives, not guaranteed outcomes.