# Signal Quest ML Masterclass — Claim-Level Source Contract

## Purpose and authority

This file governs the evidence language for the final 103-slide doctoral Signal Quest
masterclass and its 2-hour-plus narrated edition. It is a lecture source map, not a performance report, implementation claim, or
authorization to trade. Every technical statement in the lecture, slides, or companion notebook
must remain within one of the claim rows below. If a proposed statement cannot be placed in a row,
it must be omitted or added here with a source and validation method before publication.

The governing local hierarchy is `docs/textbook/manuscript-standard.md`, followed by the canonical
Signal Quest full-textbook chapters, `source-map.md`, and `safety-contract.md`. The architecture and
research prompt define proposed behavior only. External papers motivate method families in the
settings they studied; they do not establish BTC/Polymarket performance. Mutable official
documentation must be rechecked before the lecture is frozen and again before implementation.

## Baseline and evidence finding

The source audit was performed from `$REPOSITORY_ROOT` on branch
`design/automl-autorl-cyber-gyms` at `ccf159c0a42d6455e281ce19938ac35eb4c48d5b`. Its
`docs/textbook` path resolves to `$TEXTBOOK_ROOT`, whose audited branch was
`fix/red-team-remediation-2026-07-29` at `161446a31878e582e5890a1f7e806a7932f29700`.
Existing unrelated changes in both worktrees were treated as immutable. The audit covered the ten
visual-companion chapters, all thirteen canonical technical deep-dive chapters and their compiled
editions, the chapter and figure maps, both Signal Quest source maps, the safety contract,
appendices, labs, architecture artifact, research execution prompt, and its red-team report.

There is no checked-in `research/btc_polymarket/` implementation and no verified historical market
corpus, trained Signal Quest market model, executable-book replay, or measured BTC/Polymarket
performance artifact. The local notebooks contain executable teaching components and synthetic
simulation scaffolds. Therefore, this lecture has **no Measured market-performance claim**. A number
in a chapter, slide, or notebook is Illustrative or Simulated unless a future row names a retained
manifest, code revision, configuration, command, output artifact, and limitation.

## Epistemic vocabulary

Use one of these labels visibly at the first occurrence of a claim and on every results figure.

| Status | Meaning in this lecture | Minimum evidence |
|---|---|---|
| **Implemented** | Local code or a local teaching component exists. This status says nothing about market validity or deployment readiness. | Exact file and component; source inspection; focused rerun or test before presentation. |
| **Simulated** | An output comes from synthetic data, a toy replay, or a constructed scenario. | Generator or fixture, seed/configuration, command or executed notebook, and explicit synthetic-data label. |
| **Illustrative** | A number, trace, formula, or scenario explains a concept but is not an empirical result. | Visible `Illustrative` label and consistency check against the stated formula. |
| **Design target** | The behavior is required or proposed but is not implemented and verified in the research system. | Local contract plus acceptance test that would promote the claim. |
| **Literature-derived** | A primary paper or official document supports a bounded methodological or interface statement in its own setting. | Primary source, exact setting, and prohibition on transferring its result to BTC/Polymarket. |
| **Measured** | A retained real-data run produced the stated result. | Dataset manifest, code/config hashes, command, artifact, period/sample, uncertainty, and limitation. No current Signal Quest claim qualifies. |

“Implemented” and “Simulated” must not be collapsed. For example, the capstone's `paper_replay`
function is implemented teaching code, while its ledger is a simulated result from synthetic inputs.

## Final artifact trace and source-planning aliases

The released teaching package is defined by the canonical manuscript, the 103-record slide map,
the 103-slide PowerPoint, the synchronized teleprompt, the fully executed technical-masterclass
notebook and exact-version environment contract, and the narrated 1080p MP4. The slide map is the
authoritative mapping from every final slide number to a contiguous manuscript range. The
notebook validation record is the authoritative mapping from an implementation claim to retained
code output. The video validation record is the authoritative media contract. These final
artifacts supersede the earlier timing and destination shorthand below.

The S0–S10, T1–T13, NB-C, NB-A, and NB-L labels retained in the claim rows are provenance aliases
from source planning, not assertions about final slide numbers or current implementation status.
Notebook aliases originally referred
to `docs/textbook/btc-polymarket-ml/labs/signal-quest-llm-guided-capstone.ipynb` (**NB-C**) or
`docs/textbook/btc-polymarket-ml/labs/signal-quest-kimi-code-anthology.ipynb` (**NB-A**). “NB-L”
denoted a proposed lecture-only cell; implemented final teaching checks now reside in
`signal-quest-technical-masterclass.ipynb` and its validation record.

In the claim tables, a bare full-textbook filename such as `safety-contract.md` resolves relative to
`docs/textbook/btc-polymarket-ml/full-textbook/`. “Parent `source-map.md`” means
`docs/textbook/btc-polymarket-ml/source-map.md`; “research prompt” means
`docs/planning/btc-polymarket-5m-15m-research-backtest-replay-prompt.md`. NB-A and NB-C resolve to
the exact notebook paths above. These aliases shorten the tables without weakening path identity.

| Source-planning module | Planned minutes | Technical purpose | Primary textbook bridge |
|---|---:|---|---|
| S0 — Evidence before models | 8 | Status vocabulary, settlement contract, and no measured-market claim | Chapters 1–3; source and safety contracts |
| S1 — ML, supervised learning, and RL contrast | 12 | Estimation, labels, decisions, and why this project is supervised rather than RL | Chapter 1 |
| S2 — Metrics, ROC, and precision–recall | 18 | Confusion counts, ranking, imbalance, and metric denominators | Chapter 4 |
| S3 — Calibration, thresholds, and abstention | 15 | Probability meaning, policy selection, and fail-closed decisions | Chapter 6 |
| S4 — Temporal validation | 17 | Clocks, leakage, folds, purge/embargo, and locked holdout | Chapters 2, 3, and 5 |
| Break | 8 | — | — |
| S5 — CatBoost baseline | 12 | Boosted trees, categorical handling, feature contracts, and baseline role | Chapter 8 |
| S6 — Self-supervised representations | 12 | Pretext objectives, pretraining boundary, and downstream proof | Chapter 9 |
| S7 — Causal attention, DeepLOB, TLOB, and LiT | 15 | Spatial/temporal LOB hypotheses, masks, perturbation tests, and latency | Chapter 10 |
| S8 — LLM-assisted code | 12 | Contracted generation, static review, human gate, and provenance | Chapters 7 and 11 |
| S9 — Replay as an executable claim | 13 | Event clocks, executable assumptions, immutable ledger, and sensitivity | Chapter 12 |
| S10 — Bounded agents and synthesis | 8 | Capability boundary, reversible containment, escalation, and final claim ladder | Chapter 13 |

