Network Working Group M. Mashayekhi Internet-Draft Independent Researcher Intended status: Experimental 12 August 2026 Expires: 13 February 2027 Auditable Public Artifacts for Model-Independent Deliberation draft-mashayekhi-auditable-model-deliberation-00 Abstract Heterogeneous artificial-intelligence systems can exchange messages without sharing stable semantics for claims, evidence, objections, revisions, decisions, failures, and termination. This document defines an experimental public-artifact protocol for model- independent deliberation. It separates interoperable public state from private model computation and does not require disclosure of chain-of-thought, hidden state, prompts, model weights, or private memory. The document defines seven public artifact types, append-only revision, evidence provenance, blocking-objection closure, explicit failure and termination, a restricted canonical JSON profile, and SHA-256-based artifact identifiers. It does not define transport, signatures, authorization, model execution, or a completed consensus system. 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 13 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Mashayekhi Expires 13 February 2027 [Page 1] Internet-Draft Auditable Model Deliberation August 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Objective . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. Architectural Invariant . . . . . . . . . . . . . . . . . . . 5 4. Abstract Artifact Model . . . . . . . . . . . . . . . . . . . 5 4.1. Reference Object . . . . . . . . . . . . . . . . . . . . 5 4.2. Example Shape . . . . . . . . . . . . . . . . . . . . . . 6 5. Core Artifact Semantics . . . . . . . . . . . . . . . . . . . 6 5.1. CLAIM . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. EVIDENCE . . . . . . . . . . . . . . . . . . . . . . . . 6 5.3. OBJECTION . . . . . . . . . . . . . . . . . . . . . . . . 6 5.4. REVISION . . . . . . . . . . . . . . . . . . . . . . . . 6 5.5. DECISION . . . . . . . . . . . . . . . . . . . . . . . . 7 5.6. FAILURE . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.7. TERMINATION . . . . . . . . . . . . . . . . . . . . . . . 7 6. Evidence Provenance . . . . . . . . . . . . . . . . . . . . . 7 7. Immutable History . . . . . . . . . . . . . . . . . . . . . . 8 8. Reference Graph and Decision Closure . . . . . . . . . . . . 8 9. Failure and Recovery . . . . . . . . . . . . . . . . . . . . 8 10. Versioning and Extensions . . . . . . . . . . . . . . . . . . 8 11. Restricted Canonical JSON and Artifact Identity . . . . . . . 9 11.1. Admitted Values . . . . . . . . . . . . . . . . . . . . 9 11.2. Input Rejection . . . . . . . . . . . . . . . . . . . . 9 11.3. Unicode Normalization and Member Ordering . . . . . . . 9 11.4. Serialization . . . . . . . . . . . . . . . . . . . . . 10 11.5. Identifier Calculation . . . . . . . . . . . . . . . . . 10 11.6. Identifier Verification . . . . . . . . . . . . . . . . 10 11.7. Profile Boundary . . . . . . . . . . . . . . . . . . . . 10 12. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 11 13. Related Work and Protocol Boundaries . . . . . . . . . . . . 11 14. Research Context . . . . . . . . . . . . . . . . . . . . . . 11 15. Experimental Evidence and Limitations . . . . . . . . . . . . 12 16. Operational Considerations . . . . . . . . . . . . . . . . . 12 17. Security Considerations . . . . . . . . . . . . . . . . . . . 13 18. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 Mashayekhi Expires 13 February 2027 [Page 2] Internet-Draft Auditable Model Deliberation August 2026 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 20. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 14 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 22.1. Normative References . . . . . . . . . . . . . . . . . . 14 22.2. Informative References . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction Messaging interoperability does not imply deliberation interoperability. A transcript or tool-call sequence does not inherently define what was claimed, what evidence was admitted, what was challenged, what changed, which objections remain unresolved, or whether a final decision is closed over its public record. This document defines a narrow public-artifact layer. An independent reviewer can inspect the public record without accessing private model cognition or provider-internal state. 1.1. Objective The protocol objective is to make a deliberation auditable through immutable, typed, content-addressed public artifacts. 1.2. Scope This document specifies: * core public artifact semantics; * an abstract artifact data model; * evidence provenance classes; * append-only history and revision; * reference-graph and decision-closure behavior; * explicit failure and termination; * version and extension behavior; and * a restricted canonical JSON and identifier profile. Mashayekhi Expires 13 February 2027 [Page 3] Internet-Draft Auditable Model Deliberation August 2026 1.3. Non-Goals This document does not standardize: * transport or message delivery; * model inference or orchestration; * tool execution; * prompt construction; * model selection; * authentication, authorization, or signatures; * private reasoning representation; or * a fixed number or sequence of deliberation rounds. 2. Conventions and Terminology 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. The BCP 14 subseries comprises the requirement-language specifications cited above; see [BCP14]. Public artifact An inspectable protocol object intended to cross the interoperability boundary. Public means shared with the authorized participants at that boundary; it does not imply unrestricted Internet disclosure. Private model state Implementation-internal material not required for protocol interoperability. Deliberation A set of public artifacts and references through which claims can be supported, challenged, revised, and decided. Closure The artifacts transitively reachable through protocol references from a declared decision or tip set. Blocking objection An objection that prevents a decision from claiming closed status until the objection receives a public disposition. Mashayekhi Expires 13 February 2027 [Page 4] Internet-Draft Auditable Model Deliberation August 2026 3. Architectural Invariant A decision MUST be auditable from public artifacts without requiring private model state. An implementation MAY use arbitrary private computation to produce an artifact. It MUST NOT require another participant to disclose private chain-of-thought as a condition of interoperability. 4. Abstract Artifact Model A published artifact in version 0.1 is a JSON object with these core members: protocol_version The protocol profile. The value defined by this document is 0.1. artifact_id The content-addressed identity defined in Section 11. artifact_type One of the seven core types defined in Section 5. payload Type-specific public data. references An array of references to prior public artifacts. extensions An optional object containing namespaced extension data. Additional metadata MUST NOT silently change the semantics of a core member. Transport addresses, provider identifiers, model names, prompts, tool invocation metadata, and private model state are not core members. 4.1. Reference Object Each reference MUST identify a target artifact_id. It MAY include one relation from this core vocabulary: * supports; * objects-to; * revises; * supersedes; * considers; or Mashayekhi Expires 13 February 2027 [Page 5] Internet-Draft Auditable Model Deliberation August 2026 * decides. 4.2. Example Shape { "protocol_version": "0.1", "artifact_id": "sha256:<64-lowercase-hex>", "artifact_type": "CLAIM", "payload": { "statement": "A public proposition" }, "references": [], "extensions": {} } The example illustrates the common envelope. It does not assign a valid identifier to the placeholder body. 5. Core Artifact Semantics 5.1. CLAIM A CLAIM introduces a proposition that can be supported, challenged, revised, or decided. Its payload MUST contain a non-empty statement string. 5.2. EVIDENCE An EVIDENCE artifact provides support relevant to one or more artifacts. Its payload MUST contain a non-empty content string and one provenance_class value from Section 6. Supporting evidence MUST carry an applicable supports reference. 5.3. OBJECTION An OBJECTION challenges an artifact or protocol assumption. Its payload MUST contain a non-empty statement string and a Boolean blocking member. It MUST carry at least one objects-to reference. 5.4. REVISION A REVISION creates a new position without mutating history. Mashayekhi Expires 13 February 2027 [Page 6] Internet-Draft Auditable Model Deliberation August 2026 Its payload MUST contain a non-empty statement string. It MUST carry at least one revises or supersedes reference. 5.5. DECISION A DECISION records an outcome and its declared closure. Its payload MUST contain a non-empty outcome string, a status value of provisional or final, an objection_dispositions array, and an unresolved_issues array. A final decision MUST NOT omit a reachable unresolved blocking objection. 5.6. FAILURE A FAILURE records that processing could not complete. Its payload MUST contain non-empty code and description strings and a Boolean retryable member. A failure MUST NOT be silently converted into success. 5.7. TERMINATION A TERMINATION payload MUST contain a state value of completed, suspended, cancelled, deadlock, or exhausted. A completed termination MUST reference a final decision. A deadlock or exhausted termination MUST preserve relevant unresolved blocking objections. 6. Evidence Provenance The version 0.1 provenance classes are: TRACE_VERIFIED_OBSERVATION Evidence supported by an explicitly admitted execution or trace source. EXTERNAL_EVIDENCE Evidence supplied from an explicit external source admitted by the protocol context. MODEL_GENERATED_ANALYSIS A calculation, critique, estimate, simulation, or other analytical product generated by a participant. HYPOTHESIS A proposition offered for future validation rather than as an observed result. Mashayekhi Expires 13 February 2027 [Page 7] Internet-Draft Auditable Model Deliberation August 2026 Model-generated quantitative language MUST NOT be represented as independently observed empirical evidence unless it is separately grounded in an admissible source. 7. Immutable History An artifact identifier MUST bind to one artifact body. Once accepted into append-only history, the artifact MUST NOT be silently replaced. An identical resubmission MAY be treated as idempotent. A changed body MUST receive a new identity. Corrections MUST be new artifacts with explicit references to prior artifacts. 8. Reference Graph and Decision Closure Version 0.1 uses a directed acyclic public artifact graph. A closure verifier MUST reject a reference cycle. Multiple concurrent tips are permitted. A required unavailable reference causes closure verification to fail. An implementation MUST NOT construct a successful partial closure when a required artifact is unavailable. A decision declares its audited closure through references. A final decision MUST NOT hide an unresolved blocking objection reachable from that closure. Majority agreement is neither required nor sufficient for closure. Voting or scoring MAY inform a decision, but MUST NOT hide a reachable unresolved blocking objection. This document does not standardize role reliability, voting weights, or adjudication thresholds. 9. Failure and Recovery Protocol failure and transport failure are distinct. If processing cannot continue, an implementation must expose an explicit failure outcome rather than silently truncating the record. A retry MUST NOT erase a canonical failure that belongs to the auditable record. 10. Versioning and Extensions An implementation MUST reject an unsupported major version and MUST NOT infer minor-version compatibility. A different minor version MAY be accepted only under an explicit compatibility rule. Mashayekhi Expires 13 February 2027 [Page 8] Internet-Draft Auditable Model Deliberation August 2026 Extension data MUST remain separate from core members. Unknown extensions MUST NOT change core semantics. This document defines no critical-extension mechanism and requests no extension registry. 11. Restricted Canonical JSON and Artifact Identity JSON processing follows [RFC8259] subject to the additional restrictions in this section. Text is UTF-8 as specified by [RFC3629]. 11.1. Admitted Values An admitted value is null, a Boolean, a Unicode string, an integer, an array of admitted values, or an object with string member names and admitted values. Floating-point values, decimal fractions, exponents, non-finite numbers, comments, binary values, and implementation-specific JSON extensions are not admitted. Integers are restricted to the inclusive range -9007199254740991 through 9007199254740991. An artifact submitted for identifier calculation MUST be a top-level object. 11.2. Input Rejection An implementation MUST reject: * malformed JSON; * a UTF-8 byte-order mark; * invalid UTF-8; * duplicate object member names; * unpaired surrogate code points; * integers outside the admitted range; * normalization collisions; and * values outside the admitted domain. 11.3. Unicode Normalization and Member Ordering Every string and member name MUST be normalized to Unicode Normalization Form C as defined by [UNICODE-NORMALIZATION]. Mashayekhi Expires 13 February 2027 [Page 9] Internet-Draft Auditable Model Deliberation August 2026 If distinct input member names become identical after normalization, the object MUST be rejected. Object members MUST be sorted by ascending unsigned bytes of the normalized, unescaped member name encoded as UTF-8. 11.4. Serialization Quotation mark, reverse solidus, backspace, form feed, line feed, carriage return, and horizontal tab use their short JSON escapes. Other control characters U+0000 through U+001F use lowercase \u00xx form. Other Unicode scalar values are emitted directly as UTF-8. Solidus is not escaped. Integers use base-10 with no plus sign, leading zero, or exponent. Arrays retain order. Commas and colons have no surrounding whitespace. The result has no byte-order mark and no trailing newline. 11.5. Identifier Calculation 1. Validate the complete artifact. 2. Create a logical copy of the top-level object. 3. Remove exactly the top-level artifact_id member if present. 4. Serialize the remaining object under this profile. 5. Calculate SHA-256 as defined by [RFC6234] over the exact bytes. 6. Encode sha256: followed by 64 lowercase hexadecimal digits. A nested member named artifact_id MUST NOT be removed. 11.6. Identifier Verification The submitted artifact MUST contain one top-level artifact_id whose value matches sha256:[0-9a-f]{64}. A verifier MUST independently calculate and compare the complete identifier. A mismatch is an integrity failure. 11.7. Profile Boundary This restricted profile does not claim conformance with the JSON Canonicalization Scheme in [RFC8785]. Mashayekhi Expires 13 February 2027 [Page 10] Internet-Draft Auditable Model Deliberation August 2026 The public repository contains four positive and eleven negative vectors. Passing those vectors establishes tested profile behavior for one implementation, not independent interoperability. 12. Conformance A conformance claim MUST identify one or more targets: 1. canonical JSON and identifier conformance; 2. artifact-semantic validation conformance; or 3. closure-verification conformance. Canonical-profile conformance MUST NOT be presented as complete protocol conformance. Independent cross-implementation interoperability is an evidence goal, not a prerequisite for publication of this experimental revision. 13. Related Work and Protocol Boundaries KQML and FIPA-ACL historically separated communicative acts from content and ontology. Contemporary systems such as MCP, A2A, and ACP address tool, context, application, or agent communication layers. This document addresses the narrower semantics of public deliberation artifacts. [I-D.farley-acta-knowledge-units] defines Knowledge Units produced by a particular multi-model process. [I-D.farley-acta-signed-receipts] defines signed receipts. [I-D.ovidi-lip-4d] addresses intent context and authorization dialogue. [I-D.c4tz-marc] addresses control and uncertainty disclosure. This document does not prescribe a fixed round sequence, a knowledge- base output format, signatures, or an authorization dialogue. No priority, replacement, compatibility, or endorsement claim is made. 14. Research Context KQML [KQML] and FIPA ACL [FIPA-ACL] established typed communicative acts and explicit agent communication semantics. MCP [MCP] standardizes access to tools, resources, prompts, and context. A2A [A2A] standardizes task and application interoperability. ACP [ACP] is historical lineage that has joined A2A. These complementary layers do not define the artifact and closure semantics in this document. Mashayekhi Expires 13 February 2027 [Page 11] Internet-Draft Auditable Model Deliberation August 2026 Multi-agent debate [MAD] motivates structured model interaction, while later evaluation [MAD-EVAL] cautions that debate does not consistently outperform simple baselines. Free-MAD [FREE-MAD] challenges majority consensus, CIPHER [CIPHER] explores embedding exchange, and G2CP [G2CP] explores graph-grounded communication. This document claims no priority, replacement, compatibility, or adoption with respect to these systems. 15. Experimental Evidence and Limitations The design was informed by a completed twelve-round heterogeneous relay, a fail-closed full-history stress attempt, and targeted deterministic prototype tests. The completed relay used single-hop direct context. The stress attempt stopped at Round 2. The deterministic tests did not use paid model execution. The public fifteen-vector suite tests one reference implementation. This evidence does not prove efficiency, accuracy, scale, adversarial security, privacy safety, universal compatibility, or independent interoperability. 16. Operational Considerations Implementations should define limits for: * artifact size; * graph depth; * closure size; * reference fan-out; * retry behavior; and * resource consumption. A limit-induced failure SHOULD be explicit rather than appearing as successful truncation. Mashayekhi Expires 13 February 2027 [Page 12] Internet-Draft Auditable Model Deliberation August 2026 17. Security Considerations Relevant actors include artifact producers, recipients, closure verifiers, orchestrators, evidence providers, storage operators, and attackers able to submit or replay artifacts. Protected assets include artifact integrity, provenance, decision closure, authorization policy, private state, sensitive application data, and availability. Trust boundaries exist between private computation and shared artifacts, transports and validators, external evidence and policy, and artifact storage and closure verification. Threats include forgery, impersonation, replay, equivocation, malicious references, provenance spoofing, prompt injection, evidence poisoning, role hijacking, omitted objections, false closure, adversarial extensions, and graph-based denial of service. Implementations SHOULD authenticate producers when attribution is required, reject identifier mismatches and cycles, enforce resource limits, separate untrusted evidence from policy, preserve blocking objections, and fail closed on unavailable required references. Content addressing does not establish identity, authorization, freshness, non-repudiation, or evidence truth. See [RFC3552] for security-consideration guidance. 18. Privacy Considerations Public means shared at the interoperability boundary and does not imply unrestricted Internet disclosure. A conforming implementation MUST NOT require disclosure of private chain-of-thought or private model state. Implementations SHOULD minimize payloads and provider metadata, disclose artifacts only to authorized recipients, define retention and deletion policy, and protect logs and backups. Stable identifiers and reference graphs can create linkability and correlation across sessions. Deployments SHOULD avoid unnecessary personal or cross-context identifiers and document secondary-use restrictions. Sanitization occurs before publication or forwarding. Removing chain-of-thought alone does not remove personal data, secrets, confidential evidence, or sensitive metadata. Mashayekhi Expires 13 February 2027 [Page 13] Internet-Draft Auditable Model Deliberation August 2026 This revision defines no wire-level privacy labels. See [RFC6973] for privacy-design guidance. 19. IANA Considerations This document requests no IANA actions. 20. Future Work Work deferred beyond revision -00 includes: * authentication and signature profiles; * transport bindings and media types; * extension registries; * bounded-history checkpoints; * binary encodings; * compact wire grammars; * privacy-class labels; * independent implementations; and * cross-implementation testing. 21. Acknowledgements This document derives from an experimental research program on heterogeneous model deliberation and from public review of the MSB research repository. The author thanks reviewers who identify ambiguities, unsupported claims, privacy risks, and interoperability failures. 22. References 22.1. Normative References [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, March 1997, . Mashayekhi Expires 13 February 2027 [Page 14] Internet-Draft Auditable Model Deliberation August 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [UNICODE-NORMALIZATION] Unicode Consortium, "Unicode Normalization Forms", Unicode Standard Annex 15, 2026, . 22.2. Informative References [KQML] Finin, T., Fritzson, R., McKay, D., and R. McEntire, "KQML as an Agent Communication Language", DOI 10.1145/191246.191322, 1994, . [FIPA-ACL] Foundation for Intelligent Physical Agents, "FIPA Communicative Act Library Specification", FIPA SC00037, 2002, . [MCP] Model Context Protocol Project, "Model Context Protocol Specification", 2026, . [A2A] Agent2Agent Project, "Agent2Agent Protocol", 2026, . [ACP] BeeAI Community, "Agent Communication Protocol", 2025, . Mashayekhi Expires 13 February 2027 [Page 15] Internet-Draft Auditable Model Deliberation August 2026 [MAD] Du, Y., Li, S., Torralba, A., Tenenbaum, J. B., and I. Mordatch, "Improving Factuality and Reasoning in Language Models through Multiagent Debate", arXiv 2305.14325, 2023, . [MAD-EVAL] Zhang, H., Cui, Z., Chen, J., Wang, X., Zhang, Q., Wang, Z., Wu, D., and S. Hu, "Stop Overvaluing Multi-Agent Debate -- We Must Rethink Evaluation and Embrace Model Heterogeneity", arXiv 2502.08788, 2025, . [FREE-MAD] Cui, Y., Fu, H., Zhang, H., Wang, L., and C. Zuo, "Free- MAD: Consensus-Free Multi-Agent Debate", arXiv 2509.11035, 2025, . [CIPHER] Pham, C., Liu, B., Yang, Y., Chen, Z., Liu, T., Yuan, J., Plummer, B. A., Wang, Z., and H. Yang, "Let Models Speak Ciphers: Multiagent Debate through Embeddings", ICLR 2024, arXiv 2310.06272, 2024, . [G2CP] Ben Khaled, K. and D. Monticolo, "G2CP: A Graph-Grounded Communication Protocol for Verifiable and Efficient Multi- Agent Reasoning", arXiv 2602.13370, 2026, . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . [RFC6973] Cooper, A. and H. Tschofenig, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [I-D.farley-acta-knowledge-units] Farley, T., "Knowledge Units for Multi-Model Deliberation", Work in Progress, Internet-Draft, draft- farley-acta-knowledge-units-00, April 2026, . Mashayekhi Expires 13 February 2027 [Page 16] Internet-Draft Auditable Model Deliberation August 2026 [I-D.farley-acta-signed-receipts] Farley, T., "Signed Decision Receipts for Machine-to- Machine Access Control", Work in Progress, Internet-Draft, draft-farley-acta-signed-receipts, 2026, . [I-D.ovidi-lip-4d] Ovidi, O., "LIP-4D: An Intent Context and Authorization Protocol for AI Agents", Work in Progress, Internet-Draft, draft-ovidi-lip-4d-00, July 2026, . [I-D.c4tz-marc] c4tz, C., "MARC: A Control and Uncertainty Disclosure Profile for Generative Models and Agents", Work in Progress, Internet-Draft, draft-c4tz-marc-02, May 2026, . Author's Address Mohsen Mashayekhi Independent Researcher Email: mmohsen.m@gmail.com URI: https://github.com/MasonMash/MSB Mashayekhi Expires 13 February 2027 [Page 17]