From Direct Forecasting to Financial Telemetry

Research Status

Current architectural history. The telemetry framework described here is the foundation of the production SPY system.

Vyreon did not begin as a weekly market-report platform.

The project began with a broader goal: build an automated system that could learn from financial data, predict market behavior, and eventually support portfolio and execution decisions.

The research passed through several phases:

• Direct price forecasting.
• Wavelet and recurrent models.
• Market Physics hypotheses.
• Intraday bifurcation detection.
• Options probability-mass centroids.
• Flow Barometer.
• Multi-horizon state estimation.
• Production telemetry and public reporting.

The present architecture emerged because the earlier approaches repeatedly taught the same lesson:

Market state and uncertainty were more observable and more stable than one exact future path.

The Direct-Forecasting Phase

The early models attempted to forecast price or returns directly.

They used:

• Recurrent neural networks.
• Convolutional models.
• Attention.
• Wavelets.
• Fourier features.
• Technical indicators.
• PCA.
• Probabilistic outputs.

The results often looked strong in static plots.

Walk-forward testing exposed instability, alignment errors, leakage, and regime sensitivity.

The central problem was not only architecture.

The target itself combined:

• Direction.
• Timing.
• Path.
• Volatility.
• Exogenous shocks.
• Execution relevance.

One model was being asked to solve too many hidden problems.

The Market Physics Phase

The research then shifted toward the options matrix.

Open interest, implied volatility, gamma, vega, strike, and expiry were treated as a structured field.

This phase produced:

• Centroid concepts.
• Distribution width.
• Curvature.
• Cross-expiry relationships.
• Damping and resonance hypotheses.
• Force and equilibrium analogies.

Some ideas failed.

The negative damping-ratio interpretation was invalidated by a calculation error.

The analogies remained useful only as hypothesis generators.

The durable result was the recognition that the options matrix contains measurable structural state.

The Bifurcation Phase

The intraday bifurcation detector focused on structural change.

It could often identify when a local market state became unstable.

It could not reliably identify direction or immediate velocity.

The 1DTE strategy failed because:

• Confirmation arrived late.
• Direction was weak.
• Open interest was static intraday.
• Theta imposed a large cost.
• Calls and puts behaved asymmetrically.
• The detector solved structure while the instrument required velocity.

This result pushed the project away from one binary trade trigger.

The Flow Barometer Pivot

The architecture moved to daily options-flow and maturity-bucket measurements.

The new system asked:

• What does the options matrix imply across several horizons?
• How uncertain is each estimate?
• How do the horizon states agree or disagree?
• How should later outcomes update the model?
• Is the estimator remaining calibrated?
• Are innovations becoming larger or smaller?

This was the beginning of financial telemetry.

One Coupled Maturity Surface

The four current buckets are:

• Near-term, 8 to 30 calendar days.
• Short-term, 31 to 60 calendar days.
• Medium-term, 61 to 120 calendar days.
• Long-term, 121 to 365 calendar days.

These are not four independent markets.

They are four projections of one coupled options surface.

Each horizon has different:

• Sensitivity.
• Inertia.
• Contract density.
• Gamma and vega balance.
• Noise.
• Repricing speed.
• Target maturation delay.

The bucket boundaries were selected because they produced useful signal-to-noise behavior in the research.

They are not claimed to be the only possible market horizons.

Structural Inputs

The current feature family includes measurements related to:

• Open-interest centroids.
• Volatility-sensitive centers.
• Center relationships.
• Field width.
• Implied-volatility level.
• Implied-volatility slope.
• Surface fit quality.
• Price trend and curvature.
• Relative price movement.

The raw measurements are transformed causally.

Causal Feature Pipeline

The production pipeline uses:

• Endpoint Savitzky-Golay transformations.
• Exponential moving averages.
• EMA-based adaptive normalization.
• Per-bucket standardization.

The pipeline avoids centered transforms that require future data.

The same ordered feature list is used in training and production.

Horizon-Averaged Targets

The target is not a return to one arbitrary terminal date.

Several future dates are sampled across a bucket.

Their returns are averaged to create a horizon state.

