Glossary

Ten core terms

Each entry starts in plain language. The “Compose” notes show what the idea replaces if you already know Docker Compose.

scheduler (batch scheduler): The program that decides who gets which part of a shared cluster, and when. Slurm and PBS are examples. On a laptop, you are the scheduler.
allocation: The share of the cluster, for a fixed amount of time, that the scheduler grants to your job. Everything you run happens inside it, and it ends when the time is up. Compose: the stretch between docker compose up and down.
job step: A program the scheduler launches and tracks inside your allocation. In Slurm, each srun command starts one. Compose: a service.
coordinator: The one service that hands out work and collects results. It starts first, and no worker starts until the readiness gate has passed.
worker: A program that asks the coordinator for tasks and sends back results. Workers start only after the readiness gate passes.
readiness gate: A time-limited check that the coordinator gives the exact right answer before any worker starts. It proves the coordinator can serve. It does not prove that any result is right; that is verification. Compose: healthcheck plus depends_on.
verification: Your check that every result is correct. Only a full pass writes the success marker (result.json). A job can pass the readiness gate and still produce wrong results; only verification catches that. It belongs to your application, so you replace it with your own definition of correct. Compose: nothing. See also verifier and success marker.
job-scoped scratch: Temporary job storage: a private folder made for one job. Do not keep anything there that you need later. Whether and when it is cleared depends on your center. Compose: a named volume.
loopback: Local-only access: the address (usually 127.0.0.1) a machine uses to talk to itself. It keeps a service off the network, but other jobs on the same node can still reach it. Compose: replaces a published ports entry. Services in this pattern listen on it by default; reaching them from beyond the node needs access your center approves.
SSH tunnel: An approved, encrypted path from your own computer to a service on a compute node, if your center allows one. Compose: replaces a published port.

Evidence words

Tested, Shim-tested, Designed, not run

Pages on this site use three words for how much proof stands behind a claim.

Tested: it ran on a named cluster. The badge or the test record says which cluster and when.
Shim-tested: it ran only off-cluster, against test fixtures or local Docker, and never on a cluster.
Designed, not run: it is a design that has not been run. Pages label it exactly that.

More terms

Scheduler and allocation

job: Submitted work that requests resources and runs inside an allocation until completion, cancellation, failure, or timeout.
orchestration boundary: The system responsible for starting and connecting processes. Compose fills this role on a laptop; on HPC, the scheduler allocation and launch script fill it together.
reclamation: The scheduler returning allocated resources to the cluster when a job ends or reaches its wall-time limit.
terminal state: The scheduler’s final classification of a job, such as COMPLETED, FAILED, TIMEOUT, or CANCELLED.
wall time: The maximum duration requested for a job. The scheduler ends a job that reaches this limit.

Runtime and storage

bind: A host filesystem path mounted at a chosen path inside a container.
immutable image: A read-only container image, such as an Apptainer .sif file, replaced through a verified rebuild rather than edited during a run.
module load: A command that makes center-managed software available in the current environment.
rootless runtime: A container runtime, such as Apptainer or Charliecloud, that launches containers without a privileged daemon or root access.

Workflow mechanics

checksum (SHA-256): A content fingerprint used to verify that a file matches an expected artifact.
inert input: Input parsed as data rather than evaluated as code or shell commands.
readiness check: A test that confirms a service can perform its required operation before dependent work starts.
semantic readiness: A readiness check that verifies a correct service response rather than only an open port.
success marker: A machine-readable file written only after the workflow’s documented result checks pass.
readiness contract: The specific response a service must produce before dependent work starts: the agreed meaning of “ready” that a readiness check enforces.
verifier: A program that compares workflow outputs against documented success criteria and writes the success marker only when they pass.
workflow package: The complete, release-pinned code that you download and submit, as opposed to the excerpts shown on the site for teaching.
teaching excerpt: An annotated fragment of the workflow package shown on a page for explanation; it is not a replacement for the runnable source.
applicability record: A published record of where the workflow was tested: environment, scheduler, runtime, result, assumptions, and portability boundaries.
release-pinned: Referring to an immutable tagged release of the repository (such as v0.1.0) rather than a moving branch, so the cited code cannot drift.
demonstrator vs. template: The two purposes of the reference workflow package: it demonstrates that the pattern runs (producing the test record), and it is a template you edit for your own application.

Continue with the five-minute tour, Scheduler as Orchestrator, the Baseline Pattern, or Run the example.