## A. ML, supervised learning, and reinforcement-learning contrast

| Claim/topic | Epistemic status | Canonical local source | External primary source where needed | Exact allowable wording | Forbidden overclaim | Validation method | Textbook / slide / notebook destination |
|---|---|---|---|---|---|---|---|
| Source-specific settlement contract | Literature-derived | `docs/textbook/btc-polymarket-ml/chapter-01-the-question-and-the-judge.md`; parent `source-map.md`; research prompt, “Settlement contract” | Cited Polymarket market page: <https://polymarket.com/event/btc-updown-5m-1785678300> | “For the cited BTC Up/Down five-minute market type, Up resolves when the named Chainlink BTC/USD end value is greater than or equal to the start value; the rule must be reverified for every research target.” | “All Polymarket contracts use this rule,” substituting an exchange close for the named settlement source, or presenting an unarchived rule as immutable. | Archive market metadata/rules, resolution source, timestamps, outcome identifiers, access date, and content hash for each target; test the equality case. | Visual Ch1; T1–T2; S0; NB-C §1 uses a synthetic analogue only. |
| Machine learning as conditional pattern estimation | Illustrative | `docs/textbook/btc-polymarket-ml/full-textbook/chapter-01-ml-foundations-deep-dive.html`, §1 and §4 | None required | “In Signal Quest, a learned model estimates a conditional pattern from historical examples; its score is a claim to evaluate, not a law or command.” | “The model learns the true market law,” “discovers causation,” or “knows the next outcome.” | Check that the lecture keeps observation, model, estimate, policy, and outcome separate. | T1 §1–§4; S1; NB-C introduction and §1. |
| Supervised learning (SL) | Illustrative | `docs/textbook/btc-polymarket-ml/full-textbook/chapter-01-what-machine-learning-is.md`, “Three kinds of learning”; `chapter-01-ml-foundations-deep-dive.html`, §1 | None required | “Supervised learning fits a mapping from decision-time inputs to labels known for historical examples; here the proposed target is a later binary settlement label.” | “Supervised labels are ground truth regardless of source,” or “a defined label is necessarily predictable.” | Inspect the label, source, horizon, equality, and missingness fields in the teaching contract. | T1; S1; NB-C §1 and §4. |
| Probability estimate versus decision | Design target | `chapter-01-ml-foundations-deep-dive.html`, §2–§3; `safety-contract.md` | None required | “A model may produce evidence; a separately versioned deterministic policy decides whether a bounded research action is eligible.” | “A probability above 0.5 is permission to trade,” or any wording that gives model output policy authority. | Trace one score through freshness, artifact, calibration, cost, and risk gates; require a reasoned abstention on any failed gate. | T1 §2–§3 and T6; S1/S3; NB-C §7. |
| Why Signal Quest is not an RL system | Literature-derived | `chapter-01-what-machine-learning-is.md`; `chapter-13-agentic-monitoring-deep-dive.html`, §1–§2; `safety-contract.md` | Sutton & Barto, *Reinforcement Learning: An Introduction*, 2nd ed., official author site: <https://incompleteideas.net/book/the-book-2nd.html> | “The planned predictor is supervised: it learns from historical input–label pairs. RL instead frames an agent interacting with an environment, selecting actions, and learning from action-dependent reward to improve a policy over time.” | “Any agent is an RL agent,” “paper replay is RL,” or “abstention makes the classifier reinforcement learning.” | Require an explicit state/action/reward/transition/policy contract before applying the RL label; none exists for the Signal Quest predictor or guardian. | T1/T13 contrast box; S1; NB-L conceptual comparison only—no RL code. |
| Why RL is intentionally out of scope | Design target | `safety-contract.md`; `chapter-13-agentic-monitoring-deep-dive.html`, §2 and §4 | Sutton & Barto, same primary text | “Signal Quest does not optimize a trading policy through market interaction; execution authority and online reward-driven adaptation are deliberately absent.” | “RL is inferior,” “RL cannot be used in markets,” or “the architecture proves supervised learning is safer in every domain.” | Confirm no live credentials, order capability, reward optimizer, policy update loop, or environment-interaction training path exists. | T13 safety bridge; S1/S10; NB-C §9. |
| Replay versus RL experience replay | Design target | `chapter-12-replay-paper-trading-deep-dive.html`, §1–§4 | Sutton & Barto, same primary text, for RL terminology only | “Signal Quest replay deterministically re-evaluates a frozen research decision path; it is not experience replay for learning or improving an RL policy.” | “The backtest trains an RL agent,” or using “experience replay” for the immutable audit ledger. | Verify replay holds code/config/data assumptions fixed and produces evaluation records rather than gradient or value-function updates. | T12; S9; NB-C §8. |

## B. Metrics, ROC/PR, calibration, and thresholds

