A valid signature answers a narrower question than “may we serve this model to customers?” It can prove that a particular signer signed a particular artifact digest. The staging pipeline may legitimately sign experimental weights too. If the production deploy accepts any artifact signed by the organization's CI identity, an authentic staging artifact can pass verification. Sigstore's verification guidance covers signature checks. SLSA's artifact-verification guidance says provenance has value only when consumers inspect it against a policy. Authenticity alone is not release authorization.

Find the exact digest that was served, the immutable model manifest it belongs to, signing identity, build provenance, evaluation results, approval event and the deployment rule that selected it. A mutable tag such as latest or approved can move between verification and download if we resolve it twice. Admission should pin a digest, verify the whole release bundle, and check that the artifact's source, build workflow, environment and promotion record satisfy production policy. The bundle includes tokenizer and chat template, adapter, safety configuration and model weights when those affect behavior. Signatures on only the weights do not attest to the rest.

I would make promotion an explicit state transition from candidate to approved release, with an evaluation record tied to the exact digests and a separate role allowed to approve production. The serving control plane admits only that approved manifest. At startup and during rollout, instances report the digest they actually loaded. Canary and rollback point to immutable releases rather than a tag that can be repointed. Recheck authorization at deployment time, since a valid signature from last year does not mean today's safety or license policy allows the model.

The interviewer might suggest putting production in the signed metadata. That helps only if a trusted promotion process sets it and the admission controller enforces it. Otherwise a staging job can sign a self-declared label. The webhook signature is valid. Why did the agent grant access twice? is about a valid webhook signature not preventing duplicate action. Here the valid artifact signature similarly needs a separate decision about the context in which it can be used.