verification.md: format-versioning and verifier-compatibility obligations (evidence outlives verifiers)

[lywinged]

Spec gap. Compliance evidence is verified years after issuance — the artifact routinely outlives the verifier build — and the profile/enum surface is already evolving pre-1.0 (#114 proposes a new profile URI precisely to avoid breaking existing verifiers). But verification.md currently has no normative statement of what a verifier must do about version skew. Without one, every future revision risks silently orphaning existing evidence — or worse, verifiers "helpfully" accepting artifacts under semantics they don't actually implement.

Production context: in our per-action receipt format the hash-computation order is load-bearing — any change orphans every previously issued artifact. What held up operationally: a mandatory format-version field, plus a verifier obligated to check every version it claims to support and to say which version it verified under in its output.

Proposed obligations for verification.md:

1. Every record/receipt carries an explicit format/profile version (the profile-URI direction in Widen the per-call decision enum under a new profile version, not in 1.0 #114 already implies this — this makes it a verifier obligation, not just an emitter convention).
2. A conformant verifier declares the set of versions it supports and MUST refuse versions outside that set — refuse, not best-effort.
3. The verification statement includes the version under which verification ran.
4. Any downgrade/fallback behavior MUST be disclosed in the statement; silent fallback is non-conformant.

Conformance vectors for trace-tests:

• unknown-version artifact → must refuse (fail-open here is the dangerous default)
• known-version artifact → verified under correct semantics, version echoed in the statement
• downgrade-with-disclosure → conformant
• silent downgrade → must fail conformance

Happy to draft the section plus the vectors — this composes with the verifier-obligations ADR discussed in #66 and the offline verification statement discussed in #76.

[github-actions]

❔ Contributor Check: UNKNOWN

Check	Result
Profile	UNKNOWN
Credential	LOW
Overall	UNKNOWN

Automated check by AgenTrust Contributor Check.

[imran-siddique]

Thanks for this, and for the detail in the write-up.

A process note on format-versioning and verifier-compatibility obligations when evidence outlives its verifiers.

Normative spec text, meaning anything carrying an uppercase RFC 2119 keyword, needs an organizational sponsor accountable for the requirement. That is a provenance rule about who stands behind a requirement others implement against, not a judgment on the proposal or on you. Anyone may propose a normative change, and where a proposal is accepted without a sponsor, a maintainer carries the PR.

So this stays open. I have labeled it policy: take-internal, which means the substance goes through review here and a maintainer carries any resulting spec change. This issue gets updated with the outcome either way.

Two things are unaffected by the rule and are welcome directly: non-normative work such as documentation, informative crosswalks, examples and test vectors, and implementation work in the SDKs and tooling.

The rule is in CONTRIBUTING under Spec changes, pointing at GOVERNANCE.md#who-may-author-normative-text. If that was not easy to find before you put this work in, say so and I will make it more prominent.