PooledGate was three CExpertSignalAIBase method bodies in an #included
partial. It is now CPooledGate, a class the signal owns.
It needed NO data view. Diagnosing that first is the point: the module
reads a directory of CSV files and knows nothing about a model. The
only things it needs from its owner - the symbol's own numbers and the
ratio they were measured at - are arguments. Handing it a
CTrainingDataView would have been machinery for a dependency that does
not exist.
The owner fills SPoolRecord (the on-disk shape, which already existed)
because only it knows its symbol, its actual TargetRR and its label
lifespan. `id` is passed per call rather than bound, so there is no
init-order question about when the identity became available - m_symbol
is set by CExpertSignal::Init and ID by SetIdentity, at different
times.
m_poolWriteWarned was a one-shot latch living on the signal for a
warning only this module emits. It is m_writeWarned, private.
targetRR is now threaded into ReadPooledEvidence rather than read from
the owner. That is not plumbing for its own sake: a peer measured at a
different ratio has a different structural break-even, and only the
caller knows which ratio it is asking about.
Caught before compiling: I declared ReadPooledEvidence from memory as
(..., double &pooledEffN, const double targetRR). The real signature
ends in `string &detail`. Read the definition, aligned both ends.
Call sites in Training.mqh are untouched - PublishPoolRecord and
PooledGatePasses remain on the signal as the thin fillers that know its
geometry.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
MetaCorpus was already a class, so the raw-include problem was not the
one here. The problem was that the rule for naming a signal-DB pattern
table
MetaFamilyName(f) + "_Pattern_" + p + ("_Buy" | "_Sell")
was written out FOUR times, each wrapped in its own identical
family/pattern/side triple loop: the corpus loader, the stale-DB guard,
META's row counter and META's exporter. Four chances for a rename to
leave three of them querying an absent table and reporting it as
"family disabled" - which is what that code says when a table is
missing, so the failure would have looked like normal operation.
CMetaFamilies now owns the taxonomy and that rule. Callers walk ONE
flat index over all 52 tables and never spell a name:
for(int ti = 0; CMetaFamilies::TableAt(ti, table, f, p, isBuy); ti++)
Enumeration order is unchanged - Buy then Sell within a pattern,
families in order - so the corpus is assembled in exactly the same
sequence as before.
META's OneHotSlot had a second hardcoded 0/4/8/14 ladder with a comment
reading "matches MetaFamilyPatterns' 4/4/6/12" - a note asking a reader
to keep two constants in step by hand. The ladder is now summed from
the pattern counts, so they agree by construction. The bound against
META_ONE_HOT_SLOTS stays in META: the head's input width is that
class's business, and a taxonomy grown past it must be caught rather
than silently truncated.
Caught while re-reading the rewritten loop: my first counter was `t`,
and the body declares `MqlDateTime t`. Renamed to `ti` at all four
sites before it reached a compile.
MetaCorpus.mqh moves to Expert\Training\ with the other real classes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Baselines was 951 lines of CExpertSignalAIBase method bodies in a file
that only looked like a module. It is now CBaselineComparator: a class
the signal OWNS, which reads a CTrainingDataView and prints. It does
not name the signal anywhere in its code.
What the seam forced out into the open:
- Thirty-odd ArraySize() bounds tests, each carried by its caller, are
now one test per accessor next to the data. The two `hasValueN` and
one `arrowN` locals are gone with them.
- The -2.0 "never scored" sentinel on the arrow cache was tested at the
call site. It is now inside DataDirectionalCall, where it cannot be
read as a small confidence.
- DoubleToSignal needs m_outputNeuronsCount, so a raw double could not
be turned into a side by any reader. The view answers
DirectionalCall(bar, isBuy, magnitude) instead - the conversion
happens where the head width lives, and the module no longer needs
ENUM_SIGNAL at all.
- m_baselineDone was a latch on the signal for a decision only this
module makes. It is m_done, private, where it belongs.
Correction to my own earlier claim: I said Baselines had nine exclusive
members "polluting the signal class". It had none. m_x, m_f, m_ngrad,
m_AvgCE and the rest are FIELDS OF ALGLIB REPORT OBJECTS (state.m_x,
mrep.m_AvgCE) that my `\bm_\w+` scan matched after the dot. The module
needs no private state but its view pointer and that latch - which is
why it came out this cleanly.
The include sits below the g_ens* vote globals and the Alglib headers
it reads, because unlike the AIBase\*.mqh partials this is a real class
declaration compiled where it stands.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The AIBase\*.mqh files are not modules. They are method bodies of one
3,400-line class, textually #included after its declaration. Every one
of them can touch every member of every other, which is why "move this
out" has so far meant "move the whole class".
Introduce the seam that ends that:
CTrainingDataView abstract - the ONLY thing a training-side
collaborator may see: a feature row, a label, an
outcome, an excursion, the shape they share, and
the identity to log under.
CAIBaseTrainingData the adapter. MQL5 gives a class exactly one base
and CExpertSignalAIBase is already a
CExpertSignalCustom, so it cannot implement the
view itself. It owns one of these instead.
Data*() on the the published read API the adapter forwards to.
signal MQL5 has no `friend`, so reaching in from outside
was never an option - and making it explicit is
the point rather than a workaround.
Every row accessor OWNS ITS BOUNDS TEST and answers false for a bar it
has nothing for. Thirty-odd call sites currently carry their own
ArraySize() guard; one that forgets reads past a cache that is shorter
than the bar count for the whole warm-up. The -2.0 "never scored"
sentinel on the arrow cache is folded in the same way, so it can no
longer be mistaken for a small confidence.
Nothing uses it yet - this is the seam only, kept as its own commit so
the pattern compiles before 951 lines of Baselines move onto it. The
pattern is the stdlib's own: abstract base with =0 (Canvas\DX\DXObject),
concrete override, forward-declared owner pointer.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Compile error, four sites: TRAIN_TIME_BUDGET_MS was a const local to
Train(), and the four passes that yield on it are now defined above
Train(). I checked every pass for the eight locals STrainEra replaced
and missed the ninth, because it was a const rather than a variable.
It is per-call state like everything else in STrainEra, so it moves
there as budgetMs. All four sites asked the same question the same way
GetTickCount() - era.chunkStartTick >= TRAIN_TIME_BUDGET_MS
so the struct answers it once as BudgetSpent().
Swept for the same class of mistake rather than waiting for another
compile: Train() now has exactly two top-level locals left
(STABILITY_WINDOW, STABILITY_TOLERANCE) and neither appears in any
extracted body.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
673 lines after the OOS pass sat at indent 6 while being at function
level. It read as a block inside something, which is how I initially
mis-measured pass 3 as 1,178 lines when its closing brace is 504 lines
in - the indentation, not the braces, was telling the story.
Whitespace only. Verified by comparing every non-blank line of both
revisions with leading and internal whitespace collapsed, COMMENTS
INCLUDED: zero lines added, zero removed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Train() was still 2,572 lines because the four passes it runs - the
scan/queue sweep, the shuffled replay, the purged calibration walk and
the OOS scoring walk - were written inline as four consecutive blocks
sharing one scope. STrainEra removed the only obstacle to moving them.
Each pass now keeps its own guard inside its own body, so it is
self-contained: RunPass2 still tests !era.stop && era.addLoop &&
!m_isPass2Done itself rather than being called conditionally. Train()
reads as the sequence it always was.
RunOosPass MEASURES and nothing more - the recall gate, plateau ladder,
deploy gate and era checkpoint read its numbers afterwards and stay in
Train(). The first version of its header comment claimed it ran those
too; the body is 504 lines and does not, so the comment was corrected
rather than shipped.
Verified by stripping comments and whitespace from both revisions:
ZERO statements removed, sixteen added - four signatures, their eight
braces and four call sites. Every other statement byte-identical.
Train() 2,572 -> 1,282 lines.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Train() is not a function that trains a model - it is one STEP of a
resumable state machine, called again every tick until the era ends.
Eight locals carried the state from one step to the next: bars,
totalIter, oosCutoff, i, add_loop, stop, chunkStartTick and the
forward-failure latch.
Those eight are the sole reason none of the four passes could be lifted
into a method. Each would have needed eight by-reference parameters,
and a pass that takes eight parameters is not a pass - it is the same
function under another name.
Collapse them into STrainEra. Nothing else changes: no logic, no
ordering, no early return. Verified the same way as the era log - strip
comments and whitespace from both revisions, map era.X back to X, and
diff the remaining statements. The only differences are the five
declaration lines becoming one object and two assignments losing their
type. Every other statement is byte-identical.
One incidental fix: a for(int i...) loop over g_warriorEnsemble shadowed
the era counter. It ran before the era locals were declared so it was
never a live bug, but it becomes one the moment a pass moves out. It is
now mi.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Train() was 2,572 lines in one function. The largest single block in it
was ~200 lines of string building for the console line, reachable only
because twenty-one loose ints were declared at the top of the function
and read nine hundred lines later. Those declarations were the reason
the block could not move.
Introduce SEraTelemetry - one parameter object holding exactly those
twenty-one numbers, self-initialising to -1 ("not measured this era",
which is what era 0 and any stopped era report, and is not the same as
a measured zero). ReportEraProgress() takes it and renders it, guarding
on its own shouldLog so the call site is one unconditional line rather
than a 200-line branch.
Nothing is decided or measured in the moved code - it reads state and
prints. Verified by stripping comments and whitespace from both
revisions and diffing the remaining statements: the only differences
are the ten declarations collapsing into one object, the throttle test
moving inside the callee, and the new signature plus its call. Every
other statement is byte-identical.
Train() 2,572 -> 2,370 lines.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Run_Alglib_Baselines = true. It answers the question the campaign is
actually stuck on - is a flat result the architecture or the matrix - by
fitting an Alglib forest, MLP and OLS on the net's OWN windows, labels,
split and gate arithmetic. Nothing trades on it and no model is saved.
Not in BuildModelFingerprint, so this does NOT re-key anything: no
retrain, it can go out with the next compile. One-shot per chart
(m_baselineDone latches first, and g_ensembleChartBaselinesDone stops
the other three members re-measuring the identical fit), bounded by
BASELINE_BUDGET_MS = 45 s, which it spends frozen because the EA is
single threaded - it says so when it stops early.
FIXED WHILE TURNING IT ON: ReportBaselineModel sized its SE on RAW call
count while the NN's own DEPLOY BAR deflates by the mean label lifespan.
The whole point of this line is a like-for-like comparison against the
net on the same windows, and it was holding the baseline to the more
permissive standard - which is how the last forest run's +8.4pp read as
significant when it was +1.0 SE after deflation. Now uses
EffectiveSampleSize and prints how many independent calls that leaves.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Not the full split - that is withdrawn, see below. This is the part
worth having on its own: the DB journaling and the raw-view drawing were
inline in the same loop that does the vote arithmetic, so a reader had
to separate "what this computes" from "what this writes" by eye.
JournalFilterPatterns() and DrawFilterRawView() now say it at the call
site. Pure extraction, no behaviour change; Direction() drops 172 -> 146
lines.
WITHDRAWING the recommendation to split Direction() into a pure vote
plus its side effects. The operator's question - why split it when the
stdlib already supports configurable weights and prohibition signals -
is right, and my justification did not survive it. Stdlib's Direction()
is already pure; ours is a transaction because WE added journaling,
drawing, an intra-second window, one-shot vote consumption and a
readout on top of it. So the split would only remove what we added.
That was worth doing when the vote ARITHMETIC was also duplicated. It no
longer is: 616e071 put the normalization in SVoteAccumulator and both
paths use it. What is left duplicated is only the per-member vote
ACQUISITION, and the replay's SaveVoteState/RestoreVoteState bracket
handles that in ~15 lines. Restructuring the order-placing path to
delete 15 lines is not a trade worth making.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Operator's call: "META should be removed or implemented directly into
CExpertSignalBase. Only true signalers needs to be filters."
A meta head never votes - its Long/ShortCondition are structurally 0 and
its verdict reaches the pipeline through LiveMetaGate(), not through the
vote. Keeping it in m_filters meant every consumer of that list needed a
special case, and each one was a bug waiting: VoteCapableWeight() had to
return 0 for it or it would park a permanent abstainer in the consensus
divisor. The replay's divisor bug (d81ec15) had exactly this shape.
CExpertSignalCustom::IsVotingSignal() is the predicate, false for a meta
target. AddFilter() ROUTES on it into a second owned list, m_gates, so
the EA's init code stays one uniform AddFilterToSignal() call per signal
and the invariant is enforced in one place instead of re-checked by
every reader.
THE TRAP, and it is why this is not just a deletion: m_filters is not
only the voting list, it is also how a signal reaches its children for
INDICATORS, TICKS, PANEL COMMANDS, CHART EVENTS and TRAIT COUNTS.
OnTickHandler in particular is what drives each AI signal's training - a
gate dropped from it silently stops learning. So the tree is now split
by purpose:
m_filters (voting) Direction, HistoricalNetVote,
RefreshVoteReadout, vote rollback,
UpdateSignalsWeights (pattern/DB weights)
ChildSignalAt (whole tree) InitIndicators, OnTickHandler,
OnChartEventHandler, DispatchSignalCommand,
CountSignalTrait
and the IsMetaTarget() special case in VoteCapableWeight() is deleted -
the structure now guarantees what it was hand-checking.
META was already added last, so no filter's m_ignore/m_invert bit index
moves.
Not done here: removing META outright. It is default-off and has never
shown an operating point clearing break-even, so the case for deleting
it is real - but that is a feature decision, not a refactor, and it is
offered separately.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The comment added in 616e071 said the stdlib divisor "is a correct mean
only while m_weight is its default 1.0", which reads as though
CExpertSignal ignores the weight. It does not: each signal weights its
own conditions, m_weight*(LongCondition()-ShortCondition()), and every
child applies its own in turn. The weight is respected end to end.
The one real divergence is the NORMALIZER, and the argument for ours is
not deflation - both forms scale identically with agreement, so stdlib's
is a valid relative consensus measure. It is that stdlib's output scale
IS the mean module weight, and we re-derive that from held-out win rates
every era. Measured on USDJPY across five eras in this morning's log the
mean ran 0.162 -> 0.285, a 76% swing, so under /count every vote would
have risen 76% with no change in agreement or accuracy and a fixed
threshold would mean something different each era. Dividing by capable
weight cancels that factor, which is what makes the number a win rate
the threshold, the deploy gate and break-even can be compared against.
Noted in the same block: stdlib arithmetic would be exactly right with
m_weight left at 1.0 and the win rate carried by the pattern weight.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Follows the stdlib question directly: CExpertSignal::Direction() divides
by the COUNT of participating filters, which is a correct mean only
while m_weight is its stdlib default of 1.0. We set m_weight to a
win-rate-derived trust - measured 0.27-0.29 on both live charts this
morning - so dividing by count would deflate every vote by ~3.6x: a 28%
ensemble would read 7.8 against a 25 threshold and never fire. The
divisor override is load-bearing, not decoration.
What was NOT load-bearing is having two copies of it. SVoteAccumulator
is now the only place the rule lives, and both Direction()'s pass 2 and
HistoricalNetVote() Add() into it:
- capable weight ALWAYS enters the divisor, contribution or not. An
abstainer looked and said nothing; diluting the consensus is exactly
what it should do.
- a member that could not look at all (no era-end snapshot, untrained,
or a gate) contributes no capable weight, so the caller simply never
Add()s it. That is the distinction 7881159 had to patch by hand.
- only a non-zero contribution counts as a VOTER, which is what the
readout's "N voter(s)" means.
Behaviour is unchanged on the live path: same seeding condition for this
signal's own vote, same capable weight per filter, same divisor. The
abort path no longer assigns `number` before it exists - it is derived
from the accumulator afterwards instead.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Answers "why not just call Direction()": because Direction() is not a
query, it is a transaction. It journals DB rows, draws raw arrows, folds
its result into an intra-second averaging window, consumes one-shot
per-filter vote state and refreshes the live readout. All of that is
wrong on a bar from three weeks ago - which is why the classic replay
has to bracket its Direction() call in a six-field SaveVoteState /
RestoreVoteState. That bracket is not a feature, it is the evidence.
Because the sweep could not call Direction(), it re-implemented the
aggregation: mask, invert, sum, divisor. And a duplicated rule drifts.
It had:
den += filter.ModuleWeight(); // consensus: capable weight, ...
while live uses VoteCapableWeight(). Those differ for exactly the
members that must not be in a divisor: a META head returns 0 from the
latter (it is a gate, structurally incapable of agreeing) and its full
weight from the former, as does a member that has not finished training.
So every reconstructed vote was shrunk by members that could never
agree, and the comment on that very line said "capable weight" while the
code said ModuleWeight.
The loop moves to HistoricalNetVote(idx, capableOut) - one place, live's
divisor - and the sweep keeps only what it is for: threshold, direction
policy, NMS, draw. 42 lines out of the sweep.
This is the first half. The second is splitting Direction() into a pure
vote plus its side effects, at which point the save/restore bracket and
the separate replay path both delete themselves and there is one
aggregation for live, replay and the ensemble gate. Not done here
because it is the live trading path and this build is deploying.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two defects behind "arrows drawn while members are still mid-era".
1. THE DRAW. The filtered overlay armed on the FIRST member to finish
pass 3 and leaned on a 60 s rate limit to "collapse the burst",
assuming members finish seconds apart. They do not - on USDJPY one
member was at sample 10496 of pass 2 while another was at 2304,
minutes apart. A member with no era-end snapshot returns false from
SnapshotVoteAt, and the sweep's `if(!hasData) continue;` skips it
BEFORE `den += ModuleWeight()`, so the one finished model's tier
weight became the entire vote and was drawn as a consensus arrow.
An abstention is a member that looked at the bar and said nothing; a
missing snapshot is a member that has not looked. The first must
dilute the vote, the second must suppress the draw. The arm is now a
readiness MASK - one bit per m_ensembleIndex, set at that member's
pass-3 completion, cleared when a sweep arms - and a sweep waits for
every enrolled member. Bounded at 10 minutes so a member that stops
cannot freeze the chart, and the partial draw PRINTS which members
were missing: the be39674 lesson is that a hold must never silence
the thing that reports it.
2. THE VOTE ITSELF, which is the worse half and is not display-only.
Tier weights are not persisted in the .nnw - they exist only as the
output of a completed pass 3 - so before a member's first
RankTiersFromOos() it holds the constructor's stock 25/50/75/100.
Since 4858507 the vote currency is a WIN RATE, so an unranked tier-3
call enters the capability-weighted mean claiming a 100% win rate
beside ranked members contributing ~25. Not a strong opinion: the
wrong unit. One unranked member drags the ensemble over any
threshold, on every fresh deploy and every resume. USDJPY has a
measured ceiling of ~19 and was firing anyway.
LiveVoteContribution() now abstains until self-ranked, which drops
the member from the sum AND the divisor. One function, so live and
the gate move together (2c443ba).
Era 0 will therefore report 0 coverage until each member completes one
era. The ensemble line says so explicitly rather than leaving it to look
like the USDJPY unreachable-threshold case - the two are identical in
the coverage number and completely different problems.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The diagnostic shipped in de382bb came back off both live charts and
confirmed the arithmetic exactly:
CLOSE-ALL BUDGET - flattens every position every 29 bars ... an entry
landing anywhere in the cycle gets 15 bars on average. The horizon
ladder just granted 128.
So the ceiling the ladder was rejecting rungs against - BARRIER_HORIZON_MAX,
384 - never bound anything, while the one that does bind was invisible to
it. SnapHorizonToLadder and the scale ladder's fitsH test now both read
EffectiveHorizonMax(), which is the measured close-all cycle. One
function, so the ceiling cannot be lowered in the snap and left high in
the rejection test.
The CYCLE, not the 15-bar mean: a Monday entry really does get the whole
cycle, and rejecting on the mean would invent a second criterion where
the design deliberately has one ceiling and reports the milder snap-down
truncation instead of rejecting on it.
Expect the ladder to pick a NARROWER pair, which is what the MEASURE
objective already asks for - min provable EV grows as width squared, and
USDJPY's 6.00*ATR target was being asked of a trade that lives ~11 bars.
"Schedule off" is cached; "not enough bars loaded yet" is not. Caching
the latter would restore the 384-bar ceiling for the whole process
because one early call landed before history arrived.
RE-KEYS EVERY FINGERPRINT - the horizon is a label parameter, so this is
a full retrain on both charts. Done now because both are at era 0 after
a fresh deploy, which is the cheapest this change will ever be.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Every label timeout on both live charts was the scheduled close-all and
none was the horizon. Not "mostly" - all of them:
USDJPY 14417 of 14417 timeouts ended by the close-all
SP500 2434 of 2434
targetDayOfWeek is CLOSE_FRIDAY, so every position is flattened weekly.
A trading week is ~30 H4 bars and an entry lands uniformly inside it, so
the average bar is labelled under ~15 bars of runway. The horizon ladder
granted USDJPY 96 and SP500 32, and the SCALE ladder rejects rungs
against BARRIER_HORIZON_MAX (384) - a ceiling that never binds while the
one that does is invisible to it. USDJPY's chosen target is 6.00*ATR,
asked of a trade that lives ~11 bars: 78.6% of labels come back Neutral,
the base rate collapses to 14.0%, and no model can clear a 33.4%
break-even against a label that mostly cannot resolve.
The close-all itself is correct and must stay - it is what the account
actually does, and 3e467f9 put it into the labels for that reason. What
is wrong is that the geometry deriver has never been told about it.
This commit only MEASURES it. MeasureCloseAllBudget() walks the real bar
series (session- and DST-correct, not arithmetic on a nominal week) and
returns the cycle length plus the mean an entry gets; a CLOSE-ALL BUDGET
line prints both next to what the ladder granted. No geometry changes:
the horizon is a label parameter, so capping it re-keys every
fingerprint and costs a full retrain on both charts. That is the
operator's call, and it should be made against this line rather than
against my arithmetic.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The CANDIDATE GEOMETRY line shipped in 05f1a53 said per-candidate
geometry beats the global pair on every SP500 member at 2-3 sigma. It
does not. It said so because a bar that reached neither barrier scored
0 R, and the incumbent's mean is NEGATIVE (-0.07 to -0.21 R). Against a
losing baseline a free zero is a win, so the widest candidate always
came out ahead - and the reported gain ordered itself by timeout share,
not by skill:
PAI 95.1% timed out -> +0.189 R (head measured -2.42 sigma, HARMFUL)
HYB 73.8% -> +0.182 R (head at chance, +0.68 sigma)
CONV 61.8% -> +0.163 R (head measured -2.47 sigma, HARMFUL)
LSTM 27.1% -> +0.158 R (head +1.67 sigma)
Monotone in the timeout share and inverted against the sigma gate. The
acceptance test written when this was built - "the sigma gate predicts
LSTM helps and CONV hurts; if the R difference does not reproduce that
ordering, something is wrong" - is what caught it.
A trade that reaches neither barrier is not worth zero. It is closed at
the horizon, which is what the scheduled close-all does live and what
SimulateTradeOutcome's timeout path already charges. So mark it there:
TripleBarrierLabel now publishes the signed close-to-close travel at the
last bar it actually visited (m_termTravelCache, same validity flag as
the excursion and ladder caches), and LadderOutcomeR prices a timeout
off it instead of returning false. A bar that cannot be evaluated under
BOTH pairs is now dropped whole - scoring one leg and defaulting the
other is the same bug in a smaller costume.
Second defect, same function: CandidateGeometryFor applied neither of
the floors the global derivation applies, so on USDJPY it chose stop
2.00 / target 1.00 - a 67% break-even, forbidden by the 1:2 policy
floor. c3daded in miniature: a selector optimising its own criterion
with no reference to the decision criterion. Both floors now apply, and
the ratio is re-checked AFTER the per-leg rung snap, which can lose it.
Also: the module weight was an unshrunk pooled win rate. USDJPY ConvLSTM
fired 19 times (2.0 effective), won 36.8%, and took module weight 0.37 -
41% of the ensemble's capable weight and the loudest voice on the chart,
off two effective observations. It also lifted the computed vote ceiling
to 26.3 against a 25 threshold, which is why THRESHOLD UNREACHABLE never
printed on a chart whose peak vote is 14 and whose practical ceiling
without that member is 18.8. The pooled rate is now shrunk toward the
coin-flip rate on the era's own OOS bars over 30 prior-equivalent calls,
and the tiers shrink toward the shrunk value rather than the raw one. A
member with ~300 effective calls moves by ~0.4pp; the 19-fire member
goes 0.37 -> ~0.15.
MEASUREMENT ONLY still - no order reads any of this.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Stage 2a of the candidate-conditional geometry the record has named as next and
never built. MEASUREMENT ONLY - no order uses it yet.
WHY THIS AND NOT META-LABELING. Meta-labeling asks take-it-or-skip-it at fixed
geometry, and its verdict stands: real skill, 0 operating points clearing
break-even, and the 4070c5c retraction only moved that bar 1.4pp. The excursion
head, by contrast, just cleared at 3.5-4.6 sigma on LSTM across four eras and
beat the trailing-quantile incumbent. What is learnable here is MAGNITUDE, so
the lever is the geometry, not the veto. A per-candidate rung means a
per-candidate break-even, which a binary gate cannot express.
HOW IT IS SCORED. At each OOS call the same bar is resolved under the incumbent
pair AND under the pair this bar's excursion head would choose, and the paired
difference is accumulated in R with a 2-sigma test. Both legs come from the SAME
first-passage ladder - four array reads, no re-walk, exact even on the ~28% of
bars where both barriers were touched. Mixing the ladder with the price walk
here would measure the discrepancy between two of our own evaluators rather than
the effect of the geometry, which is precisely what f8ac10c had to unpick one
layer over.
The candidate pair applies the GLOBAL derivation's own rule per bar: stop at
BARRIER_SL_QUANTILE of adverse travel, target at the median of favourable.
Neither creates expectancy; what moves is the break-even, which is why the
report quotes R and never a win rate.
FREE VALIDATION. The sigma gate predicts LSTM helps and CONV hurts. If the R
difference reproduces that ordering across members, the head's usefulness is
confirmed by a second, independent measurement. If it does not, something is
wrong and this must not be wired to orders.
Two things caught while writing it, both silent if missed:
- The ladder stores TRAVEL FROM ENTRY, and the scan's mapping is
risk = ladder + spread but reward = ladder - spread, so the two legs convert
with OPPOSITE signs. The stop leg had the sign backwards.
- A GEOMETRY_BUDGET_MS wall clock, because this adds a feature-window build and
a head forward per OOS call to a walk that already runs unchunked at era end
on a single-threaded EA. That is the shape that got the process force-
terminated on 2026-08-21. It stops scoring, never the replay, and the report
prints how many calls it covered.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
USDJPY has taken no trades in 66 eras and its highest vote ever seen is 13
against a 25% threshold. Not a bug and not undertrained models - arithmetic.
Direction() divides the summed contributions by the CAPABLE weight, so a
unanimous vote returns the capability-weighted mean of the tier weights, which
is roughly the pooled holdout win rate. USDJPY's members pool at 15.6-19.4%
(its label base rate is 14.0% against SP500's 25.4%, because its derived
geometry resolves far fewer bars directionally: Buy 10.3% Sell 11.2% Neutral
78.6%). So the ensemble's CEILING is ~19 and the threshold is 25. Coverage can
never leave 0, and no amount of training moves it, because the ceiling IS the
win rate.
The report now computes that ceiling - every member voting at its best tier -
and says so when the threshold sits above it, instead of printing "0 fired at
vote>=25%" which reads as "the models are unsure".
Same class as the excursion head's disjoint gate (ee4d459) and the reason
ReportDetectability exists: a configuration that cannot reach its own bar has
to say that, not report a number that looks like evidence.
Also: VerboseMode and Run_Alglib_Baselines back to false. The per-era cadence
was for reading the horizon break-even and the excursion sigmas; both are
settled, and TrainLogDue still prints them every 25 eras. The baselines cost a
45 s single-threaded freeze at every attach and their forest row turned out to
be one deterministic observation that does not survive overlap deflation.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two literal duplications the scan found, both of the kind where a divergence is
silent:
- Training.mqh stashed the era-loop resume context at FOUR yield points, seven
identical assignments each (pass 1 differing only in i-1). A field missed at
one of them resumes the next chunk against a different era than the one that
yielded, and nothing reports it until the numbers drift. Now StashEraResume().
- AltDataFetch grew its five parallel arrays inline in three places. They are
one record split across five buffers, so a resize missed on any one reads out
of range on the NEXT append, not at the site of the mistake. Now
AltSeriesAppend(), which returns the new index and zero-fills; callers set
only the columns their source has.
Braces balance across every in-scope file.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The //| box blocks were excluded from 0b06f8e and 5efdb48 and were what
remained: 160 of them ran to 10+ lines, the longest to 88. Compressed to their
leading topic sentences - 5 lines for a function header, 8 for a file header -
keeping the box format and the standard MQL5 name/author lines verbatim.
Verified at the BYTE level this time, across every in-scope file: the list of
non-comment lines is byte-identical to HEAD and braces balance. The first check
compared a locale-decoded 'git show' against a UTF-8 read and flagged 25 files
that had not changed at all - every BOM and every non-ASCII line mismatched.
47,696 -> 40,665 lines in scope; comment share 38% -> 26%.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Same pass as 0b06f8e, applied file by file: comment runs of 4+ lines compressed
to their leading topic sentences, capped at 4 lines, whole sentences only.
Warning sentences (NEVER / MUST / trap / would-have) survive the budget.
Every file was checked the same way before committing: the list of non-comment
lines is byte-identical to HEAD, and braces balance. No code was touched.
Panel/, Enumerations/ and the already-terse System headers needed little or
nothing - PooledGate, TradeChecks, BinomialStats and Random came through with
no blocks over the threshold at all.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
4373 -> 3325 lines. 236 comment blocks compressed to their leading topic
sentences; no code line changed. The archaeology - dates, observed symptoms,
the narrative of each past bug - lives in git and in the project memory, and
repeating it beside every declaration was crowding out the declarations.
Kept: the rule a comment exists to enforce. Any sentence carrying a NEVER /
MUST / trap / would-have warning is preserved even when it falls outside the
budget, because those are the ones that stop a regression.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
EXCURSION_MIN_DISJOINT was 200, sized as "~16k scored bars over a 64-bar
horizon leaves ~250 independent ones". The head scores the OOS SLICE, not the
history. At a 30% split and a 32-bar horizon the ceiling is 4691/32 = 147, so
200 was unreachable and every era printed "[disjoint sample too small]", which
an operator reads as "wait longer". Unpassable by construction - the identical
failure this file already documents one gate down, one layer up.
The trail gate inherited it: m_excTrailScored is a subset of the disjoint bars,
so it failed the same 200 for the same reason, at 130.
Raising OOSSplit or shortening the horizon would clear it and would be fitting
the experiment to the answer. Instead, ask the question the count was standing
in for - is the skill bigger than its own noise:
- The scorer banks one paired Brier difference per DISJOINT window over the
decision rungs (base-head, and trail-head). Disjoint by construction, so no
EffectiveSampleSize deflation applies - striding by the horizon is what buys
that - and paired on identical bars, so the correlation between the two
predictors cancels instead of needing to be estimated.
- passDj and passTrail now require skill >= EXCURSION_SKILL_USEFUL_PCT AND
>= 2 sigma, with the count reduced to a sanity floor of 30.
- Both sigmas print on the verdict line.
This is not a lowered bar. The 2% skill requirement, the oracle control and the
monotone test are untouched, and the sigma test can fail where the count test
never spoke: if +8.5% is noise across 147 windows, it will now say so.
DecisionRungMask() is the single definition of "rung the decision depends on",
called by both the scorer and the report, so the standard error is computed
over exactly the rungs the skill score is. The report's inline copy of the
bracketing test is gone.
Also prints whether the disjoint count is BELOW ITS CEILING or at it, so
"not enough yet" and "not in this configuration" stop reading the same.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The compact panel leads with "learning (era N, pass X%)". The verbose panel led
with "Study -> Era N" and then progressLine, which counts BARS inside the
running pass - it changes wording between passes and reads "Era complete" for
as long as a member sits at the era barrier. So turning VerboseMode ON, which
20b7d99 did as a test-run default, took the one continuously-moving readout
away in exchange for detail. Verbose is meant to be a superset of the simple
view; this was a swap.
Both output-shape branches now carry the same "(pass X%)" beside the era, built
from the same m_passLabel/m_passProgressPct the simple branch uses so the two
cannot disagree.
Also: buy marks are clrDodgerBlue rather than clrLime, per the user - blue
against red reads at a glance where green against red does not.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
clrDarkGreen/clrDarkRed were hard to pick out against the candles. clrLime and
clrRed are the brightest pure pair MQL5 names, and they match what the vote
readout already uses for "this would trade".
The colour is the direction ENCODING, not decoration - a signal line carries no
arrow code, so SaveChartSignals recovers buy-vs-sell by comparing against
WARRIOR_SIG_BUY_COLOR, and marks left by an older build now decode as SELL. No
legacy fallback is kept, per the user: weights and arrows are wiped on every
push. The constraint is written next to the defines instead, for whoever changes
them on a chart that is not being wiped.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Audit of Delete && Reset Weights before pushing. The button is sound - the
21:11:41 wipe deleted all six files for all four members (0 FAILED, four
distinct paths), cleared the arrow sidecars, rebuilt fresh topologies, and
re-derived the barrier geometry from scratch (2.00/6.00 fallback -> 1.21/2.43
from 10610 excursions), so the 2026-08-19 geometry-laundering fix holds. The
per-run block in Train() clears the plateau, best-score and deploy-gate state,
confirmed on the log either side of the reset (PAI 29.2->24.4, HYB 30.4->25.3,
stage 1/3 -> 0/3).
One thing it could not clear, introduced by 4070c5c: m_lastTimeoutShare,
m_lastTimeoutMeanR and m_exitReplayReported. These are sticky across ERAS on
purpose - EmpiricalBreakEvenPct reads era N-1's measurement during era N - and
nothing distinguished that from sticky across MODELS. A reset therefore left
the fresh model reporting the deleted one's horizon-aware break-even on its
first eras, which is exactly the window an operator watches after pressing it.
It never showed up because a reset followed by a recompile constructs new
objects and the constructor initialises them; the failing case is the ordinary
one, reset with no recompile. Cleared with the other per-run state in Train().
Report-only in blast radius - LiveMetaGate and the rung selector still read
CostAdjustedBreakEvenPct - but it is the same class as the geometry bug that
block already had to learn: state correctly sticky for one lifecycle event,
silently inherited by another.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The EXIT-POLICY REPLAY line reported an expectancy from SimulateTradeOutcome
beside a win rate read out of the label cache, and called them "the SAME
calls". Same calls, two different walks - and the walks did not agree.
TripleBarrierLabel stops at NextScheduledCloseAll (3e467f9); SimulateTradeOutcome
never called it, so the replay kept holding positions the live EA is flattened
out of and collected targets the label had already scored as cut. On SP500 H4
the simulation's implied win rate ran 2.2-3.4pp above the label's on identical
calls, and the timeout share read 0.8-1.3% because nothing was truncating the
horizon it walked.
That gap, plus 1.4pp of spread charged twice in CostAdjustedBreakEvenPct, is
the whole of the ~5pp the replay looked "off" by. It was not horizon timeouts,
which is what 4070c5c argued and this log disproved: solving E[R] = 3.008w - 1
+ t(1+m) on each row puts the simulation's zero-crossing at an implied 33.3%
against a frictionless 33.24% - it was internally consistent all along.
- SimulateTradeOutcome takes the close-all cutoff, same expression and same
placement as the label's, falling through to the existing close-at-last-bar
branch. Expect the timeout share to rise and expectancy to fall: the replay
was optimistic.
- m_simTpHits counts this walk's own target-before-stop, printed next to the
label's with the delta, so a future divergence is visible rather than
inferable.
- The line prints all three break-evens and names the R convention. The
frictionless figure is the one this expectancy crosses zero at, because both
walks place the barriers off the spread-shifted fill.
- CostAdjustedBreakEvenPct is left alone: it still feeds the rung selector's
BarrierMinReachPct, and moving that relabels.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two diagnostics on, neither in the fingerprint, so no model is re-keyed and the run resumes:
VerboseMode false -> true per-era journal instead of every 25th
Run_Alglib_Baselines false -> true verifies 3d81fed and finally reaches the OOS scoring
And the fix that makes the run worth doing. ReportExitPolicyDivergence printed ONCE per run while
vote exits are off, justified by "then it is arithmetically guaranteed to agree with the
certificate". That is the claim 4070c5c disproved: the certificate scores win rate against a
GEOMETRIC break-even while this line replays the real payoff including horizon timeouts, and the
two disagree by ~6.5pp. The timeout share is a MEASURED quantity that moves with geometry and
volatility - one print per run is the wrong cadence for it. Now on TrainLogDue(), the same density
as every other era line, with m_exitReplayReported still guaranteeing at least one.
What to read: BREAK-EVEN geometric X% vs horizon-aware Y%, and the timeout share and mean R beside
it. Those two numbers decide whether LiveMetaGate and BarrierMinReachPct get repointed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
CostAdjustedBreakEvenPct is risk/(risk+reward) and has no horizon term. It is the win rate a trade
needs when it is CERTAIN to end at one barrier or the other. SimulateTradeOutcome has an explicit
branch for the case where it does not - runs out of horizon, closes at the last bar seen for
whatever P&L that is - so on this label geometry the figure describes a different trade than the
one being replayed.
The gap is measurable and large. Across 21 exit replays today on SP500 H4 the geometric figure read
34.5% while the EA's own R simulation crossed zero between 27.4% (lowest positive) and 28.9%
(highest non-positive). Independent corroboration: the zero-skill reference, computed empirically
over every scored bar as max(winLong,winShort)/bars, reads 25.4% - add cost and it lands on the
same ~28%. The geometric number is the outlier, and every edge printed against it was ~6.5pp too
pessimistic: LSTM's 30.6%-win era reported -4.0pp while its replay returned +0.075 R on the same
trades.
With a timeout share t paying a mean m R apiece, expectancy is w(1+RR) + t(1+m) - 1, so
w* = (1 - t(1+m)) / (1 + RR) = CostAdjustedBreakEvenPct x (1 - t(1+m))
which needs no new geometry - the existing figure already carries 1/(1+RR).
This commit MEASURES ONLY. The replay now separates timeout exits from barrier exits and latches
t and m for the next era to read (the accumulators are zeroed at era start and filled at era end,
so a mid-era reader sees zero trades and would fall back forever). Both break-evens print side by
side on the replay line with t and m beside them, and the threshold line's REPORTED edge - which
selects nothing - switches to the horizon-aware figure so the operator stops reading a wrong sign.
DELIBERATELY NOT CHANGED: LiveMetaGate's veto and the rung selector's BarrierMinReachPct still read
the geometric value. Both are decisions - the second re-derives geometry and therefore relabels -
and t and m have so far only been inferred from a zero-crossing, never seen on a log. One era of
this instrumentation settles that.
The file already contained the argument, one branch away, in the vote-exit comment: a vote exit
produces a CONTINUOUS payoff, not a win or a loss, and that is why an exit-aware gate cannot go on
scoring win-rate against a fixed break-even. A horizon timeout is the same thing, and unlike vote
exits it is on by default.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Yesterday's fix predicted the cross-validation's cost and declined it before starting, then left the
linear fit to a plain boundary check. The 17:01 run says exactly what that was worth:
ALGLIB MLP trained in 12.1 s ... NOTE: 6435 weights against 995 rows
cross-validation SKIPPED - 3 folds x 12.1 s = ~36.3 s predicted against 31.9 s left
Alglib baselines stopping before the OOS scoring - 548.8 s spent of a 45 s budget
Everything up to the linear fit obeyed the budget. LRBuild then held the thread for ~535 s in one
uninterruptible call and the check fired afterwards, on a decision that was already made. The same
block shows up in the training timer as 'SLOW ERA heartbeat - net fwd/back 3.9s | everything else
566.2s', and in three members re-arming a study event that never arrived.
LRBuild solves a (width+1)^2 normal-equation system: the cost grows as width^3 and ignores the row
count entirely, so the row cap that fixed the forest and the MLP does nothing here. Predicted from
that measurement and declined before it starts, like the CV.
Second, independent reason to decline it: at 800 columns against 1000 rows the normal equations are
singular, so any coefficients returned are one arbitrary solution of infinitely many. That fit would
have been printed as a baseline while carrying no information. Both grounds are checked, and the log
says which one applied.
The OOS scoring - the phase that answers the question the suite exists for - has now failed to run
twice for two different reasons. It is the first thing to check on the next attempt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Run_Alglib_Baselines was described as bounded because it 'cannot outrun the bar it runs on'. That
bound is four hours on H4, it was never enforced, and it is the wrong target: the EA is single
threaded, so while this pass runs there is no training, no panel, no tick handling, and a removal
request only queues.
Measured today on SP500 H4, 800 inputs x 4000 rows: forest 5 s, MLP 52 s, then the 3-fold CV -
three more full retrains. At 15:18:16, 83 s into it, MetaTrader force-terminated the EA. OnDeinit
never ran, so every arrow, panel object and label was orphaned on the chart. The init purge cleans
that up on re-attach; nothing in the pass writes to a cache, saves a model or feeds a decision, so
the damage was the freeze and the dirty chart, not corrupted state.
Three changes:
- BASELINE_MAX_CELLS. Every fit costs O(rows x width) and the row caps carried no width term.
Rows now shrink as the window widens - 1000 instead of 4000 at 800 columns - and the log says
when the cap bit.
- BASELINE_BUDGET_MS with BaselineBudgetSpent(), replacing the bare ShutdownRequested() calls at
each phase boundary. A stop and a spent budget need the same answer and only one was asked.
- The cross-validation is now declined BEFORE it starts, from its predicted cost - the measured MLP
time times the fold count. A boundary check cannot help once a phase is in flight, which is
exactly the phase that was in flight when the process died.
Also: the MLP now reports its weight count against its row count. At 800 inputs it carries ~6,400
weights, and today's run duly printed a training class error of 0.000. That is knowable from the
shape before fitting, so it is stated rather than left to a cross-validation that may not run.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two same-config charts collide on the config lock. AcquireConfigLock prints a precise REFUSED
line, but CExpert::InitIndicators then returns a bare false, RetryInitStep retries it five times
- a lock held by a live chart gives the same answer every time - and the last line on screen is
"Failed to initialize Indicators after retries", which names neither the lock nor the owner.
The explanation is six lines further up, under identical-looking retry noise.
A refusal that cannot change on a retry now says so and stops: AcquireConfigLock records the
reason, RetryInitStep repeats it and returns immediately.
Found because a second SP500 H4 chart was started to run Run_Alglib_Baselines. That input is a
diagnostic and is deliberately not in the fingerprint, so both charts resolved to the same
filename - the guard was correct and the message was not.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Features() binary-searches m_rowTime (StringToTime of a naive "2026.08.21" = 00:00) against
m_Time.GetData(idx), which is BROKER time. A row dated D carries values public from D 00:00 UTC,
so every bar in [D 00:00 broker, D 00:00 UTC) - the first H4 bar of each broker day - reads that
row 2-3 hours before it was public.
Not a leak today: every collector stamps with a conservative buffer on top of the real release,
and the overshoot fits inside all of them. Tightest is the FRED daily series - VIX prints 16:15 ET
and is stamped D+1 00:00 UTC, leaving >=1h45 in the worst DST alignment. COT (Friday 15:30 ET ->
Saturday 00:00 UTC) has no bars to read it before Monday at all; EIA has ~8h.
Recording it because nothing in the file said so, and the safety lives in a number nobody would
think to check before shortening a stamp.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The report has flagged f30 as mostly-zero (78%) on every member of every run
for days. Establishing what f30 actually IS took reconstructing the emission
order across three files, and I got it wrong on the first attempt - guessed
RSI, then MACD, both wrong because those feature blocks ship disabled.
It is spread[1], the spread CHANGE ratio, and 78% exact zeros is exactly what
that should read: the broker quotes the same spread on consecutive bars most
of the time, so the change is exactly 0. Benign, and it cost two wrong
answers to say so.
The report now names the block - "spread[1] (78%)" instead of "f30 (78%)".
The walk lists every block in the order BufferTempDataCompute emits them with
the widths Topology.mqh's m_neuronsCount sum declares, which makes this a
third place that has to stay in step with those two. So it does not stay in
step silently: the widths must total m_neuronsCount, and when they do not the
layout has drifted and every name past the drift point is wrong - so it
returns "f<slot>?" and names nothing rather than naming confidently and
incorrectly. A wrong name is worse than a bare index.
This is the same lesson as cb30360 (print the resource's IDENTITY, not just
its state), applied to the feature vector. The alt-block hint in the header
goes away with it - it existed to disambiguate one block, and every block is
disambiguated now.
Reporting only, no behaviour change.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The CALIBRATION field added in 667f2bc counted m_oosBuyPredicted, and that is
ApplyClassificationSoftmax() - the bare argmax, before the fitted operating
point ever sees the bar. The decision is AdjustedSignalFromSoftmax(), which
applies m_dirConfThreshold and is counted separately in m_oosBuyFired.
So the field was describing a layer that never places an order, and the two
layers are nowhere near each other. Era 3 of the 12:18 build, all four
members:
CALIBRATION (argmax) Buy 1.6-2.5x Sell 0.8-1.8x Neutral 0.2-0.5x
threshold fit directional coverage 34.3-38.5% vs a 37.4% target,
miss 0.3-3.1pp
Read together those say the argmax leans hard directional and the operating
point corrects it to within about a point. Read alone, the first says the
models have collapsed away from Neutral, which is what I would have concluded
from it - an instrument that misleads exactly where it is being looked at.
The traded layer now leads. The argmax stays as a tail because the GAP is its
own diagnostic: it says how much of the calibration the operating point is
carrying, and a widening gap means the head is drifting while the threshold
absorbs it.
No behaviour change - reporting only.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Neutral has been excluded from the logit adjustment since 2026-08-16 - offset
pinned to zero. That fix was right for its moment and it rested on two
justifications, one of which is now measured false.
The sound one: Neutral was then the RAREST class (10.61% on SP500 H4), so
including it SUBSIDISED abstention by 1.20 logits, and with no directional
edge to overcome that the model took the free lunch - OOS recall Buy:1%
Sell:0% Neutral:100%. The anti-collapse mechanism was the collapse.
The other: "abstention is already owned by m_dirConfThreshold". Era 1 of
2026-08-21 measured that directly, now that the operating point is fitted on
calibration and reports what it reaches. Three of four members drove the
threshold to 0.00 - no abstention filter at all - and STILL called a direction
on only 12.9-14.5% of bars against a 37.5% label rate. At 0.00 the threshold
owns nothing; the abstention is coming from the head's own argmax. So nothing
was correcting the Neutral rate, and the new CALIBRATION field shows the
result: all four members over-call Neutral 1.3-1.8x while under-calling Sell
0.0x-0.5x. CONV calls Sell on 1% of bars against a true rate of 25% - a flat
refusal to trade one whole side.
The sign has also flipped since that failure. Neutral is the DOMINANT class
now (62.5%), so including it PENALISES abstention rather than paying for it.
Rather than depend on that staying true, the invariant the old comment
STATED is now implemented literally instead of by proxy: Neutral's offset is
clamped at >= 0. It can be penalised when over-represented and can never be
boosted when rare. Pinning it to zero blocked both directions; this blocks
only the half that was ever harmful, and makes a return to the 2026-08-16
regime structurally safe rather than newly dangerous.
The cap is now sized on the full three-class spread so it bounds the real
offset range, and the log line says which way abstention is being pushed -
that being the question this correction has now got wrong in both directions.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The margin threshold now sits where the model calls a direction as often as a
direction actually occurs. Nothing else.
WHY THE OLD OBJECTIVE HAD TO GO. It maximised `coverage x (precision -
breakEven)`, and this function's own comments were already the case against
it: over 98 consecutive fits of the shipped SP500 H4 model, correlation
between the chosen threshold and the win rate at it was -0.056, while the
era-to-era spread of that win rate (1.32pp) matched its own binomial SE
(1.25pp) to within 0.07pp. The margin does not rank trades. So the argmax
returned whichever of ~37 bins drew the luckiest sample, and the threshold
teleported 0.42 -> 0.04 -> 0.74 in three eras.
The response at the time was to build a null-of-the-maximum gate, an
effective-sample SE and a parsimony fallback to hold the noise down. All of
that is gone now, because fitting on calibration removes the problem instead
of bounding it: coverage is a ratio against a fixed denominator so it is well
determined at every bin, the target is a measured label rate rather than an
outcome, and nothing is maximised over a noisy curve so there is no best-of-N
to correct for. Net 174 lines out, 62 in.
It deliberately does not chase edge. It cannot - at ~0 measured edge no
operating point has more of it, and pretending otherwise is what produced a
threshold of 0.96 that still passed 60% of bars while the model called a
direction ~10x too often. The edge at the chosen point is still REPORTED,
just no longer what chooses it.
THREE READINGS OF ONE QUANTITY, AND THEY DISAGREE. "How often does a direction
occur" is measured in three places and gives ~7% (the scan's own tally), ~41%
(the era loop's counters, via this function's old coverage floor) and ~50%
(the ensemble gate's OOS base rate). They cannot all be right. Rather than
pick one silently, ScanDirectionalRatePct() and EraDirectionalRatePct() are
now named accessors, the fitter targets the SCAN - that is the tally the
operator reads, and the one "predict the labels as measured during the scan
phase" names - and the threshold line PRINTS BOTH every time it moves, so the
disagreement is on the record instead of buried in a derived floor.
The ensemble gate's own floor is deliberately NOT changed in this commit. If
the scan is right, a calibrated member covering ~7% of bars cannot clear a
12.4% floor and every model would fail the gate by construction; if the gate
is right, the scan tally is wrong. The CALIBRATION field added in 667f2bc
reports the OOS true class rates directly and settles it in one era - that
measurement comes first, and the floor follows it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Reverts a863796 on the operator's call - "unnecessary complexity". It was
right about the mechanism and wrong about the priority: it re-cut the classes
for a case the measured verdict never reaches (SP500 H4 reads "both sides" at
the derived geometry), while the drift that IS happening affects every chart
and every era. Recoverable from a863796 if a one-sided book ever becomes real.
Two pieces of it survive, both independent of the exit idea:
The drift verdict keeps reading m_winLongCache/m_winShortCache rather than the
collapsed label pair. That line reports always-long vs always-short win rates,
which is what the win caches hold - each side scored on its own barriers,
published before the collapse. The label pair carries only the side touched
first, so it undercounted long wins by the both-won-goes-to-short share. There
are zero both-won bars at any geometry with target >= stop, so this changes no
number today; it changes the wrong number to the right one.
And the .cfg gains nothing and loses nothing: the two appended ints go away
again, and they were the last fields, so a .cfg written by yesterday's build
still reads correctly - the loader simply stops before them.
WHAT THE REVERT MAKES ROOM FOR. The operator's actual requirement is that the
model reproduce the label distribution the scan measured, and nothing in the
pipeline ties it to that. The loss trains on a rebalanced sample and the
abstain rate is owned by a margin threshold fitted on EDGE, so the call rate
and the label prior can drift arbitrarily far apart - and did, invisibly:
at era 1350 the models call Buy on 20-28% and Sell on 22-32% of bars against
a scan-measured 2.1% and 4.8%. Roughly a 10x over-call, and not one line in
the journal said so.
The era line now carries it:
CALIBRATION calls vs true rate Buy 28% vs 2% (14.0x) Sell 32% vs 5% (6.4x)
Neutral 40% vs 93% (0.4x)
Reported as a ratio because that is the readable number - 1.0x is calibrated.
This is deliberately a measurement and not yet a correction: matching the
label rate would put coverage near 7%, below the ensemble gate's own 12.4%
coverage floor, so calibration and the gate are in direct conflict and which
one yields is the operator's call, not mine.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The era-progress rate limit was a function-scope `static`:
static uint lastProgressLogTick = 0;
shouldLogProgress = (nowTick - lastProgressLogTick >= 5000);
In MQL5 that is ONE variable for the whole build, not one per object. A 5s
limit meant to keep a single model's console readable was therefore a limit
across the WHOLE ENSEMBLE, and it did not distribute fairly - it starved
whichever member finishes last, every era, deterministically.
Measured on today's run: the era barrier releases the members together and
LSTM landed 2.06s, 2.43s and 2.28s behind ConvLSTM on eras 1-3, against a 5s
window it could never reach. LSTM printed zero era lines. PAI, CONV and HYB
printed all of theirs - 3 each this run, 17 each in the 10:00 run, LSTM 0 in
both, and 0 again in the 08:32 run.
So one model in four has been training with NO per-era telemetry: no
per-class recall, no dW/W ratios, no zero-skill comparison, no deploy-bar
line. It was still doing the work - tier re-ranks, threshold fits and
exit-policy replays all appear on cadence - which is what made the hole look
like a grep that kept missing the line rather than a line that was never
written. It cost me the LSTM half of a gradient check earlier today.
Now a member, so each model rate-limits its own console output.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Found while costing whether to turn Run_Alglib_Baselines on. The suite builds
its design from BuildFeatureWindow() over DeriveHistoryBars() bars, and
neither reads any per-member state - symbol, period and feature toggles only.
So every member of an ensemble builds a byte-identical matrix and fits an
identical forest, MLP and OLS to it: four un-chunked fits over ~1000 columns
x 4000 rows, to print one answer four times. The MI suite has had a
once-per-chart gate for this exact shape since the ensemble landed; this
never got one.
Gated the same way, and here without the MI gate's caveat: that one has to
warn that the geometry scan at the end of its chain makes a DECISION, so a
donor-only run would leave the other members on a different target. This
suite decides nothing - nothing trades on it, no model is saved, and
ReportGeometryDrift assigns to nothing - so the donor's run is the complete
answer. Solo charts are unaffected.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
User request: "when an asymmetry is noticed in a market (like sp500 upward
drift) ... it does not need to predict shorts, but exit points. a sell signal
needs to be preceded by a buy so that it can say I predict we must close that
long."
Until now a LONG_ONLY verdict only BLOCKED short entries. The network went on
being trained to predict them - a third of its output capacity spent learning
an answer the direction policy guarantees it can never act on, while the
question the book actually faces (when to get out of the long) was never
asked. The two are not the same event: "a short pays" needs price to travel
the SHORT's target before the SHORT's stop, and at any geometry where reward
!= risk that is a different bar from "this long hits its stop first". The exit
is the second one.
So on a one-sided book TripleBarrierLabel re-cuts all three classes around the
only position the book can hold: Buy = it reaches its target, Sell = it
reaches its STOP first, Neutral = the horizon expired with it still open. Both
come off the allowed side's own barriers, which the walk already computed -
this reads longLost where it used to read shortWon, so it costs nothing.
Label lifespan and the timeout flag follow the allowed side too, so the
overlap correction is sized on the window this label actually spans.
DECIDED ONCE, AT ERA 0, AND PINNED. m_exitTargetSide goes in the .cfg beside
the derived geometry under the same doctrine and for the same reason: it
decides what Buy and Sell MEAN, and a target that moved mid-run would retrain
a fitted model against something it never saw. A .cfg from before this ends
early and reads 0/0 - "not decided, symmetric" - which is exactly what every
existing model was trained as, so nothing needs migrating. The weights
fingerprint keys on the INPUT only (explicit Long only / Short only); under
Intelligent the measured verdict must never reach a filename, or the model is
orphaned the moment more history downloads.
THE DRIFT VERDICT HAD TO MOVE OFF THE LABELS FIRST, and it turns out it was
measuring the wrong thing anyway. It counted m_labelCacheBuy/Sell and called
them "always-long vs always-short win rate", but the label pair is the
COLLAPSED first-touch verdict: a bar where both sides reached their target
carries only the side touched first, so long wins were undercounted by the
both-won-goes-to-short share. m_winLongCache/m_winShortCache are the actual
per-side win rates, published before the collapse, and that is what it reads
now. Necessary as well as more correct - deriving the verdict from labels the
verdict shapes is a feedback loop, since Sell-as-exit is near complementary
to Buy and would close the very gap that produced it. The gap's SE now leans
conservative rather than anti-conservative for the same reason.
LIVE. The retargeted class is wired to close the position, or training it
would be pointless: CheckClosePosition's "never vote-exit a certified
position" rule keeps governing symmetric books and gains a one-sided
exception, and the replay reads the identical rule through one
LiveVoteExitThreshold() so certified and traded cannot describe different
policies. Armed only when the operator picks a close threshold
(Signal_ThresholdClose ships Disabled) AND the model's own pin says its
blocked-side class means "close" - a model trained symmetric never fires it,
whatever the verdict has since become. This does trade a different game from
the one the win-rate certificate grades; the era's EXIT-POLICY REPLAY line
already reports expectancy in R for exactly this case and says so in words.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Found auditing pointer discipline, per the standing rule that CheckPointer
comes before every dereference.
THE LEAKS. CNeuronLSTM::feedForward allocated forget_gate, input_gate,
output_gate and new_content on the heap and deleted them only on the success
path. Eight error returns sit between the first allocation and that delete,
and every one of them abandoned whatever had been built so far. calcHidden-
Gradients was the same shape with fourteen returns past MemoryGradient. This
is the CPU path, which is the only path this machine has - no OpenCL, no
DirectML - so it ran on every era of every LSTM and CONVLSTM member.
Fixed by construction rather than by adding deletes: none of the five buffers
escapes its function, so each is now an automatic object. The return itself
destroys them, which means the leak cannot come back the next time someone
adds an error path - which is exactly how it got here.
CalculateGate had to change shape for that: it now fills a caller-supplied
CArrayDouble and answers bool, instead of handing back an object each caller
was responsible for deleting on its own error paths and none of them did. It
also allocated BEFORE testing `gate`, leaking on that very check, and never
tested `sequence` at all before dereferencing it. Both arguments are checked
first now. Protected virtual with three call sites, all in this file - no
public API moves.
THE UNCHECKED DEREFERENCES. The input-gradient loop did four rounds of
`temp = SomeGate.At(i); con = temp.getConnections().At(n); value +=
temp.getGradient() * con.weight` with no check on either pointer, and At()
answers NULL for an out-of-range index rather than failing loudly. The four
copies are now one AccumulateGateInputGradient() that checks the layer, the
neuron and the connection. The line above them read `temp.getConnections()`
off whatever the previous loop happened to leave in `temp` - NULL if
OutputLayer was empty - and is now checked too.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two UX changes the operator asked for.
THRESHOLDS. Signal_ThresholdOpen/Close were raw ints with the legal range
written in the label ("[0...100, 101 = never]") - the one input style this
codebase converted away from everywhere else. Open now takes the existing
PERCENTAGE_PRESETS, whose comment already declared itself to be "Signal_
ThresholdOpen's scale" but was never wired to it; Close takes a new
SIGNAL_CLOSE_PRESETS carrying the same rungs plus CLOSE_DISABLED = 101, which
is why it cannot just reuse the other enum. Member names are prefixed because
MQL5 enum members share ONE flat namespace - a bare PCT_25 in the second enum
would silently resolve to the first one's, warning only. Values are unchanged,
so existing .set files keep their settings. Both call sites now cast
explicitly at the CExpertSignal boundary rather than leaning on an implicit
enum-to-int conversion that only warns.
ARROWS. 2026-08-19 replaced the low/high arrows WITH trigger-price lines; that
was a swap where it should have been an addition, and it cost the zoomed-out
view. A mark is now both objects: the line is the precise entry/exit level,
the arrow off the candle's extreme is the finder that says there is something
here to zoom into. The arrow's name is the line's plus a suffix, so it stays
inside SIG_ARROW_PREFIX and every prefix-scoped purge already reaches it.
The two type-filtered sweeps had to widen or they would clear one half and
leave the other: the Hide/Show visibility loop and the pre-rescan scoped
delete both walked OBJ_TREND only. Both are typed-blind and prefix-scoped now
- the same widening this file's 2026-08-09 note describes, for the same reason
it gives. Deletes go through one WarriorDeleteSignalMark() so an arrow cannot
outlive the line it belongs to, and the sidecar deliberately still records one
row per mark off the line (the half carrying the price), with the restore
redrawing the pair.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The detector claimed "-1 means an INVALID HANDLE, 0 means created-but-never-
calculated". This run disproved it with our own instrumentation: the repair
line prints only when Create() RETURNED TRUE, and the depth it read
microseconds later was
BEFORE: MA=-1(h13) | AFTER: MA=-1(h13)
A freshly created, valid handle read -1 - the value the model says is
impossible for one. So BarsCalculated() < 0 does not mean "dead"; it also
covers "valid, not calculated yet", and the trigger cannot separate them.
Consequences, all fixed here:
- The AFTER depth was re-read synchronously, when it can only be -1 or 0, so
every repair looked like a failure and the line was unreadable either way.
It now reports the handle NUMBER across the recreate instead. A changed
number proves a new instance; SAME means MT5 handed back the same
refcounted one, so it was never dead.
- IndicatorDepthReport printed the handle number for MA alone. Every tunable
gets one now, through a single IndicatorDepthField() - nine near-identical
StringFormat calls collapse to one.
- The comment justifying "never release before re-creating" rested on the
claim just disproved. The decision stands, the reason is restated: given
the ambiguity, releasing is the dangerous half - a recycled number would
decrement whatever owns it now and CAUSE this outage - while re-creating a
live handle only leaks a reference on a path that fires a few times a
session.
The before-handle is captured on its own line, never as a sibling argument to
the Init* call: MQL5 does not define argument evaluation order.
Behaviour is otherwise unchanged - same trigger, same cooldown, same
recreate. Only what gets reported changed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ExpertSignalAIBase.mqh 4388 -> 4256 lines. Every edit verified the same
way: non-comment lines extracted before and after and diffed, so the
change is provably comments only.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Box header per function/class, section banners, and 1-3 line notes for
variables - not the paragraphs that had accumulated. Both files verified
mechanically rather than by eye: every declaration in Inputs.mqh (159 of
them) and every non-comment line in ExpertSignalAIBase.mqh is byte-
identical before and after.
Variables/Inputs.mqh 881 -> 355 lines (704 -> 179 comment lines)
Expert/ExpertSignalAIBase.mqh 4795 -> 4388, first ~800 lines converted
What was cut is narration - the history of what a constant used to be,
paragraphs restating the line below them, and commentary about earlier
versions of the comment itself. What was kept is every constant, every
measured number, and the traps worth a warning.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Reported symptom: one member at era 17 while the rest sat at era 2, with
the combined vote never scoring. Two faults compound to produce exactly
that, and neither needs a broken model to trigger.
FIRST - BUSY WAS READ AS STUCK. BarrierEraHeartbeat() decides liveness
from one signal: has m_eraCount changed in the last 12 minutes. But
Train() returns early, before the era loop, for three ONE-TIME phases
that never touch m_eraCount - the label-cache prebuild, the pattern-DB
backfill and the OOS simulation walk - and those are precisely what a
slow topology spends its first many minutes doing. A member grinding
steadily through a prebuild therefore looked identical to a dead one and
was dropped from the barrier at startup, before it had trained a single
era. The constant's own comment states the flawed premise: "comfortably
past the slowest healthy ERA on the deepest chart" - true, and not the
question being asked. Those three branches now call NoteBarrierProgress()
and a chunk of phase work re-arms the watchdog exactly as an era does.
SECOND - EXCLUSION HAD NO BOUND. Once dropped, a member is skipped by
EnsembleMinTrainingEra(). Drop every OTHER member and that loop finds
nothing to take a minimum over, falls through to its `return m_eraCount`
fallback - the CALLER'S own era - and EnsembleEraBarrierHolds() evaluates
`era > era`, false, for everybody. The barrier silently becomes a no-op
and the fastest member runs away unbounded. EnsembleMinEraAnyMember()
now measures against every still-training member, excluded or not, and a
member may lead it by at most ENSEMBLE_MAX_ERA_LEAD eras.
The cap is deliberately a real stop rather than a warning. A
desynchronised ensemble is not a degraded one: the combined-vote score
and the joint checkpoint both require every member on the same era, so
weights trained past the cap can never be certified by any gate. The
hold reports which of the two it is, because the operator's next move
differs - an ordinary barrier hold resolves itself, a lead-cap hold names
a member that needs diagnosing and will not resolve on its own.
Not yet explained: "only one NN listened to the stop command". The panel
now dispatches down the filter tree and reports the count it reached
("training stopped (N model(s))"), so the next run answers that
definitively instead of leaving it to inference.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
