Docs Validation
Predicates
The labels that travel on every attestation. Pick them carefully — policy reads them.
A predicate is the kind of validation an attestation speaks to. It is the primary key a policy contract queries. Well-named predicates make policies short; overloaded predicates make policies ambiguous.
Naming convention
Predicates use namespace:tool — for example test:go, build:docker, local-deploy:compose. The namespace answers 'what kind of evidence is this?'. The tool answers 'how was it produced?'. Both are required.
| Namespace | Meaning | Typical tools |
|---|---|---|
| build | Compiled or bundled an artifact successfully. | go, docker, gradle, pnpm, cargo, bazel |
| test | Executed a test suite, all cases passed. | go, jest, pytest, rspec, vitest, playwright |
| lint | Static analysis returned clean. | eslint, golangci-lint, ruff, clippy |
| local-deploy | Brought the whole stack up locally, smoke checks passed. | compose, k3d, tilt |
| provenance | Signed SLSA-shaped envelope for a built artifact. | slsa, cosign, in-toto |
Custom predicates
You can name any predicate you want — security-review:manual, benchmark:criterion, contract-test:pact. The CLI validates the shape (namespace:tool), not the vocabulary. Use gridtrue predicate list to see every predicate your org has emitted so far.
bash
gridtrue predicate list
# build:go (34 attestations)
# test:go (29 attestations)
# lint:golangci (29 attestations)
# local-deploy:compose (12 attestations)
# security-review:manual (3 attestations)