← All notes

Project reflection: what should accompany a research demo?

Turn a demo into a reviewable handoff with input contracts, versioned evidence, failure behavior and a clear separation between teaching output and paper results.

Basis of this note

Compiled from this portfolio’s public examples, new climate-protocol checks and the author-provided manuscript abstract. This is a design reflection, not a claim that the climate paper already has a deployed application.

01 / Start from what a reader can verify

A reviewer should be able to identify the question, change one input and understand why the output changes. For the new graph example, removing B→C changes the weighted result at C. The explanation is more useful than an unlabeled moving network.

Use four explicit artifact types: the paper record, the model implementation, a synthetic teaching example and an interface prototype. One can link to another, but a synthetic example should not inherit the paper’s performance claims.

02 / Keep a small handoff contract

Record the entry command, supported runtime, input fields, units, missing-value rule, output schema and error behavior. A graph with a missing endpoint should fail clearly; returning a plausible-looking zero can hide bad data.

YAML
artifact: climate-protocol-learning-example
data_kind: synthetic
model_training: false
python: ">=3.8"
entry: notebook/examples/climate_protocol.py
checks: notebook/examples/test_climate_protocol.py
outputs: information_flags, quantile_loss, graph_messages, split_labels
not_covered: spatial_holdouts, trained_forecasts, policy_effects

03 / Store commands and outputs together

A useful evidence bundle contains the exact source revision, configuration, commands, output and test results. With real data, add acquisition dates, permissions and hashes for the actual inputs. Record only what exists; do not insert invented dataset IDs or placeholder success rates.

The small examples were run on 27 October 2026. Ten tests passed. Recorded outputs include q=0.9 pinball loss 1.0 and graph aggregation 6.5 before edge removal versus 2.0 afterward. These are arithmetic fixtures, not measured climate-risk outcomes.

04 / A useful demo also shows failure

For an interface, distinguish loading, empty, invalid, failed and successful states. Reset should restore a documented initial case. An older request should not overwrite a later selection. Provide keyboard controls and text explanations alongside visual changes.

For a scientific example, failure includes unavailable future data, a forecast window that straddles a boundary and nonfinite values. An explicit refusal can be more informative than an uninterrupted animation.

05 / Link the research to the right artifact

The climate-risk page currently links an abstract-based overview and these learning notes. If a model release becomes available, it should add its own environment, data prerequisites, training/evaluation commands and supported claims. Until then, the small protocol example remains a separate educational artifact.

06 / The handoff I would want to receive

My preferred handoff is small enough to run and explicit enough to question: one command, one example with a hand-checkable result, one failure case and a source link. More screenshots can help navigation, but they cannot replace those four items.

Sources & further reading

Compiled from code and documents, with AI-assisted drafting and translation. Examples and proposed checks are learning material; only linked evidence establishes what was run.