Network Working Group I. Schrock Internet-Draft EMILIA Protocol, Inc. Intended status: Experimental 28 July 2026 Expires: 29 January 2027 Model-to-Matter: Authorization and Outcome Evidence for Model-Directed Physical Execution draft-schrock-model-to-matter-02 Abstract Advanced models can propose operations that produce physical effects. Model-to-Matter defines an executor-owned profile that composes model, safety, institutional, domain, screening, and human evidence over one canonical action before single-use execution. This revision also profiles post-execution Outcome Binding. An executor effect statement remains one source claim; required independent observers sign separately bound observations. Missing outcome evidence is indeterminate, not success or failure. The profile standardizes evidence custody and reconciliation; it does not perform screening, determine scientific safety, certify a facility, or establish physical truth. 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 29 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Schrock Expires 29 January 2027 [Page 1] Internet-Draft Model-to-Matter July 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Canonical Action . . . . . . . . . . . . . . . . . . . . . . 3 3. Pre-Execution Evidence and Clearance . . . . . . . . . . . . 3 4. Effect Custody . . . . . . . . . . . . . . . . . . . . . . . 3 5. Outcome Claims and Binding . . . . . . . . . . . . . . . . . 3 6. Remedy and Subsequent Action . . . . . . . . . . . . . . . . 4 7. Industrial Execution Profile . . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 12. Changes since -01 . . . . . . . . . . . . . . . . . . . . . . 6 13. Normative References . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction A digital proposal can become a physical effect through a laboratory, instrument gateway, robot, manufacturing system, or other executor. Independent authorities may each approve a different fact. The executor therefore constructs one closed Action Object and accepts evidence only when every required issuer agrees about that action. Authorization and outcome are separate phases. clear_to_execute permits one invocation; it does not assert that invocation occurred. An executor effect statement records the executor's claim; it does not prove a sensor result. Outcome reconciliation requires the independently pinned sources selected by the expected-effects policy. 1.1. Requirements Language 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. Schrock Expires 29 January 2027 [Page 2] Internet-Draft Model-to-Matter July 2026 2. Canonical Action EP-MODEL-TO-MATTER-ACTION-v1 is a closed I-JSON [RFC7493] object serialized with JCS [RFC8785]. It binds model manifest, harness and safeguards; experiment protocol, material commitment and expected- effects digest; principal; executor and facility; purpose; destination; requested time; and max_executions=1. Raw biological content, prompts, completions, and hidden reasoning MUST NOT appear in the portable object. The executor independently computes both action_digest and CAID. The identifiers MUST encode the same canonical bytes. CAID identifies the action; it does not prove identity, authority, safety, execution, or outcome. 3. Pre-Execution Evidence and Clearance The executor pins its own acceptance profile. The initial profile requires model_attestation, safety_case_attestation, institutional_authority, biosafety_review, domain_screening, and human_authorization artifacts. Each artifact is signed by a pinned issuer and binds action_digest. Presenter-supplied issuer keys, sufficiency rules, or revocation policy MUST NOT influence acceptance. The executor registers and atomically consumes a short-lived challenge. Before returning clear_to_execute it atomically consumes the action digest in durable shared state. Storage ambiguity returns indeterminate and freezes execution pending authenticated reconciliation. It MUST NOT permit blind retry. 4. Effect Custody After clearance consumption, the protected effect enters dispatch custody. The executor records a stable operation identifier and the exact action digest, CAID, clearance replay digest, provider, and facility. A lost provider response after invocation is indeterminate. Reconciliation MUST query the authenticated provider operation; it MUST NOT issue a new physical action under the consumed clearance. 5. Outcome Claims and Binding The Action Object's experiment.expected_effects_digest MUST commit to the exact source-routed predicted_effects array. Each prediction identifies an executor, system_of_record, or independent_observer role and MAY require a source class. Post-execution observations conform to [I-D.schrock-ep-outcome-binding]. Schrock Expires 29 January 2027 [Page 3] Internet-Draft Model-to-Matter July 2026 For this profile, each observation MUST bind the action_digest as action_hash, the action CAID, clearance replay digest, stable operation identifier, executor facility, and observation window. The clearance replay digest is used as the authorization digest and consumption binding; the derived authorization identifier is "ep:m2m:clearance:" followed by the lowercase hexadecimal digest value. EP-MODEL-TO-MATTER-EFFECT-v1 remains the executor's signed statement. Its status is completed, failed, aborted, or indeterminate. Its observed_effect_digest MUST equal the observed_effects_digest of the accepted executor-role observation. This prevents an executor statement from being attached to different executor observations. An accepted executor statement is necessary when required by policy and is not physical truth. If a prediction requires an independent observer, the verifier MUST NOT reconcile without an accepted observation from a separately pinned source matching the required role, class, and facility. The independent source MUST use an Ed25519 canonical key identity and a relying-party-declared control domain distinct from every executor or other non-independent source. A second key in the executor's control domain is not independent. The executor's acceptance profile MUST pin source status and validity, source quorum, distinctness dimensions, and any required observation window and maximum attestation delay. Those requirements are verifier policy and MUST NOT be accepted from the observation presenter. A compromised at the attestation instant, retired outside its pinned historical validity interval, expired, not-yet-valid, non- distinct, late, or window-mismatched source cannot satisfy the required evidence role. Missing or unauthenticated evidence yields lifecycle_state=indeterminate and outcome=null. Authentic evidence yields in_bounds, divergent, or incomparable under Outcome Binding. An indeterminate state MUST NOT be mapped to incomparable. 6. Remedy and Subsequent Action A divergent or failed outcome does not authorize a remedy. Any rollback, compensation, cleanup, repeat experiment, or other consequence is a new action with a separately constructed Action Object, CAID, evidence set, challenge, clearance, and consumption event. Schrock Expires 29 January 2027 [Page 4] Internet-Draft Model-to-Matter July 2026 7. Industrial Execution Profile An industrial deployment SHOULD separate at least three roles: the actuator or facility executes; a meter, EMS, SCADA historian, laboratory instrument, or other telemetry source observes under a separately pinned identity; and the Model-to-Matter verifier reconciles evidence and applies settlement or remediation policy. A controller acknowledgment MUST NOT be represented as an independent physical measurement. Action State or another external evidence format MAY carry the stable action identity, custody transition, and Outcome Binding result digest. Such a carrier is an adapter and is not a core dependency of this profile. 8. Security Considerations This profile does not decide scientific safety, validate raw material, certify a source, establish control-domain ownership, or establish physical truth. Pinned sources may be wrong, compromised, correlated, or colluding. Deployments need independent operational controls, source calibration, key governance, bounded observation windows, incident response, and legal review appropriate to the physical consequence. Exact action, CAID, clearance, operation, executor, facility, source, and time bindings are mandatory. Evidence for different operations or facilities MUST NOT be joined. An effect status of indeterminate and an Outcome Binding lifecycle of indeterminate prohibit blind retry. 9. Privacy Considerations Portable evidence can reveal models, institutions, facilities, principals, purposes, destinations, and times. Deployments SHOULD minimize identifiers and use hiding commitments for low-entropy sensitive content. A plain digest is not automatically confidential. 10. IANA Considerations This document has no IANA actions. Schrock Expires 29 January 2027 [Page 5] Internet-Draft Model-to-Matter July 2026 11. Implementation Status An Apache-2.0 TypeScript implementation provides the closed Action Object, CAID binding, six signed evidence adapters, registered challenge, durable single-use clearance, effect statements, source- routed Outcome Binding, independently signed observation sets, canonical-key and control-domain separation, source status and validity, observation-window policy, distinct-source quorum, and adversarial tests. Demonstrations are synthetic and process no raw biological content. No wet-lab deployment, scientific validation, partner endorsement, or independent implementation is claimed. 12. Changes since -01 This revision makes expected_effects_digest resolve to source-routed predicted effects, adds independent signed observations and exact operation/facility bindings, distinguishes indeterminate evidence from an incomparable measurement, permits an indeterminate executor effect status, requires canonical-key and declared-control-domain separation, binds source status, validity, quorum, observation windows, and attestation delay, and makes remedies separately authorized actions. It preserves the limitation that signed observations are claims by pinned sources rather than proof of physical truth. 13. Normative References [I-D.schrock-ep-outcome-binding] Schrock, I., "Outcome Binding for Authorized Actions and Independently Observed Effects", Work in Progress, Internet-Draft, draft-schrock-ep-outcome-binding-00, July 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Schrock Expires 29 January 2027 [Page 6] Internet-Draft Model-to-Matter July 2026 [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . Author's Address Iman Schrock EMILIA Protocol, Inc. United States of America Email: team@emiliaprotocol.ai Schrock Expires 29 January 2027 [Page 7]