Auditable Public Artifacts for Model-Independent Deliberation

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.

Objective The protocol objective is to make a deliberation auditable through immutable, typed, content-addressed public artifacts.

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.

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.

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 when, and only when, they appear in all capitals, as shown here. The BCP 14 subseries comprises the requirement-language specifications cited above; see .

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.

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.

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 .
artifact_type: One of the seven core types defined in .
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.

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

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.

Core Artifact Semantics

CLAIM A CLAIM introduces a proposition that can be supported, challenged, revised, or decided. Its payload MUST contain a non-empty statement string.

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 . Supporting evidence MUST carry an applicable supports reference.

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.

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

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.

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.

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.

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.

Model-generated quantitative language MUST NOT be represented as independently observed empirical evidence unless it is separately grounded in an admissible source.

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.

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.

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.

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

Restricted Canonical JSON and Artifact Identity JSON processing follows subject to the additional restrictions in this section. Text is UTF-8 as specified by .

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.

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.

Unicode Normalization and Member Ordering Every string and member name MUST be normalized to Unicode Normalization Form C as defined by . 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.

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.

Identifier Calculation

Validate the complete artifact.
Create a logical copy of the top-level object.
Remove exactly the top-level artifact_id member if present.
Serialize the remaining object under this profile.
Calculate SHA-256 as defined by over the exact bytes.
Encode sha256: followed by 64 lowercase hexadecimal digits.

A nested member named artifact_id MUST NOT be removed.

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.

Profile Boundary This restricted profile does not claim conformance with the JSON Canonicalization Scheme in . The public repository contains four positive and eleven negative vectors. Passing those vectors establishes tested profile behavior for one implementation, not independent interoperability.

Conformance A conformance claim MUST identify one or more targets:

canonical JSON and identifier conformance;
artifact-semantic validation conformance; or
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.

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. defines Knowledge Units produced by a particular multi-model process. defines signed receipts. addresses intent context and authorization dialogue. 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.

Research Context KQML and FIPA ACL established typed communicative acts and explicit agent communication semantics. MCP standardizes access to tools, resources, prompts, and context. A2A standardizes task and application interoperability. 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 motivates structured model interaction, while later evaluation cautions that debate does not consistently outperform simple baselines. Free-MAD challenges majority consensus, CIPHER explores embedding exchange, and G2CP explores graph-grounded communication. This document claims no priority, replacement, compatibility, or adoption with respect to these systems.

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.

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.

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 for security-consideration guidance.

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. This revision defines no wire-level privacy labels. See for privacy-design guidance.

IANA Considerations This document requests no IANA actions.

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.

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.