Observe, decide, and act panels for checking an artifact handoff.

CI artifacts need an explicit handoff contract

A CI job can finish successfully while the next job receives the wrong files. An artifact is a stored output handed to another step, job, person, or release process. Its name alone rarely identifies everything the consumer needs to know. Treat the handoff as a contract covering the producing run, source revision, payload, integrity evidence, access policy, and availability window. Those details turn “download the build” into a checkable operation. ...

September 3, 2027 · 4 min · XB Field Notes
A stable dependency install remains reusable when frequently edited application code is copied afterward.

Copy dependency inputs before application code

Dockerfile order determines which earlier inputs an expensive build operation depends on. If application source is copied before dependency installation, changing that source can make the installation run again even when the dependency declaration is unchanged. Copying the dependency inputs first, installing them, and copying application code afterward creates a smaller dependency boundary that matches the work the installer actually needs. ...

August 17, 2027 · 5 min · XB Field Notes
Observe, decide, and act panels for investigating build differences.

Reproducible builds connect source to artifacts

A reproducible build lets another party recreate specified artifacts byte for byte from the stated source, build instructions, and relevant environment. The promise must name its outputs: matching object files is insufficient when the shipped executable differs. Reproduction provides evidence connecting source and distribution, while source review, provenance, and signatures address other questions. Two identical malicious builds are still malicious, and a compromised toolchain can reproduce its own unwanted behavior. ...

August 15, 2027 · 5 min · XB Field Notes
Two application images share a base and library while separate writable layers hold runtime edits.

Related images share layers; running containers keep separate changes

An image describes an ordered filesystem assembled from immutable layer changesets, together with configuration such as its default command. Related images can reference the same base layers while adding different application files. A running container gets its own writable layer above that image. Distinguishing those three things explains how image reuse saves work without making every container’s runtime edits visible to its neighbors. ...

March 22, 2027 · 5 min · XB Field Notes
The final stage contains the selected executable; its runtime dependencies still determine whether it can start.

Multi-stage builds need a tested runtime boundary

A multistage Dockerfile can compile software in one stage and copy selected outputs into another stage that becomes the runtime image. The final stage inherits its own base and the files explicitly copied into it, rather than automatically inheriting the builder’s compiler, source tree, and package caches. This creates a useful boundary, but the author must still identify everything the program needs when it executes. ...

September 25, 2026 · 5 min · XB Field Notes