Check what a builder actually attests about an artifact

The in-toto Statement v1 structure separates subjects from a predicate and identifies the predicate's meaning with a type URI. A subject digest binds the statement to content; a convenient subject name or registry tag is not an equivalent substitute. Match the intended algorithm and digest against the artifact being considered. A statement can contain multiple subjects, so inspect the relevant subject rather than assume the first name is the only output. Verify the signed envelope or signature format according to its contract and keep the verified payload as the data being interpreted, avoiding an unsigned replacement document.

The predicate type supplies semantics, not just a label to display. An inventory statement, test result, and build provenance make different assertions even when their envelopes share a structure. A verifier must understand the required type and version and must not count an unrelated predicate as satisfying a provenance requirement. Distinguish unsupported required semantics from harmless unknown extension fields permitted by a specification's parsing rules. SLSA's versioned provenance rules do not require indiscriminately rejecting every unfamiliar field, while external build parameters may need stricter policy scrutiny because they can change what was built.

SLSA 1.2 build provenance uses the provenance/v1 predicate and organizes information into buildDefinition and runDetails. The build definition identifies the build type, external parameters, and resolved dependencies; run details identify the builder and particular execution information. The specification's builder identity represents a defined trusted platform boundary, not merely a human-friendly job name. Consumers need an expectation for the allowed source, parameters, and builder. For an AI build, that may include which repository revision and toolchain or model-conversion inputs the approved workflow is supposed to use, with each requirement grounded in available evidence.

Do not infer complete input capture merely because resolvedDependencies is present. The specification describes completeness as best effort in the relevant build levels and documents the builder's guarantees separately. A build script can fetch an unrecorded tool, and a compromised builder can emit a false account of what happened. A valid signature preserves that false account's attribution rather than making it true. Stronger isolation, control-plane-generated evidence, source controls, and independent reconstruction constrain different threats. Explain which party observes each field and which assurance would fail if that party were compromised.

Record the verified subject, builder, predicate version, relevant parameters, and policy version with the deployment decision. A changed trust root or newly distrusted builder can require reevaluation of a previously accepted statement. Keep provenance discoverable and retained with its artifact, but do not confuse registry attachment with authenticity. Handle missing, malformed, or unsupported required claims explicitly. If verification becomes a throughput bottleneck, improve capacity or an appropriately keyed cache; silently omitting builder or subject checks changes the policy rather than merely improving performance.

The queue lab explores only the capacity of such work. For each separate run, Reset, set both arrival rate λ=2 and service rate μ=4, predict the initial backlog's drain time, then Play or Step. The deterministic fluid backlog starts at four and drains in two seconds under these fixed rates. It does not parse statements, authenticate builders, or decide which claims are true. The operational connection is that a required verification stage needs capacity and a defined failure path; reducing its backlog does not justify weakening the evidence checks performed on each item.