VIOLET V3.4b: validate live-factor field paths + HZ sourcing adapter
#1 (validation) — VIOLET_V34B_LIVE_FACTOR_FIELD_VALIDATION.md documents the ground truth from BLUE's own code (esf_alpha_orchestrator / adaptive_circuit_breaker / nautilus_event_trader): of the 8 sizing inputs, ONLY `posture` is a flat HZ key. `esof_score` is in HZ but as a payload to parse. The other five — boost, beta, mc_scale, ob_median_imbalance, ob_agreement_pct, dc_status — are BLUE-organ outputs (ACB over DOLPHIN_FEATURES.exf_latest, MC flag derivation, OBFeatureEngine, the per-asset signal generator) and are NOT present as scalars in any HZ map. This inverts live_factors.py's flat-snapshot premise; its speculative alternate paths (acb_boost / s_acb_boost / ("acb","boost") / …) match nothing real. The full live sourcing of the five is a multi-organ sprint (V3.4c), not a HZ scrape. #2 (sourcing adapter) — live_factor_source.py sources what BLUE actually publishes, read-only and pure (callers pass already-fetched HZ blobs; no client, no I/O): - posture ← engine_snapshot['posture'] (DOLPHIN_STATE_BLUE), default APEX - esof_score ← DOLPHIN_FEATURES['esof_latest'] via BLUE's OWN parse_esof_payload + esof_score_from_payload (wrap, don't reimplement; staleness gate honored when max_age_s supplied) - boost/beta/mc_scale/ob_*/dc_status ← BLUE's neutral sentinels (1.0/0.0/1.0/None/ None/"NONE") until V3.4c — explicit, never silently faked. Flows through the validated extract_live_sizing_factors normalizer. ORGAN_DERIVED_ FACTORS names the six deferred to V3.4c so the journal can mark them NEUTRAL. 9 new tests green (posture default/upper, esof dict+raw-JSON+staleness, neutral integration, all-neutral-when-empty). violet-only; no shared-file edits; no soak. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
61
prod/docs/VIOLET_V34B_LIVE_FACTOR_FIELD_VALIDATION.md
Normal file
61
prod/docs/VIOLET_V34B_LIVE_FACTOR_FIELD_VALIDATION.md
Normal file
@@ -0,0 +1,61 @@
|
||||
# VIOLET V3.4b — live-factor field-path validation
|
||||
|
||||
**Date:** 2026-06-16
|
||||
**Task:** validate `prod/clean_arch/violet/live_factors.py`'s candidate field paths
|
||||
against how live BLUE actually sources the five sizing multipliers, *before* wiring
|
||||
the launcher-sourcing half of V3.4b.
|
||||
|
||||
## TL;DR
|
||||
|
||||
`live_factors.py` assumes the eight sizing inputs arrive as flat/nested keys in a
|
||||
single `hz_snapshot` dict. **That premise holds for only one of them (`posture`).**
|
||||
`esof_score` is present in HZ but as a *payload to parse*, not a flat key. The other
|
||||
five (`boost`, `beta`, `mc_scale`, `ob_median_imbalance`, `ob_agreement_pct`,
|
||||
`dc_status`) are **BLUE-organ outputs that are not published to any HZ map** — they
|
||||
live in the live `NDAlphaEngine`'s process memory / are recomputed per scan.
|
||||
|
||||
The speculative alternate paths in `live_factors.py` (`acb_boost`, `s_acb_boost`,
|
||||
`("acb","boost")`, `day_mc_scale`, `("esof","advisory_score")`, `("ob","market",…)`,
|
||||
`("signal","dc_status")`, `safety_posture`, …) **correspond to nothing in live BLUE.**
|
||||
They are harmless (first-match-wins, flat canonical key is tried first) but dead.
|
||||
|
||||
## Per-factor validated sourcing
|
||||
|
||||
Source of truth: `esf_alpha_orchestrator.py` (the composition), `adaptive_circuit_breaker.py`
|
||||
(ACB), `nautilus_event_trader.py` (the HZ reads/publishes).
|
||||
|
||||
| Factor | How live BLUE gets it | In a VIOLET-readable HZ map? |
|
||||
|---|---|---|
|
||||
| `posture` | `_day_posture`, set in `begin_day(posture=…)`; published in `engine_snapshot['posture']` (`nautilus_event_trader.py:5097`, map `DOLPHIN_STATE_BLUE`) and `DOLPHIN_SAFETY.latest.posture` | ✅ **flat key `posture`** in engine_snapshot |
|
||||
| `esof_score` | `_read_esof_payload()` → `DOLPHIN_FEATURES['esof_latest'\|'esof_advisor_latest']` → `parse_esof_payload` → `esof_score_from_payload(..., max_age_s=ESOF_FRESHNESS_S)` (`nautilus_event_trader.py:707-719`) | ✅ but a **payload parse**, not a flat `esof_score` |
|
||||
| `boost` / `beta` | `acb.get_dynamic_boost_from_hz(date)` → `acb_info['boost'\|'beta']`; the ACB **computes** them from `DOLPHIN_FEATURES['exf_latest']` (funding_btc/dvol_btc/fng/taker — `adaptive_circuit_breaker.py:511,528-533`). Applied via `begin_day` / `update_acb_boost` (`esf_alpha_orchestrator.py:764,946`). | ❌ raw inputs are in HZ; the **scalar requires running the ACB** |
|
||||
| `mc_scale` | `_day_mc_scale`, **derived** in `begin_day` from MC-Forewarner `mc_orange`/`mc_red` flags (`esf_alpha_orchestrator.py:962-964`: orange→0.5, red/TURTLE/HIBERNATE→…) | ❌ not a HZ scalar |
|
||||
| `ob_median_imbalance` / `ob_agreement_pct` | `ob_engine.get_market(bar_idx, symbols)` over the live OB feed, **per asset** (`esf_alpha_orchestrator.py:590-595`) | ❌ computed live; not in HZ |
|
||||
| `dc_status` | per-asset `signal.dc_status` from the signal generator (`esf_alpha_orchestrator.py:576`) | ❌ computed per-scan; not in HZ |
|
||||
|
||||
`engine_snapshot` payload (the map BLUE publishes for consumers) was inspected in full
|
||||
(`nautilus_event_trader.py:5092-5126`): it carries `posture`, `last_vel_div`, `vol_ok`,
|
||||
`last_scan_number`, `capital`, leverage caps, position list — **and none of the five
|
||||
organ-derived multipliers.**
|
||||
|
||||
## Consequence for V3.4b sourcing (#2)
|
||||
|
||||
A faithful, *complete* live-factor source is NOT a HZ scrape — it requires VIOLET to run
|
||||
the same organs BLUE does:
|
||||
- an **ACB** over `DOLPHIN_FEATURES['exf_latest']` → boost/beta,
|
||||
- the **MC** flag→`mc_scale` derivation,
|
||||
- an **OBFeatureEngine** over the OB feed → ob_*,
|
||||
- a **signal generator** → dc_status.
|
||||
|
||||
That is a multi-organ sprint (call it **V3.4c**), not a quick wiring.
|
||||
|
||||
What IS sourceable now, from maps BLUE already publishes, read-only:
|
||||
- **`posture`** ← `engine_snapshot['posture']`
|
||||
- **`esof_score`** ← `DOLPHIN_FEATURES['esof_latest']` via BLUE's own `esof_score_from_payload`
|
||||
|
||||
So the honest V3.4b increment (this PR) is a **pure adapter** —
|
||||
`live_factor_source.py` — that sources those two faithfully and supplies BLUE's own
|
||||
neutral sentinels for the organ-derived five (`boost=1.0`, `beta=0.0`, `mc_scale=1.0`,
|
||||
`ob_*=None`, `dc_status="NONE"`), feeding `extract_live_sizing_factors`. The shadow
|
||||
journal's V3.4 breakdown then records posture+esof live and the rest neutral — explicit,
|
||||
not silently faked. The organ wiring (boost/beta/mc/ob/dc live) is deferred to V3.4c.
|
||||
Reference in New Issue
Block a user