Robot Software Deal Review: Identify the Attested Artifact

A robot software deal may include a provenance document next to a downloadable package. Their presence in the same folder does not explain which artifact the document describes. Before a buyer discusses the strength of any supply chain claim, the document must be associated with the actual delivery. This article proposes questions for a fictional procurement handover; it does not verify a real software package or an attestation.

Start with the artifact named in the delivery agreement

The buyer and supplier should first identify the deliverable under discussion. A software bundle, an installer and a supporting archive may all appear in a delivery folder while serving different purposes. Ask the supplier which of these is covered by the accompanying statement. Keep the supplier's answer linked to the delivery description rather than treating the folder's display name as a definitive identity.

A useful record distinguishes the artifact received from a document explaining it. If the supplier replaces the artifact, retain the earlier reference and ask whether the accompanying statement has changed as well. Replacing a file while leaving its documentary association implicit makes it difficult for a later reviewer to understand which item was considered during acceptance.

Read provenance as information with an identified scope

The SLSA version 1.2 provenance overview describes provenance as verifiable information about the origins and production of software artifacts. It distinguishes tracks with their own purposes. The overview explains what the information is intended to describe; it does not make a particular file in a sales folder trustworthy merely because the supplier calls it provenance.

Ask which kind of statement the supplier delivered and where its scope is explained. Do not infer build details from a generic assurance paragraph. A receiver who cannot identify the format or the artifact concerned should record that as a documentary gap before trying to draw conclusions about the underlying production process.

Locate the subject rather than reading only the headline

The official in-toto Statement version 1 specification defines a subject collection identifying the software artifacts to which the attestation applies. Its subject descriptors require a digest. This supplies a concrete place to inspect when a delivery is said to use that statement format. It does not prescribe that every unrelated supplier document must follow the same structure.

For the fictional delivery, ask the supplier to point from the subject description to the actual artifact being supplied. A convenient file name can help a person navigate the package, but the association needs the format's relevant identity information and an explanation of the verification performed. Copying a name into a spreadsheet is not itself a verification of the artifact.

The buyer's acceptance note can distinguish between a field being present, a relationship being explained and a verification being performed by an authorized reviewer. These are separate observations. Recording the distinction is particularly useful when procurement staff receive the documents while a different team is responsible for technical validation.

Handle a mismatch without inventing a production history

Imagine that the delivered archive is replaced after a packaging correction, while the statement still appears to describe the earlier item. The immediate task is to ask which artifact is now intended and which document supports it. The mismatch does not, by itself, establish malicious behaviour or prove that the production process changed. It establishes a question that the supplier must resolve.

Preserve the original question, the supplier's clarification and the replacement references together. If an authorized validation later occurs, attach its actual result and conditions. Do not fill a missing answer with a plausible build date, a guessed repository or a claim that an unchanged project name makes all versions equivalent. None of those inferences follows from the folder arrangement.

It can help to give the supplier a precise reply field: identify the delivered item, identify the statement subject, and describe the evidence connecting them. This is an editorial request, not a proposed new attestation standard. Its value is that the person receiving the answer can see which association was explained and which technical verification still requires an authorized decision.

State what acceptance covered and who still needs to act

A documentary conclusion should say whether the artifact and the stated subject can be associated from the supplied evidence. It should separately identify validation work that remains outstanding. Even a confirmed association does not answer every question about software behaviour, licensing, vulnerability exposure or suitability for a particular robot installation. Those matters require their own scope and evidence.

The original illustrations show a hypothetical handover relationship and contain no real digests, signatures or build records. Additional material is available through the robot deal documentation section and the article directory. Identifying the object of a statement makes later review possible; the record should remain explicit about which claims have actually been examined.