trading / confluences / b_roomstop
Corpus lane — EN-06 · Killed before scoring, in the open, with a written reason.
Is the nearest opposing obstacle at least 2× the stop distance away? Proposed as a stop-relative counterpart to the live c6.
Every parameter below was fixed in the design document before any candidate value was computed. No sweep, no tuning: a bit that needs tuning to pass has failed.
| Field | Value |
|---|---|
| Source component | EN-06-room-to-target-gate |
| Evidence tier | CLAIMED |
| Backlog rank | #12 |
| mult | 2.0 |
| reference | "stop distance" |
| Note | DROPPED — see SCREEN_DROPPED['b_roomstop'] |
| Design doc | backtests/conf_lab/SCREEN-2026-08-07-DESIGN.md |
| Doc sha256 | e2ba7ca77acce01c03ebcdb7afb51ffade7bb7a591303a2923329dba13a91d94 |
DROPPED as a duplicate of the live c6. The design doc justified it as 'stop-relative, vs c6's target-relative', but c6 is ALREADY stop-relative at exactly this multiple: `helpers.htf_and_room` calls `defs.room_to_target(entry, sl_dist, ..., mult=2.0)`, i.e. 'nearest opposing obstacle >= 2 x stop distance', and c6 is that boolean. The candidate therefore reduces to an existing live gate, which is the §1 do-not-retest situation one step stronger: it would spend a multiplicity slot to re-measure c6, and — because a non-live column is stratified on the total of all six live bits, c6 included — it would do so with the exact compositional bias `pooled_delta` exists to remove. Re-parameterising it to a different multiple would be tuning, which the design forbids.
DROPPED as a duplicate of the live c6. The design doc justified it as 'stop-relative, vs c6's target-relative' — but reading the actual engine code rather than the gate's one-line description shows c6 is ALREADY stop-relative at exactly this multiple: `helpers.htf_and_room` calls `defs.room_to_target(entry, sl_dist, ..., mult=2.0)`, and c6 IS that boolean. The candidate reduces to an existing live gate, which is the do-not-retest situation one step stronger: it would spend a multiplicity slot to re-measure c6, and — since a non-live column is stratified on the total of all six live bits, c6 included — it would do so with the exact compositional bias `pooled_delta` exists to remove. Re-parameterising it to a different multiple would be tuning, which the design forbids.
Nothing to retest: the bit is c6. The live question it points at (is 2.0 the right multiple?) would be a c6 parameter study in a new pre-registered grid.