| Internet-Draft | Verifier Exercise Evidence | October 2026 |
| He | Expires 20 April 2027 | [Page] |
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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:¶
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.¶
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.¶
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.¶
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.¶
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.¶
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 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.¶
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.¶
[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 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. 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.¶
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 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 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.¶
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.¶
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.¶
This document has no IANA actions.¶
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.¶
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.¶
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.¶
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 on 3 or more reports | 1.000 | 0.033 | 1.033 |
| origin-aware, 2 or more independent origins | 0.000 | 0.533 | 0.533 |
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.¶
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.¶
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.¶