In a SLSA v1 provenance predicate, what do buildDefinition and runDetails each describe?

## The shape Provenance is a claim about **how an artifact came to be**. In SLSA v1 that claim is carried by a predicate with two top-level members and nothing else: ``` buildDefinition buildType (required) URI naming the kind of build externalParameters (required) the caller's inputs internalParameters (optional) the platform's own settings resolvedDependencies (optional) artifacts the build consumed runDetails builder.id (required) URI naming the build platform metadata (optional) invocationId, startedOn, finishedOn byproducts (optional) extra outputs such as logs ``` The split is not cosmetic. `buildDefinition` is meant to be **reproducible input**: in principle, the same `buildType` plus the same parameters plus the same resolved dependencies should describe the same build again. `runDetails` is **observational**: it records one particular execution and could never be reproduced, because a second run has a different invocation id and different timestamps. ## buildDefinition, field by field **`buildType`** is a URI, and it is the schema for everything beside it. It does not point at your source; it points at a document that says which parameters this kind of build accepts and what each one does. Two different platforms can implement the same `buildType`, and one platform can offer many. Without knowing the `buildType`, the other fields are just JSON with plausible names. **`externalParameters`** holds the inputs supplied by whoever asked for the build — typically things like the source repository, the ref or revision, a path to a build config, a version string. This is the security-interesting half, because anything a person who can trigger a build may choose lands here. **`internalParameters`** holds configuration the build platform applied itself, which the requester did not choose — a runner image, a default toolchain version. It is optional and frequently omitted; when it is present it is mostly for completeness and debugging, since a consumer who trusts the platform is implicitly trusting these values anyway. **`resolvedDependencies`** is an unordered collection of artifacts the build needed — a base image, a fetched tarball, a toolchain — each described with a URI and/or a digest. The spec is explicit that this collection **may be incomplete**, so its absence or emptiness means "not stated", never "there were none". ## runDetails, field by field **`builder.id`** is the trust anchor. It is a URI naming the build platform whose security properties you are relying on when you accept the artifact. A verifier's job is to match it against an expected value — and, crucially, to confirm that whoever signed the statement is authorized to speak for that identifier. A `builder.id` that the build's own steps could write is a self-assertion and proves nothing. **`metadata`** carries `invocationId` (a handle back to the specific run and its logs), `startedOn` and `finishedOn`. These are useful for correlation and incident work, and, like `builder.id`, they only mean anything if the platform stamped them rather than the job. **`byproducts`** collects other outputs of the run that are not the artifact being attested — logs, reports, intermediate files. Note the direction: `resolvedDependencies` is what went **in**, `byproducts` is what came **out** besides the artifact. ## What the predicate is not Three confusions are worth naming up front. The predicate is not an inventory of what is **inside** the artifact — that is a component list, a different kind of document, and `resolvedDependencies` only approximates it (a compiler appears in the build but not in the binary). The predicate is not self-protecting: the JSON is a payload wrapped and signed separately, so an unsigned predicate is a text file anyone can write. And the predicate says nothing about **quality** — no field reports a vulnerability, a test result, or a license. Provenance tells you the route the artifact travelled; judging what arrived is a separate exercise. ## Reading one in an interview Handed a provenance document, a strong candidate narrates it in this order: what kind of build is this (`buildType`), who asked for what (`externalParameters`), who ran it (`builder.id`), and does any of that match what I expected? A weak one starts reading digests without asking what recipe produced them.