Claim-Preserving Exchange of AI Evaluation Evidence

Internet-Draft	AI Evaluation Claim Preservation	September 2026
Abak	Expires 27 March 2027	[Page]

Abstract

AI evaluation records can pass through evaluation frameworks, exporters, evidence services, independent reviewers, and systems that make decisions. A conversion can retain a score while losing whether the measurement ran, which result was selected, whether a criterion existed, or which evidence was unavailable. Authenticating the converted record does not recover these distinctions.¶

This document specifies format-neutral requirements for mapping profiles and consumers that exchange AI evaluation evidence. It separates source assertions, explicit derivations, and later policy judgments; requires claim-relevant loss and uncertainty to remain visible; and describes consumer behavior when preservation cannot be established. It includes synthetic counterexamples and guidance for composition with existing evidence mechanisms. It defines neither a wire format nor an evaluation benchmark, safety certification, authorization protocol, or new cryptographic envelope. A concrete mapping profile is needed for interoperable implementation.¶

1. Introduction

Consider an evaluation operator that exports results to an evidence service. A second organization retrieves a summary from that service and uses selected results in its own decision system. These boundaries can involve different native formats, parser versions, aggregation conventions, access permissions, and trust policies. A correctly authenticated summary can nevertheless misrepresent the source if a conversion changes the meaning of a result.¶

Native formats already make relevant distinctions. Inspect documents evaluation-log status separately from scoring results [INSPECT]. LightEval documents task-indexed numerical results and configuration metadata [LIGHTEVAL]. This document does not allege a defect in either implementation. Its question is what a converter and a downstream consumer need to preserve when exchanging such records.¶

For example, completion of a run does not mean that a metric met a criterion. A consumer can legitimately apply its own threshold to a source score, but that is a new assessment by that consumer, not a verdict reported by the original evaluator. Similarly, checking a signature on a model-name assertion does not establish which model actually executed.¶

General evidence-to-decision architectures and preservation principles are not new contributions of this document. RATS separates evidence appraisal from relying-party policy [RFC9334]. Related work on evidence qualification, statement graphs, and agent control intermediaries is discussed in Section 8. The contribution proposed here is a bounded set of requirements for AI-evaluation-specific mappings: result selection, run and measurement state, scores and criteria, population scope, and the qualifications that survive conversion.¶

1.1. Scope and Non-Goals

The requirements apply to exchange across components or administrative domains, including offline exchange. They apply to evaluations of AI systems, including frontier-system use cases, without defining a frontier capability threshold. They do not require native evaluation frameworks to adopt a new format or to disclose confidential samples.¶

This document does not define scientific validity, acceptable risk, evaluator competence or independence, legal authority, or whether deployment should occur. It does not create an evidence-to-decision graph format, transparency service, trust-anchor system, or control-delivery mechanism. Accurate preservation of an unsupported or false source assertion does not make that assertion true.¶

1.2. Requirements Language and Applicability

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 [BCP14] when, and only when, they appear in all capitals, as shown here.¶

These requirements apply to a mapping profile, converter, or consumer that explicitly adopts them. They do not retroactively change the specifications of native formats or evidence carriers. A claim of compliance with these requirements MUST identify the concrete profile, the implementation role, and the tested version; a bare claim of "claim-preserving" is insufficient. A profile supplies the encodings, selection rules, and processing details identified in Section 5. This document alone is not a complete wire-level interoperability specification.¶

An application can accept a limited result while withholding a stronger conclusion. Preservation failures affect the conclusions that require the missing distinction; they do not automatically make every other field unusable. No requirement here prescribes a particular deployment or business decision.¶

2. Terminology and Claim Boundaries

