# Open-Predicate Standardization

A short roadmap note: how the Probity predicate types — `security-verdict`
and `adversarial-execution-evidence` above all — become an **open standard the incumbent
admission controllers recognize natively**, so an enterprise's existing Kyverno /
sigstore policy-controller can demand and verify a Probity verdict without a single
Probity-authored component in the trust path.

This is the demand-pull other half of the admission bundle in
[`deploy/admission/`](../../deploy/admission/README.md): that bundle shows the
verdict is *already* enforceable today by an incumbent pointed at our public key;
this note is about making the predicate type a recognized member of the broader
in-toto / SLSA predicate ecosystem so recognition is the default, not a
per-deployment configuration.

## Why standardize the predicate type

What makes this durable is that the value lives in the **verifiable verdict an
existing admission controller can consume directly**, not in a gate we ship. That
value grows as the predicate type becomes something a tool recognizes out of the box:

- An admission controller, registry, or CI gate keys off `predicateType`. The more
  widely `https://in-toto.io/attestation/adversarial-execution-evidence/v0.7` is a
  *known* predicate type, the less configuration a consumer needs and the higher the cost
  of a competing, incompatible verdict schema.
- A stable, published predicate type with a published schema and a conformance
  suite is exactly the shape the in-toto attestation framework and the SLSA
  predicate conventions are built to register and route.

## What is already in place

| Requirement for a recognized open predicate | Status | Where |
|---|---|---|
| A **stable predicateType URL** under a controlled namespace | DONE | `https://getprobity.dev/predicate/v1/<name>` for the Probity-namespace types; the flagship evidence predicate is proposed under the in-toto namespace as `https://in-toto.io/attestation/adversarial-execution-evidence/v0.7` |
| A **published predicate schema** (machine-readable) | DONE | `spec/schemas/v1/adversarial-execution-evidence.schema.json` (draft 2020-12), the on-wire SSOT; prose in `spec/v1/adversarial-execution-evidence.md` |
| A **predicate-agnostic signing envelope** | DONE | `spec/v1/signing-envelope.md` — DSSE PAEv1 + ed25519 + RFC-7638 keyid |
| A **conformance suite** any tool can run offline | DONE | `spec/v1/conformance.json` + signed bundles; the `@probity/verify` package carries it (`packages/verify/`) |
| **Reject vectors** proving fail-closed behavior | DONE | `packages/verify/vectors/aee-v06/` (bare v0.7 in-toto statements — unknown predicateType, stripped catchPolicy, ...; inline-signed with an ephemeral key for the crypto rails) |
| A **binding chokepoint** mirrored across runtimes | DONE | `bindings.ts` (TS) + the Python verdict_bundle verifier + `deploy/admission/rego/probity_admission.rego` (rego) |
| A **discoverable verification-key endpoint** | SHIPPED (2026-06-29, DEC-20260630-001) | `https://getprobity.dev/.well-known/verification-keys` — served from `website/public/.well-known/verification-keys.json`; a `keyid`-resolving verifier fetches the public key (`427a1092…` → `probity-mcp.pub`) instead of pinning it inline, which is what an incumbent's "trusted issuer" configuration wants |
| An **admission-freshness field** (`issuedAt`) | SPECIFIED (2026-07-06) | OPTIONAL top-level `issuedAt` (RFC3339 UTC) in `spec/schemas/v1/adversarial-execution-evidence.schema.json` + `spec/v1/adversarial-execution-evidence.md`; the Kyverno freshness policy in `deploy/admission/kyverno/` gates on it (deny if older than the consumer's threshold, e.g. 168h) and fails closed while it is absent — the threshold is the consumer's policy, not part of the standard; producer emission is the remaining code change |

The format is therefore already an open standard in substance: vendor-neutral,
offline-verifiable against a *configurable* trust anchor (the envelope explicitly
forbids hardcoding `probity.pub` as the only acceptable key), with a published
schema and a runnable conformance suite.

## What native recognition still needs

Two items remain open, both process (the discoverable key endpoint and the `issuedAt`
freshness field, formerly listed here, have shipped / been specified — see the table
above; producer emission of `issuedAt` is the one remaining code change).

1. **Submit the predicate type to the in-toto / SLSA predicate registry.** in-toto
   maintains a list of known predicate types; SLSA references predicate
   conventions. `adversarial-execution-evidence` is authored FOR that namespace
   (`https://in-toto.io/attestation/adversarial-execution-evidence/v0.7`),
   positioned as the active-stimulus sibling to the passive `runtime-trace`
   family: bounded adversarial stimulus, per-attack-to-catch attribution, and a
   cryptographically committed coverage bound, with a fused `result` that is a
   deterministic, severity-independent, offline-recomputable reduction of the
   enclosed evidence (the in-toto `test-result` precedent) — deliberately NOT an
   SVR-class delegated policy decision. Register it (with links to the schema +
   conformance suite) so registry-aware tooling resolves the type without
   per-deployment config; the envelope IS DSSE with PAEv1.

2. **A neutral-governance signal.** Broad recognition benefits from genuine
   multi-vendor governance: a public
   `CHANGELOG`/versioning policy (the two-axis envelope-vs-predicate-schema split is
   already documented), an explicit deprecation policy, and an invitation for other
   producers to emit verdicts under their own keys (which the configurable trust
   root already permits). The format does not name or assume `probity.pub`; that
   neutrality is the credible-open-standard hook.

## Honesty / scope

- Standardizing the *predicate* does not standardize the *runtime*. The runtime
  that produces a sound verdict (the substrate, the corpus, the gate engine) stays
  proprietary; the open surface is the verdict shape and its offline-verify
  contract. A third party can verify a verdict's integrity, provenance, subject
  binding, and the offline-checkable bindings — it cannot, from the verdict alone,
  re-derive the producer or confirm the assessment taxonomy is complete (the
  verdict specs say this plainly).
- Registry submission is an external-party action with its own timeline; it is
  named here as roadmap, not as shipped. Both remaining items (registry filing,
  governance) are process; the filing mechanics and submission draft are prepared in
  `research/91-standards-filing-2026-07-06/`. Producer emission of the now-specified
  `issuedAt` field is a one-field code change.