A configuration review can be technically correct and still be difficult to verify because a one-line expression has been compressed into a shape that hides its arguments, references, or closing braces. It is tempting to make tofu validate the first automated check, but validation has a different dependency boundary: OpenTofu requires an initialized working directory with its referenced providers and modules available. Formatting does not.

The useful first gate is tofu fmt -check -diff. It reads local configuration, reports canonical-format drift, shows the change it would make, and does not rewrite the files. That makes it suitable for a pull-request or pre-commit step before a job initializes a backend, downloads providers, or obtains cloud credentials.

A package import can be a more important compatibility boundary than the first vector operation inside it. Go 1.27 ships experimental simd and simd/archsimd packages, but they are not part of an ordinary build. Code that imports either package needs GOEXPERIMENT=simd at build time. If that requirement is left as tribal knowledge, a developer can add an intrinsic locally, CI can build a different program, and a release job can discover the gap only after the source has reached a broader branch.

A service-unit review often ends with a useful but non-enforcing observation: systemd-analyze security reports an exposure score, the reviewer notes it, and the change still moves on. That is reasonable for discovery, but it does not make a sandbox regression visible to a pull request or deployment job. A unit can lose NoNewPrivileges=, regain access to host devices, or widen its filesystem access without a syntax error.

The useful boundary is an exposure budget. This guide uses systemd-analyze security --offline=yes --threshold= to make a candidate unit fail before it is installed or restarted. The check runs against a file in the review workspace; it does not contact the service manager, reload a unit, or start the service. The result is a small CI gate that distinguishes a valid unit file from one that also meets the team’s agreed sandbox target.

A Prometheus configuration can load cleanly while a recording rule still produces the wrong number. That difference is easy to miss when a rule has valid YAML, valid PromQL, and a sensible name. The error often appears later, when a dashboard panel is unexpectedly high, an alert threshold is crossed early, or a dependent rule has no series to evaluate.

The useful gate is not another configuration check. It is a small rule test with known input series and an expected result. In an isolated Linux AMD64 validation with Prometheus 3.15.0-rc.1, a recording rule that summed two synthetic http_inprogress_requests series passed when the expected value was 7. Changing only the expected value to 6 made promtool test rules return exit status 1 and show the expected and actual samples. promtool check rules accepted the rule in both cases because its job is syntax and rule-file validation, not proving an intended result.

An API job can fail in two different ways at once: the HTTP status says the request was rejected, and the response body contains the only useful explanation. A plain curl --fail handles the first part well. It returns a nonzero status for an HTTP response of 400 or higher, so a shell script, timer, or CI job does not report success. By design, though, it does not save the response body. That can leave an operator with an exit code but no server-provided error identifier, retry advice, or validation detail.

A one-way transfer is often described as the safer choice because it does not remove destination-only files. That is true of rclone copy, but it is not enough to make the command safe to place in a scheduled job. The source and destination still need to be named correctly, a dry run must show the expected scope, and a successful transfer needs a separate comparison before it becomes evidence that the copy is usable.

A restore command can succeed cryptographically and still put bytes in the wrong place. That is easy to miss with encrypted archives because a command such as age -d writes plaintext to standard output when no output file is named. If that standard output is a terminal, a binary archive, database export, or image is not useful to read and can corrupt the display or escape sequence state of the terminal emulator.

A checksum tells you whether a file matches a published digest. It does not, by itself, tell you who made that digest, which repository produced the file, or which workflow made the claim. That distinction matters when a release archive is about to become an executable on an administrator workstation or a CI runner.

GitHub CLI can verify an artifact attestation before that handoff. gh attestation verify calculates the artifact digest, obtains the matching signed attestation, and checks its provenance against an expected owner or repository. The repository boundary is not optional decoration: without it, a valid attestation for a different project is not evidence that the intended project produced the file.

A top-level import is often doing more work than its caller needs. A command-line program may import an optional client, a report renderer, or an SDK before it has parsed the subcommand that would use it. That work is visible as startup latency, but moving imports into functions can make dependency ownership difficult to see and can postpone errors in ways that are hard to test.

Python 3.15 adds explicit lazy imports through PEP 810. A lazy import statement keeps the normal, module-level declaration but defers loading the named module until code uses it. That makes it useful for a narrow startup boundary, not a switch to apply across an application without tests. An import that registers a plugin, changes process state, reads configuration, or is needed to make a module importable has an observable time boundary. Moving that boundary can change behavior even when the imported module itself is correct.

A goroutine count can show that a service is growing, but it does not explain whether the blocked work is expected. A busy HTTP server may have many goroutines waiting on sockets, timers, or a work queue and still be healthy. A goroutine that is waiting on a channel which no remaining code can ever send to is different: it will retain its stack and anything it references until the process exits.