The improvement architecture developed in Part VI assumed one feedback loop: closed trades feed a scorecard recalibration that, after walk-forward and Monte Carlo validation, eventually promotes a new set of weights. This is the most natural loop in a trading system because closed trades are the highest-quality, cash-grade outcome data the system produces. It is also the smallest feedback set the system has access to. A platform that takes 200 trades a year and refuses to learn from anything else is leaving 99 % of its decision history unlabelled and undiscovered. This chapter develops the second loop: a system-wide learning architecture that logs every algorithmic decision (not just the trades that closed), attaches several independent outcome labels to each decision, and mines the labelled corpus for statistically validated patterns.
Figure 1. Concept map for this episode: fight, desk translation, what to lock.
Why log every decision, not just every trade
A typical platform with five generators (a universe filter, a pre-market gate, a scoring engine, a screener, a debate or consensus layer) produces in a typical day: - 200 universe-filter verdicts (admit / reject). - 100 pre-market gate verdicts (pass / fail). - 50 scoring-engine verdicts (rank). - 30 screener verdicts (long / short / flat). - 10 debate verdicts (buy / sell / wait). - 5 actual trades.
Context enrichment: a substrate the generator never asked for
A generator built today does not know what features the miner of three years from now will need. A scoring engine that reads ten technical features may not pull in macro regime indicators, institutional flow indicators, or implied-volatility-regime indicators - because the engineer who built the scoring engine did not think those features were relevant to that particular generator. But the miner has no such prior; it would happily discover that "scoring-engine BUY verdicts emitted when implied volatility is in the panic regime have a 12 % lower forward-return" - if only the proposal carried the implied-volatility feature at all. The solution: enrich every proposal, at write time, with a common pool of market-context features pulled from the warehouse. The proposal-writer interposes a thin function between the generator's verdict and the on-disk row; that function reads the generator's existing case dictionary and appends a fixed set of context keys pulled from the warehouse for that subject's date. The generator's own code stays unchanged. The miner downstream sees a uniform context block on every proposal regardless of which generator emitted it.
Multi-axis outcome attribution
A trade has one cash outcome. A decision has many possible labelled outcomes - and which outcomes are most informative depends on the question being asked. Multi-axis outcome attribution applies a suite of outcome resolvers to every proposal and stores all of their labels, leaving the miner free to ask different questions of different label types.
Predicate mining at scale
With a corpus of (proposal, multi-resolver-outcome) tuples, the miner's job is to discover boolean predicates whose conditional win rate beats baseline by enough to clear the multiple-testing threshold and the multi-axis sniff test. The procedure: 1. Candidate enumeration. For each feature the generators recorded, generate threshold-based candidates (feature above some cutoff, feature equal to some category, feature missing), plus two-feature combinations from the strongest individual features. 2. Support floor. Drop any candidate that isn't backed by enough matching proposals to trust - a rule from 5 examples is noise, not a pattern. 3. Wilson-LB scoring. For each surviving candidate, compute a conservative lower bound on its true win rate and only keep candidates that clear a fixed threshold. 4. Lift filter. Drop candidates whose edge over baseline is too small to be worth the maintenance cost, even if statistically real. 5. Bonferroni/FDR correction. Apply a multiple-testing correction across the whole candidate population, since testing thousands of candidate rules will turn up some by chance alone.
Definition
A proposal is the unified record of one algorithmic decision. It carries: a unique identifier, a timestamp, the generator identifier (which algorithm made the call), the kind (what type of call within that generator's repertoire), the subject (the symbol and market the call is about), the verdict (the call itself, as a structured body), the case (a flat dictionary of numeric or categorical features that the generator considered at decision time), and a context block (any additional metadata the operator might want at audit time - model version, configuration hash, request id). The flat case dictionary is the most important field for downstream mining. Every key in it is a candidate predicate dimension. The miner that sees thousands of proposals across many generators reads the union of all case keys as its feature space.
Worked picture
Baseline win rate on forward-return labels: 53%. Candidate predicate "gate PASS AND vol-regime = calm" matches 40 proposals with 29 wins - a raw win rate of 72.5%. Running that through the Wilson 95% one-sided lower bound (the same statistic Chapter 36's promotion gate uses) to correct for the small sample brings the conservative estimate down to about 60%, still comfortably above the 58% promotion threshold, for a lift of roughly 1.37× over baseline. Survives support floor - still must pass Bonferroni across the candidate family and the alpha-vs-benchmark axis before promotion.
What breaks in production
The temptation when designing the context block is to load it with every clever derived feature the engineer has ever wanted. Resist. The context block's job is to provide common ground across generators, not to be the system's primary feature panel. Keep it small (10-20 keys), keep it canonical (warehouse-derived, point-in-time-correct), and keep the schema stable for years so the miner's historical comparisons remain valid. Experimental features belong inside individual generators, where they can be ablated without polluting the cross-generator corpus.
The multi-axis cross-validation defence
Multiple-testing corrections (Bonferroni, Holm-Sidak, FDR; Chapter 15) defend against finding spurious rules by chance. Multi-axis cross-validation defends against a different failure: finding rules that are real but uninformative - rules that capture market drift, calendar effects, or other shared factors that any naive strategy would also ride. A rule that survives both a Bonferroni-corrected significance test and the multi-axis sniff test is what the production miner promotes. The asymmetry is the strongest single defence the miner has against discovering "edges" that are really beta in disguise.