Portable Agent Qualification Statements for Consequential Actions
draft-schrock-agent-qualification-statements-00

Network Working Group                                         I. Schrock
Internet-Draft                                     EMILIA Protocol, Inc.
Intended status: Informational                              27 July 2026
Expires: 28 January 2027

   Portable Agent Qualification Statements for Consequential Actions
            draft-schrock-agent-qualification-statements-00

Abstract

   Agent evaluations report what happened in a test environment.  They
   do not, by themselves, establish that a measured candidate satisfies
   a relying party's policy, remains current, matches the runtime
   candidate, or is authorized to perform a consequential action.  This
   document defines a portable Qualification Statement that binds a
   candidate, complete evaluation campaign, qualification policy,
   assignment, and status.  It preserves three separate claims:
   observation, qualification, and authorization.  A relying party can
   accept a current qualification as evidence at runtime, but MUST make
   a separate exact-action authorization and admission decision.

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 28 January 2027.

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

Schrock                  Expires 28 January 2027                [Page 1]
Internet-Draft             Agent Qualification                 July 2026

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Non-Collapsing Claims . . . . . . . . . . . . . . . . . . . .   2
   3.  Artifact Set  . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Candidate Manifest  . . . . . . . . . . . . . . . . . . .   3
     3.2.  Evaluation Campaign . . . . . . . . . . . . . . . . . . .   3
     3.3.  Qualification Statement . . . . . . . . . . . . . . . . .   3
     3.4.  Qualification Status  . . . . . . . . . . . . . . . . . .   4
   4.  Qualification Verification  . . . . . . . . . . . . . . . . .   4
   5.  Runtime Composition . . . . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Appendix A.  Implementation Status  . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Evaluation systems can execute tests, compare models, and fail a
   build.  A consequential system needs an additional portable claim:
   this exact measured candidate satisfied this policy for this
   assignment, based on this complete campaign, and the claim remains
   current now.  It also needs to avoid turning that claim into a
   universal score or transferable authority.

   This document defines the qualification layer.  It does not define a
   benchmark runner, model leaderboard, certification business,
   universal intelligence score, or authorization token.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119]
   [RFC8174] when, and only when, they appear in all capitals.

2.  Non-Collapsing Claims

   Evaluation Attestation  Signed evidence of what was observed during a

Schrock                  Expires 28 January 2027                [Page 2]
Internet-Draft             Agent Qualification                 July 2026

      named campaign over a measured candidate.

   Qualification Policy  The relying-party-selected predicates,
      thresholds, assignment, and validity rules that must be satisfied.

   Qualification Statement  A signed claim that the candidate and
      complete campaign satisfy that policy for that assignment.

   Authorization  A separate decision about whether an exact action may
      execute now under current authority and local policy.

   A verifier MUST NOT reinterpret an Evaluation Attestation as a
   Qualification Statement.  A relying party MUST NOT reinterpret a
   Qualification Statement as authorization.  The labels VERIFIED,
   ACCEPTED, QUALIFIED, SATISFIED, AUTHORIZED, and ADMITTED describe
   different checks and MUST NOT be collapsed into one boolean.

3.  Artifact Set

3.1.  Candidate Manifest

   The Candidate Manifest identifies the exact evaluated configuration.
   It MUST bind immutable or content-addressed identifiers for code,
   model, prompt, tools, policy-relevant configuration, and evaluation
   environment.  Mutable model aliases or unpinned remote resources make
   runtime identity INDETERMINATE unless a profile defines an
   authenticated resolution procedure.

3.2.  Evaluation Campaign

   The Evaluation Campaign binds the Candidate Manifest, assignment,
   qualification-policy digest, evaluator identity, harness and suite
   versions, ordered test results, start and completion times, and a
   complete campaign-graph digest.  Selectively omitting a failing
   result MUST change the graph digest and invalidate the later
   qualification.

3.3.  Qualification Statement

   A Qualification Statement MUST bind exactly three subjects: the
   Candidate Manifest, the head Evaluation Campaign, and the complete
   qualification-graph digest.  Its signed predicate MUST bind the
   qualification-policy digest, assignment digest, issuer, creation and
   expiry times, and a closed result of QUALIFIED or NOT_QUALIFIED.

Schrock                  Expires 28 January 2027                [Page 3]
Internet-Draft             Agent Qualification                 July 2026

   The signed statement MUST use a deterministic serialization or an
   envelope profile that defines exact signing bytes.  An unknown
   critical member, missing subject, duplicate subject, or graph
   mismatch is refused.

