A release ships an attestation whose predicate claims peer review was completed — what does that prove?
answer
- a schema pointer, not a proof
- authenticity is not accuracy
- who is allowed to assert this type
- beware claims the beneficiary can mint
- mechanically derived beats declared
basics
~10 sOnly that whoever held the signing key asserted that claim about those exact bytes. A predicate type names an assertion's schema, never its truth; value depends on who may issue that type.
solid answer
~50 sAn in-toto statement is a signed assertion, not a proof. The `predicateType` URI tells a verifier how to parse the predicate and which policy applies; it carries no guarantee that the content is accurate. So a "peer review completed" predicate proves that an issuer with a key made that claim about the subject digest. The value comes from two things outside the document. First, **who may assert this type**: your policy has to map each predicate type to the identities allowed to issue it, or a developer's own pipeline can mint review claims about their own release. Second, **how the fact was derived**: a claim generated by the system that owns the fact — the code-review service — is evidence, while a claim assembled by a job the author controls is self-attestation. Predicate types are an open set, which is the framework's strength and exactly why the issuer mapping is not optional.
go deeper
Know that a predicate can hold many kinds of claim, not only build provenance, and that signing a claim does not check whether the claim is accurate.
Explain that predicateType is an open, extensible schema pointer, and that a verified attestation establishes issuer plus subject plus claim type — nothing more.
Spot self-attestation: identify when the party benefiting from a claim can also emit it, and describe the issuer separation that fixes it.
Own the policy matrix — which predicate types count, from which issuers, over which subjects — and defend requiring independent issuers where audit truth, not just integrity, is the asset.
## The claim layer is open by design Anyone can define a predicate type. The type is just a URI, and the framework deliberately does not enumerate a fixed list. That is why the same statement structure carries build provenance, component inventories, verification summaries, test results, vulnerability reports and entirely bespoke organisational claims like "peer review completed" or "exported under licence X". They all share the subject digest binding and the same signing envelope, so a consumer's transport, storage, signature check and subject matching are written once. The cost of that openness is that **a predicate type asserts nothing about truth**. It is a schema pointer. `predicateType` tells your verifier: parse the body this way, and apply the policy registered for this type. It does not tell you the body is accurate, complete, or produced by anyone in particular. ## What a signed attestation actually establishes Stripped to essentials, a verified attestation supports exactly this sentence: *some issuer holding a key my policy recognises asserted a claim of this type about bytes with this digest*. Three things follow. **Authenticity is not accuracy.** The signature protects the claim from modification and ties it to an issuer. It does not audit the claim. A build system that genuinely ran no tests can sign a perfectly valid "all tests passed" predicate. **The issuer is the whole question.** A policy that accepts any predicate of a type from any recognised signer collapses into "any team can vouch for anything". Useful policy is a matrix: this predicate type is meaningful only from this issuer, about subjects in this namespace. A "peer review completed" claim is worth something when the review system issues it and nothing when a job in the author's own repository can. **Self-attestation is the recurring failure.** Consider an insider with legitimate commit rights who wants a change merged without a second pair of eyes. They cannot forge the reviewer's approval in the review system, but if the release pipeline they control emits the review predicate, they do not have to — they emit the claim directly. The attestation verifies, the policy passes, and the audit trail records a review that never happened. The damage here is not to customer data or availability; it is to **audit truth**: the organisation's ability to say later, with evidence, what actually happened. That is exactly the property attestations are bought for, so losing it silently is worse than never having claimed it. ## How to tell a strong predicate from a decorative one Ask three questions of any predicate type before your policy honours it: 1. **Who is the authority for this fact?** The system that owns the fact should be the one signing. Provenance comes from the build platform, review comes from the review system, test results from the test runner. A claim re-typed by an intermediary is hearsay. 2. **Could the party who benefits from the claim produce it?** If yes, the claim is self-attestation and should be treated as a declaration, not evidence. Separation between the identity that produces an artifact and the identity that vouches for a property of it is what gives the second signature meaning. 3. **Is the fact mechanically derived or asserted?** "This digest was produced from this source revision by this builder" is observed by the builder. "This code was carefully reviewed" is a human judgment rendered as a boolean, and the predicate can at best record that a process was followed, not that it was performed well. ## Practical consequences for a verifier An unrecognised predicate type is not a pass and not a failure of the artifact — it is an absence of evidence, and the policy should say so explicitly rather than skipping it silently. Requiring *N distinct predicate types from distinct issuers* over the same subject digest is where the model gets its strength: the digest is the join key, so provenance from the builder, a test result from the test system and a review record from the review system can be demanded together, and forging the set requires compromising several independent issuers rather than one. The short version to say out loud: predicate types make attestations extensible; policy about issuers makes them meaningful. Without the second, an attestation only proves that somebody typed something and signed it.
- If anyone can define a predicate type, what stops a producer inventing one to look compliant?Nothing stops them publishing it — and nothing makes a consumer count it. Verification policy enumerates the types it honours and the issuers allowed to make each one; anything outside that list is an unrecognised claim and contributes zero. The defence is on the consuming side, which is why 'we publish attestations' is a much weaker statement than 'we verify these types from these issuers'.
- Why is a test-result predicate usually stronger evidence than a review predicate?Because the underlying fact is mechanically derived by a system observing its own execution, rather than a human judgment rendered as a boolean. A test-result claim can still be issued by a job that ran nothing, so the issuer question does not disappear — but when the test platform itself signs, the claim reports something it directly observed.
- How does requiring several predicate types over one subject digest raise the bar?The digest is the join key, so a policy can demand provenance from the build platform, a test result from the test system and a review record from the review system, all about the same bytes. Satisfying that fraudulently means compromising several independent issuers rather than one pipeline, which is a materially harder position to reach.
A notary confirms who signed a document, not that its contents are true. An attestation is the same: the signature settles authorship, and the value of the statement rests entirely on whether that author was in a position to know.
saying these in an interview costs you the question
- Thinks a valid signature makes the predicate's content true
- Believes predicate types are a closed set fixed by the spec
- Treats a self-issued claim as independent evidence
- Assumes provenance is the only predicate type
- Counts an unrecognised predicate type as a pass