A source consumer checks that it trusts the SCS that issued the VSA and that the VSA applies to the fetched revision, that the VSA's claims match its expectations, and optionally that the source provenance supports the claims. Step 1: configure roots of trust once (recognised SCS identities and keys with the highest Source level each is trusted for), then follow the VSA verification steps using the revision identifier for subject matching and checking verifier.id against the roots. Step 2: compare at least verifier.id, subject.digest, verificationResult, resourceUri, sourceRefs and verifiedLevels with expected values. Step 3 (optional, L3 and above): examine source provenance directly, with expectations formed together with the SCS and the producer. Expectations attach to a branch or tag and may be formed by trust on first use or defined by the producer (with an authenticated channel and protection against one-sided change). Verification may happen at the build system when source is fetched, at the package ecosystem on upload, at the consumer or in a monitor; at least one should be used.
The graph holds this control, the 0 it maps to, and the evidence behind each claim, over MCP and REST.