Exercise and Completeness Evidence for Agent Protocol Verifier Results
draft-he-agentproto-verifier-evidence-01
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-18 | ||
| 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-01
Network Working Group J. S. He
Internet-Draft Independent
Intended status: Informational 18 October 2026
Expires: 21 April 2027
Exercise and Completeness Evidence for Agent Protocol Verifier Results
draft-he-agentproto-verifier-evidence-01
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 or
unverifiable 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 declared rejecting and unverifiable outcomes,
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 21 April 2027.
He Expires 21 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 . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
5. EXR-1: Exercised Rejection and Unverifiable Paths . . . . . . 6
6. Outcome Vocabulary . . . . . . . . . . . . . . . . . . . . . 8
7. EXR-2: Reporting an Unexercised Check . . . . . . . . . . . . 9
8. CMP-1: Coverage Domain . . . . . . . . . . . . . . . . . . . 10
9. CMP-2: Material-Party Detection . . . . . . . . . . . . . . . 11
10. What These Requirements Do Not Establish . . . . . . . . . . 12
11. Scope Relative to Agent Protocol and Audit Work . . . . . . . 13
12. Relationship to Adjacent Work . . . . . . . . . . . . . . . . 13
13. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
14. Security Considerations . . . . . . . . . . . . . . . . . . . 18
15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
17. Normative References . . . . . . . . . . . . . . . . . . . . 18
18. Informative References . . . . . . . . . . . . . . . . . . . 19
Appendix A. Negative Vectors . . . . . . . . . . . . . . . . . . 21
A.1. Check Comparing Too Little . . . . . . . . . . . . . . . 21
A.2. Constant Probe . . . . . . . . . . . . . . . . . . . . . 21
A.3. A Silent System Under a One-Sided Endpoint . . . . . . . 21
A.4. Withheld Record Under a Completeness Claim . . . . . . . 22
A.5. One Outcome Token, Two Rules . . . . . . . . . . . . . . 22
A.6. Path Shadowed by an Earlier Rule . . . . . . . . . . . . 23
Appendix B. Changes from -00 . . . . . . . . . . . . . . . . . . 23
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
He Expires 21 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 or the evidence could not settle the
question.
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 an input
leading to a rejecting or unverifiable outcome has never occurred.
The 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 that input.
Neither failure is addressed by the presence of negative test
vectors. A suite can contain many and still contain checks whose
rejecting or unverifiable 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.
He Expires 21 April 2027 [Page 3]
Internet-Draft Verifier Exercise Evidence October 2026
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.
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.
neither path: The condition, stated by the specification or profile,
under which a check returns an outcome classified as neither
accepting nor rejecting, including a path to an unverifiable
outcome.
exercise path: A declared rejection path or neither path for which
the profile requires exercise evidence.
reachable-unexercised: An exercise path for which the defined input
domain contains a reaching input, but no identified input in the
exercise record produced the path's outcome under the current
check revision.
shadowed-unreachable: An exercise path that no input in the defined
input domain can reach under the current check revision because an
earlier rule or structural precondition necessarily returns first.
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 expected to accept
and one expected to produce the declared non-accepting outcome on
the exercise path, whether that outcome is rejecting or neither.
The pair is used to detect a check that cannot tell the
populations apart. Which population is expected to produce each
outcome depends on what the check asserts, and is stated by the
profile rather than implied by the labels.
He Expires 21 April 2027 [Page 4]
Internet-Draft Verifier Exercise Evidence October 2026
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.
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.
He Expires 21 April 2027 [Page 5]
Internet-Draft Verifier Exercise Evidence October 2026
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 and Unverifiable Paths
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 declared exercise
paths have each been exercised by an input that produced the path's
stated outcome, and that the input, the resulting outcome, and the
rule or condition reached are identified in the record.
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.
He Expires 21 April 2027 [Page 6]
Internet-Draft Verifier Exercise Evidence October 2026
Each exercise record MUST name a stable rule or condition identifier
from the governing specification or profile. An outcome token alone
does not identify the rule or condition that fired when more than one
condition produces that outcome. Where multiple conditions are
reached, the record MUST identify each and preserve the order needed
to reproduce the reported result.
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. Where a check
specifies paths to outcomes classified as neither, including
unverifiable, EXR-1 applies to each declared path in the same way: it
is exercised when an input has produced that outcome 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
non-accepting outcome was last observed under an earlier revision is
unexercised for the current one.
For each declared exercise path, the exercise record MUST identify a
discriminating pair under the same check revision: one population
expected to accept and one expected to produce the path's rejecting
or neither outcome. 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.
He Expires 21 April 2027 [Page 7]
Internet-Draft Verifier Exercise Evidence October 2026
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
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.
He Expires 21 April 2027 [Page 8]
Internet-Draft Verifier Exercise Evidence October 2026
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 a declared exercise-path
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
exercise 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 or neither path exists. A specification that means a check
has no reachable non-accepting outcome MUST state that, because it is
a strong claim about the check and is itself reviewable.
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.
He Expires 21 April 2027 [Page 9]
Internet-Draft Verifier Exercise Evidence October 2026
Where the profile establishes that an input in the defined domain can
reach the path, but the exercise record contains no such input, the
evaluator SHOULD report reachable-unexercised. Where the
specification's rule order and input-domain constraints establish
that an earlier rule necessarily returns first, the evaluator SHOULD
report shadowed-unreachable. Absence from a sample establishes
neither classification.
A shadowed-unreachable report MUST identify the shadowing rule and
the rule or condition that cannot be reached. It MUST NOT count the
path as exercised or as measured coverage. If the record cannot
distinguish reachability from absence of an exercising input, it MUST
retain the broader implemented-unexercised annotation.
A report of implemented-unexercised SHOULD carry a machine-readable
reason identifying the unexercised exercise 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 or unverifiable 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 15 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.
He Expires 21 April 2027 [Page 10]
Internet-Draft Verifier Exercise Evidence October 2026
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.
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
He Expires 21 April 2027 [Page 11]
Internet-Draft Verifier Exercise Evidence October 2026
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
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 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.
He Expires 21 April 2027 [Page 12]
Internet-Draft Verifier Exercise Evidence October 2026
11. Scope Relative to Agent Protocol and Audit Work
The protocol-facing obligation in this document is conditional.
Where an agent protocol, profile, or reference architecture relies on
or exposes a verifier result as evidence of coverage, it can require
the result to carry the exercise and completeness facts defined here.
A protocol that makes no such claim need not acquire an audit data
model merely because this document exists.
This document does not define an audit record, corpus-commitment
encoding, interaction-trace format, transport, or validation testbed.
Work concerned with how evidence records cross component or
administrative boundaries can define those mechanisms and use these
requirements as acceptance conditions. A protocol or architecture
document can state the dependency without defining the mechanism that
satisfies it.
This document does not assign either obligation to a working group
and does not claim adoption by AgentProto, AUDIT, or any other IETF
group. It states a separable requirements layer so that a group can
adopt, profile, reference, or decline it without treating the present
individual submission as a venue decision.
12. 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.
[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
He Expires 21 April 2027 [Page 13]
Internet-Draft Verifier Exercise Evidence October 2026
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.
[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.
He Expires 21 April 2027 [Page 14]
Internet-Draft Verifier Exercise Evidence October 2026
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.
13. 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
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
He Expires 21 April 2027 [Page 15]
Internet-Draft Verifier Exercise Evidence October 2026
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.
The original four 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. The two
additional vectors in this revision are prose vectors; they are not
part of that pinned executable suite and do not constitute
implementation evidence.
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.
He Expires 21 April 2027 [Page 16]
Internet-Draft Verifier Exercise Evidence October 2026
Lars Kersten Kroehl published a separately authored report reader at
commit 6d8ee54b01d20a819869ceb9fcea096d59251f8c [MOLTRUST-READER].
On 165 report objects the pinned reader produced 82 accept, 28
reject, and 55 cannot-tell results. Twenty-five of its rejections
agreed with the upstream expected verdict; four of those reached a
different requirement line than the member name suggested. The
published selection includes a corpus digest, covered-member list,
and selection rule, making the boundary of that selected run
inspectable. It does not establish that the named checkers ran or
that the supplied report objects describe genuine underlying
artifacts.
The present author reproduced that pinned run and published a bounded
audit at commit 635f3d57eb6f90fdf4c6945778020c34521be0a1
[MOLTRUST-AUDIT]. The package freezes 35 mutation scenarios,
including the baseline, and a separately written specification-only
reader. The latter rejects 34 cases and reports 131 as cannot-tell.
Ten cases rejected by that reader are cannot-tell under Kroehl's
documented refusal policy; case-by-case adjudication finds eight
explicit contradictions or omissions whose mandatory-rejection policy
is disputed and two cases underdetermined by the source text. The
audit does not promote those disagreements into reader errors. The
separately written reader shares the present author's project control
and is not a second external evidence root.
Toshikatsu Oga applied EXR-1 and EXR-2 to the MUSUBI settle core and
froze the result at horizon-shield commit dd64d0e2 [MUSUBI-N17], also
described in [I-D.oga-musubi-settlement]. Among the original 123
vectors, every one of ten deviation codes was produced, while 18 of
28 underspecified reasons were produced and ten were not. The
project added five vectors, yielding 128 vectors, drove two further
paths through an in-memory exercise script, and marked four specified
reasons as shadowed by earlier contract checks and therefore
unreachable. The branch for more than 200000 verified headers
remains unexercised. A separately written implementation reproduces
all 128 vectors, run by its author; nobody outside the MUSUBI project
has rerun the exercise script.
The MUSUBI result is an external appraisal of whether the
requirements in this document expose useful distinctions. It is not
independent verification of MUSUBI: the counts are outputs of the
MUSUBI reference implementation, and the added vectors and exercise
script were produced and run within that project. The result
supports the distinction among exercised, reachable-unexercised, and
shadowed-unreachable paths without establishing the correctness or
completeness of the underlying protocol.
He Expires 21 April 2027 [Page 17]
Internet-Draft Verifier Exercise Evidence October 2026
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.
14. 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 an exercise 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.
15. 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.
16. IANA Considerations
This document has no IANA actions.
17. 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>.
He Expires 21 April 2027 [Page 18]
Internet-Draft Verifier Exercise Evidence October 2026
[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>.
18. 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.oga-musubi-settlement]
Oga, T., "MUSUBI Settlement: Recomputing Whether an Agent
Acted Within a Signed Grant", Work in Progress, Internet-
Draft, draft-oga-musubi-settlement-01, October 2026,
<https://datatracker.ietf.org/doc/draft-oga-musubi-
settlement/>.
[MOLTRUST-READER]
Kroehl, L. K., "Reporting Format v0.1 Reader, frozen-run-
1", Git commit 6d8ee54b01d20a819869ceb9fcea096d59251f8c,
October 2026, <https://github.com/MoltyCel/reporting-
format-v01-reader/
tree/6d8ee54b01d20a819869ceb9fcea096d59251f8c>.
[MOLTRUST-AUDIT]
He, J. S., "MolTrust v0.1 Reader Audit", Git
commit 635f3d57eb6f90fdf4c6945778020c34521be0a1, October
2026, <https://github.com/Silentpartnercoding/agent-
security-verifier-
matrix/tree/635f3d57eb6f90fdf4c6945778020c34521be0a1/
experiments/moltrust-reader-audit-001>.
[MUSUBI-N17]
Oga, T., "MUSUBI Settle Core v0 Exercise Record, N17", Git
commit dd64d0e2, October 2026, <https://github.com/
ogasurfproject-jpg/horizon-shield/tree/dd64d0e2/workers/
hs-ledger/nenrin/musubi-v0/settle-core-v0>.
[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/>.
He Expires 21 April 2027 [Page 19]
Internet-Draft Verifier Exercise Evidence October 2026
[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/>.
[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>.
He Expires 21 April 2027 [Page 20]
Internet-Draft Verifier Exercise Evidence October 2026
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.
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.
He Expires 21 April 2027 [Page 21]
Internet-Draft Verifier Exercise Evidence October 2026
+=========================+===========+============+===========+
| 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
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.
A.5. One Outcome Token, Two Rules
Construct two inputs that produce the same non-accepting outcome
token through two different rules. Publish an exercise record
containing only the input identifiers and shared outcome token.
He Expires 21 April 2027 [Page 22]
Internet-Draft Verifier Exercise Evidence October 2026
Expected under EXR-1: the record does not establish which rule or
condition fired for either input. A conforming record identifies the
governing rule or condition for each result even though the outcome
token is unchanged.
A.6. Path Shadowed by an Earlier Rule
Define a later rule that is evaluated only after an earlier rule
accepts, while making the later rule's stated condition imply that
the earlier rule rejects. Supply inputs satisfying the later
condition.
Expected under EXR-2: every such input returns at the earlier rule.
The later path is reported shadowed-unreachable, with both rules
identified. It is not counted as exercised, and absence of its
outcome is not reported merely as reachable-unexercised.
Appendix B. Changes from -00
* Expanded exercise accounting from rejecting outcomes to declared
paths producing rejecting or neither outcomes, including
unverifiable.
* Required the exercise record to identify the rule or condition
reached rather than relying on an outcome token alone.
* Distinguished reachable-but-unexercised paths from paths made
unreachable by an earlier rule or structural precondition.
* Stated the conditional protocol-facing requirement separately from
audit-record formats, corpus commitments, transports, and
testbeds.
* Added bounded MolTrust and MUSUBI implementation evidence and its
limitations.
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.
He Expires 21 April 2027 [Page 23]
Internet-Draft Verifier Exercise Evidence October 2026
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 13.
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.
Lars Kersten Kroehl supplied the frozen report-reader case,
identified the need to retain the rule that fired, and published the
corpus digest, covered-member list, and selection rule used in the
run.
Toshikatsu Oga applied the EXR requirements to MUSUBI, published the
resulting vectors and exercise record at an immutable commit, and
stated the remaining unexercised and rerun limits.
Orie Steele asked that the draft state how its protocol-facing
requirement differs from the mechanisms and records considered in
audit work. Section 11 is the author's answer; it does not imply
Orie's agreement with that boundary.
Acknowledgment does not imply endorsement of this document.
Author's Address
James Siyuan He
Independent
Email: jsiyuanhe@gmail.com
He Expires 21 April 2027 [Page 24]