| Claim/topic | Epistemic status | Canonical local source | External primary source where needed | Exact allowable wording | Forbidden overclaim | Validation method | Textbook / slide / notebook destination |
|---|---|---|---|---|---|---|---|
| Confusion counts and threshold metrics | Literature-derived | `chapter-04-metrics-deep-dive.html`, §1–§2 | scikit-learn model evaluation: <https://scikit-learn.org/stable/modules/model_evaluation.html> | “Accuracy, precision, recall, specificity, and F1 answer different questions after scores are converted to class decisions at a declared threshold.” | “Accuracy summarizes model quality,” or reporting any metric without class prevalence, positive label, threshold, and denominator. | Recompute TP, FP, TN, and FN from the displayed fixture; derive every metric from those counts. | T4 §1–§2; S2; NB-L metric fixture. |
| Accuracy under imbalance | Illustrative | `chapter-04-metrics-deep-dive.html`, §2 | scikit-learn model evaluation, same official source | “High accuracy can be achieved by a majority-class rule; compare it with class prevalence, a confusion matrix, and relevant baselines.” | “Accuracy is useless for imbalanced data,” or treating the chapter's 95%/98% examples as observed market results. | Run the constructed majority-class example and visibly label all numbers `Illustrative`. | T4 §2; S2; NB-L confusion-matrix cell. |
| ROC curve and ROC-AUC | Literature-derived | `chapter-04-metrics-deep-dive.html`, §1 and §3 | scikit-learn `roc_curve` and `roc_auc_score`: <https://scikit-learn.org/stable/modules/generated/sklearn.metrics.roc_curve.html> | “ROC traces true-positive rate against false-positive rate across score thresholds; ROC-AUC summarizes ranking discrimination, not probability calibration or decision value.” | “ROC-AUC is accuracy,” “AUC proves probabilities are correct,” or “high ROC-AUC proves value after costs.” | Recompute the curve from held-out labels and scores; record positive label, weighting, and evaluation interval. | T4 §3; S2; NB-L ROC cell. |
| Precision–recall curve and AP/area terminology | Literature-derived | `chapter-04-metrics-deep-dive.html`, §1 and §4 | scikit-learn `precision_recall_curve`: <https://scikit-learn.org/stable/modules/generated/sklearn.metrics.precision_recall_curve.html>; `average_precision_score` from the same official API | “A precision–recall curve shows precision–recall tradeoffs across thresholds and is especially informative when the positive class is uncommon. Report average precision (AP) when that is the computation used; do not silently rename AP as trapezoidal PR-AUC.” | “PR is always better than ROC,” “PR-AUC is prevalence-invariant,” or treating AP and every notion of area under a PR curve as identical. | Recompute with the pinned library version; report positive prevalence, curve convention, and whether the scalar is AP or trapezoidal area. | T4; S2; NB-L PR/AP cell. |
| ROC/PR versus calibration | Literature-derived | `chapter-04-metrics-deep-dive.html`, §3; `chapter-06-calibration-abstention-deep-dive.html`, §1 | scikit-learn calibration guide: <https://scikit-learn.org/stable/modules/calibration.html> | “ROC and PR characterize ranking behavior across thresholds; neither establishes that a score of 0.70 is a 70% event probability.” | “Good ranking implies calibration,” or using ROC/PR curves as reliability diagrams. | Construct or identify two monotone score mappings with the same ranking and different probability scales; compare their reliability curves. | T4/T6; S2–S3; NB-L ranking-versus-calibration cell. |
| Reliability/calibration curve | Literature-derived | `chapter-06-calibration-abstention-deep-dive.html`, §1; NB-A “Calibration summary” | scikit-learn calibration guide, same official source | “A reliability curve bins held-out forecasts and compares mean predicted probability with observed positive frequency; its interpretation depends on sample size and binning.” | “A diagonal-looking plot proves universal calibration,” or evaluating calibration on the data used to fit the model/calibrator. | Use untouched temporal data; publish bin rule, count per bin, uncertainty/limitation, and pre/post-calibration views. | T6 §1; S3; NB-A calibration component; NB-C §5. |
| Brier score and log loss | Literature-derived | `chapter-04-metrics-deep-dive.html`, §3; `chapter-06-calibration-abstention-deep-dive.html`, §1 | scikit-learn model evaluation and calibration guide, same official sources | “Brier score and log loss are proper probabilistic scores. They assess the probability forecast as a whole; Brier score alone does not isolate calibration because reliability, resolution, and uncertainty contribute.” | “A lower Brier score proves better calibration,” “log loss is a calibration metric only,” or comparing scores across different samples without qualification. | Recompute from stored probabilities/labels with the pinned version; pair scores with a reliability curve and prevalence. | T4/T6; S2–S3; NB-C §5. |
| Expected calibration error (ECE) | Design target | research prompt, “Forecast quality”; `chapter-06-calibration-abstention-deep-dive.html`, §1 | No single external implementation is canonical; pin and document the chosen definition | “If ECE is reported, define bin edges, weighting, empty-bin handling, positive label, and evaluation sample; treat it as a bin-dependent summary alongside a reliability curve.” | “ECE is calibration,” comparing ECE values computed with different binning silently, or claiming a low ECE proves action readiness. | Recompute from retained held-out probabilities and labels under the declared definition; vary defensible bin schemes and report sensitivity/counts. | T6 metric extension; S3; NB-L ECE cell. |
| Calibration status | Design target | `chapter-06-calibration-abstention-deep-dive.html`, §1 and §4; `source-map.md` | None beyond official calibration definitions | “Any eventual Signal Quest calibration claim requires a dated data manifest, temporal split, fitted calibrator artifact, evaluation command, sample counts, and limitations.” | “The current Signal Quest model is calibrated,” “calibration confidence is 80%,” or treating interactive teaching controls as measurements. | Require retained predictions and outcomes from an untouched interval; reject a claim sourced only to prose, a figure, or synthetic notebook data. | T6; S3; NB-C §5 as simulated practice only. |
| Classification threshold | Literature-derived | `chapter-05-fair-experiments-deep-dive.html`, worked trace; `chapter-06-calibration-abstention-deep-dive.html`, §4 | scikit-learn threshold tuning: <https://scikit-learn.org/stable/auto_examples/model_selection/plot_tuned_decision_threshold.html> | “A decision threshold converts a score or probability into a class or policy state; it is a separate choice from fitting the predictor.” | “0.5 is intrinsically optimal,” “the threshold changes the underlying probability,” or tuning it on the final test. | Freeze the objective and tune only inside validation; evaluate the frozen threshold once on a later untouched interval. | T5/T6; S3–S4; NB-L threshold cell. |
| Policy threshold and abstention | Design target | `chapter-06-calibration-abstention-deep-dive.html`, §2–§3; `safety-contract.md`; NB-C §7 | None required | “Signal Quest may abstain when data, artifact, calibration, cost, uncertainty, or risk conditions fail; abstention is a policy output, not a third settlement label.” | “Abstention improves accuracy by definition,” “NO_TRADE is a model class,” or “a passed threshold authorizes live execution.” | Test every gate independently and preserve the reason code; report coverage/abstention rate alongside conditional metrics. | T6; S3; NB-C §7. |
| Capstone policy outcomes | Simulated | NB-C §7, `decide_paper_only`; `labs/signal_quest_lab/experiment_manifest.json` | None required | “The capstone's `PAPER_UP` and `NO_TRADE` examples are simulated teaching outcomes produced from synthetic inputs and a hand-written fail-closed policy.” | Calling the decisions trades, recommendations, measured edge, or evidence that the policy is calibrated or safe in a market. | Rerun the synthetic cases with seed/configuration recorded; inspect every input gate and retain the simulated label. | T6 lab bridge; S3; NB-C §7. |

