Skip to content

Glossary

Page Maps

graph LR
  family["Reproducible Research"]
  program["Deep Dive DVC"]
  section["Execution Environments Reproducible Inputs"]
  page["Glossary"]
  capstone["Capstone evidence"]

  family --> program --> section --> page
  page -.applies in.-> capstone
flowchart LR
  orient["Orient on the page map"] --> read["Read the main claim and examples"]
  read --> inspect["Inspect the related code, proof, or capstone surface"]
  inspect --> verify["Run or review the verification path"]
  verify --> apply["Apply the idea back to the module and capstone"]

This glossary keeps the language of Module 03 stable.

The goal is practical runtime clarity: when you keep environment, determinism, and tool boundaries distinct, drift becomes reviewable instead of spooky.

Terms

Term Meaning in this module
execution environment The runtime surface that can influence results beyond data, code, and declared parameters, such as interpreters, libraries, OS/runtime behavior, or hardware.
environment input surface The subset of runtime facts that matter enough to belong in the causal story of a run.
environment drift Meaningful runtime difference between executions that can influence behavior even when other workflow state still matches.
deterministic A run whose outputs stay the same under the conditions that matter for review.
conditionally deterministic A run whose sameness depends on certain runtime conditions being held stable.
canonical executor The environment a team treats as the authoritative reference for proof, usually a CI context or similarly controlled runtime.
runtime evidence Concrete artifacts or reports that help explain environment state, such as version reports, lockfiles, container definitions, or CI metadata.
lockfile A dependency-resolution artifact that records package versions more explicitly than loose dependency declarations alone.
container strategy A runtime-control approach that standardizes more of the software image across machines and automation.
CI authority The practice of treating one automated execution environment as the shared proof route for the team.
DVC environment boundary The line between what DVC helps make diagnosable and what still belongs to lockfiles, containers, CI, or policy.
acceptable drift A declared level of result variation that the workflow or team considers consistent with its current runtime strategy.

How to use these terms

If Module 03 starts feeling vague, ask which term has blurred:

  • is this a data or parameter problem, or is it environment drift?
  • is the workflow deterministic here, or only conditionally deterministic?
  • is this evidence about DVC-recorded state, or runtime evidence from another layer?
  • is the team using CI as a canonical executor, or only as another machine?

Those questions usually turn a fuzzy runtime complaint into a reviewable explanation.