Native evidence: The source output of an evaluation process, such as a result file, sample record, log, or configuration. "Native" identifies provenance, not truth or completeness. Evidence is used here in a general sense, not as a replacement definition for RATS Evidence.¶
Result unit: The particular source observation or assessment being exchanged: an identified source object and selection, together with the run, attempt, task, scorer, metric, aggregation, and population context needed to distinguish it. A run identifier alone need not identify a result unit.¶
Mapping profile: An identified, versioned definition of source and destination interpretations, selection rules, permitted transformations, preserved qualifications, and consumer behavior. It is not a model-safety profile.¶
Mapping instance: A particular application of a mapping profile to identified source objects. It records the converter, outputs, transformations, and material limitations of that application.¶
Source assertion: An assertion attributable to an identified source, including its scope and qualifications. A copied assertion does not become independently observed merely because a converter signs it.¶
Derivation: A reported calculation or transformation with identified inputs and rules. A derivation may add useful information, but it is distinct from a source assertion. A policy judgment based on it is also distinct.¶
Verification basis: The procedure, inputs, accepted identities or trust material, and policy under which a particular verification result is produced. Different verification types establish different properties.¶
Material qualification: Context or uncertainty needed to interpret a stated claim, such as a denominator, missing samples, a criterion, units, access limitations, or the distinction between declared and verified identity. Materiality is relative to the claim and mapping profile, not to an arbitrary converter preference.¶
Claim preservation: Preservation of the attribution, meaning, scope, and material qualifications of the source assertions selected for exchange. It does not prohibit explicitly identified derivations or new judgments. It prohibits representing those as stronger original assertions or silently broadening what the source supports.¶
Reliance record: A record asserting that an actor used identified evidence as an input to a particular decision under an identified policy. It does not, by itself, establish causation, complete deliberation, valid authority, or enforcement.¶

Claim preservation is evaluated for a specified mapping and bounded claim set. This document provides no universal decision procedure for semantic equivalence, natural-language entailment, or arbitrary converter correctness. A profile that claims preservation of a particular distinction needs an explicit rule and testable examples for that distinction.¶

4. Preservation Requirements

4.1. R-CP-1: Source and Mapping Identity

A mapping instance MUST identify its source objects, source format and interpretation basis, destination basis, converter implementation/version, and mapping-profile revision. Where a source revision cannot be established, that limitation MUST be explicit and MUST NOT be replaced with an assumed current revision. A content digest identifies bytes; it does not by itself identify the rules used to interpret those bytes.¶

The instance MUST bind the output and material mapping information to the source objects and selections on which they depend. For each content digest, the algorithm and byte selection or canonicalization rule MUST be identified. Hashing an original JSON file and hashing a canonical representation are different operations; a profile MUST NOT silently substitute one for the other. Native source objects SHOULD remain available under the applicable access policy; their unavailability is handled under Section 4.8.¶

4.2. R-CP-2: Unambiguous Result Selection

A mapping MUST identify the result unit being carried or assessed. It MUST preserve the context needed to distinguish task, scorer, metric, run attempt, aggregation, dataset/split, and population whenever these affect the claim. A profile MUST specify which native identifiers or selectors supply that context and how their uniqueness is scoped. Unsupported, unresolved, or ambiguous selections MUST NOT be resolved by taking an arbitrary first, last, largest, or most favorable result.¶

A selector MUST be interpreted against the identified source snapshot and under an identified selector syntax. When a summary combines results, the inputs and selection/aggregation rule MUST be identifiable. When a referenced object changes, the old selector MUST NOT silently become a reference to new content. A selector identifies data, not a measured population's completeness. JSON Pointer [RFC6901] is one possible syntax, not a required wire mechanism.¶

4.3. R-CP-3: Execution, Observation, and Assessment

A mapping MUST distinguish whether a measurement executed, what value or finding was reported, and whether an identified criterion was assessed. It MUST NOT translate successful process completion into a successful metric or safety assessment. Non-execution, invalidation, error, inconclusive outcome, and absence of evidence MUST NOT silently become a measured pass. They also MUST NOT be relabeled as a measured failure unless the source semantics actually establish such a failure.¶