## C. Temporal contracts and validation

| Claim/topic | Epistemic status | Canonical local source | External primary source where needed | Exact allowable wording | Forbidden overclaim | Validation method | Textbook / slide / notebook destination |
|---|---|---|---|---|---|---|---|
| Event, receive, decision, and settlement clocks | Design target | `chapter-02-labels-clocks-deep-dive.html`, §2 and worked trace; `chapter-12-replay-paper-trading-deep-dive.html`, §2 | None required | “Event time records when a source says an event occurred; receive time records when the system observed it; decision time includes processing; settlement time belongs to the later label.” | “An event timestamp proves decision-time availability,” or silently substituting an archive timestamp for missing receive time. | Use a fixture where an earlier event arrives after cutoff; the feature path must exclude or reject it. | T2/T12; S4/S9; NB-C §2. |
| Random splitting of temporal evidence | Design target | `chapter-05-fair-experiments-deep-dive.html`, §1; research prompt, “Hyperparameter optimization” | scikit-learn `TimeSeriesSplit`: <https://scikit-learn.org/stable/modules/generated/sklearn.model_selection.TimeSeriesSplit.html> | “Random row splits are invalid when neighboring examples share time windows, labels, regimes, entities, or processing artifacts; the split must match the intended future-facing question.” | “Random splitting is always wrong,” or “chronological ordering alone eliminates leakage.” | Audit raw-event, feature-window, label-window, entity, and transform overlap across every boundary. | T5 §1; S4; NB-C §5. |
| Purge and embargo | Design target | `chapter-05-fair-experiments-deep-dive.html`, §2; research prompt, “Hyperparameter optimization” | None required; scikit-learn `gap` is not by itself the full Signal Quest purge contract | “Signal Quest requires purge/embargo durations derived from label horizon, maximum feature lookback contamination, measured availability delay, and source behavior.” | “A fixed five-minute gap is sufficient,” “`TimeSeriesSplit(gap=...)` proves no leakage,” or calling an undocumented gap purged validation. | For each fold, prove no retained training row shares forbidden raw inputs or label availability with evaluation; save the boundary audit. | T5 §2; S4; NB-L split-visualization cell. |
| Nested temporal model selection and frozen holdout | Design target | `chapter-05-fair-experiments-deep-dive.html`, §3–§5; research prompt, “Hyperparameter optimization” | None required | “Inner temporal folds select features, hyperparameters, calibration, and thresholds; an outer temporal procedure estimates the selection procedure, and the final holdout remains unopened until choices freeze.” | “Cross-validation makes the final test reusable,” “the best final-test threshold is confirmatory,” or hiding repeated holdout inspection. | Preserve trial history, split manifest, access log, selection rule, and frozen configuration; any post-holdout change starts a new experiment. | T5; S4; NB-C §5 is only a simplified chronological teaching split. |
| Fit/transform boundary | Design target | `chapter-02-labels-clocks-deep-dive.html`, §3; `chapter-03-data-engineering-deep-dive.html`, §4; NB-C §§4–5 | None required | “Scalers, imputers, normalizers, encoders, target statistics, and calibrators must be fit only on the permitted training portion of each fold.” | “Unsupervised preprocessing cannot leak,” or fitting normalization on the full sequence because labels were not used. | Unit-test fit indices; mutate future evaluation values and require earlier fitted artifacts and scores to remain unchanged. | T2/T3/T5; S4; NB-C §§4–5. |
| Scope of a fair historical result | Design target | `chapter-05-fair-experiments-deep-dive.html`, §5 | None required | “A frozen historical evaluation supports a claim about that specified procedure on that specified retained interval; it does not guarantee future persistence or live execution.” | “Out-of-sample means production-ready,” or “a locked holdout proves a stable edge.” | State period, opportunity set, missing intervals, selection history, assumptions, and uncertainty in the result caption. | T5; S4 and closing synthesis; notebook defense. |

## D. CatBoost as the tabular challenger

| Claim/topic | Epistemic status | Canonical local source | External primary source where needed | Exact allowable wording | Forbidden overclaim | Validation method | Textbook / slide / notebook destination |
|---|---|---|---|---|---|---|---|
| Boosted-tree mechanism | Literature-derived | `chapter-08-catboost-deep-dive.html`, §1 | Prokhorenkova et al. (2018), *CatBoost: unbiased boosting with categorical features*: <https://proceedings.neurips.cc/paper/2018/hash/14491b756b3a51daac41c24863285549-Abstract.html> | “Gradient boosting combines successive weak tree predictors; CatBoost is a gradient-boosting toolkit with specific ordered methods.” | “Each tree asks a causal question,” “boosting automatically prevents overfitting,” or interpreting a split as a market mechanism. | Tie the lecture equation to the paper's ensemble construction and label it simplified; do not infer feature causality. | T8 §1; S5; NB-A “CatBoost candidate specification.” |
| Ordered boosting and categorical processing | Literature-derived | `chapter-08-catboost-deep-dive.html`, §1–§2; parent `source-map.md` | Prokhorenkova et al., same primary paper | “The CatBoost paper introduces ordered boosting and an ordered approach to categorical-feature statistics to address prediction shift and target-leakage mechanisms studied by the authors.” | “CatBoost eliminates all leakage,” “ordered boosting is chronological market validation,” or “CatBoost safely handles any category by default.” | Verify the pinned CatBoost configuration and category handling; independently audit temporal feature construction and folds. | T8 §1–§3; S5; NB-A specification only. |
| Role in Signal Quest | Design target | `chapter-08-catboost-deep-dive.html`, §2 and §6; research prompt, “Required model ladder and ablations” | CatBoost paper for method only | “CatBoost is the proposed tabular challenger after constant, market, and regularized-logistic baselines; it must face the same temporal data, costs, and opportunity set as deeper models.” | “CatBoost is implemented for the market study,” “is the production model,” or “will outperform the market baseline.” | Require a real curated dataset manifest, training artifact, calibration artifact, baseline table, and untouched temporal evaluation. | T8; S5; NB-C §6 currently contains prompts/gates, not a trained CatBoost model. |
| Feature importance and causality | Literature-derived | `chapter-08-catboost-deep-dive.html`, §3 and §6 | CatBoost paper does not supply causal identification for Signal Quest | “Feature importance or attribution describes aspects of fitted-model behavior under the analyzed data; it does not prove that changing the feature would change the outcome.” | “The top feature causes BTC direction,” or using importance to validate a settlement mechanism. | Pair attribution with leakage tests, correlation/ablation analysis, stability across folds, and an explicit noncausal label. | T8 §3/§6; S5; notebook defense only. |
| CatBoost performance status | Design target | `source-map.md`; `baseline.md`; `chapter-08-catboost-deep-dive.html`, evidence section | CatBoost paper results are on the paper's datasets, not BTC/Polymarket | “No local evidence currently shows that CatBoost predicts Signal Quest labels or beats any baseline.” | Any accuracy, AUC, calibration, edge, or profitability claim for a local CatBoost model. | Check for a retained model/run manifest and deterministic report; absent those, keep the statement as a design target. | T8 evidence box; S5 close; NB-C/NB-A limitations. |

