Appendix E. Evidence and Reproducibility

E.1 Distinguish the kind of evidence

A diagram describes an arrangement. An analytical example checks declared assumptions. A simulation executes a simplified model. A measurement records a real program and environment. None automatically validates the others. Captions and experiment records should make this distinction visible.

Chapter 2 and the systems trade-off examples use identified synthetic inputs or hypothetical budgets. Chapter 10 includes actual small-classifier training and CPU inference records; Chapter 11 reuses those artifacts for classifier collaboration. Chapter 12 executes a runtime with a scripted default planner. Chapters 13–14 execute local cryptographic and policy checks but not a distributed ledger. These are complementary teaching artifacts, not a claim of a single end-to-end field deployment.

E.2 Reproduce without rewriting the record

Use a new output directory, preserve the supplied input and model files, and record software versions and hardware. Compare values and decisions before comparing time. Random keys or stochastic model outputs need an appropriate semantic comparison rather than byte-for-byte identity. Local timing on shared hardware can vary and should not be presented as a board or cloud benchmark.

A test count describes a set of checks, not the number of independent scientific observations. Three model initializations on one evaluation set do not create three independent populations. Repeated validation on the same test data reduces its value as an untouched holdout. Report reuse explicitly and reserve new field data for the claims that require it.

E.3 Version models, policies and meaning

Record model identity, preprocessing, numerical representation, runtime, prompt or template, tool interface, data snapshot, and policy. Changing a sensor unit or the interpretation of a timestamp is a semantic change even if the file format still parses. Changing a cached model answer’s permissions is not just a performance setting.

References identify publications, standards, or documentation snapshots. A later API or product release may require a revised laboratory rather than a revised principle. The companion reference map records merged duplicate citations, and the editable chapter sources retain stable section and figure identifiers.

E.4 Validate the target environment

A container recipe is not a successful deployment. A loopback API test is not language-model inference. A software approval record is not physical actuation. A signed registry is not a multi-node blockchain. Board-level memory, energy and thermal behavior, real network delay, model task quality, and platform lifecycle behavior need their own measurements.

Before a classroom deployment, test installation, an ordinary request, a malformed or unauthorized request, overload, an unavailable dependency, and restart behavior under the intended account and hardware constraints. Do not infer the safety of a physical controller or the privacy of a data release from the successful execution of a teaching example.

E.5 Read photographs and diagrams accurately

A photograph establishes what was visible in a particular scene; it does not establish an undocumented processor configuration, deployment date, or performance result. A schematic explains selected relationships and can intentionally omit physical details. Pairing them helps connect mechanism to equipment without confusing illustration and evidence.

The existing real photographs originated in the course slides and retain their source-slide credits. Their original publication rights and detailed deployment identities still require verification before external publication. New photo requests are kept in a separate worksheet until a source and caption can be checked; synthetic diagrams are not presented as real installations.