A plain-language brief on the system, its vocabulary, and how it measures success.
The Rotation Floor Bookkeeper is a deterministic accounting engine that takes trading signals from RCQ's two strategy engines, translates each one into a capital rotation between two assets, tracks whether that rotation beat simply holding, and routes the winnings into a Bitcoin-denominated accumulation ledger — all at zero token cost, with the LLM agents reserved for governance and oversight.
RCQ runs two signal engines: an XRP/BTC z-score mean-reversion strategy and a BTC/USD mean-reversion strategy. These engines are good at one thing — identifying when an asset is statistically mispriced and likely to revert. But a signal is not a position, and a position is not an accounting record. Something has to sit between "the engine says rotate" and "here is exactly what that did to our capital."
That something is the Bookkeeper. It is deliberately not an LLM agent. The work it does — translating signals into sized rotations, tracking sub-balances, computing results, allocating profit — is pure arithmetic. There is no judgment to exercise, so there is no reason to spend tokens on it. This keeps the expensive reasoning capacity (floor-commander for governance, risklab for monitoring) focused on the decisions that actually require thought, while the deterministic math runs for free.
Three terms run through everything the floor does. Each means something specific inside this system.
A sat (satoshi) is the smallest unit of Bitcoin: one BTC equals 100,000,000 sats.
In this system, sats are simply the display unit for results. The Bookkeeper computes everything in BTC, but those numbers are tiny fractions — a result like 0.0000462 BTC is hard to read and easy to miscount. The dashboard multiplies by 100 million so it reads as "4.62k sat" instead. Nothing is calculated in sats; they are the ruler, not the thing being measured. When sats appear on the dashboard, they represent the BTC-denominated result scaled up for readability.
A chunk is one rotation event — the Bookkeeper's fundamental unit of work.
When a signal fires, the Bookkeeper rotates a fixed percentage (currently 10%) of a sub-balance from one asset into another. That rotation, from the moment it opens to the moment it closes, is a chunk. It has a complete lifecycle:
Every chunk receives its own row in the RotationChunks tab, with a unique ID (such as RC-XB-0084 or RC-BU-0091), its entry and exit prices, the quantities involved, and its computed result. One signal-engine trade becomes one rotation chunk. When the dashboard reports "183 total chunks," that is 183 rotation events tracked across both legs.
Alpha is the single most important number the floor produces, and it has a precise meaning here.
Generically, alpha means returns above a benchmark — the value a strategy adds beyond a baseline. In this system, the benchmark is specific and deliberate: "what if we had never rotated and simply held the original asset?"
For every chunk, the Bookkeeper computes two values:
Alpha is the difference between them:
Alpha = close value − hold value
Positive alpha means the rotation beat doing nothing — executing the trade was worth it. Negative alpha means holding would have been better, usually because transaction fees consumed a price move too small to overcome them (the "nothing happened" scenario).
This is the concept most worth internalizing, because the two can disagree.
There is only one trade per chunk — the rotation is the trade. But there are two different questions you can ask about its outcome:
These produce different answers in two important cases:
The Bookkeeper records alpha, not raw profit. The AlphaVsHold_BTC figure — the one that drives cumulative performance and feeds the profit router — is always the against-holding measure. It is computed from real entry and exit prices, so it fully reflects the trade's actual outcome, but it is expressed as the difference versus holding.
Because the entire thesis of the rotation strategy is "we can beat simply holding Bitcoin." If the floor measured raw profit, it would deceive itself: in a rising market almost everything looks profitable, but that reflects the market rising, not the strategy working. Alpha strips out the market's own movement and isolates whether the rotation decisions created value. A chunk can post positive alpha on a day Bitcoin falls, because alpha measures the rotation's edge, not the market's direction.
In short: raw profit asks "did I make money?" Alpha asks "was trading smarter than sitting still?" The floor lives or dies on the second question, because that is the one that proves the strategy earns its keep.
The full pipeline, end to end:
One sentence captures it: the Bookkeeper turns signals into chunks, measures each chunk's alpha against a hold benchmark, the profit router allocates the positive alpha, and sats are how the results are read.
SubBalances is a balance sheet — it shows where capital currently sits within each leg, split between the two assets. These numbers move constantly as chunks open and close. They tell you your current allocation state, not your accumulated profit. You cannot read "am I winning?" off the sub-balance, because the balance of any single asset rises and falls with every rotation cycle.
Cumulative alpha is the scorecard — it tells you whether the floor is actually accumulating value above the hold benchmark. Positive cumulative alpha means the strategy is beating holding and stacking real, strategy-earned Bitcoin. Negative cumulative alpha means the rotations are, on net, behind where simply holding would have left you.
The rule of thumb: SubBalances tells you where your money is; cumulative alpha tells you whether you are winning. To answer "am I stacking sats through skill rather than market drift," watch alpha.
The profit router operates in accounting-only mode. It records what the 40/40/20 allocation to Layer 2 would be, but it does not yet move capital out of the trading pool. All realized gains stay in the pool and compound. A future configuration toggle will activate real capital movement into the Layer 2 yield stack once the floor's cumulative alpha is consistently positive and the reserve has meaningful size. Until then, every sat earned stays in the pool, working.
The Bookkeeper embodies a single principle that runs through the entire RCQ floor: deterministic math runs for free; reasoning is reserved for judgment. Signal translation, sizing, alpha computation, compounding, and profit allocation are all arithmetic — they live in the Bookkeeper at zero token cost. Whether to pause a leg, how to interpret a stop-loss streak, when to change an allocation — those are judgments, and they belong to risklab and floor-commander. The Bookkeeper gives those agents a clean, trustworthy, read-only picture of the floor; the agents reason over it without ever touching the math. That separation is what lets the floor scale without the cost or the risk compounding alongside it.
Living document. This dissertation is an active research artifact, not settled doctrine. Sections 1–8 develop the theoretical and early-empirical case for the dual-strategy regime loop; Section 9 (added June 20, 2026) documents the rotation execution layer — the Bookkeeper, fee filter, profit router, and compounding model — and its first live shadow-mode results. Open items are tracked explicitly in Sections 6.5, 7, and 9.7. All figures reflect shadow-mode paper trading, not live capital.
This dissertation examines the theoretical and empirical case for operating two structurally distinct trading strategies — a directional trend-following system on BTC/USD (15-minute timeframe) and a statistical mean-reversion system on the XRP/BTC spread (5-minute timeframe) — as a coordinated "dynamic regime loop" within the RCQ Trading Floor architecture. The central thesis is that these two strategies are not merely two independent sources of return sitting side by side, but are structurally complementary: the market conditions that suppress one strategy's opportunity set tend to be precisely the conditions that create the other strategy's opportunity set. This natural, emergent decorrelation — rather than a manually enforced "one at a time" allocation rule — is what produces the drawdown reduction and capital efficiency gains that make the combined system more robust than either strategy alone.
We walk through the theoretical foundations of trend vs. mean-reversion regimes, the portfolio mathematics of combining negatively or weakly correlated return streams, the specific mechanics of how RCQ's btc4h/btc15m and XRP/BTC z-score engines interact, early empirical observations from live paper trading, and the failure modes that must be monitored as the system scales toward live capital deployment.
Any single trading strategy, no matter how well designed, has an opportunity set that is conditional on market regime. A strategy that bets on reversion to a "normal" range makes money when prices stay within the range it has learned, and loses money when the underlying relationship it is tracking shifts to a new range without first reverting through the old one. The specific trigger for that failure — a sharp move, a structural catalyst, a correlation breakdown — depends on what the strategy is measuring, but the shape of the risk is the same: extended profitable periods punctuated by occasional "the world changed and I bet it wouldn't" losses.
This is not a flaw specific to any one strategy's implementation — it is a structural property of reversion-based strategies generally. Any two such strategies will share this basic risk shape. Whether they also share the specific moments at which that risk materializes — i.e., whether their losses cluster together or apart in time — depends entirely on whether they are measuring the same thing. Two strategies betting on reversion of the same underlying quantity will tend to fail together. Two strategies betting on reversion of different quantities, measured over different timeframes, may fail at different times even when driven by the same underlying market event — and it is this latter case that creates genuine diversification.
RC Quantum Automation operates two strategies. An earlier draft of this dissertation characterized these as a "trend-following" strategy (BTC/USD) paired with a "mean-reversion" strategy (XRP/BTC), and built its entire theoretical argument on that distinction. A review of both strategies' actual implementation code shows this framing was incorrect. Both strategies are, by construction, mean-reversion strategies:
XRP/BTC 5-minute z-score engine (Phase 4 signal engine) — trades the log-ratio spread between XRP and BTC. Enters when the z-score of the spread exceeds ±1.5σ over a 48-bar (4-hour) rolling window and the z-score has already begun declining back toward the mean (the zDecl confirmation). Exits as the spread reverts toward — and characteristically overshoots past — the mean.
BTC/USD algorithm (4H + 15M variants, agents btc4h/btc15m) — trades absolute BTC/USD price. The 4H variant enters BUY when price is below its 10-period moving average and the 4H z-score (over a ~40-hour lookback) is at or beyond an adaptive threshold and RSI < 30 (oversold) — the SELL case is the mirror image at the upper extremes. Stop-loss and take-profit are set at 1.5× and 3× ATR respectively, in both directions — a defined-risk bet that an oversold/overbought extreme reverts.
Both strategies, in other words, ask the same fundamental question — "has this quantity strayed unusually far from its recent normal range, and has it started coming back?" — of two different statistical objects, over different timeframes, using different confirmation oscillators (z-decline for XRP/BTC; RSI extremes for BTC/USD).
This is a meaningfully different basis for the dynamic regime loop than the original "trend vs. reversion mirror image" framing — but it does not eliminate the case for combining the two strategies. It changes why they decorrelate. Sections 2-3 below develop the corrected mechanism.
Mean-reversion strategies are built on the empirical observation that certain quantities — a single asset's price relative to its own recent average, or the ratio between two related assets — tend to oscillate around a "normal" level, with deviations beyond some threshold having a higher-than-random probability of correcting back toward that level. The trade is: identify an unusual deviation, confirm it has begun correcting (via a momentum oscillator like RSI or a smoothed-z "declining" check), enter in the direction of the correction, and exit at or beyond the normal level.
A mean-reversion system's return profile is characteristically:
Since both strategies share the same basic paradigm, the question that matters for diversification is not "do these strategies behave oppositely" (they don't — they behave similarly, as reversion bets) but "how correlated are the specific deviations each strategy is watching for?" Three structural differences between the two strategies bear on this:
Different objects. The BTC/USD algorithm measures deviation of BTC's absolute USD price from its own recent average. The XRP/BTC engine measures deviation of a cross-asset ratio (XRP priced in BTC) from its own recent average. A move that is large in absolute USD terms for BTC can be entirely "normal" for the XRP/BTC ratio if XRP moved proportionally — and conversely, a move that is small in absolute BTC/USD terms can be a large deviation for the ratio if XRP did not move proportionally. The two strategies are, in effect, looking for deviations in different coordinate systems overlaid on the same underlying market.
Different timeframes / lookback windows. The BTC/USD 4H variant computes its z-score over a ~40-hour (10×4H) lookback; the 15M variant uses standard-deviation-based SL/TP at the 15-minute bar level. The XRP/BTC engine's z-score uses a 48-bar × 5-minute = 4-hour lookback. These are meaningfully different "memories" of what constitutes normal — a move that is unremarkable against a 4-hour window may be highly unusual against a 40-hour window, or vice versa.
Different confirmation oscillators. The BTC/USD algorithm requires RSI to be in oversold/overbought territory (< 30 / > 70) as its momentum confirmation. The XRP/BTC engine requires the z-score itself to already be declining toward the mean (zDecl). These are related but not identical signals, and can — and in the live data, evidently do — diverge in timing.
The original Section 2.3 argued the two strategies were "near-perfect inversions" of each other — one profitable exactly when the other was not. That framing does not survive contact with the actual code. The corrected picture is more modest but still supports the core thesis:
Both strategies: profitable when their respective "normal range" holds
and the current deviation reverts as expected
Both strategies: unprofitable when their respective "normal range"
is itself invalidated by a genuine regime shift
before reversion occurs
The two strategies are not opposites — they are two independent reversion bets on different aspects of the same underlying market, with different objects, timeframes, and confirmation logic. Two consequences follow:
First, there is a shared failure mode: a sufficiently large, fast, genuinely trend-like BTC move can invalidate both strategies' "normal range" assumptions simultaneously — BTC's own price extends past its ATR-based stop before reverting, and the XRP/BTC ratio extends past its z-score stop before reverting, if XRP's beta to BTC is unstable during the same move. Section 5.8's PT-0036 (occurring during BTC's worst cumulative drawdown of the observation window) is a plausible instance of exactly this — not a counterexample to "the strategies decorrelate," but a direct illustration of the shared failure mode that exists precisely because both strategies are reversion bets.
Second, there is a genuine source of decorrelation, but it now operates through threshold mismatch rather than opposite regime preference: a BTC move that is large enough to trigger the XRP/BTC engine's z-score extreme (because it's measured against a 4-hour window and/or because XRP didn't move proportionally) may be entirely within BTC/USD's own 40-hour "normal range" — no signal, no position, nothing at risk on that side. Conversely, a move that pushes BTC/USD into RSI-oversold/overbought territory against its 40-hour window may be small enough, and proportional enough between XRP and BTC, that the XRP/BTC ratio's 4-hour z-score never approaches ±1.5σ. Section 5.8's 6/7 cluster (PT-0023/24/25 — BTC/USD strategy winning, in a sustained favorable run, while the XRP/BTC engine took three losses including two extreme-z entries) is consistent with this: a BTC move that BTC/USD's strategy correctly read as "extreme and reverting" coincided with a period where the XRP/BTC ratio's own 4-hour-window extremes did not revert as the z-score model expected — different objects, different timeframes, different outcomes from what may have been related underlying market activity.
The dynamic regime loop, under this corrected framing, is therefore not "trend strategy active when reversion strategy is quiet, and vice versa." It is: two reversion strategies, watching different signals at different timescales, whose losses will sometimes coincide (shared genuine regime shifts — Section 6.1's failure mode) and will sometimes not (threshold mismatches — the diversification benefit). The empirical question — addressed in Section 5 — is which of these dominates in practice, and Section 5.8's mixed result (5 winning / 3 losing / 1 ambiguous, with one clear instance of each pattern just described) is consistent with both mechanisms being present, as this corrected theory would predict.
The original Section 3.1 described btc4h's current_regime.json as classifying BTC into confirmed_bullish / confirmed_bearish / neutral "trend" states, with btc15m trading more actively during confirmed trend regimes. Given that the BTC/USD algorithm is itself a mean-reversion system (oversold/overbought + z-score extremes against a 40-hour window), what current_regime.json actually captures — or should capture — is better understood as "is BTC/USD currently near one of its own reversion extremes, and in which direction?" rather than "is BTC trending."
This is not merely a semantic correction. It changes what information is useful to pass to the XRP/BTC engine. Under the original framing, the implied logic was "when BTC is trending, expect XRP/BTC mean-reversion to behave differently." Under the corrected framing, the more precise question is: "is BTC/USD's current price action itself an extreme-and-reverting event on BTC/USD's own 40-hour timescale, and if so, is the same underlying move large enough, on a 4-hour timescale, to also register as extreme for the XRP/BTC ratio?" This is a question about the relationship between two different lookback windows applied to correlated price series, not a question about "regime type."
When BTC/USD is not near a reversion extreme (its own 40-hour z-score is unremarkable): BTC's price is, by definition, behaving normally on its own timescale. The XRP/BTC ratio's movements in this state are dominated by idiosyncratic XRP flow relative to a "calm" BTC — exactly the kind of noise the XRP/BTC engine's 4-hour-window z-score is designed to harvest. This is consistent with the first ~36 hours of live paper trading: 16 signals, the overwhelming majority reverting quickly and often overshooting to TP3 — a healthy mean-reversion environment for the XRP/BTC engine, occurring (per the BTC/USD log) during a period without RSI extremes on the BTC side.
When BTC/USD is near one of its own reversion extremes: This is where the two strategies' different timeframes start to matter. A BTC move large enough to push BTC/USD's 40-hour z-score and RSI into extreme territory is, almost by construction, also a large move on the 4-hour timescale the XRP/BTC engine watches. Two sub-cases:
If XRP moves roughly proportionally with BTC during this move (the "altcoins follow BTC on sharp moves" effect), the XRP/BTC ratio may not move much at all — BTC/USD registers an extreme, XRP/BTC stays quiet. BTC/USD's reversion bet plays out on its own; XRP/BTC has nothing to do. This is the clean decorrelation case.
If XRP does not move proportionally — its beta to BTC is unstable during this specific move, perhaps due to an XRP-specific factor coinciding with the BTC move — then the XRP/BTC ratio also registers an extreme on its 4-hour window, and the XRP/BTC engine may enter. Whether that position then reverts depends on whether XRP's deviation from BTC was itself temporary (reverts — both strategies can win) or reflects a genuine, lasting change in the XRP/BTC relationship (doesn't revert — XRP/BTC stops out while BTC/USD's own reversion bet may still play out successfully on its separate timescale, as in the 6/7 cluster), or — in the least favorable case — the same underlying shock is severe enough that neither timescale's "normal range" holds, and both strategies stop out together (the PT-0036 pattern).
The original Section 3.3's central claim survives the reframing largely intact, for a similar reason as before but on corrected grounds: the XRP/BTC engine's filter stack (BTC trend filter, volume filter, zDecl confirmation) was never actually implementing "is BTC trending" — the BTC-trend filter, per the code, measures XRP/BTC's own price movement over 48 bars as a proxy, not BTC/USD's RSI/z-score state. What it does do is block entries when the XRP/BTC ratio itself has moved more than 3% over its lookback — i.e., it's a same-object, same-timeframe "is this move too large to trust" check, independent of whatever BTC/USD's own strategy is doing.
This means the two strategies' filters are independently self-regulating on their own objects and timeframes without needing to reference each other at all — which is a more robust form of "emergent" decorrelation than the original framing implied (which leaned on btc4h's regime classification as the implicit link). The link between the two strategies is not "one reads the other's state" — it's that both are independently reacting to the same underlying price series, filtered through different lenses, and the resulting correlation structure of their outcomes is whatever it empirically turns out to be (Section 5).
This does suggest one concrete refinement worth considering for Phase 5: since current_regime.json (if/when the propagation bug is fixed) would carry BTC/USD's own RSI/z-score extreme state, it could be used by the XRP/BTC engine not as a gate, but as a flag on entries that coincide with a BTC/USD extreme — useful for exactly the kind of post-hoc analysis in Section 5.8, and potentially for widening the XRP/BTC stop on such flagged entries (per the original Section 3.3's suggestion, which remains reasonable under the corrected framing — entries coinciding with a BTC/USD extreme are more likely to be the "same underlying shock" case from 3.2, where the relationship may be less stable).
The conclusion of the original Section 3.4 — that simultaneous positions in both strategies are diversification, not double-exposure, and that "one at a time" was overly conservative — still holds, but the reasoning changes slightly.
Under the original framing, overlap was framed as "two different bets on two different aspects of the same market event" (a directional bet plus a relative-value bet). Under the corrected framing, overlap is better described as "two reversion bets on different objects/timeframes, whose joint outcome depends on how the current move decomposes across those objects and timeframes" — per the three sub-cases in 3.2. In the clean-decorrelation case and the "XRP deviates but reverts" case, overlap is genuinely diversifying. In the shared-shock case, overlap means both positions are exposed to the same root cause — which is exactly why joint risk monitoring (risklab) matters, as the original section also concluded, but now for a more precise reason: not "two different kinds of bet" but "two reversion bets that share a tail-risk scenario (a shock large enough to break both timescales' normal-range assumptions simultaneously)."
The practical implication is the same as before — size for joint exposure, don't prevent overlap — but the risk being managed is now correctly characterized as correlated tail risk between two reversion strategies, not as residual risk between a trend strategy and a reversion strategy.
A note on what carries over from Sections 1-3's reframing: the portfolio mathematics below is mechanism-agnostic — it describes the relationship between correlation and portfolio variance regardless of why two return streams are correlated or not. What changed in Sections 1-3 is the explanation for why $\rho_{1,2}$ might be low or favorably structured (threshold mismatches between two reversion strategies on different objects/timeframes, per Section 2.3 — rather than "trend vs. reversion mirror image"). The math in 4.1-4.4 applies unchanged; only the causal story behind the correlation term changes.
For a portfolio combining two return streams with weights $w_1$ and $w_2$ (where $w_1 + w_2 = 1$ if fully allocated, though in RCQ's case both strategies can be "fully sized" simultaneously since they trade different instruments — but the framework still illustrates the mechanism), the portfolio variance is:
σ²_portfolio = w₁²σ₁² + w₂²σ₂² + 2w₁w₂ρ₁,₂σ₁σ₂
Where $\sigma_1, \sigma_2$ are the individual strategy volatilities and $\rho_{1,2}$ is the correlation between their return streams.
The critical term is $\rho_{1,2}$. If $\rho_{1,2} = 1$ (perfectly correlated), the portfolio volatility is simply the weighted average of the individual volatilities — no diversification benefit. If $\rho_{1,2} = 0$ (uncorrelated), the portfolio volatility is strictly less than the weighted average — this is the diversification benefit. If $\rho_{1,2} < 0$ (negatively correlated), the benefit is even larger, and in the extreme case can produce a portfolio volatility lower than either individual strategy's volatility alone.
The argument developed in Section 3 amounts to a claim that $\rho_{1,2}$ is not constant — it is regime-conditional, and importantly, it tends toward negative or near-zero values specifically during the periods when each strategy is taking its losses.
This is a more powerful property than simple unconditional low correlation. Consider two strategies with an unconditional correlation of, say, 0.1 (essentially uncorrelated on average) — but where, conditional on Strategy A experiencing a drawdown, Strategy B's expected return is positive. This is sometimes called "crisis alpha" in the trend-following literature (trend-followers are famous for this property relative to equity portfolios — they tend to perform well during equity bear markets, which is exactly when diversification is most valuable).
In RCQ's case, the analogous claim is: conditional on the XRP/BTC engine experiencing a stop-loss (i.e., the BTC-XRP relationship has decoupled due to a strong directional BTC move), the BTC/USD trend strategy is more likely than average to be experiencing one of its best trades (since a decoupling event of this kind is, almost by construction, associated with a strong directional BTC move — the exact condition btc15m is designed to capture).
If this conditional relationship holds even approximately, the result is that the XRP/BTC engine's worst days are partially or fully offset by the BTC/USD engine's best days — which is precisely the mechanism by which combined portfolio drawdown can be meaningfully lower than either strategy's standalone drawdown.
To make this concrete, consider a simplified illustrative (not empirically fitted) scenario:
Strategy A (XRP/BTC mean reversion), standalone: - 100 trades, 71.5% win rate per MC calibration - Average win: +1.13% net (TP-weighted average) - Average loss: -2.62% net (SL, including costs) - Expected value per trade: (0.715 × 1.13%) + (0.285 × -2.62%) = 0.808% - 0.747% = +0.062% per trade - Standalone max drawdown (MC simulated): ~0.16%
Strategy B (BTC/USD 15m trend), standalone — illustrative parameters: - Lower win rate (~40%, typical for trend systems), larger average win, smaller average loss - Expected value per trade: positive, but with higher per-trade variance - Standalone max drawdown: historically larger than mean-reversion systems due to the "many small losses" character
Combined, with the regime-conditional relationship described above:
If Strategy A's losing trades (the 28.5% that hit SL) are disproportionately likely to occur during periods classified as confirmed_bullish/confirmed_bearish by btc4h — i.e., periods where Strategy B is more likely to be in a winning trade — then the joint drawdown distribution is narrower than either marginal distribution would suggest. The portfolio's worst days are no longer "Strategy A has a bad day" OR "Strategy B has a bad day" independently — they become conditional on both strategies having a bad day simultaneously, which (if the conditional correlation argument holds) is a lower-probability event than either individual bad day.
This is the formal mechanism by which "dead time in one strategy is live time in the other" translates into a reduction in the probability mass of the joint drawdown tail — which is exactly what shows up in backtests/simulations as "lower max drawdown for the combined system than for either component."
A second, related benefit — distinct from drawdown reduction but often conflated with it — is capital utilization. If Strategy A and Strategy B were run on separate, segregated capital pools (e.g., $50k allocated to each), then during periods where Strategy A is inactive (no signals passing filters), that $50k sits idle, earning nothing, while Strategy B may be highly active and capacity-constrained by its own $50k allocation.
If instead both strategies draw from a shared capital pool (governed jointly by risklab with combined exposure limits), then during Strategy A's quiet periods, Strategy B can be sized larger (up to the joint risk limit), and vice versa. This does not reduce drawdown directly — in fact, it could increase drawdown if not managed carefully, since a single strategy could theoretically use 100% of the joint limit. But it increases the expected return per dollar of capital deployed, which improves the risk-adjusted return profile (Sharpe, Calmar) even if absolute drawdown is unchanged or modestly increased. The combination of (a) conditionally negative correlation reducing drawdown and (b) shared capital pools increasing utilization is what produces the larger Sharpe/Calmar improvements suggested in earlier capital efficiency estimates.
The first empirical snapshot, taken after approximately 36 hours of live paper trading, consisted of 16 trades, a 100% win rate, and 0% drawdown — explicitly framed at the time as a statistical tail outcome (roughly a 1% probability event at the MC-calibrated 71.5% win rate) rather than a representative result. That snapshot was documented as a baseline, with the explicit caveat that no losing trades, no time stops, and no BTC regime transitions had yet occurred.
As of June 12, 2026, the live scorecard now reflects 48 closed trades — roughly a 3x increase in sample size, and critically, the first sample to include mixed outcomes:
Total Trades: 48
Wins: 38 (79.17%)
Losses: 9 SL (18.75%)
Time Stops: 1 (2.08%)
Max Drawdown: 0.052%
Max Consec Loss: 3
Avg Bars Held: 18
The most important single data point here is the SL frequency. The Monte Carlo calibration assumed a 19.5% stop-loss probability (195/1000). The live result of 18.75% (9/48) is remarkably close — well within normal sampling variance for n=48. This is a meaningful validation of the underlying statistical model of the z-score distribution: the spread is extending past the -2.5/+2.5 threshold at almost exactly the rate the simulation assumed it would, even though the simulation was built before any live data existed.
Win rate (79.17%) now exceeds the MC baseline (71.5%) by a healthy margin, and all seven circuit breaker checks pass for the first time, including Sortino — which previously displayed as a divide-by-zero artifact (0.00, FAIL) when no losing trades existed to compute a downside deviation. With 9 losing trades now in the sample, Sortino computes to a real value of 31.28, comfortably above the ≥6 threshold.
It is important to be precise about what this new data validates and what it does not.
What it validates: The XRP/BTC mean-reversion engine, considered on a standalone basis, is behaving statistically consistent with its MC calibration. Win rate, SL frequency, and drawdown are all tracking close to or better than expectation. This is a necessary precondition for the regime loop thesis — if Strategy A's standalone behavior didn't match its model, there would be no stable baseline against which to measure the effect of combining it with Strategy B. That precondition is now reasonably well satisfied.
What it does not yet validate: The scorecard above is a XRP/BTC-only view — it tells us that 9 stop-losses occurred, but on its own says nothing about when relative to the BTC/USD strategy's state. (This gap was closed in Sections 5.6 and 5.8 below — see those for the actual cross-referenced results.)
This cross-reference has now been performed — see Sections 5.6 and 5.8. At the time this paragraph was first written, the immediate next step was: pull the timestamps of the 9 SL trades and the 1 Time stop from PaperTrades, and cross-reference each against the BTC/USD strategy's state at that timestamp, to get the first real (if small, n=9) test of whether losses on one strategy coincide with wins or losses on the other. That step was completed manually in 5.6 and via the automated tracker in 5.8; both are retained below as the historical record of that first test, including the methodology note (5.6) that the cross-strategy simultaneous new-position overlap scenario was not fully exercised by this initial sample — which remains an open item for future iterations (Section 7).
One pattern in the 48-trade data warrants investigation before it affects either the regime-loop analysis or any recalibration: of the 38 winning trades, all 38 closed via TP3, with zero TP1 or TP2 exits — versus an MC expectation of roughly 36.6% TP1 and 23.5% TP2. At n=16 this was plausibly a lucky-window artifact; at n=38-for-38 it more likely indicates an exit-condition logic issue in _checkOpenTradeExits() (e.g., a comparison-direction bug that prevents TP1/TP2 from ever evaluating true for one or both trade directions). This does not undermine the SL-frequency validation in 5.2 — SL and Time-stop logic appear to be evaluating correctly — but it does mean the path each winning trade takes to its exit may not be representative of the MC's assumed exit distribution, which matters for any future recalibration and for precisely characterizing "how a winning trade resolves" in the regime-conditional analysis above. This should be resolved before recalibrating recalibrateFromPaperTrades() against this dataset.
Following the 48-trade scorecard update (Section 5.2), the timestamps of all 9 SL events and the 1 Time-stop event were extracted from the PaperTrades sheet and cross-referenced against the BTC/USD 15m strategy log for the corresponding moments. This is the first time the dissertation's core hypothesis — that XRP/BTC losses cluster favorably relative to BTC/USD trend strategy performance — has been tested against paired, timestamped data rather than considered theoretically.
Methodology: For each SL timestamp, the nearest BTC 15m log rows were examined for (a) the active signal state (BUY/SELL/HOLD), (b) the short-term trend of the oscillator value, and (c) the trajectory of the strategy's cumulative PnL column — used as a proxy for whether the BTC strategy's existing position was, at that moment, winning or losing.
Results (n=9 SL events):
4 of 9 — BTC strategy winning at the moment of XRP/BTC SL
4 of 9 — BTC strategy in active drawdown at the moment of XRP/BTC SL
1 of 9 — ambiguous / transitional
The "4 winning" events are not 4 independent occurrences — 3 of them (PT-0023, PT-0024, PT-0025) fired within a single ~75-minute window on 6/7, during which BTC's cumulative PnL climbed steadily and the oscillator held a consistent elevated reading. This single cluster — two of its three entries at extreme z-scores above 3.4 — is the most supportive individual data point for the hypothesis obtained so far: a sustained BTC winning run coinciding with a cluster of XRP/BTC stop-losses.
Against this, PT-0036 (6/8) is a direct counterexample: it occurred at the moment of BTC's worst cumulative drawdown in the entire 9-day observation window — both strategies losing simultaneously, the failure mode described in Section 6.1.
Interpretation: At n=9, with one of the four "supportive" events actually being three correlated sub-events from a single cluster, this result is mixed-to-inconclusive. It does not validate the hypothesis as originally framed (simple positive/negative correlation between XRP/BTC losses and concurrent BTC strategy P&L), nor does it refute it. A plausible refinement suggested by this small sample is that the relevant variable may not be "is the BTC strategy currently winning or losing" but rather the character of the BTC move — a sustained, low-noise directional run (as in the 6/7 cluster) may behave differently than a choppy, reversal-heavy drawdown (as in the 6/8 event) — but this refinement itself rests on n=1 examples of each pattern and should be treated as a hypothesis to track, not a finding.
A further limitation: in nearly all 9 cases, the BTC 15m strategy's own signal state at the moment of the XRP/BTC SL was HOLD rather than an active BUY/SELL entry. The cross-strategy simultaneous new-position overlap scenario described in Sections 3.4 and 6.1 — two strategies entering trades at the same time — was therefore not really exercised by this sample. What was measured is closer to "was the BTC strategy's existing open position profitable," a softer and less direct test than originally envisioned.
Status: This addendum should be treated as the first data point in an ongoing series, not a conclusion. The methodology (timestamp extraction → cross-reference against BTC log → classify as winning/losing/ambiguous) is now established and can be re-run as the XRP/BTC loss sample grows. A larger sample — particularly more instances of both "sustained directional BTC run" and "choppy BTC drawdown" co-occurring with XRP/BTC losses — is needed before the refined hypothesis above can be meaningfully evaluated.
The empirical case has moved from "a hypothesis awaiting a sufficient sample" (Phase One) to "a standalone-validated strategy with its first genuinely mixed dataset, plus a first completed round of cross-strategy analysis" (Phase Two). The first cross-referenced test of the core hypothesis is documented in Sections 5.6 and 5.8 — result: mixed-to-inconclusive at n=9, with one clear supportive cluster (6/7) and one clear shared-failure counterexample (PT-0036), broadly consistent with the corrected theory in Sections 2-3 (which predicts a mix of decorrelated and correlated loss events, not a clean one-sided result). The dataset is small; the methodology is now established and ready to re-run as more SL/Time events accumulate.
The regime-correlation-tracker (Section 5.6's methodology, now implemented as code) was re-run against the complete 9-day BTC/USD 15m log and all 9 SL timestamps — superseding the partial test run used to validate the tool itself.
Results (n=9):
BTC strategy WINNING at exit: 5 (56%)
BTC strategy LOSING at exit: 3 (33%)
Ambiguous: 1 (11%)
Compared to the manual read in Section 5.6 (4 winning / 4 losing / 1 ambiguous), two events were reclassified:
Interpretation: The overall picture is essentially unchanged from Section 5.6. The shift from 4/4/1 to 5/3/1 reflects the tool replacing two borderline, eyeballed judgment calls with a consistent, defined-threshold rule — this is the expected and desired effect of moving from manual to automated classification, not a new finding about the underlying market behavior. The two load-bearing observations from 5.6 both survive unchanged:
At n=9 (effectively n=7 independent observations once the 6/7 cluster is counted once), this remains mixed-to-inconclusive by the same standard set in 5.6. The "character of the move" dimension (SUSTAINED/CHOPPY/FLAT) returned FLAT for all 9 events with the current ±30-minute window — this is likely a window-size artifact (at 15-minute bar resolution, ±30 minutes captures only ~4 bars, often containing 0-1 non-HOLD signals) rather than a finding that BTC's moves lack character. Widening the window (60-90 minutes) is a tuning step for the next run, not a conclusion to draw now.
Status: The tool is now validated against the real dataset and ready for ongoing use. The next addendum should come from a larger n — ideally the next batch of SL/Time events from the 48-trade-and-growing scorecard, run through the tracker with the wider window setting.
A rigorous treatment of this strategy combination requires being explicit about the ways the theoretical benefit could fail to materialize, or could even reverse.
Under the corrected framing (Section 2.3), this is no longer an edge case the diversification argument has to defend against — it is the expected shared failure mode of two reversion strategies. A sharp, fast, large BTC move can invalidate both strategies' "normal range" assumptions in the same window: BTC/USD's own price extends past its ATR-based stop without the oversold/overbought extreme reverting, and — if XRP's beta to BTC is unstable during that same move — the XRP/BTC ratio extends past its z-score stop without reverting either. Section 5.8's PT-0036 (occurring during BTC/USD's worst cumulative drawdown of the 9-day window) is a plausible live instance of exactly this.
Mitigation: unchanged from the original — risklab's joint exposure monitoring matters precisely because this shared failure mode exists. The corrected framing makes the mitigation's rationale more precise: it isn't insurance against a rare edge case, it's sizing for the known shared tail risk of running two reversion strategies on correlated underlying price series.
As noted in earlier planning, there is an inherent lag between when BTC/USD's own reversion-extreme state changes and when any classification derived from it (current_regime.json, if/when propagated per Section 3.3) catches up. During this lag window, a flag-based refinement to the XRP/BTC engine (per Section 3.3's suggestion) would be operating on stale information. This is the rationale for a transition buffer — though as discussed in Section 3.3, the XRP/BTC engine's own same-object, same-timeframe filters provide a first line of defense independent of any cross-strategy signal.
The relationship between BTC/USD's reversion-extreme state and the XRP/BTC ratio's behavior is not static — it depends on XRP's beta to BTC, which itself shifts based on macro factors (e.g., "alt season" periods where altcoins broadly decouple from BTC, vs. periods dominated by BTC beta). A regime loop calibrated during one such period may behave differently during another — for instance, a period of XRP-specific regulatory or ETF news could drive the XRP/BTC ratio independently of whatever BTC/USD's own 40-hour z-score and RSI are doing. This argues for periodic recalibration and for monitoring the realized correlation between the two strategies' outcomes as a tracked metric, not a fixed assumption.
Under the corrected framing, there remains a state where neither strategy's reversion-extreme conditions are met — BTC/USD's price is within its normal 40-hour range (no RSI/z-score extreme) and the XRP/BTC ratio is within its normal 4-hour range (|z| < 1.5σ, or volume insufficient). In this state both strategies are simultaneously idle — not a drawdown risk, but an opportunity cost / capital utilization issue. This is the scenario the Layer 2/3 yield stack partially addresses — idle trading capital is not idle capital, because surplus continues compounding in the XRPL yield layer.
The BTC/USD strategy was informally described during planning as "z-score retest plus a MACD flip." The two code files reviewed for this revision (the 4H CoinMarketCap-based script and the 15M trade-logging/closure script) show the entry/confirmation logic as z-score (vs. a 10-period and a ~40-hour/4H moving average) combined with RSI extremes (<30 / >70) — no MACD appears in either file. This revision is based on the RSI-based logic as written. If a separate, currently-operative version of the BTC/USD signal-generation logic uses MACD instead of (or in addition to) RSI, the specific oscillator-confirmation details in Sections 1.2, 2.2, and 3.1-3.2 should be revisited against that version — though the higher-level conclusion (both strategies are reversion-type, on different objects/timeframes) is likely to hold regardless of which oscillator is used, since MACD-flip-on-a-pullback is also commonly used as a reversion-confirmation signal (as distinct from MACD-flip-as-trend-initiation, which would be a genuinely different case). This should be confirmed before the next major revision.
As the live track record accumulates, the following questions should be tracked explicitly, ideally with dedicated logging/dashboards:
Conditional correlation estimation: Once both strategies have a meaningful number of closed trades, compute the realized correlation between strategy returns conditional on BTC/USD's own reversion-extreme state (RSI/z-score). Does it differ meaningfully from the unconditional correlation, and is it consistent with the threshold-mismatch mechanism in Section 2.3?
Drawdown timing overlap: For each XRP/BTC stop-loss, what was the concurrent state of the BTC/USD strategy — was BTC/USD also near/at one of its own reversion extremes at that moment (suggesting the shared-shock failure mode, Section 6.1), or was BTC/USD's price action unremarkable on its own 40-hour timescale (suggesting an XRP-idiosyncratic event, Section 3.2's "XRP deviates but BTC/USD doesn't" case)? Section 5.8's tracker could be extended to pull BTC/USD's RSI/z-score state (not just its cumulative PnL trend) at each XRP/BTC SL timestamp.
Filter effectiveness as same-object regulation: How often does the XRP/BTC engine's own filter stack (BTC-trend-via-XRPBTC-movement, volume, z-declining) correctly block entries during the large moves that also trigger BTC/USD's RSI/z-score extremes? This tests the "independently self-regulating" claim in Section 3.3.
Combined vs. separate Sharpe/Calmar: Once sufficient data exists for both strategies independently, compute the combined portfolio Sharpe and Calmar ratios under (a) the actual joint capital allocation, (b) a hypothetical fully-segregated allocation, and (c) a hypothetical "one at a time" allocation — to quantify the actual magnitude of the benefits described in Sections 4.3 and 4.4, rather than relying on the theoretical framework alone.
Regime transition buffer cost/benefit: If a transition buffer (pausing new XRP/BTC entries when BTC/USD is flagged as near a reversion extreme) is implemented, measure its effect on both (a) avoided stop-losses during such windows and (b) missed profitable trades that would have occurred during those windows. The net effect is not obvious a priori and should be measured.
BTC/USD strategy logic confirmation: Resolve the open item in Section 6.5 — confirm whether RSI or MACD (or both) is the operative confirmation oscillator for the live BTC/USD strategy, and update Sections 1.2/2.2/3.1-3.2 accordingly if the answer changes the timeframe or confirmation-logic details materially.
The dynamic regime loop between the BTC/USD strategy and the XRP/BTC z-score engine is grounded in portfolio theory, but — per the corrected framing in Sections 1-3 — not via the "opposite market regimes" mechanism originally proposed. Both strategies are mean-reversion strategies. The diversification case instead rests on threshold mismatch: the two strategies measure deviation-from-normal on different statistical objects (absolute BTC/USD price vs. the XRP/BTC ratio), over different lookback windows (~40 hours vs. 4 hours), using different confirmation oscillators (RSI extremes vs. z-declining). A market move that registers as extreme on one strategy's object/timeframe may or may not register as extreme on the other's — and when it does register on both, whether both then revert, both fail together, or one reverts while the other doesn't depends on how the underlying move decomposes across objects and timeframes (Section 3.2's three sub-cases).
The architecture RCQ has built remains well-positioned to capture this benefit, and the regulation continues to happen organically — each strategy's filters operate on its own object/timeframe without needing to reference the other (Section 3.3), which is a more robust form of self-regulation than the original framing's reliance on cross-strategy regime classification. The role of current_regime.json, under the corrected framing, shifts from "tell the other strategy what regime we're in" to "flag when the same underlying move is registering as extreme on both timescales simultaneously" — useful context for risklab's joint exposure monitoring (Section 6.1) and for the kind of post-hoc analysis performed in Section 5.8.
Section 5.8's empirical result — 5 of 9 XRP/BTC stop-losses occurring while BTC/USD's strategy was in a favorable run, 3 occurring while BTC/USD was also struggling, 1 ambiguous — is consistent with both mechanisms described above being present in the live data: genuine threshold-mismatch decorrelation in the majority of cases, and the shared-shock failure mode in a minority. This is a more modest claim than the original "near-perfect inversion" framing, but it is the claim the actual strategy code and the live data support. The honest framing for the team going forward: the corrected theory predicts a mix of decorrelated and correlated loss events, roughly what Section 5.8 shows; the open questions in Section 7 — particularly confirming the BTC/USD oscillator (6.5) and extending the tracker to BTC/USD's own reversion-extreme state (Q2) — are what will sharpen this from "consistent with" to either a validated or revised model.
Sections 1–8 establish why RCQ runs two reversion strategies on different objects and timeframes. This section documents how their signals are translated into capital movements, measured, and accounted for — the execution and bookkeeping layer built between June 16 and June 20, 2026. This layer is the bridge between "the engine fired a signal" and "here is precisely what that did to our Bitcoin-denominated capital."
The execution layer is implemented as a Google Apps Script — the Rotation Bookkeeper — not as an LLM agent. This is a deliberate architectural choice. The work involved — translating a signal into a sized rotation, tracking sub-balances, computing results, allocating profit — is pure arithmetic with no judgment to exercise. Spending model tokens on it would be waste. The expensive reasoning capacity is therefore reserved for the two governance agents (floor-commander for orchestration and gate approval; risklab for monitoring and interpretation), while the deterministic bookkeeping runs at zero token cost. This separation — deterministic math runs free, reasoning is reserved for judgment — is the organizing principle of the entire floor.
Neither strategy executes as a true long/short position. Both execute as spot rotations on Binance — "sell asset A for asset B" — which avoids margin, funding costs, and liquidation risk entirely:
Each leg therefore maintains two sub-balances, and the strategy expresses itself by shifting weight between them rather than by taking leveraged directional exposure.
When a signal fires, the Bookkeeper rotates a fixed fraction — ROTATION_PCT = 10% — of the relevant source sub-balance into the destination asset. This single rotation, from open to close, is a chunk. Each chunk receives a unique ID (e.g., RC-XB-0084, RC-BU-0091), a full row in the RotationChunks ledger, and a complete lifecycle: it opens when the signal fires and capital rotates out, and closes when the position exits (take-profit, stop-loss, or time-stop) and capital rotates back. One signal-engine trade becomes one rotation chunk. The chunk is the atomic accounting unit of the floor.
The fixed-percentage model produces a natural compounding taper: repeated same-direction signals each rotate 10% of a progressively smaller (or larger) remaining balance, so position sizing self-adjusts to the leg's running state without any explicit sizing rule.
The Bookkeeper's central metric is alpha, defined against a specific benchmark: what the capital would be worth if it had never rotated and simply held the original asset. For each chunk:
Alpha = close value (BTC-denominated) − benchmark hold value (BTC-denominated)
This is deliberately distinct from raw profit. A chunk can post positive raw profit yet negative alpha (it made money, but holding would have made more) or negative raw profit yet positive alpha (it lost, but holding would have lost more). The system records and compounds alpha, not raw profit, because the entire thesis of the rotation strategy is that it can beat holding Bitcoin. Measuring against the hold benchmark strips out the market's own direction and isolates whether the rotation decisions added value — a chunk can show positive alpha on a day BTC falls, because alpha measures the rotation's edge, not the market's move. Alpha is the honest scorecard for the strategy specifically.
Not every signal is worth executing. During tight-spread, low-volatility periods, a z-score can cross the entry threshold while the actual price deviation is so small that round-trip transaction fees would exceed the captured move — the "nothing happened" trade that posts negative alpha purely from fee drag.
The Bookkeeper guards against this with a fee-adjusted filter applied before each chunk opens. It estimates expected price movement and compares it to round-trip fee cost:
Proceed only if |z-score| × price-stdDev ≥ MIN_FEE_MULTIPLE × (2 × taker-fee × price), with
MIN_FEE_MULTIPLE = 2.0.
For the XRP/BTC leg, the standard deviation is computed live from the most recent 48 price observations in the engine's Signals tab (matching the engine's own 4-hour reversion window). For the BTC/USD leg, the take-profit distance (set at 3×ATR by the engine) serves as the expected-movement estimate. Signals that fail the test are logged as SKIP_LOW_CONVICTION and no rotation occurs. The filter adapts to conditions automatically: during volatile periods it lets lower z-scores through (the dollar move is large enough to clear fees); during quiet periods it requires higher conviction. It directly targets the "nothing happened" loss category identified in early shadow-mode data.
Compounding is built into chunk close. When a chunk closes, the destination asset is rotated back and the returned capital — including any alpha, positive or negative — flows into the source sub-balance. A winning chunk returns more than it took (the balance grows, the next chunk is larger); a losing chunk returns less (the balance shrinks, the next chunk is smaller). This is genuine compounding: returns reinvest automatically, and risk de-levers automatically after losses, with no explicit rule.
The profit router sits on top of this. Each cycle it scans for newly-closed chunks with positive alpha and records a 40/40/20 allocation — 40% to a notional BTC stack, 40% to an XRP stack, 20% to an RLUSD reserve — in the ProfitAllocation ledger. Critically, the router currently operates in accounting-only mode: it records what the Layer 2 allocation would be but does not move capital out of the trading pool. All realized gains remain in the pool and compound. A future configuration toggle will activate real capital movement into the Layer 2/3 yield stack once cumulative alpha is consistently positive and the reserve reaches meaningful size. The router only ever routes positive-alpha chunks — ensuring Layer 2 accumulates only from rotations that genuinely beat holding, never from chunks that merely rode a rising market.
This design also resolves a governance question raised during construction: the profit-routing function was deliberately not given to risklab. Risk monitoring (which must be willing to recommend pausing a leg) and capital allocation (which deploys gains) are structurally opposed incentives; keeping allocation as deterministic arithmetic in the Bookkeeper, with risklab only monitoring the outcome, preserves the separation of concerns.
The Bookkeeper ran its first full shadow-mode backfill and live cycle over the June 16–20 window, processing both legs' signals into tracked chunks. Headline observations:
XRP/BTC leg — the healthier of the two. Win rate ~56%, exits dominated by take-profit (62 TP / 20 SL / 2 Time out of 84 closed chunks), cumulative alpha essentially flat (slightly negative, within noise of break-even). The leg's average loss modestly exceeds its average win, but the win rate compensates. This is a functioning reversion engine operating near break-even against the hold benchmark.
BTC/USD leg — carries nearly all of the floor's current negative alpha. Win rate ~39%, and the diagnostic signature is in the exit mix: 35 of 99 closed chunks (35%) exited via time-stop, the large majority at negative alpha. Critically, the leg's average win exceeds its average loss — when trades resolve, they win bigger than they lose. The problem was never signal quality; it was that a third of trades never had time to resolve under the original 1.5-hour time-stop.
The single highest-leverage intervention identified from this data was extending TIME_STOP_HOURS from 1.5 to 3.5 hours (applied June 19–20 in both the signal logic and the execution engine). The thesis — testable in forthcoming data — is that lengthening the window converts a meaningful fraction of those 35 time-stops into take-profits, which would flip the BTC/USD leg's win rate upward and, since wins already exceed losses in magnitude, push its cumulative alpha positive. Because BTC/USD holds nearly all the floor's drawdown, this single change is expected to be the dominant driver of whether the combined floor crosses from break-even into positive accumulation.
A second observation connects directly to Section 6.1's shared-failure-mode prediction: the BTC/USD leg showed a cluster of five consecutive same-direction stop-losses on June 17 — repeated SELL signals during a period when BTC was climbing, i.e., the engine fighting a move that did not revert on its timescale. This is precisely the regime-mismatch signature the dissertation's theory anticipates, and it is now detected automatically: the Bookkeeper flags any run of 3+ consecutive stop-losses as a STREAK_WARNING, surfacing exactly this condition for risklab without halting the floor.
Open items specific to the execution layer:
Sub-balance reconstruction. The historical backfill opened 174 chunks before the close-side compounding-reversal logic existed, so current sub-balances do not cleanly reflect "started with X, now hold Y." They self-correct as new chunks cycle through with the reversal active, but the present sub-balance figures are not yet a trustworthy accumulation measure — cumulative alpha, not sub-balance, is the reliable accumulation scorecard during this transition.
Time-stop fix validation. The 1.5 → 3.5 hour change is live but its effect is not yet visible in closed-chunk data. The next review should measure what fraction of the prior time-stop population converts to take-profit under the wider window, directly testing the Section 9.7 thesis.
Fee-filter effectiveness audit. The filter began skipping low-conviction signals only after June 19. Its skipped signals should be retrospectively checked: did the corresponding source trades end up profitable or not? This validates whether the filter correctly blocks "nothing happened" rotations or occasionally filters genuine winners.
Agent integration deferred. The Bookkeeper exposes a read-only JSON endpoint (consumed today by the live dashboard at rotation.rcqsignals.com). Feeding this to floor-commander and risklab for autonomous monitoring is designed but intentionally deferred until the director has fully internalized the dataset — a deliberate human-in-the-loop posture during the break-even shakeout, not a technical limitation.
The execution layer does not alter the dissertation's central claim; it instruments it. Cumulative alpha per leg is now the live, continuously-measured realization of the "does each reversion strategy add value over holding?" question. The exit-type breakdown (TP/SL/Time) and streak detection give risklab the concrete signals needed to monitor the shared-failure-mode (Section 6.1) and regime-transition (Section 6.2) risks in real time rather than only in post-hoc analysis. And the profit router's positive-alpha-only allocation rule operationalizes the distinction, central to this whole document, between beating the market and riding it. In short: Sections 1–8 argued the strategy should work and defined how to tell; Section 9 is the machinery that now tells, chunk by chunk.
This document is an internal research artifact for the RCQ Trading Floor team. It is intended to articulate the theoretical foundation for the dynamic regime loop architecture, to document the execution and bookkeeping layer that instruments it, and to define the empirical questions that future live trading data should answer. It should not be construed as a performance guarantee or validated backtest result. All performance figures reflect shadow-mode paper trading.