Bringing this as one narrow, concrete consistency point, as suggested.
The spec is careful in one place and silent in the place that mirrors it, and I think the silent one is the riskier of the two.
§7.2 and §7.3 both state plainly that the relevance score and the Explore cutoff reflect relevance only and MUST NOT be read as a trust, compliance, or safety judgment. Good. But §7.1 shows filtering on trustManifest.attestations.type: ["SOC2-Type2"], and nothing in the filter semantics says what a match on that does and does not mean.
In practice that is the filter people will over-read. Nobody mistakes a relevance score of 80 for a compliance verdict. A result set filtered on attestations.type = SOC2-Type2 reads exactly like a a quality seal: "here are the SOC2-compliant agents." It isn't. The presence of an attestation entry means the publisher linked a document of that type. Whether it is valid, what it actually covers, and whether it is still current are things a consumer only learns after it dereferences the uri and checks the digest, per §5.2.
So the asymmetry is that the spec guards the low-risk misread twice and leaves the high-risk one unguarded.
The fix is small: one sentence in §7.1's filter semantics (or under §5.2), mirroring the language already in §7.2. Roughly: "Matching on an attestation field such as trustManifest.attestations.type indicates that an entry links an attestation of that type. It is not a trust, compliance, or safety judgment; a consumer is expected to dereference and verify the attestation before relying on it."
That keeps it consistent with the line the spec already draws for relevance, and it stops a registry or orchestrator from quietly turning a filter into a badge. Happy to open a PR with exact wording if the direction is welcome.
Bringing this as one narrow, concrete consistency point, as suggested.
The spec is careful in one place and silent in the place that mirrors it, and I think the silent one is the riskier of the two.
§7.2 and §7.3 both state plainly that the relevance score and the Explore cutoff reflect relevance only and MUST NOT be read as a trust, compliance, or safety judgment. Good. But §7.1 shows filtering on
trustManifest.attestations.type: ["SOC2-Type2"], and nothing in the filter semantics says what a match on that does and does not mean.In practice that is the filter people will over-read. Nobody mistakes a relevance score of 80 for a compliance verdict. A result set filtered on
attestations.type = SOC2-Type2reads exactly like a a quality seal: "here are the SOC2-compliant agents." It isn't. The presence of an attestation entry means the publisher linked a document of that type. Whether it is valid, what it actually covers, and whether it is still current are things a consumer only learns after it dereferences theuriand checks thedigest, per §5.2.So the asymmetry is that the spec guards the low-risk misread twice and leaves the high-risk one unguarded.
The fix is small: one sentence in §7.1's filter semantics (or under §5.2), mirroring the language already in §7.2. Roughly: "Matching on an attestation field such as
trustManifest.attestations.typeindicates that an entry links an attestation of that type. It is not a trust, compliance, or safety judgment; a consumer is expected to dereference and verify the attestation before relying on it."That keeps it consistent with the line the spec already draws for relevance, and it stops a registry or orchestrator from quietly turning a filter into a badge. Happy to open a PR with exact wording if the direction is welcome.