a632c595badb88a3a84eff2b0ef0d9f88036ff6c
#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>
Description
No description provided
Languages
Python
100%