This reduces dependence on one endpoint.

It also creates a delayed-label problem.

The complete target is not known until the final sampled date has occurred.

Near-term targets mature quickly.

Long-term targets can take approximately one year.

Causal Baseline

The system models excess return relative to a rolling baseline of previously matured outcomes.

The baseline is calculated before the current target is appended to history.

This prevents the current outcome from influencing its own reference.

The public total expected return is:

expected total return
= expected excess return
+ causal matured-return baseline

Regularized Initial Model

A Ridge regression provides the initial relationship between standardized structural features and excess return.

A linear model was retained because it is:

• Stable.
• Auditable.
• Easy to reproduce.
• Less data-hungry than a deep network.
• Compatible with recursive adaptation.

The intercept is stored in the artifact but is numerically tiny under the centered target and standardized features. The production recursive state historically modeled the coefficient vector without a dynamic intercept.

Adaptive Coefficient State

A multidimensional Kalman filter adapts the 14 Ridge coefficients as new outcomes mature.

The state is:

beta(t) in R^14

The coefficient covariance is a full 14 by 14 matrix.

The observation remains scalar:

excess return = x' beta + observation error

Every matured observation can update all coefficient dimensions through the Kalman gain.

Predictive Uncertainty

The predictive variance combines:

• Coefficient uncertainty projected through the current feature vector.
• Process covariance for coefficient evolution.
• Adaptive observation or innovation variance.

The public interval is intended to describe a future realized outcome, not only uncertainty in one coefficient estimate.

Innovation And Volatility

When an outcome matures, the prior expectation is compared with the realized value.

The difference is the innovation.

Innovation magnitude across horizons becomes a volatility-state signal.

This provides a second product layer:

• Expected state.
• Uncertainty.
• Model surprise.
• Calibration.

Why Telemetry Is Different From Prediction

A prediction product often says:

The price will be X.

A telemetry system says:

• This is the current estimated state.
• This is the uncertainty around it.
• This is how the state changed.
• This is how realized behavior compared with the prior estimate.
• This is whether the system remains calibrated.

Telemetry does not remove uncertainty.

It makes uncertainty visible.

The Public Report

The weekly SPY report turns the model state into five core charts:

1. Current volatility regime.
2. Multi-horizon forward expectation states.
3. Current options structure.
4. Actual versus expected return validation.
5. Volatility-signal validation.

The written synthesis is generated from those measurements.

The report avoids turning every structural measurement into a deterministic directional story.

What The Architecture Solved

The telemetry architecture solved several problems that had weakened the earlier systems.

It Separated State From Execution

The public model does not need to select an option contract to be useful.

It Separated Direction From Uncertainty

A positive expected mean can still have a wide mixed interval.

It Preserved Horizon Disagreement

The system does not force one global label when maturities conflict.

It Created Model-Health Outputs

Calibration and innovation are visible.

It Supported Delayed Outcomes

The maturation process respects the actual horizon.

It Became Operationally Stable

The system could run daily, publish weekly, and accumulate live evidence.

What It Did Not Solve

The current system does not solve:

• Exact future path.
• Short-term execution.
• News interpretation.
• Dealer-position sign.
• Individual option selection.
• Portfolio allocation.
• Guaranteed profitability.

Those remain separate research problems.

Why The Architecture Matters Commercially

The same measurement system can support:

• Public reports.
• Internal research.
• API outputs.
• Portfolio overlays.
• Risk dashboards.
• Additional assets after separate validation.

The product is not one chart.

It is a repeatable observability system.

Production Data Lifecycle

A daily model state passes through several stages.

1. Option-Chain Snapshot

The system receives the current option matrix and underlying price history.

2. Primitive Measurements

Per-bucket structural measurements are calculated from the chain.

3. Causal Feature State

The feature engine updates its rolling Savitzky-Golay, EMA, and adaptive-normalization states.

4. Maturation

Previously issued feature dates are checked to see whether their complete future-return grids are now available.

5. Recursive Update

Each newly matured outcome is scored against the prior Kalman state and then assimilated.

6. Current Prior