3.4.  Qualification Status

   Qualification status is a separately authenticated, monotonically
   sequenced chain.  Each entry binds the statement, authority,
   sequence, predecessor digest, state, issuance time, and next-update
   time.  A stale, rolled-back, equivocated, revoked, or missing
   required status yields NOT_QUALIFIED or INDETERMINATE according to
   the relying party's profile; it never yields QUALIFIED.

4.  Qualification Verification

   The relying party MUST pin accepted issuers, evaluators, signature
   suites, candidate-measurement rules, assignment vocabulary,
   qualification policies, freshness limits, and status authorities.
   None of those trust inputs may come solely from the presented bundle.

   Verification proceeds in this order: envelope and signature; complete
   campaign graph; candidate identity; assignment and policy binding;
   predicate replay; statement time; current status; and runtime
   candidate measurement.  The result is QUALIFIED only if every
   required check passes.  A conclusive predicate failure is
   NOT_QUALIFIED.  Missing, ambiguous, unsupported, stale, or
   unavailable required input is INDETERMINATE and fails closed.

   At runtime the verifier MUST establish EXACT_MATCH between the
   measured candidate and Candidate Manifest and IN_SCOPE between the
   protected request and assignment.  A changed prompt, tool, code
   digest, model, or policy-relevant configuration requires a new
   qualification unless the qualification policy explicitly covered the
   exact change.

5.  Runtime Composition

   A Qualification Statement MAY be carried as evaluation evidence in an
   Authorization Evidence Chain [AEC] and evaluated at an Action
   Evidence Boundary [AEB].  It can satisfy only the qualification role
   selected by the relying party.  The boundary still MUST establish the
   exact CAID, verify authority evidence, make a local authorization
   decision, durably admit the action, and enforce one-time invocation
   or refusal.

Schrock                  Expires 28 January 2027                [Page 4]
Internet-Draft             Agent Qualification                 July 2026

   Qualification freshness is checked immediately before admission.
   Qualification supersession after admission affects future admissions;
   it does not rewrite a provider effect.  An uncertain provider result
   remains an execution-reconciliation matter, not a qualification
   decision.

6.  Security Considerations

   Implementations MUST defend against mutable aliases, selective-result
   omission, evaluator-key substitution, assignment widening, policy
   substitution, stale or rolled-back status, runtime candidate drift,
   cross-tenant replay, and treating benchmark success as authority.  A
   qualification can be valid and still be irrelevant to the exact
   action.  A compromised accepted evaluator can issue false
   observations; relying parties therefore need explicit evaluator
   roots, revocation, and diversity rules appropriate to risk.

   Scores are meaningful only within the named task, environment,
   candidate, harness, rubric, and campaign.  Implementations MUST NOT
   derive a persistent universal reputation label from this protocol.

7.  IANA Considerations

   This document requests no IANA action.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2.  Informative References

   [AEB]      Schrock, I., "The Action Evidence Boundary for
              Consequential Agent Effects", Work in Progress, Internet-
              Draft, draft-schrock-action-evidence-boundary-02, July
              2026, <https://datatracker.ietf.org/doc/draft-schrock-
              action-evidence-boundary/>.

Schrock                  Expires 28 January 2027                [Page 5]
Internet-Draft             Agent Qualification                 July 2026

   [AEC]      Schrock, I., "Authorization Evidence Chains: Composing
              Heterogeneous Agent-Action Evidence", Work in Progress,
              Internet-Draft, draft-schrock-ep-authorization-evidence-
              chain-04, July 2026, <https://datatracker.ietf.org/doc/
              draft-schrock-ep-authorization-evidence-chain/>.

Appendix A.  Implementation Status

   An Apache-2.0 TypeScript reference implementation is published in the
   EMILIA Protocol repository.  It includes exported qualification
   verifiers, a Promptfoo evaluation-only adapter, Gate composition, in-
   memory and PostgreSQL admission stores, portable conformance vectors,
   hostile tests, and a bounded TLA+ lifecycle model.  This is same-team
   implementation and model evidence.  It is not independent
   interoperability, certification, a managed service, or proof of any
   external evaluation system.

Author's Address

   Iman Schrock
   EMILIA Protocol, Inc.
   United States of America
   Email: team@emiliaprotocol.ai

Schrock                  Expires 28 January 2027                [Page 6]