Episode 8: c36 And c4, Promising Is Not Deployable

Read this article with Options Backtesting API, Backtesting Framework, Backtesting Data Quality Checklist, Backtesting Execution Realism, Quote-Aware Options Backtests, and Backtest to Paper Trading Parity Checklist.

Scope

This episode focuses on the two most interesting near-misses in the repo:

• c36 VWAP mean reversion
• c4 dispersion-relative breakout

The main evidence lives in RUNS.md, decision_gate.json, launch_contract.json, and launch_contract.json.

Result Snapshot

c36

• c36_vwap_mr_option_native_quality_v1: +16004 PnL, 15 trades, DSR 0.6400
• failed only trades_per_week_ok
• final label on April 8: open_paper_only

c4

• repaired stock stage restored realistic behavior after a false collapse
• best repaired rows reached 79 and 85 trades in later follow-ups
• final label on April 18: park_c4

These are not dead branches in the same way as Episode 7. They are stronger than that. But they still did not earn admission.

Strategy Context

c36 is an option-native descendant of the c18 VWAP mean-reversion family. The underlying logic is a short-horizon intraday mean-reversion trade defined by VWAP residual z-scores, bounded VWAP slope, explicit sigma constraints, and short holding periods. The quality version requires relative volume, raises the z-score entry threshold, narrows acceptable sigma and slope conditions, and cuts the time-in-trade budget. The opportunity version does the opposite: it lowers the excursion threshold, relaxes some constraints, and allows more trades to form. c36 then monetizes those stock-level setups through quote-aware single-leg option execution in the 0-2 DTE window. So the branch is scientifically clean: same core signal family, same option-expression type, but different tradeoffs between selectivity and sample size.

c4 is a different animal. It is a dispersion-relative breakout family. The stock-level logic requires the primary ticker to break its opening structure while outperforming a beta-adjusted proxy by a minimum relative-strength edge. The guard_v3 version tightens that edge, caps the proxy's own movement more aggressively, adds a beta-shock veto, and forces the trade to prove itself quickly. The later density-repair versions then relax those same constraints incrementally to recover trade count. In the SPY repair path, the repo even introduced an SPY-to-DIA proxy override so that the index sleeve would be benchmarked against a broader market proxy without disturbing the rest of the default proxy map. The option follow-up overlays then tried to express the same stock winner through 2-5 DTE single-leg or vertical-debit structures with strict quote-aware filters.

The c36 Lesson

c36 is a good example of why raw profitability is not enough.

The branch produced a quality variant that made money and looked reasonable on robustness, but it was too sparse. Then it produced an opportunity variant with much better activity but meaningfully worse quality.

Seen mechanistically, this is exactly what one would expect from the parameter changes. Lowering the z-score hurdle and widening the admissible microstructure envelope increases the number of mean-reversion attempts, but it also admits weaker excursions and noisier reversals. The repo did more than observe that density and quality traded off. It engineered that tradeoff explicitly and then measured the degradation.

That is a classic frontier in systematic trading:

• more opportunity
• less edge quality

The repo handled it well by refusing to pretend those are the same outcome. c36 therefore became:

• not dead
• not promoted
• kept as open_paper_only

That is a rational status.

The c4 Lesson

c4 is more complicated because part of its story is debugging.

On April 17, the repo showed that a prior collapse was not a true strategy failure. It was a launch-path bug:

• the run had used an empty writable DuckDB instead of the intended seeded snapshot
• the corrected rerun restored normal trade counts and strategy shape

That is a valuable result because it prevented the wrong conclusion. But after the bug fix, the branch still failed the promotion gate.

This is what makes c4 such a good public case study. The branch combined three different research realities in one arc: a real implementation bug, a real post-bug improvement in strategy shape, and a real subsequent failure to clear a strict portfolio gate. Those are analytically different events, and the repo treated them as such.

The c4 gate required more than just "interesting":