A score without an established criterion MUST remain a score without an attributed source verdict. "The source states that no criterion was applied" and "the available source does not establish a criterion" MUST remain distinguishable. An omitted field alone establishes neither condition unless the identified native format defines that omission unambiguously. A non-applicability assertion MUST retain its stated scope and basis, not be invented from a missing value.¶

4.4. R-CP-4: Values, Units, and Numerical Transformations

For a selected result, a mapping MUST preserve the meaning of its value, including applicable units, scale, metric definition, comparator direction, precision, and uncertainty information. A profile MUST specify acceptable numerical conversions and any tolerance. It MUST distinguish a source uncertainty estimate from information lost through conversion. Missing uncertainty information MUST NOT be mapped to zero uncertainty or to a source claim of statistical confidence. An exact integer identifier MUST NOT be changed by a lossy numeric representation.¶

Rounding, normalization, aggregation, or recomputation MUST be identified as a derivation when it can affect interpretation. A consumer MUST NOT use a rounded presentation value to claim that the source met a threshold when the unrounded source did not. If the native representation cannot support the requested numerical comparison, that comparison MUST remain unestablished. A profile MAY permit a bounded conversion for a narrower claim; the bound and the affected claim MUST be explicit.¶

4.5. R-CP-5: Criteria, New Judgments, and Chronology

A transported criterion assessment MUST identify the criterion and revision actually attributed to its source. A consumer MAY apply a new criterion or policy to a source observation, provided it records a separate assessment with its own actor, inputs, rule/version, scope, and result. It MUST NOT describe this new judgment as the original evaluator's verdict or as a criterion fixed before the source run without supporting evidence.¶

A claim that criteria preceded execution MUST have a supported ordering relationship between the identified criteria and that run. A bare timestamp string, matching identifiers, or a hash-only commitment is not sufficient by itself. Existing preregistration mechanisms can be referenced; this document defines none. Unknown ordering MUST remain unknown. Legitimate corrections and later reassessments are permitted but MUST preserve the original assessment and explicit revision relationship.¶

4.6. R-CP-6: Coverage, Aggregation, and Attempts

A claim about an evaluation campaign or complete population MUST identify the population or reproducible inclusion rule, its source, and the accounting method. Recorded samples, unexecuted samples, errors, exclusions, invalidations, and unknown portions MUST NOT disappear solely because an aggregate counts only successful records. When totals or categories are unknown, a mapping MUST record that limitation rather than invent counts.¶

The profile MUST define how retries, repeated measurements, duplicate records, changed sample sets, and overlapping outcomes affect the denominator. It MUST NOT assume that native status categories are disjoint when they are not. A partial run MAY preserve a local criterion result; that result MUST retain its narrower scope. Preserving all supplied records does not establish that all actual attempts were supplied. Selection or deduplication that changes the population MUST be visible as a transformation.¶

4.7. R-CP-7: Qualified Identity and Evaluation Context

A mapping MUST distinguish display names and declarations from identities established by a specified verification procedure. When a conclusion requires an exact model, checkpoint, configuration, dataset, harness, or environment, the profile MUST identify the evidence required for that conclusion. Missing required identity evidence MUST prevent that conclusion, but need not prevent carrying a more limited declared result.¶

Context material to the selected claim, such as tool access, network restrictions, safeguard state, scoring method, or system configuration, MUST retain its source and verification status. A declared container digest or model hash MUST NOT be presented as proof that those bytes executed. Attestation references MUST retain the scope and accepting verification basis of the attestation. Evaluator access and independence declarations MUST NOT be promoted to established access or independence merely through conversion.¶

4.8. R-CP-8: Evidence Availability and Digest Knowledge

A mapping MUST distinguish evidence availability from digest knowledge. It MUST distinguish a digest recomputed from available bytes by an identified actor, a digest reported by another source but not recomputed by that actor, and a digest that is unavailable. It MUST NOT fabricate a digest or use a dummy value to make an unavailable object appear content-bound.¶

