<?xml version="1.0" encoding="UTF-8"?>
<rfc category="info" docName="draft-watts-agent-noncollapse-requirements-00" ipr="trust200902" submissionType="IETF" version="3">
  <front>
    <title abbrev="Agent Non-Collapse Requirements">Non-Collapse Requirements for Evidence-Bearing Agent Systems</title>
    <seriesInfo name="Internet-Draft" value="draft-watts-agent-noncollapse-requirements-00"/>
    <author fullname="Deonte O'dell Watts" initials="D. O." surname="Watts"><organization>GoodShyt Group Inc.</organization><address><email>deonte@goodshyt.fun</email><uri>https://orcid.org/0009-0005-8586-3650</uri></address></author>
    <date year="2026" month="October" day="8"/>
    <area>Security</area>
    <abstract><t>This document defines architectural non-collapse requirements for agent systems that consume evidence, provenance, model outputs, or other machine-readable claims before consequential actions. It requires implementations to keep integrity, provenance, evidence qualification, authorization, and execution as distinct states; to represent unresolved required evidence explicitly; and to preserve issued evaluation records append-only. The document defines no new transport protocol and no IANA registrations.</t></abstract>
  </front>
  <middle>
    <section><name>Introduction</name><t>Agent systems increasingly combine identity, delegation, evidence, memory, policy, and execution. A recurring failure mode is semantic collapse: a property established in one layer is treated as though it were established in another. Examples include treating a signed object as true, a supported premise as authorized action, or an authorization as proof of successful execution.</t></section>
    <section><name>Normative Non-Collapse Requirements</name>
      <t>An implementation conforming to this architecture MUST distinguish at least the following states: artifact integrity, provenance, evidence qualification, authorization decision, and execution outcome.</t>
      <t>Integrity MUST NOT be interpreted as proposition validity. Provenance MUST NOT be interpreted as truth. Evidence qualification MUST NOT be interpreted as authorization. Authorization MUST NOT be interpreted as execution.</t>
      <t>Where a policy requires qualified evidence, missing, stale, unresolved, or type-incompatible required evidence MUST NOT be silently treated as satisfied.</t>
    </section>
    <section><name>Three-Valued Evidence State</name><t>Evidence evaluation SHOULD preserve PASS, FAIL, and INDETERMINATE as distinct states. FAIL indicates a required condition is contradicted or violated. INDETERMINATE indicates that no required condition has established FAIL but one or more required inputs or bridges are missing or unresolved. A policy requiring PASS MUST NOT accept INDETERMINATE.</t></section>
    <section><name>Append-Only Lifecycle</name><t>Issued evaluation records SHOULD be immutable. New evidence SHOULD create a successor record that can identify its predecessor. A successor MUST NOT be interpreted as erasing the historical state under which an earlier decision was made.</t></section>
    <section><name>Typed Promotion Boundaries</name><t>Crossing from observation to evidence, evidence to warranted premise, premise to authorization, and authorization to execution requires explicit interfaces or witnesses. Implementations SHOULD make these promotion rules inspectable and testable.</t></section>
    <section><name>Relationship to Evidence Qualification Receipts</name><t>An Evidence Qualification Receipt can implement the evidence-qualification layer described here. A PASS receipt remains an authorization input only; local policy retains authority over action.</t></section>
    <section><name>Security Considerations</name><t>Semantic collapse can enable authority laundering, replay of stale evidence, profile substitution, confused-deputy execution, and false completion records. Implementations should bind evidence states to exact propositions, profiles, contexts, and actions when consequence warrants it.</t></section>
    <section><name>Privacy Considerations</name><t>Evidence graphs can expose sensitive information. Systems should minimize plaintext evidence in authorization paths and prefer scoped digests or privacy-preserving references when sufficient.</t></section>
    <section><name>IANA Considerations</name><t>This document has no IANA actions.</t></section>
  </middle>
</rfc>