## E. Self-supervised learning (SSL) and LOB representations

| Claim/topic | Epistemic status | Canonical local source | External primary source where needed | Exact allowable wording | Forbidden overclaim | Validation method | Textbook / slide / notebook destination |
|---|---|---|---|---|---|---|---|
| SSL training signal | Literature-derived | `chapter-09-self-supervised-lob-deep-dive.html`, §1–§2 | SimLOB primary preprint: <https://arxiv.org/abs/2406.19396> for its autoencoder setting | “Self-supervised objectives derive supervision from the input structure rather than the later direction label; examples include reconstruction or other pretext tasks, each requiring its own evidence boundary.” | “SSL is unsupervised and therefore leak-free,” “SSL needs no labels anywhere,” or attributing every objective in the chapter to SimLOB. | Name the exact objective, input view, target view, cutoff rule, and split; mutate future input and test invariance of earlier representations. | T9 §1–§2; S6; NB-A “Self-supervised LOB masking.” |
| What SimLOB specifically supports | Literature-derived | `chapter-09-self-supervised-lob-deep-dive.html`, evidence section; appendix C subject to normalization note below | Li et al. (2024), *SimLOB: Learning Representations of Limited Order Book for Financial Market Simulation*: <https://arxiv.org/abs/2406.19396> | “SimLOB uses a Transformer-based autoencoder to learn vector representations of LOB data for financial-market-simulation calibration and reports preservation of selected temporal and price-level structure in its experiments.” | “SimLOB proves masked, contrastive, or next-event pretraining improves BTC direction prediction,” or “SimLOB is a profitable trading model.” | Check the claim against the paper's objective, datasets, downstream calibration task, and reported experiment; retain its simulation-calibration scope. | T9 literature box; S6; no local market notebook result. |
| Pretraining boundary | Design target | `chapter-09-self-supervised-lob-deep-dive.html`, §3; research prompt model ladder | None required beyond the selected SSL paper | “The conservative Signal Quest default pretrains on the temporal training partition, selects the objective with validation data, and evaluates the frozen complete procedure on an untouched later period.” | “Unlabeled future data is automatically permissible,” or allowing final-period behavior to influence objective, architecture, or preprocessing choices without disclosure. | Record corpus intervals, window rules, normalization fit period, objective selection, encoder hash, and downstream split manifest. | T9 §3; S6; NB-C §6 acceptance gates. |
| Encoder output and downstream proof | Design target | `chapter-09-self-supervised-lob-deep-dive.html`, §4–§5 | SimLOB supports representation learning only in its stated task | “An encoder produces a learned representation; downstream usefulness must be tested separately against tabular and simple sequence baselines under the same temporal protocol.” | “A low reconstruction loss proves direction skill,” “an embedding explains the market,” or “pretraining establishes economic value.” | Compare pretext metrics, frozen-transfer metrics, fine-tuned metrics, calibration, and replay separately; include ablations and uncertainty. | T9 §4–§5; S6; NB-C §6 remains a scaffold. |
| SSL implementation status | Implemented | NB-A “Self-supervised LOB masking”; NB-C §6 prompts and advanced-model gates | None | “The local anthology implements and tests a small masking-contract teaching function; the capstone contains design prompts, not a trained Signal Quest LOB encoder.” | “Signal Quest has an implemented pretrained encoder,” or treating returned masked rows as learned embeddings. | Inspect and rerun the anthology cell; verify no training loop, model artifact, market corpus, or downstream evaluation is present. | T9 lab bridge; S6; NB-A masking component and NB-C §6. |

## F. Causal attention, DeepLOB, TLOB, and LiT

