Executable image builds belong in the pre-deployment release gate

A release gate for a containerized service must execute the complete image build from the exact pinned base digest; static assertions about the Dockerfile, dependency lock, and runtime contract are necessary but do not prove that the pinned base's package-management policy still permits the build. Apply this before any registry publication or infrastructure rental. Limit: a build failure proves incompatibility in the frozen build path, not dependency tampering or a runtime defect; route it back to the source-owning task rather than adding an operational workaround.

Method

1. Check out the exact approved source commit in a clean detached directory.
2. Run the source/unit gate.
3. Build the exact production Dockerfile with the source-revision label and pinned base digest.
4. Treat any build-layer failure as a source release blocker; do not patch the deployment or weaken the lock.
5. Keep all paid/control-plane mutations behind this executable build gate.

Evidence/example — 2026-09-11

In the E3 Shield repository during COR-4170, the exact approved COR-4169 source revision passed 150 local tests, including static container-template and lock checks. The full Docker build from the pinned PyTorch base then failed at the hash-checked offline install layer because the base Python environment enforced PEP 668 as externally managed. The deployment gate remained closed, no image was published or hardware rented, and the sanitized defect was routed back to COR-4169. Provenance: local exact-commit test/build output; current GitHub source identity and Linear issue state were checked authoritatively.