• selection_status=feasible
• positive return
• trades_per_week >= 1.5
• orb_overlap_days >= 30
• c66_overlap_days >= 30
• offset_ratio_on_orb_down_days >= 0.5
• zero extra option attempts
• zero quote rejects

By April 18, the repo's answer was clear enough to say publicly: park_c4.

What Worked

What worked in both branches was discrimination.

The repo did not flatten these cases into a single vague category of "still being evaluated." Instead:

• c36 became a backup candidate with a known density problem
• c4 improved materially, then still failed a harsh and explicit gate

That gives the public a much more truthful view of progress.

What Did Not Work

The negative result is that neither branch could yet cross the line from credible research to clear promotion.

For c36, the bottleneck is density.

For c4, the bottleneck is admission under a portfolio-aware gate, even after important bug repair.

For c4 in particular, the negative result is instructive because the branch did not fail on one spectacular flaw. It failed by accumulating several smaller deficits: feasibility, overlap, offset behavior on ORB-down days, and option-parity cleanliness. That kind of failure is common in serious portfolio construction. A strategy often dies not because it is obviously bad, but because it is not clearly additive enough.

Those are different kinds of failure. Publishing them together shows an audience that not all near-misses are the same.

Why This Week Matters

This is the episode where the repo proves it can say no to models it likes.

In One Piece terms, these are crew candidates that passed some tests, failed others, and did not get the slot yet.

That is how a portfolio improves. Not by loving every promising profile equally, but by being specific about why each one is not yet ready.

Public Build Takeaway

The right public framing is:

• c36 has signal but not enough density
• c4 has improved shape but still does not clear the gate
• "promising" and "deployable" are not synonyms

That distinction is one of the most valuable things this repo can teach publicly.

Related workflow

For the Episode 8: c36 And c4, Promising Is Not Deployable workflow, continue through Options Backtesting API, Backtesting Framework, Backtesting Execution Realism, Backtesting Data Quality Checklist, Quote-Aware Options Backtests, and Backtest to Paper Trading Parity Checklist.

How the terminology applies

For Episode 8: c36 And c4, Promising Is Not Deployable, the backtesting workflow should treat Point-in-time contracts, Quote-aware fills, Reject reasons, Replay artifact, Cache key, and Signal timestamp as operational state rather than glossary decoration. That framing keeps the research claim causal: the strategy can only select instruments, prices, and labels that existed at the decision time.

A developer implementing this research idea should persist Look-ahead leakage, Walk-forward test, Slippage model, Same-bar fill, Promotion gate, and Options data API beside the result, instead of leaving those words in a term card. It also turns attractive performance into an auditable record where fills, skips, thresholds, and replay inputs can be challenged independently.

The review artifact for Episode 8: c36 And c4, Promising Is Not Deployable becomes more useful when OPRA-originating data, OCC option symbol, Bid/ask spread, Midpoint, Quote/trade condition, and Quote vs trade semantics appear in the same body of evidence as the selected rows. When a result is promoted, these fields should appear in the run manifest, rather than a prose summary or final equity curve.

In production notes for this backtesting workflow, REST snapshot, WebSocket stream, Entitlement gate, Quote freshness, Timestamp semantics, and Pagination cursor define the checks that decide whether the workflow is reproducible. The result is a backtest that can be rerun, compared across threshold families, and rejected when the evidence is not strong enough.

For Episode 8: c36 And c4, Promising Is Not Deployable, the practical acceptance test is simple: another developer should be able to read the body, identify the exact inputs, reproduce the request sequence, and explain the accepted and rejected rows without relying on the bottom terminology grid. If a phrase appears in the page vocabulary, it should correspond to a stored field, a validation check, a replay step, or an implementation decision in the backtesting workflow.

This is also the reason the article should not measure success only by the final chart, table, or headline metric. The better standard is whether the data path, timing model, entitlement state, and evidence trail survive review. When those pieces are written directly into the body, the terminology becomes part of the workflow readers can implement.