SLSA Source Track: Name the Claim in a Robot Deal Room

A software deal room can contain information about source development alongside information about a built package. Both may be relevant to a robot integration handoff, but they describe different activities. The current SLSA 1.2 specification makes that distinction visible through its track structure. This article reads the approved version and its change summary on November 2, 2026. It uses a fictional deal-room discussion and makes no claim that any supplier, repository, or artifact has achieved a SLSA level.

The specification now distinguishes multiple tracks

The approved SLSA 1.2 specification presents Build and Source tracks, among other information. Its change summary identifies the addition of the Source Track relative to version 1.1. These are facts about the specification’s structure, not an assessment of the software in a particular transaction.

A deal-room editor should therefore name the track or claim being discussed. A broad phrase such as “SLSA evidence included” may leave the receiving party unsure whether the material concerns source management, a build process, or something else. Precision helps the reader ask for the relevant explanation.

Two documents can concern different stages of software work

Imagine a fictional integrator handing over a software package with two supporting documents. One discusses how development changes were managed. The other describes a build-related claim. Placing both in the same folder does not make them interchangeable, even when they refer to related work.

The recipient can first ask what object and activity each document describes. A source-process account and a built artifact have a relationship that needs to be explained. The example does not supply a real repository, package digest, or attestation. It only illustrates why the document’s subject belongs in its label.

Keep the requested claim narrower than “everything is secure”

A meaningful request should identify the conclusion the recipient is trying to evaluate. For example, the fictional parties might want to understand which source-related process a statement covers. That is different from asking whether every aspect of an entire robot installation is secure.

The specification should be used at its stated scope. A software supply-chain claim cannot by itself establish the physical condition of a robot, the ownership of equipment, or the performance of an integration. Those subjects would need their own appropriate evidence. The article offers no conclusion on any of them.

Nor should a track name become a decorative certification badge. A responsible assessment needs the actual applicable requirements and evidence. Reading the specification introduction does not complete such an assessment, and the fictional example should not be presented as one.

A relationship needs more than a nearby filename

Suppose the fictional source-process document and build document have similar names. The receiving party still needs to understand how they relate to the package being delivered. Similarity in a folder view may be a useful clue, but it is not a sufficient explanation of the software relationship.

The document author can identify the relevant objects and provide the explanation appropriate to the actual material. If the relationship is not yet established, the deal-room note can preserve that gap. It should not invent a source revision or claim that a verification step succeeded.

A clear gap can guide a focused conversation with the provider. It is more useful than a generic “documentation incomplete” label because it says which relationship remains uncertain. The provider can then respond without disclosing unrelated private material or supplying credentials.

Use the version structure to improve the handoff vocabulary

The Source Track addition gives editors a more specific vocabulary for discussing source-process information. It does not require them to collapse every software document into that track. A handoff can retain several kinds of evidence and state the question each is intended to address.

If the recipient later performs an actual verification, that activity should have its own record, including the material and scope reviewed. The result should not be backfilled into the earlier fictional discussion. This article has not verified an attestation, assessed a builder, or inspected a source-control platform.

The benefit of the current structure is therefore practical and limited: it helps parties distinguish claims before debating whether the supporting material is sufficient. That makes a software deal room easier to read without turning it into a universal assurance about the whole transaction.

The fictional parties can also record the purpose of their clarification request. A response intended to explain one source-related process should not later be reused as though it answered every build question. Keeping the request beside the answer preserves the meaning of the exchange.

Other information-scope topics appear in our robot deal documentation section and the article directory. The two original illustrations show conceptual source and build relationships, with no actual supplier evidence, verified level, or transaction approval.