The updated state is applied to today's feature vector to create a new expectation and predictive uncertainty.

7. Telemetry Output

Prior rows, matured diagnostics, spot, model version, and metadata are transmitted to the backend.

8. Canonical Storage

The backend stores raw and parsed records, resolves corrections, and computes derived return and price-space outputs.

9. Weekly Synthesis

The latest canonical state and validation history are rendered into charts and a written report.

This lifecycle is why the public report can show both current expectation and evidence about historical behavior.

Why Daily Cadence Was Retained

A faster system might appear more responsive.

Daily cadence was selected because the important production inputs include option-chain structure and open interest across maturity buckets.

The daily system provides:

• More stable contract coverage.
• Lower infrastructure cost.
• Manageable target maturation.
• Less sensitivity to microstructure noise.
• A practical weekly publication cycle.
• Compatibility with long horizons.

The earlier intraday path showed that faster cadence is not automatically more useful.

Why The Report Is Weekly

The model state updates daily.

The public report is weekly because:

• Many structural changes are slow.
• Daily publication can exaggerate noise.
• Weekly comparison improves readability.
• Long-horizon state does not require constant commentary.
• The report can include complete validation and options context.
• One consistent publication is easier to operate reliably.

The weekly report is a presentation cadence, not the model cadence.

One System, Several Outputs

The platform can produce several surfaces from the same state.

Public Report

A readable summary for a broad audience.

Internal API

Full prior, matured, and derived fields for research notebooks.

Customer API

A smaller stable schema of validated outputs.

Model-Health Dashboard

Coverage, error, innovations, data quality, and service status.

Future Portfolio Layer

Position sizing or risk allocation, only after separate validation.

This separation prevents the public narrative from becoming part of the mathematical estimator.

Public And Proprietary Boundaries

The public methodology explains:

• The data categories.
• Horizon design.
• Causal transformations.
• Ridge and Kalman architecture.
• Uncertainty interpretation.
• Validation logic.
• Limitations.

The project does not publish:

• Production coefficients.
• Scaler values.
• Full covariance state.
• Private thresholds.
• Credentials.
• Operational secrets.
• Unreleased execution rules.

Transparency does not require exposing every artifact.

It requires making the claims and limitations understandable.

Research Status By Layer

Layer	Status
SPY daily telemetry	Production
Weekly reports	Production
Public methodology and validation	Production
Additional assets	Future, requires separate validation
Expiry-response research	Active research
Eigenstructure instability	Exploratory diagnostic
Automated portfolio allocation	Future research
Reinforcement-learning execution	Future research

This table matters because the broader QuantBot vision is larger than the current product.

The public site should distinguish what exists from what is planned.

Why The Architecture Remains Intentionally Simple

The production estimator is not the most complex model explored in the project.

That is intentional.

The current architecture favors:

• Reproducible artifacts.
• Stable feature order.
• Linear initial relationships.
• Explicit covariance.
• Incremental updates.
• Human-readable diagnostics.
• Low operational cost.

A more complex model should replace this foundation only if it produces stable out-of-sample improvement under the same causal target and validation rules.

The project no longer treats architectural novelty as evidence of advancement.

The advancement is the ability to maintain a useful state estimate through time while showing when that estimate is wrong.

Scaling Beyond SPY

The architecture is asset-agnostic in principle.

Production expansion is not a matter of changing one ticker.

Each new asset requires checks for:

• Option-chain depth.
• Strike density.
• Expiry coverage.
• Open-interest quality.
• Stable primitive calculation.
• Feature scaling.
• Target availability.
• Calibration.
• Volatility-signal behavior.
• Operational compute cost.

The SPY model cannot be copied and declared valid elsewhere.

The shared architecture can be reused. The statistical evidence must be rebuilt.

Current Conclusion

The move from forecasting to telemetry was not a retreat from prediction.

It was a correction of the problem definition.

The project stopped requiring one model to guess a complete price path.

It began estimating:

• Market state.
• Maturity structure.
• Uncertainty.
• Innovation.
• Calibration.
• Change through time.

That architecture has survived live operation better than the direct-forecasting and short-dated trading paths that came before it.