hjnormey/sentiment-engine
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

uv(parity): OB TP coefficient dormancy caution — verify tp_mod_factor fires live before porting as active

Browse Source
This commit is contained in:
Codex
2026-07-12 12:38:50 +02:00
parent c403800030
commit e395b34eec
1 changed files with 13 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
prod/docs/uv_cert/UV_EXIT_DOCTRINE_PARITY_PASS_20260712.md
View File

@@ -134,3 +134,16 @@ is therefore PART OF PARITY.** Transcribe it regardless of verdict; analyze
its net contribution separately (candidate: flight recorder + trade_events its net contribution separately (candidate: flight recorder + trade_events
per-leg attribution over historical windows). Parity is fidelity to what per-leg attribution over historical windows). Parity is fidelity to what
runs, not to what should run. runs, not to what should run.
**⚠ OPERATOR CAUTION (×3): the OB TP coefficient may be DORMANT qua code
path.** Wiring exists (`esf_alpha_orchestrator.py:842` attaches ob_engine to
exit_manager) but MUST NOT be transcribed as active on faith. Before porting
TP modulation, VERIFY LIVE: (1) the attach call executes in the live trader
with a REAL OBFeatureEngine (not None/MockOBProvider); (2) empirically:
BLUE logs `tp_mod_factor` on EVERY decision (aem diag) — sweep the live
decision record/logs for tp_mod_factor ≠ 1.0 occurrences. If none ever fire,
the coefficient is dormant-in-effect and UV must transcribe it in the SAME
dormant state (present, wired identically, firing identically — i.e. never)
or parity breaks in UV's favor of a mechanism BLUE doesn't actually express.
Same verification applies to each modulation branch separately (cascade vs
withdrawal vs per-asset — one may fire while others are dead).