Your vendor published and signed the model checkpoint themselves — what do a matching digest and a valid signature rule out?
answer
- two claims about custody, not conduct
- which bytes, and whose key
- the publisher can be the adversary
- no chain compromise was needed here
- only running the weights reaches behaviour
basics
~20 sThey rule out custody problems only. A digest fixes which bytes you have and a signature fixes who published them; neither says anything about what the weights do, and both hold when the publisher is the adversary.
solid answer
~50 sA matching digest tells you your copy is byte-for-byte the file the vendor published. A verifying signature tells you that publication came from the vendor's key. Both are claims about provenance — which bytes, and whose — so what they rule out is substitution, corruption in transit and publication by an outsider. Behaviour is a third claim and neither artefact touches it. The case that makes this concrete is a vendor who trained an undisclosed conditional response into the weights themselves: no key is stolen, no mirror is tampered with, no build server is compromised, and every check passes by construction. The signature is then evidence for them — it establishes that the artefact is exactly what that publisher shipped. The only thing that reaches behaviour is running the weights on inputs and reading the outputs, so the number worth asking about is how many behavioural probes were run, not how many artefact checks passed.
go deeper
Be ready to name the three claims separately: which bytes, whose key, and what the model does. Recall that the first two are provenance and the third is only reachable by running the model.
An interviewer expects you to explain why the checks stay green when the publisher is the adversary — nothing in the distribution chain had to break — and to say which threats those checks genuinely do stop.
Show the production habit: when someone reports that the artefact verified, ask how many behavioural probes were run against these weights and what conditions they covered, and record the answer even when it is zero.
Own the framing for the organisation. Decide what your acceptance record must state about behaviour as distinct from custody, so that trusting a vendor is a decision somebody made rather than a gap nobody noticed.
## Three different claims, routinely collapsed into one A model artefact can carry three separable claims: 1. **Which bytes.** A cryptographic digest published beside the file. Recomputing it over your copy and getting a match tells you your copy is the file the publisher intended you to have. 2. **Whose file.** A signature over that digest, verified against a key you have some reason to associate with the publisher. It tells you the act of publication came from the holder of that key. 3. **What it does.** How the weights map inputs to outputs. The first two are *provenance*. The third is *behaviour*. Provenance answers questions about custody: was the file swapped in transit, did a mirror serve you something else, did somebody outside the vendor publish under the vendor's name. Those are real questions and the checks answer them well. Behaviour is a different question, and no quantity of custody evidence reaches it. ## The adversary who breaks nothing Take a vendor that ships an object-detection model inside a retail loss-prevention camera appliance, and suppose the vendor themselves trained an undisclosed conditional into the weights: on ordinary scenes the detector performs exactly as advertised, and under one condition they chose it does not report what it sees. They then publish that checkpoint through the normal release process — digest published, signed with the release key, release note attached — and the buyer mirrors it into their internal registry. Count what this adversary needed. No stolen key. No compromised build machine. No tampering with a mirror, a registry or a network path. Every check the buyer runs passes, and passes *correctly*: the file really is the vendor's file and the signature really is the vendor's signature. The adversary's entire requirement is to be a publisher somebody trusts. And the signature has changed sides. It now establishes that the artefact is exactly what that publisher shipped — which is precisely the situation you are worried about when the publisher is the one who planted the behaviour. A control that is strong against an outsider is silent against the author. ## Why competent engineers get this backwards The instinct comes from source code, where provenance plus review plausibly does reach behaviour. If you know a patch came from the maintainer and a human read the diff, you have some grounded opinion about what the code does. Two habits transfer badly to a checkpoint. First, the reviewable object is gone: a weight file has no named routines and no readable change, so there is nothing for the second half of that pairing to act on. Second, the failure mode people picture is an outsider substituting a file, so the control that stops substitution feels like it stops everything. The result is a review conversation in which the chain of custody is presented and the behavioural question is never asked, because everybody in the room believes it was already answered. ## What actually touches behaviour Only evaluation: running these specific weights on inputs and observing outputs. That makes the honest question quantitative — how many behavioural probes were run against this checkpoint, and what conditions did they cover — and on a great many acceptance workflows the answer is zero beyond a headline accuracy figure that the publisher had every reason to preserve. So the useful discipline is to state each claim with its scope attached, out loud, in the words you would use in front of the person who has to sign the deployment off: - this digest fixes the bytes; - this signature fixes the publisher; - and we have run this many behavioural probes, covering these conditions. The third sentence is the one people cannot finish, and noticing that is most of the value of the question. ## Keep the direction of every claim straight None of this makes provenance checks useless, and a candidate who concludes that has overcorrected. A digest *mismatch* is a genuine, strong finding: something is wrong with your copy. The asymmetry is that a pass bounds custody and only custody, while a failure is real information. Verify digests and signatures, keep doing it, and stop reading the pass as a statement about the model. Trust in the publisher is still the thing carrying the behavioural claim; the checks did not replace it, they only confirmed you are trusting the party you meant to trust.
- Does a digest mismatch tell you more than a match does?Yes, and the asymmetry is the point. A mismatch is a real finding about custody — a substituted file, a corrupted transfer, a mirror serving something else — and you should act on it. A match bounds custody and nothing further. Keep verifying; just stop reporting the pass as evidence about the model.
- If the publisher is trusted, does this distinction matter in practice?It matters because trust is not binary or permanent. A publisher can be compromised, acquired, coerced, or simply careless with a data pipeline they inherited themselves. The aim is not to distrust vendors; it is to record that the behavioural claim rests on trust rather than on a check, so that the organisation is choosing it rather than assuming it was verified.
- Where does the signature still buy you something real here?It fixes attribution. If the checkpoint later turns out to behave badly, you can say which party published it and that your copy was theirs, which is what a recall, a contractual claim or an incident timeline needs. That is a custody service, and a valuable one — it is simply not an assurance about the weights.
A tamper-evident seal on a box proves who sealed it and that nobody opened it since. It says nothing about what the sealer put inside.
saying these in an interview costs you the question
- Says a verified signature means the weights are safe
- Treats a matching digest as a behavioural guarantee
- Assumes any attack requires a compromised distribution chain
- Cannot state what the check actually bounds
- Thinks naming a trusted publisher closes the behavioural question