<?xml version="1.0" encoding="UTF-8"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     category="info"
     docName="draft-watts-gov-verification-promotion-boundaries-00"
     ipr="trust200902"
     submissionType="IETF"
     version="3">
  <front>
    <title abbrev="Gov Verification Promotion Boundaries">Government-Oriented Verification Promotion Boundaries for Agentic Assurance Profiles</title>
    <author fullname="Deonte O'dell Watts" initials="D. O." surname="Watts">
      <organization>GoodShyt Group Inc.</organization>
      <address>
        <postal>
          <city>San Francisco</city>
          <region>CA</region>
          <country>US</country>
        </postal>
        <email>deonte@goodshyt.fun</email>
        <uri>https://orcid.org/0009-0005-8586-3650</uri>
      </address>
    </author>
    <date year="2026" month="October" day="14"/>
    <keyword>agentic systems</keyword>
    <keyword>verification</keyword>
    <keyword>assurance stages</keyword>
    <keyword>government</keyword>
    <keyword>fail-closed</keyword>
    <keyword>non-collapse</keyword>
    <keyword>promotion boundaries</keyword>
    <abstract>
      <t>Government and critical-infrastructure relying parties require explicit boundaries between successive assurance claims. This document defines Verification Promotion Boundaries (VPB) as a protocol-neutral profile that prevents verification evidence obtained at one stage from being silently promoted to a stronger claim. The stages are REGISTERED, SPEC_VALIDATED, LOCAL_CONFORMANT, INDEPENDENTLY_REPRODUCED, SECURITY_TESTED, and RELEASE_ELIGIBLE. A local PASS does not imply independent reproduction; an independent reproduction does not imply security testing; and no stage implies endorsement by any standards body or government agency. The profile further distinguishes subject evidence (negative findings against the tested artifact) from verifier evidence (positive findings that the verification system correctly detected defects). Arithmetic and protocol preconditions, including on-curve validation before metamorphic fixtures, are mandatory before any promotion. This document is intended for high-assurance government deployments and is not a U.S. Government standard.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro"><name>Introduction</name>
      <t>Agentic systems present a verification problem distinct from conventional software: successful execution of one test suite can be misread as evidence of readiness for a higher assurance claim. Government relying parties operating under zero-trust principles and high-impact AI policies require that each promotion step be explicit, independently attested, and fail-closed.</t>
      <t>This document formalizes Verification Promotion Boundaries. The central invariant is that verification evidence at level L_i does not authorize a claim at level L_{i+1}. In particular, detection of a specification defect by a verifier constitutes negative evidence for the tested subject and positive evidence for the verifier. This dual semantics is essential for government audit and accountability.</t>
      <t>The profile is designed to compose with existing identity, authorization, evidence, and revocation mechanisms. It does not replace them. It constrains the claims that may be made from their outputs.</t>
    </section>

    <section anchor="requirements"><name>Requirements Language</name>
      <t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals.</t>
    </section>

    <section anchor="stages"><name>Assurance Stages and Promotion Boundaries</name>
      <t>A conforming relying party MUST maintain the following ordered stages. Promotion from one stage to the next requires an independent attestation that the required predicates for the higher stage have been satisfied. No stage may be skipped.</t>
      <ol>
        <li><t>REGISTERED: The specification, schema, and initial test corpus are published with digests.</t></li>
        <li><t>SPEC_VALIDATED: The specification is syntactically valid and free of known internal contradictions (including arithmetic counter-examples).</t></li>
        <li><t>LOCAL_CONFORMANT: An implementation passes the published positive and negative vectors under a controlled environment. The implementation under test MUST NOT generate its own expected results.</t></li>
        <li><t>INDEPENDENTLY_REPRODUCED: A second party, using an independent implementation or clean-room environment, reproduces the LOCAL_CONFORMANT result and records the environment digest.</t></li>
        <li><t>SECURITY_TESTED: Authorized penetration testing, fault injection, and adversarial evaluation have been completed and their findings incorporated or accepted with residual risk.</t></li>
        <li><t>RELEASE_ELIGIBLE: All prior stages are satisfied, provenance is signed, and a human approval authority independent of the implementation authors has recorded acceptance.</t></li>
      </ol>
      <t>A local PASS MUST NOT be treated as satisfying an INDEPENDENTLY_REPRODUCED or SECURITY_TESTED requirement. An UNKNOWN or INDETERMINATE result at any required predicate MUST prevent promotion.</t>
    </section>

    <section anchor="dual"><name>Dual Evidence Semantics</name>
      <t>When a verifier detects a defect in a published specification or test vector (for example, an elliptic-curve point that does not satisfy the declared curve equation), the resulting evidence record MUST be classified as:</t>
      <ul>
        <li><t>Negative evidence against the tested subject (the draft or implementation that published the invalid vector).</t></li>
        <li><t>Positive evidence for the verifier (the verification system correctly rejected the invalid input).</t></li>
      </ul>
      <t>This classification prevents a successful defect detection from being collapsed into a claim that the subject has passed, and it provides an auditable record for government oversight.</t>
    </section>

    <section anchor="preconditions"><name>Mandatory Preconditions</name>
      <t>Before any metamorphic or higher-order fixture is executed, the following preconditions MUST hold and be recorded:</t>
      <ol>
        <li><t>All published elliptic-curve parameters have a non-zero discriminant.</t></li>
        <li><t>Every published affine point satisfies the curve equation over the declared field.</t></li>
        <li><t>Negative vectors (off-curve points, wrong field, singular curve) are present and cause rejection.</t></li>
        <li><t>The implementation under test does not supply the expected outputs for the vectors it is being tested against.</t></li>
      </ol>
      <t>Failure of any precondition MUST result in INDETERMINATE for the current stage and MUST prevent promotion.</t>
    </section>

    <section anchor="objects"><name>Promotion Receipt</name>
      <t>A Promotion Receipt is an integrity-protected, non-bearer record that binds the source stage, target stage, evidence digests, environment digest, independent observer identifiers, and the decision (PROMOTED or BLOCKED). Possession of a Promotion Receipt MUST NOT be treated as authorization to execute any action outside the declared assurance claim.</t>
    </section>

    <section anchor="gov"><name>Government Deployment Considerations</name>
      <t>This profile is vendor-neutral and may be used by agencies implementing zero-trust architecture, high-impact AI risk management, or secure software development frameworks. It does not constitute a U.S. Government standard or imply endorsement by any agency. Deployments SHOULD pin the applicable policy identifiers (for example, current OMB memoranda or NIST publications) outside the protocol core so that policy updates do not require protocol changes.</t>
      <t>For high-impact agent actions, a relying party SHOULD require at least INDEPENDENTLY_REPRODUCED before production admission and SECURITY_TESTED before high-consequence authorization.</t>
    </section>

    <section anchor="security"><name>Security Considerations</name>
      <t>Threats include circular testing (implementation generates its own expected values), silent promotion of local results, suppression of negative evidence, and treatment of a Promotion Receipt as a bearer credential. The independent observer and human approval roles MUST be distinct from the authors of the implementation under test. Arithmetic preconditions are security-relevant because an off-curve point can invalidate all subsequent group-law claims.</t>
    </section>

    <section anchor="iana"><name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>

  <back>
    <references><name>Normative References</name>
      <reference anchor="RFC2119" target="https://www.rfc-editor.org/rfc/rfc2119"><front><title>Key words for use in RFCs to Indicate Requirement Levels</title><author initials="S." surname="Bradner"/><date year="1997" month="March"/></front><seriesInfo name="RFC" value="2119"/></reference>
      <reference anchor="RFC8174" target="https://www.rfc-editor.org/rfc/rfc8174"><front><title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title><author initials="B." surname="Leiba"/><date year="2017" month="May"/></front><seriesInfo name="RFC" value="8174"/></reference>
    </references>
    <references><name>Informative References</name>
      <reference anchor="NIST800207" target="https://csrc.nist.gov/pubs/sp/800/207/final"><front><title>Zero Trust Architecture</title><author initials="S." surname="Rose"/><date year="2020" month="August"/></front><seriesInfo name="NIST SP" value="800-207"/></reference>
      <reference anchor="RFC6090" target="https://www.rfc-editor.org/rfc/rfc6090"><front><title>Fundamental Elliptic Curve Cryptography Algorithms</title><author initials="D." surname="McGrew"/><author initials="K." surname="Igoe"/><author initials="M." surname="Salter"/><date year="2011" month="February"/></front><seriesInfo name="RFC" value="6090"/></reference>
    </references>
  </back>
</rfc>