| Claim/topic | Epistemic status | Canonical local source | External primary source where needed | Exact allowable wording | Forbidden overclaim | Validation method | Textbook / slide / notebook destination |
|---|---|---|---|---|---|---|---|
| Causal attention mask | Literature-derived | `chapter-10-causal-lob-transformer-deep-dive.html`, §1 and §3 | TLOB and LiT papers below for model families; local contract for the invariant | “At sequence position `t`, a causal mask permits attention only to positions at or before `t`; decision-time validity additionally requires every token and preprocessing artifact to have been available by the cutoff.” | “A triangular mask proves the pipeline is causal,” or equating architectural masking with causal inference. | Perturb all future raw events and rerun the full path; the earlier score must remain unchanged within a declared tolerance. | T10 §1/§3; S7; NB-C §6 gate. |
| Local causal-mask teaching function | Implemented | NB-A “Causal Transformer mask” | None required | “The anthology implements a small function that returns a lower-triangular Boolean attention-permission matrix for a requested sequence length.” | “A causal Transformer is implemented,” “the end-to-end data path passed a perturbation test,” or “the toy matrix prevents preprocessing leakage.” | Rerun the anthology assertions and inspect the returned matrix for multiple lengths; retain the teaching-only boundary. | T10 lab bridge; S7; NB-A mask component. |
| DeepLOB lineage | Literature-derived | parent `source-map.md`; appendix C; `chapter-01-what-machine-learning-is.md`, cross-links | Zhang, Zohren & Roberts, *DeepLOB*: <https://arxiv.org/abs/1808.03668> | “DeepLOB combines convolutional processing of LOB structure with LSTM temporal modeling and reports results on cash-equity LOB datasets in the paper.” | “DeepLOB validates Transformers,” “proves universal LOB features,” or transfers its reported equity results to BTC/Polymarket. | State the datasets/instruments and architecture from the paper; use it only as sequence-model lineage, not local evidence. | T10 literature context; S7; no direct notebook implementation. |
| TLOB contribution | Literature-derived | `chapter-10-causal-lob-transformer-deep-dive.html`, §2 | Berti & Kasneci, *TLOB: A Novel Transformer Model with Dual Attention for Price Trend Prediction with Limit Order Book Data*: <https://arxiv.org/abs/2502.15757> | “TLOB proposes dual attention for spatial and temporal dependencies in LOB data and reports stock-trend benchmark results, including FI-2010 and selected equities, under the paper's protocols.” | “TLOB is causal by name,” “TLOB predicts BTC settlement,” or repeating paper benchmark gains as expected local gains. | Check tokenization, mask, labels, datasets, horizons, and benchmark protocol in the paper; reproduce locally before any implementation claim. | T10 §2; S7; NB-C §6 prompt is design-only. |
| LiT contribution | Literature-derived | `chapter-10-causal-lob-transformer-deep-dive.html`, §2 | Xiao et al. (2025), *LiT: limit order book transformer*: <https://www.frontiersin.org/journals/artificial-intelligence/articles/10.3389/frai.2025.1616485/full> | “LiT uses structured LOB patches and Transformer self-attention to model spatial and temporal features and reports multi-dataset, multi-horizon results in the article.” | “LiT proves robustness to future BTC regimes,” “is a production-ready fast model,” or transferring article comparisons to Signal Quest. | Reproduce the selected paper setting first; for Signal Quest, require causal tests, latency measurements, matched temporal baselines, and calibration. | T10 §2; S7; no local LiT implementation. |
| TLOB versus LiT selection | Design target | `docs/textbook/btc-polymarket-ml/chapter-06-tlob-or-lit-direction-head.md`, grown-up truth; research prompt, model ladder item 5 | TLOB and LiT primary sources | “TLOB and LiT are alternative architecture families. The research contract requires selecting and documenting one directional head before final testing.” | “TLOB/LiT is one combined model,” cherry-picking the final holdout winner, or implying the literature chooses a BTC winner. | Predeclare the selection rule and latency budget; choose on inner temporal validation and freeze before the outer/final evaluation. | Visual companion Ch6; T10; S7; NB-C §6. |
| Latency as part of the model contract | Design target | `chapter-10-causal-lob-transformer-deep-dive.html`, §4; `chapter-12-replay-paper-trading-deep-dive.html`, §2 | None required | “Measured feature, inference, policy, and ledger latency changes the earliest valid decision time and must enter replay.” | Invented millisecond values, “offline accuracy dominates latency,” or scoring at one timestamp while assuming action at an earlier one. | Benchmark in the declared environment with warm/cold policy, sample distribution, clock method, and retained raw results; replay measured distributions. | T10 §4/T12; S7/S9; future NB-L benchmark cell only. |
| Local deep-model status | Design target | `baseline.md`; `source-map.md`; NB-C §6 | Literature sources do not establish local implementation | “No trained Signal Quest TLOB, LiT, or causal LOB direction model is present in the audited checkout.” | “The three-model stack is implemented,” any local deep-model metric, or a diagram treated as runtime evidence. | Require source, tests, model artifact, manifest, causal perturbation evidence, latency results, and untouched evaluation before promotion. | T10 evidence box; S7 close; NB-C §6 limitation. |

## G. LLM-assisted code and provenance

| Claim/topic | Epistemic status | Canonical local source | External primary source where needed | Exact allowable wording | Forbidden overclaim | Validation method | Textbook / slide / notebook destination |
|---|---|---|---|---|---|---|---|
| Contracted code-assistance loop | Implemented | `chapter-11-llm-python-deep-dive.html`, §1–§3; NB-A introduction/provenance; NB-C §3/§3A | None required | “The teaching workflow constrains an LLM request to a small contract, preserves the response and hash, applies static/human review, and executes only separately approved code.” | “LLM-generated code is safe because it passed syntax,” “the LLM ran its own patch,” or “prompting transfers scientific responsibility.” | Inspect prompt, response hash, AST/static findings, approved source, test output, and human gate as separate artifacts. | T11 §1–§3; S8; NB-C §3/§3A and NB-A. |
| Existing LLM traces | Implemented | `labs/signal_quest_lab/llm_feature_draft.json`; `llm_on_demand_code_trace.json` | None | “The checked-in capstone traces record review-required placeholders with the LLM disabled; they demonstrate provenance structure, not successful generation.” | “The capstone called a live LLM,” “the model generated the accepted feature function,” or attributing student-controlled code to the disabled trace. | Verify provider/model/status/response/hash fields and compare the hash to the stored response. | T11 lab bridge; S8; NB-C §3/§3A. |
| Kimi anthology components | Implemented | `signal-quest-kimi-code-anthology.ipynb`, nine named contract sections | None | “The anthology contains nine small generated teaching components with stored hashes and constrained contract checks; passing them supports only those narrow teaching contracts.” | “The anthology implements the market system,” “proves trading safety,” or “validates CatBoost/SSL/TLOB performance.” | Rerun in an isolated environment; inspect exact function, forbidden syntax checks, assertions, outputs, and hashes. | T7/T11 lab bridge; S8; NB-A. |
| LLM explanation versus evidence | Design target | `chapter-11-llm-python-deep-dive.html`, §4; `docs/textbook/manuscript-standard.md`, Evidence and Provenance | None | “An LLM may summarize supplied artifacts and label inference, but it may not manufacture a test result, metric, causal explanation, or data-availability claim.” | Treating fluent narrative as validation, letting the generator certify its own scientific result, or claiming commands ran without output. | Require the cited artifact and independent review; spot-check every numeric and behavioral statement against source/output. | T11 §4; S8; NB-C §10 defense. |
| Tool and authority boundary | Design target | `chapter-11-llm-python-deep-dive.html`, §2; `safety-contract.md` | None | “LLM tools are least-privilege and bounded; untrusted repository, web, log, and dataset text remains data, not governing instruction.” | Secrets in prompts, unreviewed external writes, broad irreversible commands, or trading capability. | Threat-model prompt injection, secrets, dependency changes, and tool overreach; test denials and record approvals. | T11 §2; S8/S10; NB-C §3A. |

## H. Replay and paper-trading research

