hjnormey/siloqy
Public Access
1
0
Fork 0
Code Issues 7 Pull Requests 2 Actions Packages Projects Releases Wiki Activity
Files
47da295ffe2d7f54acf040a8e10e95a852232321
siloqy/prod/docs/VIOLET_V34B_LIVE_FACTOR_FIELD_VALIDATION.md
Codex a632c595ba 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>
2026-06-16 13:22:59 +02:00

4.2 KiB
Raw Blame History

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.