Availability statements MUST be scoped to an actor and the relevant observation or exchange context. Public location, permission to access, successful retrieval, and retention are different properties. A profile MUST define how known restrictions and unknown availability are represented. It MUST NOT invent a custodian, withholding reason, or claim that an object exists. When the destination cannot express a required unavailable state, the mapper MUST provide a bound, interpretable qualification through the profile or report that the affected mapping is unsupported.¶

4.9. R-CP-9: Loss, Conflict, and Multi-Hop Preservation

The mapping report MUST distinguish copied assertions, transformations, out-of-band declarations, and material losses. A profile MUST identify which source qualifications are required for each supported claim class. A converter MUST NOT omit a known material qualification merely by declaring it irrelevant. Unknown extensions that may qualify the selected claim MUST remain uninterpreted or prevent that claim from being established; a profile MAY define an explicit criticality mechanism or extension points whose contents cannot qualify its stated claim class under that profile.¶

Every transformation hop used to support an end-to-end preservation claim MUST be accounted for, either through the chain of mapping records or by a direct check against an adequately identified earlier source. A later converter MUST NOT erase an earlier material loss or present reintroduced information as though it had survived the lost hop. Corrections, contradictory records, alternative interpretations, and amendments MUST retain provenance. A signed loss report is itself an assertion; it does not prove that its loss inventory is complete. A contradictory source verdict may be retained as an attributed assertion, but MUST NOT be endorsed merely because it was copied faithfully.¶

4.10. R-CP-10: Typed Verification and Bounded Consumption

A verification result MUST identify the actor, procedure/version, checked inputs, verification type, result, and material limitations. Structural validation, digest recomputation, signature verification, attestation appraisal, mapping verification, and substantive evaluation judgments MUST remain distinct. Successful verification of a carrier MUST NOT imply successful verification of an unsupported profile, unavailable source, or source statement not covered by that carrier.¶

A consumer MUST evaluate preservation relative to the selected claim and accepted verification basis. If an essential binding, interpretation, qualification, or verification input is unavailable, it MUST NOT report that claim as established. It MAY retain or forward an opaque record without accepting its semantics. A local policy may deny, defer, request evidence, or otherwise act on uncertainty, but the resulting action MUST NOT rewrite uncertainty as a measured source failure or success.¶

4.11. R-CP-11: Separate Reliance and Downstream Decisions

An exporter completing a conversion MUST NOT, on that basis alone, assert that a governance decision occurred. When a reliance record is supplied, it MUST identify the asserting actor, actual reported decision, applicable policy basis, affected subject, and selected evaluation inputs. A new judgment under Section 4.5 MUST remain separate from the transported source assertions.¶

The consumer MUST NOT infer valid decision authority, complete deliberation, causal influence, control delivery, enforcement, or observed effect solely from a reliance record. Authentication of its author is a separate check. Changes to evidence or policy MUST produce a distinguishable reassessment or amendment, not retroactively rewrite the evidentiary basis of an earlier decision. Existing decision and control mechanisms should carry any actual downstream records; this document defines no such protocol.¶

4.12. R-CP-12: Versioned Mappings and Verification Evidence

A concrete profile MUST identify the source and destination versions and semantic rules it supports, including its extension and unknown-value policy. An implementation MUST NOT silently treat a new or incompatible basis as the old one. A profile MUST specify observable expected behavior for negative and ambiguous cases, including cases where a limited result can be preserved but a stronger claim cannot.¶

Implementation reports MUST identify the profile and implementation versions, source cases, procedure, and observed results on which their claims rely. A schema check or a documentation crosswalk MUST NOT be described as a complete semantic mapping test. Same-author tests MUST NOT be described as independent interoperability. An interoperability claim MUST name the tested producer and consumer, exact bases, inputs, procedure, outcomes, and known limitations.¶

7. Worked Counterexamples

All examples in this section are synthetic. Field names outside the explicitly described native-style fragments are explanatory notation, not a wire schema, registered vocabulary, full native log, or released AIREP profile. No model was run to produce these values. The examples illustrate required distinctions; they neither demonstrate upstream implementation defects nor establish interoperability.¶

