Methodology

Signal Types

Every signal is a first-class object in a registry. It has a stable identifier, a versioned formula, a category, a polarity, declared input series, and a packaging status that determines whether it ships through the paid API.

• Composite signals combine multiple input series into a single normalized score (−1 to +1). Eighteen composites currently cover growth, labor, inflation pressure, inflation expectations, inflation breadth, policy restriction, the real-yield curve, liquidity, credit stress, housing, consumer stress, dollar pressure, manufacturing activity, global rates, equity regime, and three macro surprise indices (US macro, growth, inflation). These are the product_ready set.
• Series-momentum signals score a single FRED series' recent trend against its own history. More than one hundred run as diagnostic inputs that explain composite movements; they are not exposed as standalone products.

Data Pipeline

A daily Vercel cron at 06:00 UTC drives a deterministic pipeline. Each stage is idempotent and writes its output to Postgres before the next stage runs.

1. Ingest. Fetch all active FRED series since the last observation. Upsert intoobservations keyed on (series_id, date).
2. Score. Recompute signal values from the latest observations. Each signal records itsnormalized_score, direction, strength, confidence,explanation, and top_input_drivers.
3. Relate. Compute pairwise correlations on monthly percent change across all series for each window. Persist to relationship_values.
4. Aggregate. Build precomputed snapshot tables (digest, regime, alerts, health, relationships, explainability) so dashboard pages and API responses read a single row instead of recomputing per request.

The full per-stage status is recorded in cron_stage_runs. If a stage fails, the previous successful snapshot remains readable; the next cron cycle retries.

Versioning

Every signal carries a formula_version. When the formula changes, the version bumps and historical values stay queryable under the old version. Snapshot tables track theingestion_run_id that produced each row, so you can trace any displayed value back to the run, the input observations, and the formula that produced it.

Validation

Each candidate signal is paired with one or more targets — observable market or macro series (e.g. 10Y yield, S&P 500, unemployment rate) and a directional hypothesis. The validation runner performs walk-forward evaluation over the available history, producing for each (signal, target) pair:

• Hit rate. Fraction of windows where the signal's direction matched the target's realized move.
• Sample size. Number of independent forward windows evaluated.
• Average and median forward move. Magnitude of the target's reaction.
• Status. product_ready when the hit rate and sample size clear configured thresholds; otherwise research_only.

Backtests deliberately use point-in-time logic: a signal's value on date d only sees observations released by d. ALFRED vintages will be added once core signal coverage stabilizes.

Anomaly Detection

Change-point detection (pelt_l2, v1). We run PELT (Pruned Exact Linear Time) with an L2 cost on the last 730 days of each tracked series to detect structural shifts in the level. The penalty is 3 * log(n) * sigma_squared, where sigma_squaredis the variance of first differences. A detection is persisted only when the post-/pre-breakpoint level shift is at least 1 standard deviation. The confidence value is a magnitude-derived proxy (min(1, magnitude/3)), not a Bayesian posterior. We run this daily.

Lead-lag matrix (v1). For each ordered pair of tracked series, we resample to weekly observations (ISO-week last-obs convention) and compute Pearson cross-correlation at lags 1 through 26 weeks. A pair is persisted only when (a) |r| at the best lag is at least 0.55, (b) the lagged correlation improves on the contemporaneous correlation by at least 0.10, and (c) the sign and magnitude are stable on a 130-week sub-window (tolerance 0.20). This is statistical predictiveness, not causation. We refresh this weekly on Sundays.

Versioning. Both algorithms tag their outputs with algorithm_version. v1 is the initial release; future parameter changes will be persisted as v2 rather than rewriting history.

Sources and Licensing

The current product runs entirely on FRED public data. Each series carries metadata for provider, source owner, license class, and attribution. Per FRED's terms, displayed views include:

This product uses the FRED® API but is not endorsed or certified by the Federal Reserve Bank of St. Louis.

SEC EDGAR, GDELT, and other public sources are on the roadmap. Paid vendors (Intrinio, RavenPack, etc.) require license review before integration; redistribution rules vary.

What This Is Not

• Not trading advice. Signals describe macro conditions and historical correlations; they do not constitute investment recommendations.
• Not real-time. Signals refresh once per day on the FRED release schedule. Intraday changes are not reflected.
• Not causal. Relationship analytics are descriptive. Correlation is exploratory, not proof.
• No black boxes. Every composite explains its top driver inputs and contribution direction in every API response.