Exercise and Completeness Evidence for Agent Protocol Verifier Results
draft-he-agentproto-verifier-evidence-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | James Siyuan He | ||
| Last updated | 2026-10-17 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-he-agentproto-verifier-evidence-00
Network Working Group J. S. He
Internet-Draft Independent
Intended status: Informational 17 October 2026
Expires: 20 April 2027
Exercise and Completeness Evidence for Agent Protocol Verifier Results
draft-he-agentproto-verifier-evidence-00
Abstract
A verifier result reports what a check returned. It does not report
whether the check could have returned anything else. A check that
inspects too narrow a set of fields, and a check whose rejecting
input has never occurred, both report the same accepting value as a
check that distinguishes, and a conformance matrix does not tell them
apart.
This document defines requirements for reporting whether a check has
been exercised into its rejecting outcome, and requirements for
results that claim completeness: that the records relied on were the
whole of some stated set. Those are two separate obligations. A
result must name the set it claims to have seen, and must not treat a
party with an interest in the answer as the only thing looking.
This document defines no wire format, encoding, token, claim
vocabulary, test harness, or registry. It does require a record to
identify certain facts, which is a constraint on what a record must
be able to express rather than on how it is written down. A profile
satisfying these requirements will need a place to put those facts.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 20 April 2027.
He Expires 20 April 2027 [Page 1]
Internet-Draft Verifier Exercise Evidence October 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
5. EXR-1: Exercised Rejection Path . . . . . . . . . . . . . . . 5
6. Outcome Vocabulary . . . . . . . . . . . . . . . . . . . . . 7
7. EXR-2: Reporting an Unexercised Check . . . . . . . . . . . . 8
8. CMP-1: Coverage Domain . . . . . . . . . . . . . . . . . . . 9
9. CMP-2: Material-Party Detection . . . . . . . . . . . . . . . 10
10. What These Requirements Do Not Establish . . . . . . . . . . 11
11. Relationship to Adjacent Work . . . . . . . . . . . . . . . . 11
12. Implementation Status . . . . . . . . . . . . . . . . . . . . 13
13. Security Considerations . . . . . . . . . . . . . . . . . . . 15
14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
16. Normative References . . . . . . . . . . . . . . . . . . . . 16
17. Informative References . . . . . . . . . . . . . . . . . . . 16
Appendix A. Negative Vectors . . . . . . . . . . . . . . . . . . 17
A.1. Check Comparing Too Little . . . . . . . . . . . . . . . 18
A.2. Constant Probe . . . . . . . . . . . . . . . . . . . . . 18
A.3. A Silent System Under a One-Sided Endpoint . . . . . . . 18
A.4. Withheld Record Under a Completeness Claim . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
He Expires 20 April 2027 [Page 2]
Internet-Draft Verifier Exercise Evidence October 2026
1. Introduction
Agent protocol work has converged on conformance matrices: a row per
security-relevant claim, recording which field carries it, which
party verifies it, and what the verifier returned. The value of such
a matrix rests on an assumption that is rarely stated, which is that
a row reporting an accepting outcome would have reported something
else had the protocol misbehaved.
That assumption fails in two ways, and both produce the same printed
result.
In the first, the check compares too little. It runs, it returns an
accepting outcome, and the difference it was written to detect is not
expressible in what it reads. Increasing the number of observations
does not help, because every observation is drawn from the same blind
region.
In the second, the check reads the right material but the rejecting
input has never occurred. The rejection path is written down and may
be correct, but nothing has driven the check into it, so its
accepting results carry no information about what it would do with a
rejecting input.
Neither failure is addressed by the presence of negative test
vectors. A suite can contain many and still contain checks whose
rejecting outcome has never occurred on the record. A vector's
existence is not its execution, and a matrix that records outcomes
does not record which outcomes were reachable.
The interoperability problem is not that checks differ between
implementations. It is that two implementations can publish the same
conformance row, with the same accepting outcome, where one check
would have rejected a malformed input and the other could not have.
A relying party comparing candidate protocols, or composing across
administrative domains, cannot tell those apart from what is
published, so rows that are not comparable are compared anyway. What
follows is a reporting requirement aimed at that. It does not
prescribe test methodology, coverage arithmetic, or the correctness
of any protocol.
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
He Expires 20 April 2027 [Page 3]
Internet-Draft Verifier Exercise Evidence October 2026
3. Terminology
check: A procedure that returns one of an enumerated set of outcomes
for a given input.
rejection path: The condition, stated by the specification or
profile, under which a check returns an outcome classified as
rejecting. An outcome classified as neither accepting nor
rejecting is not a rejection path.
exercised: An input was supplied that produced the outcome in
question, and both the input and the outcome are identified in the
record.
discriminating pair: Two populations supplied together with the
outcome expected on each stated in advance, one accepting and one
rejecting, used to detect a check that cannot tell them apart.
Which population is expected to reject depends on what the check
asserts, and is stated by the profile rather than implied by the
labels.
coverage domain: The set of records over which a completeness claim
is asserted.
material party: A party whose conduct or assertion is at issue in
the claim a result supports. The term is taken from
[I-D.wadkins-agentproto-action-determinability], where it
qualifies a claimed transition. It is applied here to the claim a
verifier result supports; the test is unchanged and only the
object differs.
4. Problem Statement
The instances below are why the author noticed the problem. They are
not offered as a survey, a rate, or evidence that the failure is
widespread, and no requirement in this document rests on them. Each
is in a public repository [MP] so that a reader can check the
characterisation against the artifact rather than take it on trust.
Instances known to the author that are not public are omitted,
because an unpublished instance is author testimony.
A tightness check reported 4,638 of 4,638 from a computation that
never constructed a second world. The quantity it reported could not
have come out otherwise, and the ratio was recorded as though it were
a measurement.
He Expires 20 April 2027 [Page 4]
Internet-Draft Verifier Exercise Evidence October 2026
A registered endpoint set a 95 percent recall target on a two-arm
comparison in which both arms run the identical scanner. Recall is
therefore equal by construction, and was measured equal to the digit
on both corpora. The endpoint was retired and re-scoped to an
invariant that can fail: if the arms ever stop sharing a scanner, the
comparison silently stops being a comparison.
A positive test case was found to be an identity. Its verdict is a
function of a multiset that the transformation under test preserves,
so the case cannot fail under the intended reading and its zero is
not evidence about the schema. This was published as a correction to
two earlier findings by the same author, and the neighbouring cases
that do carry information were identified at the same time.
A record-only rule accepted 642 of 642 records written over six weeks
by a production job-control system. The rule is not inaccurate; it
is non-falsifiable, because the condition it was written to detect is
not expressible in the fields it reads. A second rule, evaluated on
the same corpora, found the condition absent in 284 of 284 cases
where it could be checked.
These differ in mechanism and are identical on the page. None was
found by reading the check. Each was found by asking what input
would produce the other outcome, and then looking in the record for
that input.
The coverage domain of this evidence is one research programme, and
the instances were selected from its records by the author of this
document. CMP-1 makes that limited domain explicit; under CMP-2 the
author's selection supplies no independently appraised basis for
excluding omission. It establishes that these failures occur and are
recognisable; it does not establish how often they occur, or that
this programme is representative. Nothing below depends on the rate.
A related observation, because it bears on Section 7: a scoring
endpoint that counts only incorrect confirmations is optimised by a
system that never confirms anything. Appendix A records a
measurement. The silent system scores perfectly on such an endpoint
while producing no useful output.
5. EXR-1: Exercised Rejection Path
A specification or profile claiming conformance to EXR-1 and
permitting a check to be reported as implemented under its exercise-
evidence requirement MUST require that the check's stated rejection
path has been exercised by an input that produced the rejecting
outcome, and that the input and the resulting outcome are identified
in the record.
He Expires 20 April 2027 [Page 5]
Internet-Draft Verifier Exercise Evidence October 2026
A check whose outcomes have only ever held one value MUST NOT be
reported as satisfying this exercise-evidence requirement,
irrespective of the number of observations.
The classification MUST be computable from the record alone. Two
evaluators holding the same record and the same profile that reach
different classifications indicate an underspecified record rather
than a disagreement to be settled by judgement, and the profile MUST
state the form in which an exercising input and its outcome are
identified.
The obligation is per check. A suite-level statement that negative
vectors exist does not satisfy EXR-1 for any individual check,
because the property EXR-1 requires is a property of the check.
Where a check states more than one rejection path, EXR-1 applies to
each separately. Exercising one path establishes nothing about the
others, and a report that does not say which paths were exercised
does not satisfy this requirement for any of them.
Accepting and rejecting do not exhaust the outcomes a check may
return. A check may report that the record could not settle the
question, which is neither. Where a check has such an outcome the
profile MUST classify each outcome as accepting, rejecting, or
neither, and MUST do so before the check is exercised. An outcome
classified as neither is exercised in its own right: it is exercised
when an input has produced it and some other input has produced a
different outcome. CMP-2 below returns such an outcome and is
subject to this paragraph.
EXR-1 does not grade an exercising input by who supplied it. An
input supplied by the party reporting the result can satisfy EXR-1.
For a separate completeness claim relying on that input, its party-
controlled provenance does not by itself establish the independent
omission-detection basis required by CMP-2. The record MUST identify
who supplied each exercising input, and MUST permit a later reader to
establish that the input preceded the report relying on it. Co-
presence in one record does not establish that order.
An exercising input establishes the property only for the revision of
the check it was supplied to. Where the check changes, prior
exercise MUST NOT be carried forward, and the record MUST identify
the revision each exercising input was supplied to. A check whose
rejecting outcome was last observed under an earlier revision is
unexercised for the current one.
He Expires 20 April 2027 [Page 6]
Internet-Draft Verifier Exercise Evidence October 2026
For each declared rejection path, the exercise record MUST identify a
discriminating pair under the same check revision: one population
expected to accept and one expected to reject. The profile MUST
state those expectations before the check is run, and the check MUST
return the stated outcome on each. A check that returns the same
outcome on both has not satisfied this requirement, whichever outcome
it returned. The expected outcomes are not implied by which
population is called positive: a check asserting that a defect is
absent rejects where the defect is present, and a check asserting
that a property holds rejects where it does not.
6. Outcome Vocabulary
An evaluator reporting the result of a check MUST distinguish at
least the following four outcomes, and MUST NOT collapse any of them
into another:
verified The check ran over the evidence it names and the condition
held.
violation The check ran over the evidence it names and the condition
did not hold. This is the only outcome that condemns, and it is
available only where the check actually reached an answer.
unverifiable The check was attempted and could not reach an answer,
because required evidence was unavailable, a resolver did not
respond, or no resolver was configured. A claim whose source has
become unreachable is not a claim that failed.
not-evaluated The check was not reached, or the record names nothing
for it to range over. No check verdict was reached. An explicit
not-evaluated record identifies the unattempted check and the
reason.
The separation of unverifiable from violation is the load-bearing
one. Collapsing it in one direction manufactures false confidence
and in the other manufactures false alarms, and the party making a
claim controls which way the collapse runs: producing evidence that
cannot be checked is cheap, so an evaluator that treats unreachable
as refuted can be driven, and one that treats it as satisfied can be
starved. A profile MAY define finer outcome values, but MUST NOT
collapse these four.
The evaluator MUST distinguish a known absence of a required verifier
capability from a supported check that was not attempted. The record
MUST identify the capability or evaluation-plan evidence supporting
that diagnosis. This distinction MAY be represented by separate
outcome values or by mandatory structured diagnostics; it does not
He Expires 20 April 2027 [Page 7]
Internet-Draft Verifier Exercise Evidence October 2026
require a fifth native outcome token. Where the record does not
establish which condition applies, the evaluator MUST preserve that
uncertainty and MUST NOT infer either condition from a broad outcome
label alone. Missing resolver configuration, for example, does not
by itself establish that the verifier revision lacks resolver
capability. A profile mapping these results into another
specification's outcome vocabulary MUST retain its required
capability and attempt context rather than treating a bare
unverifiable value as proof of unsupported.
An outcome of unverifiable or not-evaluated MUST NOT contribute to a
coverage figure as though it were verified, and MUST NOT be
relabelled to improve one. This is the same prohibition
[I-D.bu-agentproto-security-principal-binding] places on relabelling
a not-run scenario as not-applicable.
7. EXR-2: Reporting an Unexercised Check
Where a check has not been exercised into its rejecting outcome, the
evaluator MUST NOT report that check as satisfying this document's
implemented exercise-evidence condition. It MAY use implemented-
unexercised as an EXR exercise annotation for a check with
implementation evidence under another profile, identifying the
rejection path for which no exercising input appears in the record.
That annotation is not an upgrade to the other profile's
implementation status.
A record produced to satisfy EXR-1 or EXR-2 is orthogonal to any
implementation-status field a profile already maintains. It MUST NOT
raise such a field, and a rejection path with no exercising input
MUST NOT be counted as measured coverage on the strength of the
record's existence. Where a profile maintains per-scenario
dispositions of its own, those dispositions and the per-input
outcomes required here are separate records of separate properties
and MUST NOT be merged into one figure.
An explicit weaker result is required rather than silence. Without a
name for it, a report can conceal the difference between a check
whose rejection path was exercised and one whose rejection path
remains unexercised.
An absent declaration MUST NOT be treated as a statement that no
rejection path exists. A specification that means a check has no
reachable rejecting outcome MUST state that, because it is a strong
claim about the check and is itself reviewable.
He Expires 20 April 2027 [Page 8]
Internet-Draft Verifier Exercise Evidence October 2026
implemented-unexercised does not by itself distinguish a check whose
rejecting outcome is unreachable for every input the verifier can
receive from one that has simply not received such an input. These
are different facts: the first is a property of the check, the second
of the sample. Where a profile can tell them apart it SHOULD report
which, and where it cannot it MUST NOT imply either.
A report of implemented-unexercised SHOULD carry a machine-readable
reason identifying the unexercised rejection path, so that two
implementations can compare results without reading prose. A single
token is not sufficient for cross-implementation diagnosis.
implemented-unexercised is not a failure grade. It reports that the
record does not establish that the check can reject, which is a
different fact from a check that ran and rejected.
A check whose rejecting condition is not expected to arise in normal
operation will hold implemented-unexercised indefinitely, and that is
the intended reading rather than a defect in the requirement. A
safety check that has never fired has not been shown to work; saying
so is the point. Where a profile can construct a synthetic input
that drives such a check into its rejecting outcome, EXR-1 is
satisfied by that input, and Section 14 permits a synthetic input for
this purpose.
8. CMP-1: Coverage Domain
A result claiming completeness over a stated coverage domain,
including a claim of independent observation of that complete domain,
MUST name that domain and the mechanism by which an omission within
it would be revealed. Independently checking one identified artifact
does not by itself claim completeness of a wider event or artifact
history.
A result that names neither does not support a completeness claim,
whatever the number of individually valid artifacts it presents.
Validity of disclosed artifacts is a property of those artifacts and
carries no information about records that were not disclosed.
A record may be absent for more than one reason: it was never
created, it was created but not observed, it was observed but not
recorded, or it was recorded and later removed. CMP-1 requires the
revealing mechanism to be named; it does not require that mechanism
to separate these causes. A profile whose mechanism can separate
them SHOULD say which it separates, because a relying party that must
act on the difference cannot infer it from the fact of absence.
He Expires 20 April 2027 [Page 9]
Internet-Draft Verifier Exercise Evidence October 2026
9. CMP-2: Material-Party Detection
Where the mechanism that would reveal an omission is operated by a
material party, or where its inputs are selected by a material party,
that mechanism alone is same-party regardless of the number of
independently valid artifacts presented. Unless an independent basis
has been appraised for this result as required below, the evaluator
MUST NOT report the completeness claim as verified. It MUST report
the completeness appraisal using the outcome vocabulary of Section 6
and record why it remains unestablished. Lack of an independent
omission-detection basis alone MUST NOT be reported as a violation.
A violation of a separately completed predicate check remains
reportable.
The distinction a relying party acts on is not settled versus
unsettled. A predicate reported as a violation asserts that its
check ran and the condition did not hold; for example, two
authenticated occurrences can refute an at-most-once predicate even
if completeness of the wider record set remains unknown. A
completeness appraisal reported as unverifiable asserts that the
available record cannot settle whether an omission remains. These
are separate checks and verdicts.
CMP-2 is bounded by what counts as an independent basis. A profile
with no such basis may name a domain and mechanism under CMP-1 but
cannot establish completeness under CMP-2. An independent basis is a
constraint on the record set that was not under the sole control of a
material party when the records were produced: an append-only log
whose inclusion is witnessed by parties not material to the claim; a
counterparty-held record that must reconcile with the disclosed set;
or a substrate that cannot produce the effect without emitting a
record a material party cannot suppress. Naming one is necessary but
does not establish that it constrained the record set for this
result.
Before reporting the completeness claim as verified, the deciding
verifier MUST establish, under the named profile, the independent
basis's authority, its binding to this result and coverage domain,
the extent of its coverage, and the relevant time. The result MUST
retain evidence of those checks. Naming a basis or describing a
future check does not satisfy this condition. A basis that was
authoritative for a different scope, or in force at a different time,
has not been shown to bear on this result, and the completeness claim
remains unestablished.
The available exercise record MUST demonstrate, under the same check
revision and expectations stated in advance, both a result whose
completeness appraisal remains unestablished and one whose
He Expires 20 April 2027 [Page 10]
Internet-Draft Verifier Exercise Evidence October 2026
completeness is verified after the required independent appraisal. A
record containing only the former does not satisfy this exercise
condition; it does not by itself establish that the latter outcome is
unreachable.
10. What These Requirements Do Not Establish
These requirements separate claims. They do not make claims true.
An exercised check is not a correct check. Exercising a rejection
path establishes that the check can return its other outcome for some
input. It does not establish that the rejection path is the right
one, that its condition is correctly specified, or that the accepting
outcomes were correct.
An exercised rejection path establishes nothing about paths that were
not exercised. EXR-1 is a floor and is not a coverage claim.
implemented-unexercised is not evidence of a defect. A check may be
correct, well specified, and simply never driven into its rejecting
condition.
CMP-2 does not establish that an omission occurred. It establishes
that the record as presented cannot exclude one. A profile that
supplies an independent basis for excluding omission can establish
the completeness claim only when the deciding verifier appraises that
basis for this result. The disclosed artifacts need not change.
These requirements apply to themselves. A check implementing EXR-1
is subject to EXR-1, and a report of CMP-2 is subject to CMP-2. The
regress terminates rather than continuing without limit, because
exercising a check is itself the discriminating pair the requirement
asks for: a checker that classifies a discriminating check and a non-
discriminating one identically has been shown unexercised by that
pair, and no further level is needed. Appendix A exercises the
checker this way.
None of these requirements reaches the correctness of an underlying
protocol, the honesty of any party, or the security of any
deployment.
11. Relationship to Adjacent Work
[I-D.wadkins-agentproto-action-determinability] states in DET-4 that
presentation of individually valid evidence must not by itself be
treated as proof that all material evidence has been presented.
CMP-1 and CMP-2 narrow that concern to the detecting mechanism
itself.
He Expires 20 April 2027 [Page 11]
Internet-Draft Verifier Exercise Evidence October 2026
[I-D.bu-agentproto-security-principal-binding] Section 14 already
requires that a row not be reported implemented merely because a
carrier is emitted or a positive exchange completes: the evidence
must show the stated verifier decision and at least one security-
relevant rejection path, and Section 11 draws the same distinction
against a happy-path exchange. That floor is established there. It
is not introduced here, and a row lacking such evidence is already
not fully implemented under that definition.
Section 33 of the same document lists as open issues which negative
test cases authors should provide, whether a row may claim
implemented status without a public or reviewable negative test
exercising the stated rejection path, and when same-party evidence
may support a row claiming independent observation. EXR-1 and EXR-2
are addressed to the first two. What they add to the existing floor
is that the exercising input be pinned to a revision, that a
discriminating pair be exhibited rather than a single rejecting
input, and that the record name the outcome observed for each
declared rejection path. A row satisfying Section 14 may still carry
no such record.
CMP-1 and CMP-2 address the completeness and omission subcase of the
third open issue. They do not resolve that issue for every kind of
row, and independently checking one scoped observation is not the
same as establishing completeness over a domain.
That document's rules governing coverage denominators, and its
prohibition on relabelling a not-run scenario as not-applicable to
improve a denominator, are complementary and are deliberately not
restated here. That document's implementation-status vocabulary is a
closed set of implemented, partial, none, and external. implemented-
unexercised is not proposed as a fifth member of it: it reports a
different property on a different axis. A row may satisfy Principal
Binding's minimum rejection-evidence requirement while lacking the
stronger EXR record for every declared rejection path or lacking
EXR's revision-pinned discriminating-pair evidence. Those gaps
remain explicit; an EXR record does not raise Principal Binding
implementation status. A profile using both states them separately.
[I-D.bradleyb-audit-decision-records] distinguishes correspondence,
where two records agree about what happened, from precedence, where
the order of decision and effect is established. The present
document addresses the same shape one level down, where a check's
outcome is taken to establish a property the check was never shown
able to contradict.
He Expires 20 April 2027 [Page 12]
Internet-Draft Verifier Exercise Evidence October 2026
[IA9-OVERLAY] argues that non-repudiation over a self-asserted
subject lacks a testable assertion about actor identity. That is an
adjacent warning about the evidentiary force of a control, not an
implementation or derivation of EXR-1: this document asks whether a
stated rejection path has actually been exercised. A check that
could not run is also kept distinct from one that ran and established
a violation in Section 6.
[I-D.schrock-ep-bounded-capability-receipts] requires, in its
treatment of action scope, that the basis for a transitivity claim be
classified as definition-derived, mechanically-checkable, or
asserted, and states that an asserted claim is profile-author
testimony rather than a demonstrated algebraic property. EXR-1 makes
the same separation for a check's rejection path. That section also
requires that missing components not be treated as successful
comparisons, and that an undecided comparison state why the deciding
verifier could not establish a result, distinguishing the case where
the governing profile supplies no applicable relation from the case
where the exact profile definition was unavailable to that verifier.
EXR-2 and CMP-2 apply the same discipline to the two cases treated
here: a result that could not be established is reported as such, and
is not merged with a result that was established and negative.
[I-D.laurie-tmif] defines falsifiability as the design property
ensuring that subversion of a system's stated claims carries a high
risk of independent discovery, and specifies metadata by which an
evaluator assesses that property. That is falsifiability of the
claims a system makes about itself. The present document concerns a
different object: whether the check an evaluator applies has been
shown able to return its rejecting outcome at all. The two compose
rather than overlap. A system whose claims are highly falsifiable,
assessed by a check that has never rejected anything, is not thereby
verified, and EXR-2 requires that to be visible in the report.
12. Implementation Status
This section records the status of implementations known to the
author at the time of writing, per [RFC7942]. It is intended to be
removed before publication as an RFC.
The outcome vocabulary of Section 6 draws on, but is not a one-to-one
copy of, the public implementation in [MP] at commit
b4ee46924ebe8fd0bee38b4986a01229e859764b. Its dereference layer
separates verified, absent, unverifiable, and no_reference. A
resolver that is offline, rate-limited, or not configured has not
shown a reference to be absent; only a completed negative lookup can
do that. A root naming no reference produces no dereference verdict.
A separate mandatory-reference presence check may establish a
He Expires 20 April 2027 [Page 13]
Internet-Draft Verifier Exercise Evidence October 2026
violation from that absence, while an optional-reference profile
would not. The report and policy layers carry these facts into
further dispositions; their labels are not interchangeable with
either the four values in Section 6 or another profile's
implementation statuses. The pinned implementation does not yet
establish the mandatory capability-versus-skipped diagnostic
distinction specified here. Its V4 weaker supported claim is
reported as downgraded in that layer, not as one of the four check
outcomes.
A worked case for CMP-1 and CMP-2. A verdict is sought over a set of
records in a profile that requires each root to name a reference.
Some references resolve, one resolver is unreachable, and one root
names no reference. Reporting the resolved subset as a completeness
figure would claim a domain that was never covered. The unreachable
dereference is unverifiable rather than a violation. For the
unreferenced root, the dereference check was not attempted and its
not-evaluated record names the missing-reference reason. Separately,
the mandatory-reference presence check completes and reports a
violation. If references were optional, their absence would not
violate that presence rule but would still provide no reference
coverage or completeness assurance. CMP-1 names the domain and
omission-detection mechanism; CMP-2 does not permit a verified
completeness claim based solely on a material party's mechanism. An
independently appraised basis would be needed for that claim. These
check verdicts and the completeness appraisal remain separate; one
unsettled label cannot express all of them.
A discipline close to EXR-1 is in use in the public repository [MP],
where a declaration must name a contrasting population in which the
declared property is absent, and the probe must report below the
declared minimum on that population. A probe that cannot tell the
two populations apart is refused as unfalsifiable, and that refusal
is reported before any other verdict, on the stated grounds that if
the probe cannot fail the other result is meaningless in both
directions. A probe that reports a constant is refused on a
population that genuinely has the property. That code predates this
document and was not written as a conformance implementation of EXR-
1; it is offered as evidence that the requirement is implementable
and has been lived with, not that it has been implemented as
specified here.
The same repository refuses a registration that omits the declaration
entirely, on the grounds stated in EXR-2 that an absent declaration
is not consent.
He Expires 20 April 2027 [Page 14]
Internet-Draft Verifier Exercise Evidence October 2026
The vectors in Appendix A are published in executable form at the
pinned commit above, with a test suite of twenty-eight cases. Three
of those vectors are constructed fixtures written for this document
rather than observations of a deployed system; they show that the
requirements have content and that a check can fail them, not that
any particular check does. The fourth reads a frozen artifact from
an earlier experiment and pins its digest.
Songbo Bu replayed the author's source and fixtures at the pinned
commit: twenty-eight verifier-evidence tests and thirty-eight related
dereference, warrant, resolver, and policy tests passed. This is a
bounded source replay, not a second implementation or a conformance
result. No independently implemented CMP-1 or CMP-2 appraisal has
been verified, and no interoperability between independent
implementations is claimed for any requirement in this document.
One consequence is worth stating rather than leaving to be derived.
A profile with no independent omission-detection basis can identify
its coverage domain but cannot demonstrate the accepting side of
CMP-2 for a completeness claim. EXR-1 then forbids reporting that
check as implemented on the strength of only its unestablished
outcomes. The worked case above illustrates the reporting
distinction; it is not a claim that CMP-1 or CMP-2 has been
implemented as specified here.
13. Security Considerations
The failure mode these requirements address is a system that appears
verified. An unexercised check is worse for a relying party than an
absent one, because it occupies the position in a matrix where a
reviewer would otherwise notice that nothing is checking the claim.
An adversary who knows which checks are unexercised knows where a
conformance matrix will not look. Because the property is visible
from a published matrix and published vectors, and because a check
that compares too little is often evident to an implementer, this
information may be more available to an adversary than to a reviewer.
Reporting implemented-unexercised discloses that a rejection path is
untested, and profiles should weigh that. The alternative is that
the same fact remains true and is not written down, which does not
reduce the exposure and removes the relying party's ability to
account for it.
He Expires 20 April 2027 [Page 15]
Internet-Draft Verifier Exercise Evidence October 2026
14. Privacy Considerations
These requirements concern verifier results and test inputs. Where
an exercising input is drawn from production data, publishing it to
satisfy EXR-1 may disclose personal data. A profile SHOULD permit a
synthetic exercising input where the rejecting outcome does not
depend on the provenance of the input.
15. IANA Considerations
This document has no IANA actions.
16. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
17. Informative References
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[I-D.wadkins-agentproto-action-determinability]
Wadkins, D., "Independent Determinability of Agent
Actions", Work in Progress, Internet-Draft, draft-wadkins-
agentproto-action-determinability-00, September 2026,
<https://datatracker.ietf.org/doc/draft-wadkins-
agentproto-action-determinability/>.
[I-D.bu-agentproto-security-principal-binding]
Bu, S., "Security Principal and Verifier Binding for Agent
Communication Protocols", Work in Progress, Internet-
Draft, draft-bu-agentproto-security-principal-binding-08,
October 2026, <https://datatracker.ietf.org/doc/draft-bu-
agentproto-security-principal-binding/>.
He Expires 20 April 2027 [Page 16]
Internet-Draft Verifier Exercise Evidence October 2026
[I-D.bradleyb-audit-decision-records]
B, B., "Signed Decision Records for Agent Authorization:
Disclosures, Entry Emission, and Ordering Evidence", Work
in Progress, Internet-Draft, draft-bradleyb-audit-
decision-records-00, September 2026,
<https://datatracker.ietf.org/doc/draft-bradleyb-audit-
decision-records/>.
[IA9-OVERLAY]
Murali, T. and B. B, "IA-9 Overlay: Identification and
Authentication of Non-Person Actors in AI Systems",
DOI 10.5281/zenodo.22031159, 20 August 2026,
<https://doi.org/10.5281/zenodo.22031159>.
[I-D.schrock-ep-bounded-capability-receipts]
Schrock, I., "Bounded Capability Receipts and Durable
Spend Control for Agent Actions", Work in Progress,
Internet-Draft, draft-schrock-ep-bounded-capability-
receipts-06, September 2026,
<https://datatracker.ietf.org/doc/draft-schrock-ep-
bounded-capability-receipts/>.
[I-D.laurie-tmif]
Laurie, B., Santoro, T., Anthonysamy, P., and S. de Haas,
"A Standard for Claiming Transparency and Falsifiability",
Work in Progress, Internet-Draft, draft-laurie-tmif-02,
September 2026,
<https://datatracker.ietf.org/doc/draft-laurie-tmif/>.
[MP] Silentpartnercoding, "Minority Prophet: evidence and
registration discipline for knowledge-ledger experiments",
2026,
<https://github.com/Silentpartnercoding/minority-prophet>.
Appendix A. Negative Vectors
These vectors are stated so that a reader can construct them
independently. They are illustrative and are not a normative test
suite. An executable form, with a deterministic machine-readable
result and its source pinned by digest, is published at [MP] under
research/verifier-evidence. Each vector there supplies a positive
population and its contrasting population and runs both a check that
cannot distinguish them and one that can; the pair is the evidence,
not either half.
He Expires 20 April 2027 [Page 17]
Internet-Draft Verifier Exercise Evidence October 2026
A.1. Check Comparing Too Little
Construct a check whose accepting condition is evaluated over a
proper subset of the fields in which the defect can appear. Supply a
discriminating pair: one population containing the defect, for which
the rejecting outcome is expected, and one without it, for which the
accepting outcome is expected.
Expected under EXR-1: the check returns the accepting outcome on both
populations, so no exercising input for the rejection path exists and
the check reports implemented-unexercised. A check reading the full
field set returns the expected outcome on each and is exercised.
A.2. Constant Probe
Supply a probe that reports a fixed value satisfying the declared
minimum, and evaluate it against a contrasting population in which
the declared property is absent.
Expected: the probe reports the same value on both populations and is
refused as unfalsifiable before any other verdict is reported.
A.3. A Silent System Under a One-Sided Endpoint
Score three systems against one frozen fixture on an endpoint
counting only incorrect confirmations, then on a two-sided endpoint
adding a cost for indefinite non-confirmation. Lower is better.
+=========================+===========+============+===========+
| system | one-sided | delay cost | two-sided |
+=========================+===========+============+===========+
| silent, never confirms | 0.000 | 1.000 | 1.000 |
+-------------------------+-----------+------------+-----------+
| count-based, confirms | 1.000 | 0.033 | 1.033 |
| on 3 or more reports | | | |
+-------------------------+-----------+------------+-----------+
| origin-aware, 2 or more | 0.000 | 0.533 | 0.533 |
| independent origins | | | |
+-------------------------+-----------+------------+-----------+
Table 1
The silent system attains the best available one-sided score, tying
with the origin-aware system, so a one-sided endpoint cannot
distinguish a system that never confirms from one that confirms
correctly. Under the two-sided score the silent system no longer
ties for best and is beaten by the origin-aware system. It is not
last: the count-based system scores worse, having confirmed every
He Expires 20 April 2027 [Page 18]
Internet-Draft Verifier Exercise Evidence October 2026
false event. The point of the second term is that it removes silence
from the winning set, not that it makes silence the worst available
strategy.
A.4. Withheld Record Under a Completeness Claim
Where a claim asserts that an event occurred at most once, withhold
one of two occurrences from disclosure while leaving every disclosed
signature and inclusion proof valid.
Expected under CMP-1 and CMP-2: unless the deciding verifier
appraises an independent basis for excluding the omission in this
result, the evaluator reports the completeness claim as
unestablished. Reporting it as satisfied is the defect. From the
evaluator's disclosed record, reporting it as failed is also
incorrect, because that record does not establish the omission.
This vector is due to Iman Schrock.
Acknowledgments
Bradley B drew attention to keeping a check that could not run
distinct from a check that ran and failed. His published IA-9
analysis is cited for the separate problem of an unauthenticated
subject in a control's evidence.
Iman Schrock contributed the withheld-record vector in Appendix A and
reviewed its attribution and outcome wording. The coverage
requirements were developed separately.
Songbo Bu raised the related questions in Principal Binding
Section 33, reviewed this document's outcome and evidence boundaries,
and replayed the author's pinned source and fixtures as described in
Section 12.
Henri Sirkkavaara stated the reproduction bar under which a candidate
counts as demonstrated only when a party controlling neither end
reaches the same verdict using an implementation sharing no code with
the proposer.
Acknowledgment does not imply endorsement of this document.
Author's Address
James Siyuan He
Independent
Email: jsiyuanhe@gmail.com
He Expires 20 April 2027 [Page 19]