7.1. Run Completion Is Not a Scoring Verdict

Inspect documents run status and scoring results separately [INSPECT]. The following synthetic excerpt uses those concepts. It is not a complete EvalLog. The run finished successfully; the accuracy observation is 0.734. The excerpt supplies no criterion, so it does not establish whether the full evaluation had one.¶

{
  "status": "success",
  "results": {
    "scores": [
      {
        "name": "example_scorer",
        "metrics": {
          "accuracy": {
            "value": 0.734
          }
        }
      }
    ]
  }
}

Figure 2: Synthetic Inspect-Style Excerpt

An output that attributes PASS to the evaluator solely from status = success violates Section 4.3. A limited view can preserve the reported completion status and selected score while leaving the criterion state unknown. Explicit source evidence that no criterion was applied would instead support that narrower absence assertion.¶

A consumer can apply its own threshold. The following explanatory record reports a new local assessment; it does not invent a historical source verdict. The source object reference is an illustrative identifier scoped to this example, not a substitute for the binding required by a deployed profile.¶

{
  "actor": "consumer.example",
  "source_selection": {
    "object": "example-inspect-fragment",
    "syntax": "RFC6901",
    "pointer": "/results/scores/0/metrics/accuracy/value"
  },
  "source_criterion_state": "unknown",
  "new_criterion": {
    "id": "local-accuracy-policy-v1",
    "operator": ">=",
    "threshold": 0.7
  },
  "new_assessment": "PASS",
  "criterion_preceded_source_run": "not-established"
}

Figure 3: A Separately Attributed Local Assessment

This new assessment is allowed by Section 4.5. Its authority and suitability for a real decision remain separate questions. A later evidence view must not remove the attribution and turn it into "the evaluation passed its preregistered test".¶

7.2. A Run Identifier Does Not Select a Metric

LightEval describes a task-keyed results object with numerical metrics [LIGHTEVAL]. The following is a synthetic excerpt, using a fictional task name and an added explanatory run identifier. The values are not a real LightEval run.¶

{
  "example_run_id": "run-17",
  "results": {
    "example/task|0": {
      "em": 0.62,
      "maj@8": 0.8
    }
  },
  "versions": {
    "example/task|0": 1
  }
}

Figure 4: Synthetic Task-Indexed Results

Under JSON Pointer [RFC6901], /results/example~1task|0/em selects 0.62; /results/example~1task|0/maj@8 selects 0.8. These are different result units. A record saying only "run-17 passed 0.75" fails to specify the metric or the assessment rule. The slash in the task key is escaped as ~1 in the pointer. This example uses a JSON Pointer string, not an assumed URI-fragment convention for application/json.¶

A deployed mapping must additionally bind the source snapshot, native task/scoring interpretation, and population needed for its claim. A JSON pointer into a mutable URL does not satisfy those requirements. A pointer to a numerical value also does not carry the surrounding context on its own.¶

7.3. Local Success and Incomplete Coverage

{
  "population": {
    "source": "declared-plan-v1",
    "planned_samples": 100
  },
  "completed_samples": 80,
  "sample_criterion_met": 76,
  "sample_criterion_not_met": 4,
  "not_run_samples": 20,
  "derived_fraction_among_completed": 0.95
}

Figure 5: Synthetic Bounded Sample Accounting

Here the sample categories are defined by the example to be disjoint. The observed fraction is 76/80, not evidence that 95 of 100 planned samples met the criterion. A new policy could accept incomplete coverage, but it must identify that choice separately. If the plan were unavailable, the record could not infer a total of 100. If attempts rather than unique samples were counted, the deduplication and retry rules would have to be stated. Even a verified plan does not establish that an operator disclosed all real attempts.¶

7.4. Rounding Can Change a Decision