| Claim/topic | Epistemic status | Canonical local source | External primary source where needed | Exact allowable wording | Forbidden overclaim | Validation method | Textbook / slide / notebook destination |
|---|---|---|---|---|---|---|---|
| Event-driven replay architecture | Design target | `chapter-12-replay-paper-trading-deep-dive.html`, §1–§2; research prompt, “Event-driven backtest and replay requirements” | Polymarket API introduction and market channel for interface concepts only: <https://docs.polymarket.com/api-reference/introduction>, <https://docs.polymarket.com/market-data/websocket/market-channel> | “The proposed evaluator advances through captured events in availability order and exposes only evidence eligible at each simulated decision time.” | “The event-driven replay exists,” “replay reproduces live markets,” or using bar-close tables as proof of event-time availability. | Implement deterministic fixtures for ordering, ties, late/out-of-order events, inference delay, and settlement availability. | T12 §1–§2; S9; NB-C §8 is a smaller synthetic demonstration. |
| Existing capstone replay function | Implemented | NB-C §8, `paper_replay` | None | “The capstone implements a small teaching function that iterates over a frame and records policy fields in a ledger.” | “It is the contracted event-driven evaluator,” “models an order book,” or “implements executable fills.” | Inspect the function and rerun its assertions; verify it uses no captured venue event stream, depth, queue, or fee history. | T12 lab bridge; S9; NB-C §8. |
| Existing capstone replay output | Simulated | NB-C §8; `labs/signal_quest_lab/experiment_manifest.json` | None | “The capstone ledger is a simulated teaching result generated from synthetic prices, a conservative cost input, and synthetic later labels.” | “It uses executable Polymarket prices,” “measures edge,” “is a BTC backtest,” or supports any profitability inference. | Rerun with seed 8414; confirm the synthetic generator, ledger `epistemic_status`, decisions, and manifest limitations. | T12 lab bridge; S9; NB-C §8. |
| Executable price, fills, and costs | Design target | `chapter-12-replay-paper-trading-deep-dive.html`, §3; research prompt, “Execution realism” | Polymarket official API/market-data docs for current fields only; recheck before implementation | “A future replay must use observable buy-side asks and sell-side bids, visible depth, partial/no fills, dated fees, and declared latency/slippage assumptions.” | Midpoint buys, infinite depth, guaranteed queue position, zero unknown costs, or calling assumptions measured observations. | Reconstruct decisions from captured books; test level consumption, no-fill and partial-fill paths, fee effective dates, and adverse sensitivity ranges. | T12 §3; S9; NB-C explicitly does not meet this standard. |
| Immutable decision ledger | Design target | `chapter-12-replay-paper-trading-deep-dive.html`, §4; research prompt, “Deterministic replay” | None required | “Each future decision record must link frozen raw-input, feature, model, calibration, configuration, book, cost, gate, action, fill, and settlement evidence.” | A summary chart as replay evidence, dropping abstentions/rejections, or mutable rows without lineage. | Select a decision ID and reconstruct every field from hashes and immutable artifacts; preserve mismatches as failures. | T12 §4; S9; NB-C §8 is a teaching ledger only. |
| Byte-for-byte deterministic replay | Design target | research prompt, “Deterministic replay”; visual companion Chapter 8 “Grown-up truth” | None required | “The research contract requires `replay --decision-id` to reproduce a frozen decision byte-for-byte; this requirement is not currently implemented.” | “Signal Quest replay is deterministic,” unless a command and retained verification output exist; or assuming cross-platform floats are byte-identical without a serialization contract. | Define canonical serialization and environment; run repeated and clean-environment verification; any mismatch invalidates the associated report. | Visual Ch8/T12; S9; future implementation notebook should call the package, not redefine it. |
| What replay can establish | Design target | `chapter-12-replay-paper-trading-deep-dive.html`, §5; parent `source-map.md` | None required | “Replay tests a specified historical simulation under declared assumptions; it can expose convenient timing and fill assumptions but cannot establish future fills, liquidity, behavior, or live advantage.” | “Backtested profitability proves alpha,” “paper trading proves executability,” or “determinism proves realism.” | Publish latency/fee/fill/depth sensitivity and a ‘what this does not prove’ section with every report. | T12 §5; S9 close; NB-C defense. |

## I. Bounded agents and fail-closed monitoring

| Claim/topic | Epistemic status | Canonical local source | External primary source where needed | Exact allowable wording | Forbidden overclaim | Validation method | Textbook / slide / notebook destination |
|---|---|---|---|---|---|---|---|
| Bounded monitoring loop | Design target | `chapter-13-agentic-monitoring-deep-dive.html`, §1; `safety-contract.md` | None required | “The proposed guardian observes, verifies a predicate, performs an allowlisted reversible containment action, verifies it, records evidence, and escalates.” | “The agent fixes anomalies,” autonomous improvisation, or natural-language diagnosis as an authorization mechanism. | Test each predicate/runbook pair, denial path, rollback, evidence record, resource bound, and escalation condition. | T13 §1; S10; NB-C §9 is a synthetic guardian demonstration. |
| Capability boundary | Design target | `chapter-13-agentic-monitoring-deep-dive.html`, §2; `safety-contract.md` | None required | “The monitor must lack credentials and APIs capable of placing, canceling, resizing, or modifying orders; lack of capability is stronger than a prompt prohibition.” | “The agent could trade but is instructed not to,” or any live-order tool in the monitor identity. | Inspect identity permissions and available tools; attempt denied actions in a safe test environment; retain authorization evidence. | T13 §2; S10; NB-C §9. |
| Containment versus remediation | Design target | `chapter-13-agentic-monitoring-deep-dive.html`, §3–§4 | None required | “Containment limits use of suspect evidence through reversible bounded actions; schema, model, threshold, policy, or deployment changes require separate human-approved remediation.” | “Quarantine repairs the data,” “rerunning validation approves a model,” or allowing the monitor to change scientific contracts. | Scenario-test stale source, schema drift, artifact mismatch, replay divergence, and calibration staleness; require human approval for state-changing fixes. | T13 §3–§4; S10; NB-C §9. |
| Existing guardian functions | Implemented | NB-C §9, `guardian_check`; NB-A “Guardian containment” | None | “The local notebooks implement small evidence-only guardian functions that return bounded status/action records and do not modify external systems.” | “An agentic monitor is deployed,” “the guardian autonomously remediates,” or “the function verifies real system health.” | Inspect the functions and confirm no network, credential, model, policy, account, or evidence-mutation path. | T13 lab bridge; S10; NB-C §9 and NB-A guardian component. |
| Existing guardian health record | Simulated | `labs/signal_quest_lab/experiment_manifest.json`; NB-C §9 | None | “The checked-in `HEALTHY` guardian record is a simulated result over synthetic notebook inputs.” | “HEALTHY proves system health,” “monitoring passed,” or using it as deployment evidence. | Rerun healthy and failed-gate fixtures; confirm synthetic inputs and manifest limitations remain visible. | T13 lab bridge; S10; NB-C §9. |
| Agent is not an RL policy | Design target | `chapter-13-agentic-monitoring-deep-dive.html`, §1–§2; `safety-contract.md` | Sutton & Barto, official primary text cited above | “The guardian follows fixed predicates and allowlisted runbooks; it does not learn an action policy from reward and should not be described as an RL agent.” | “Agentic means reinforcement learning,” “incident outcomes train the guardian online,” or reward-driven runbook selection without a new approved contract. | Inspect for reward, value, policy-update, exploration, and environment-interaction training paths; all must be absent for this claim. | T13; S1/S10; NB-C §9. |

