| Internet-Draft | Auditable Model Deliberation | August 2026 |
| Mashayekhi | Expires 13 February 2027 | [Page] |
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.¶
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 (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 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.¶
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.¶
The protocol objective is to make a deliberation auditable through immutable, typed, content-addressed public artifacts.¶
This document specifies:¶
This document does not standardize:¶
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].¶
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.¶
A published artifact in version 0.1 is a JSON object with
these core members:¶
protocol_version
0.1.¶
artifact_id
artifact_type
payload
references
extensions
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.¶
Each reference MUST identify a target
artifact_id. It MAY include one relation
from this core vocabulary:¶
{
"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.¶
A CLAIM introduces a proposition that can be supported,
challenged, revised, or decided.¶
Its payload MUST contain a non-empty
statement string.¶
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.¶
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.¶
A REVISION creates a new position without mutating history.¶
Its payload MUST contain a non-empty
statement string. It MUST carry at least
one revises or supersedes reference.¶
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.¶
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.¶
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.¶
The version 0.1 provenance classes are:¶
TRACE_VERIFIED_OBSERVATION
EXTERNAL_EVIDENCE
MODEL_GENERATED_ANALYSIS
HYPOTHESIS
Model-generated quantitative language MUST NOT be represented as independently observed empirical evidence unless it is separately grounded in an admissible source.¶
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.¶
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.¶
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.¶
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.¶
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.¶
JSON processing follows [RFC8259] subject to the additional restrictions in this section. Text is UTF-8 as specified by [RFC3629].¶
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.¶
An implementation MUST reject:¶
Every string and member name MUST be normalized to Unicode Normalization Form C as defined by [UNICODE-NORMALIZATION].¶
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.¶
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.¶
artifact_id member if present.¶
sha256: followed by 64 lowercase hexadecimal digits.¶
A nested member named artifact_id
MUST NOT be removed.¶
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.¶
This restricted profile does not claim conformance with the JSON Canonicalization Scheme in [RFC8785].¶
The public repository contains four positive and eleven negative vectors. Passing those vectors establishes tested profile behavior for one implementation, not independent interoperability.¶
A conformance claim MUST identify one or more targets:¶
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.¶
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.¶
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.¶
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.¶
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.¶
Implementations should define limits for:¶
A limit-induced failure SHOULD be explicit rather than appearing as successful truncation.¶
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.¶
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.¶
This revision defines no wire-level privacy labels. See [RFC6973] for privacy-design guidance.¶
This document requests no IANA actions.¶
Work deferred beyond revision -00 includes:¶
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.¶