{
  "source_decimal": "0.94996",
  "display_decimal": "0.950",
  "criterion": {
    "operator": ">=",
    "threshold_decimal": "0.95"
  },
  "comparison_on_source": "FAIL",
  "comparison_on_display": "PASS"
}

Figure 6: Synthetic Decimal Comparison

The strings in this example denote exact base-10 values. Rounding to three fractional places changes the result of the stated comparison. Displaying 0.950 can be useful, but treating it as the original evidence for a 0.95 threshold violates Section 4.4. A new assessment deliberately using rounded values would require its own explicit rule and attribution; it cannot replace the earlier comparison silently.¶

7.5. A Restricted Reference Is Not Verified Bytes

{
  "object_ref": "https://evaluator.example/private/run-17.log",
  "availability_to": "publisher.example",
  "availability_context": "this conversion",
  "availability": "not-retrieved",
  "digest_knowledge": "unavailable",
  "reason": "source supplied a restricted reference only",
  "object_existence_basis": "source assertion only"
}

Figure 7: Synthetic Unavailable Evidence Description

The publisher can preserve the reference and its limitation. It cannot supply a made-up all-zero hash, claim a recomputed digest, infer the log's contents, or conclude that the source actually retained a complete log. Whether another actor can retrieve the object is a separate observation. A destination requiring a known digest needs a supported qualification mechanism or must report the affected object as unsupported, not counterfeit compliance.¶

7.6. Later Authentication Does Not Repair Earlier Loss

Suppose an initial mapper receives the partial-population record in Section 7.3 and exports only 0.95. A second mapper signs that score and reports "complete evaluation passed". The signature may authenticate the second mapper, but it neither recovers the missing population nor authenticates the first operator's actions. A consumer without adequate upstream evidence cannot establish that stronger claim.¶

A direct recheck against the identified original can restore the missing context for a new derived view. The new view must identify that recheck, rather than assert that the context survived the earlier mapping. If a corrected source result later appears, it must be distinguished from the source snapshot used in the original decision.¶

9. Security Considerations

A conforming mapping can preserve a false, biased, manipulated, or selectively published source assertion. A compromised source, converter, or verifier can sign false claims. Claim preservation is not a substitute for source trust, independent observation, evaluator competence assessment, containment, or scientific review. A loss report cannot independently prove that no omitted information existed.¶

A deployed profile MUST specify the integrity and attribution bindings required for its claims, including which actor authenticated which object. An authenticated channel can protect a transfer while leaving later re-export attribution unresolved. When offline third-party verification is claimed, the profile MUST provide evidence sufficient for that verification rather than relying only on an earlier channel session. Signature validity under an unaccepted or self-declared key is not accepted source attribution.¶

Source and mapping substitution, replay, and equivocation can make a genuine result appear to concern another model, policy, population, or time. Consumers need binding and freshness checks appropriate to the requested claim. A recent signature over an old evaluation does not make the evaluation recent. Append-only history does not by itself prove all real evaluations were logged. Revocation or a changed trust basis may alter a verification conclusion without authorizing silent rewriting of historical records.¶

Implementations MUST apply bounded resource limits to parsing, archive expansion, reference traversal, and evidence graphs. A profile using JSON needs deterministic handling of duplicate names, excessive nesting, large numbers, and invalid encodings; ambiguity in claim-relevant data MUST NOT be resolved by accidental parser behavior. The interoperability cautions in [RFC8259] are relevant. A structural validator does not necessarily perform numerical, chronological, or semantic consistency checks.¶

An evidence reference is not permission to fetch or execute its target. Consumers MUST apply an explicit retrieval policy, including access control and restrictions on destinations, redirects, schemes, and content processing. Evaluation logs, prompts, and tool outputs are untrusted data, even when embedded in a valid signed record. Instructions in them MUST NOT be executed as verifier instructions merely because they appear in evidence.¶

A display layer can undo preservation performed by the converter. Interfaces that collapse "not checked", "unavailable", "invalid", and "passed" into the same indicator can mislead a decision maker. A profile MUST preserve the distinction at the consumer interface for the claims it supports, not only in an inaccessible raw attachment.¶