## Primary-source normalization notes

The lecture bibliography must use the primary-source metadata below even where an older local
appendix uses a shortened or inaccurate title. These corrections constrain the lecture only; they
do not silently rewrite the existing textbook.

| Local shorthand requiring care | Canonical primary-source form | Lecture boundary |
|---|---|---|
| “CatBoost: gradient boosting with categorical features,” with incomplete author metadata | Prokhorenkova, Gusev, Vorobev, Dorogush, and Gulin (2018), “CatBoost: unbiased boosting with categorical features.” | Ordered boosting and categorical processing; no BTC result and no claim that all leakage is removed. |
| “SimLOB: Self-supervised learning for limit order books” | Li, Wu, Zhong, Liu, and Yang (2024), “SimLOB: Learning Representations of Limited Order Book for Financial Market Simulation.” | Transformer-autoencoder LOB representation for simulation calibration; not generic evidence for every SSL objective or downstream direction skill. |
| “TLOB: A temporal limit order book Transformer” | Berti and Kasneci (2025), “TLOB: A Novel Transformer Model with Dual Attention for Price Trend Prediction with Limit Order Book Data.” | Dual spatial/temporal attention and reported stock/benchmark setting; not a BTC settlement model. |
| “LiT: A limit-order-book Transformer approach” | Xiao et al. (2025), “LiT: limit order book transformer.” | Structured patches/self-attention and the article's datasets/horizons only. |
| “Brier/log loss test calibration” | scikit-learn official evaluation and calibration documentation | Proper probabilistic scores assess the forecast jointly; use reliability evidence to discuss calibration specifically. |
| “PR-AUC” without a computation definition | scikit-learn `precision_recall_curve` and `average_precision_score` documentation | Name AP when AP is computed; state the integration convention for any other PR area. |

## External-source contract

Only the primary papers and official documentation named in this map may support external claims in
the lecture. Search-result snippets, blogs, vendor marketing, social posts, generated summaries, and
secondary explainers are not evidence. The external source supports only the stated method or
interface claim. Paper-reported benchmark values may appear only with the paper's dataset, task,
split, metric, and a visible **Literature-derived — not Signal Quest performance** label.

Polymarket documentation and market rules are mutable. Before freezing the lecture, archive the
specific page or response used, access date, URL, and content hash. The source contract permits the
market-specific wording: “For the cited BTC Up/Down five-minute market type, Up resolves when the
named Chainlink BTC/USD end value is greater than or equal to the start value; verify the rule for
every target market.” It forbids presenting one archived market page as a universal Polymarket rule.

## Global forbidden claims

The following statements remain prohibited until this map is updated with qualifying measured
evidence:

- Signal Quest has a verified historical BTC/Polymarket dataset or production data pipeline.
- CatBoost, an SSL encoder, TLOB, LiT, an ensemble, or an LLM predicts the target successfully.
- Any model beats the Polymarket or logistic baseline, is calibrated, finds edge, or is profitable.
- The synthetic capstone is a market backtest, executable replay, live paper-trading service, or RL
  environment.
- A replay demonstrates live fills, future liquidity, market impact, or production readiness.
- A risk gate prevents loss, a guardian guarantees safety, or an LLM-generated patch is trustworthy
  without independent evidence.
- “Causal Transformer” means causal effect identification rather than past-only information flow.
- A literature benchmark, architecture diagram, prompt requirement, or passing toy test is a local
  market result.

## Lecture and artifact validation gate

Before publication or recording, the lecture owner must perform the following checks and record the
evidence in the future lecture package:

1. Extract every declarative technical and numeric statement from textbook excerpts, slides, speaker
   notes, and notebook Markdown; map it to one row in this file.
2. Search for status terms and ensure every result figure or number is labeled Implemented,
   Simulated, Illustrative, Design target, Literature-derived, or Measured.
3. Re-run all notebook cells used live from a clean environment. Preserve environment versions,
   executed notebook, stdout/stderr, seed, and output hashes. Do not present a stale embedded output
   as a fresh run.
4. Recompute confusion metrics, ROC, AP/PR, Brier score, log loss, calibration bins, and threshold
   results from stored labels and scores with a pinned library version.
5. Audit temporal examples for event/receive/cutoff/settlement consistency and verify the future-event
   perturbation invariant for any sequence demonstration.
6. Confirm advanced-model cells remain clearly labeled as scaffolds unless source, tests, artifacts,
   and evaluation evidence have been added under an updated contract.
7. Verify that replay demonstrations say `synthetic` or `simulated`, never imply live fills, and retain
   abstentions and failed gates.
8. Inspect the notebook/runtime capability list and prove that neither the LLM helper nor guardian has
   secrets, networked order authority, or a path to mutate model, policy, account, or evidence.
9. Open every external primary-source link, verify current metadata and quoted scope, and archive
   mutable official documentation with access date and hash.
10. Run `git diff --check` and verify that this source map is the only file changed by this assignment.

The release decision is **GO** only when every lecture claim is mapped, every current numerical
result is visibly non-Measured, all demonstrations reproduce under their declared status, and no
slide, speaker note, or notebook crosses the research-only authority boundary.