14. References

14.1. Normative References

[BCP14]: Best Current Practice 14, <https://www.rfc-editor.org/info/bcp14>.
At the time of writing, this BCP comprises the following:

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>.

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>.

14.2. Informative References

[AIREP-PROFILE]: Abak, A. T., "AIREP Embedded Evaluation Profile v0.1", Experimental companion profile; AIREP carrier 0.2. Source commit 9c1154ffd15781782e8b77242d05b6da87d240f7. Accessed 22 September 2026., <https://github.com/halvrenofviryel/ai-runtime-evidence-protocol/blob/9c1154ffd15781782e8b77242d05b6da87d240f7/spec/airep/v0.2/profiles/embedded-evaluation/README.md>.
[CONTROL-EVIDENCE]: Abak, A. T., "Evidence Requirements for Agent Control Delivery and Outcome Reconciliation", Work in Progress. Individual submission; in particular, Section 5.16, R-CD-16., Work in Progress, Internet-Draft, draft-abak-agent-control-delivery-evidence-01, 4 September 2026, <https://datatracker.ietf.org/doc/html/draft-abak-agent-control-delivery-evidence-01>.
[EQR]: Watts, D., "Evidence-Bounded Authorization for Agentic Systems: Evidence Qualification Receipts", Work in Progress. Individual submission., Work in Progress, Internet-Draft, draft-watts-agent-evidence-boundary-00, 12 September 2026, <https://datatracker.ietf.org/doc/html/draft-watts-agent-evidence-boundary-00>.
[IN-TOTO]: in-toto, "in-toto Attestation Framework: Statement", Statement v1 documentation, accessed 22 September 2026. The linked branch can change., <https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md>.
[INSPECT]: Inspect, "Log Files", Online documentation, accessed 22 September 2026. Not a pinned implementation revision., <https://inspect.aisi.org.uk/eval-logs.html>.
[LIGHTEVAL]: Hugging Face, "Saving and Reading Results", LightEval documentation, accessed 22 September 2026. Not a pinned implementation revision., <https://huggingface.co/docs/lighteval/saving-and-reading-results>.
[PRML]: Ozturk, C., "A SCITT Profile for Pre-Run Evaluation Criteria (PRML)", Work in Progress. Individual submission., Work in Progress, Internet-Draft, draft-ozturk-scitt-prml-profile-00, 11 September 2026, <https://datatracker.ietf.org/doc/html/draft-ozturk-scitt-prml-profile-00>.
[RFC6901]: Bryan, P., Zyp, K., and M. Nottingham, "JavaScript Object Notation (JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013, <https://www.rfc-editor.org/info/rfc6901>.
[RFC8259]: Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC9334]: Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/info/rfc9334>.
[RFC9943]: Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, <https://www.rfc-editor.org/info/rfc9943>.
[SCITT-COMPOSITE]: Aoki, N., "Composite Evidence Verification for SCITT Statement Graphs", Work in Progress. Individual submission., Work in Progress, Internet-Draft, draft-nobuo-scitt-composite-evidence-verification-00, 7 July 2026, <https://datatracker.ietf.org/doc/html/draft-nobuo-scitt-composite-evidence-verification-00>.
[SLSA-VSA]: SLSA, "Verification Summary Attestation", SLSA v1.1; status Retired. Historical related work, accessed 22 September 2026., <https://slsa.dev/spec/v1.1/verification_summary>.

Appendix A. Mapping Test Scenarios

These are proposed test obligations for concrete profiles, not a claimed executed conformance suite. A profile needs actual source and destination fixtures, accepted interpretation bases, and observable consumer outputs. An expected limitation can be the correct result; a test does not need to produce a pass verdict about a model.¶

Each test report should state exactly which checks were performed. Native-format schema acceptance, arithmetic correctness, carrier verification, mapping correctness for selected cases, and independent interoperability are different claims.¶