MARC: A Control and Uncertainty Disclosure Profile for Generative Models and Agents
draft-c4tz-marc-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | c4tz | ||
| Last updated | 2026-10-04 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-c4tz-marc-03
Network Working Group c4tz
Internet-Draft c0dx3
Intended status: Experimental 4 October 2026
Expires: 7 April 2027
MARC: A Control and Uncertainty Disclosure Profile for Generative Models
and Agents
draft-c4tz-marc-03
Abstract
This document specifies MARC, an experimental, vendor-neutral profile
for control and uncertainty-disclosure metadata in generative models
and agentic systems. MARC separates pre-decision capability
assessment from post-decision answer confidence, identifies
uncertainty sources and confidence targets, and defines a bounded set
of primary actions and a minimal disclosure object.
The experiment evaluates whether independently developed components
can exchange and interpret these metadata consistently across
implementation and protocol boundaries. It also supports evaluation
of action selection, uncertainty attribution, confidence calibration,
and downstream presentation.
MARC specifies externally observable semantics. It does not define
model internals, transport, authentication, authorization, agent
discovery, tool schemas, or task execution, and it does not require
disclosure of internal reasoning. The intended users are
implementers of agent runtimes, orchestration layers, model gateways,
evaluation systems, and user interfaces. This document does not
define an Internet Standard.
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."
c4tz Expires 7 April 2027 [Page 1]
Internet-Draft MARC October 2026
This Internet-Draft will expire on 7 April 2027.
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements Language and Terminology . . . . . . . . . . . . 6
4. Design Goals and Non-Goals . . . . . . . . . . . . . . . . . 7
4.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Experimental Scope and Objectives . . . . . . . . . . . . 8
4.3.1. Semantic Interoperability . . . . . . . . . . . . . . 8
4.3.2. Operational Evaluation . . . . . . . . . . . . . . . 9
4.3.3. Reporting and Assessment . . . . . . . . . . . . . . 10
4.3.4. Limits of the Experiment . . . . . . . . . . . . . . 10
5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Ambiguous User Request . . . . . . . . . . . . . . . . . 11
6.2. Retrieval-Augmented Answering . . . . . . . . . . . . . . 11
6.3. Agent Tool Invocation . . . . . . . . . . . . . . . . . . 12
6.4. API Gateway or Orchestration Layer . . . . . . . . . . . 12
6.5. Agent-to-Agent Handoff . . . . . . . . . . . . . . . . . 12
6.6. High-Risk Domain Escalation . . . . . . . . . . . . . . . 12
7. Architecture and Processing Model . . . . . . . . . . . . . . 12
7.1. Functional Components . . . . . . . . . . . . . . . . . . 12
7.2. Processing Stages . . . . . . . . . . . . . . . . . . . . 13
7.3. State Machine . . . . . . . . . . . . . . . . . . . . . . 13
8. MARC Values and Decision Policy . . . . . . . . . . . . . . . 14
8.1. Pre-Decision Capability . . . . . . . . . . . . . . . . . 14
8.2. Uncertainty Attribution . . . . . . . . . . . . . . . . . 14
8.3. Remediability . . . . . . . . . . . . . . . . . . . . . . 15
8.4. Post-Decision Confidence . . . . . . . . . . . . . . . . 16
8.5. Confidence Band . . . . . . . . . . . . . . . . . . . . . 16
8.6. Confidence Target . . . . . . . . . . . . . . . . . . . . 17
8.7. Primary Action Set . . . . . . . . . . . . . . . . . . . 17
8.8. Action Selection . . . . . . . . . . . . . . . . . . . . 18
8.9. Action Semantics . . . . . . . . . . . . . . . . . . . . 19
c4tz Expires 7 April 2027 [Page 2]
Internet-Draft MARC October 2026
9. MARC-Core Object . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Required and Optional Fields . . . . . . . . . . . . . . 20
9.2. Enumerated Values . . . . . . . . . . . . . . . . . . . . 21
9.3. Validation Constraints . . . . . . . . . . . . . . . . . 22
9.4. Cross-Field Consistency Constraints . . . . . . . . . . . 22
9.5. JSON Example . . . . . . . . . . . . . . . . . . . . . . 23
10. MARC-Disclosure Object . . . . . . . . . . . . . . . . . . . 24
10.1. Meaning of the Answer Field . . . . . . . . . . . . . . 24
10.2. Projection from MARC-Core . . . . . . . . . . . . . . . 24
10.3. Disclosure Constraints . . . . . . . . . . . . . . . . . 25
11. Versioning and Extension Rules . . . . . . . . . . . . . . . 25
12. Relationship to Agent Communication Protocols . . . . . . . . 26
12.1. Example Carrier Locations . . . . . . . . . . . . . . . 27
13. Operational Profiles . . . . . . . . . . . . . . . . . . . . 27
13.1. MARC-Core Only . . . . . . . . . . . . . . . . . . . . . 27
13.2. MARC-Disclosure . . . . . . . . . . . . . . . . . . . . 28
13.3. MARC-Carrying . . . . . . . . . . . . . . . . . . . . . 28
14. Human Factors Considerations . . . . . . . . . . . . . . . . 28
15. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 29
16. Security Considerations . . . . . . . . . . . . . . . . . . . 29
17. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31
18. Manipulation-Resistance Considerations . . . . . . . . . . . 31
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
20. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 32
20.1. Minimum Viable Conformance . . . . . . . . . . . . . . . 32
20.2. Conformance Classes . . . . . . . . . . . . . . . . . . 33
21. Interoperability and Operational Considerations . . . . . . . 34
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
22.1. Normative References . . . . . . . . . . . . . . . . . . 34
22.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. End-to-End Decision Flow Example . . . . . . . . . . 36
Appendix B. Example MARC-Core Records . . . . . . . . . . . . . 38
B.1. Ambiguous Request . . . . . . . . . . . . . . . . . . . . 38
B.2. Missing Evidence . . . . . . . . . . . . . . . . . . . . 38
B.3. Tool Use . . . . . . . . . . . . . . . . . . . . . . . . 39
B.4. Capability Limit in a High-Risk Setting . . . . . . . . . 39
B.5. Answer . . . . . . . . . . . . . . . . . . . . . . . . . 40
Appendix C. Example MARC-Disclosure Objects . . . . . . . . . . 40
C.1. Clarification Disclosure . . . . . . . . . . . . . . . . 41
C.2. Answer After Retrieval Disclosure . . . . . . . . . . . . 41
Appendix D. Non-Normative JSON Schemas . . . . . . . . . . . . . 41
D.1. MARC-Core JSON Schema . . . . . . . . . . . . . . . . . . 41
D.2. MARC-Disclosure JSON Schema . . . . . . . . . . . . . . . 45
Appendix E. Evaluation Considerations . . . . . . . . . . . . . 47
Appendix F. Design Rationale and Literature Traceability . . . . 49
Appendix G. Changes from -02 . . . . . . . . . . . . . . . . . . 49
Appendix H. Validation Test Vectors . . . . . . . . . . . . . . 50
H.1. Valid ANSWER Record . . . . . . . . . . . . . . . . . . . 50
c4tz Expires 7 April 2027 [Page 3]
Internet-Draft MARC October 2026
H.2. Invalid ANSWER without post_answer_confidence . . . . . . 51
H.3. Invalid primary_source none . . . . . . . . . . . . . . . 51
H.4. Invalid Score Range . . . . . . . . . . . . . . . . . . . 52
H.5. Invalid confidence_target for ANSWER . . . . . . . . . . 52
H.6. Invalid MARC-Disclosure Confidence Target for ANSWER . . 53
Appendix I. Implementation Status . . . . . . . . . . . . . . . 53
Appendix J. Open Issues . . . . . . . . . . . . . . . . . . . . 55
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction
Generative models and agentic systems increasingly combine answering,
retrieval, tool invocation, and user interaction within a single
workflow. In many deployments, these behaviors are implemented as
separate heuristics, producing inconsistent handling of uncertainty,
unnecessary tool calls, silent failure, misleading refusals, or user
overreliance.
MARC defines a vendor-neutral profile for control metadata and
structured uncertainty disclosure. It leaves model internals and
internal scoring methods unspecified. Instead, it defines the
semantics of capability and uncertainty assessments, a bounded
primary-action set, confidence targets, and a minimal disclosure
profile. These semantics can be implemented by a base model, an
external orchestrator, a model gateway, an agent runtime, or a hybrid
architecture.
This document is proposed for publication as an Experimental RFC
through the Independent Submission Stream. It is not an IETF working
group product, does not claim IETF consensus, and does not define an
Internet Standard or a mandatory deployment architecture.
The experiment investigates whether independently developed emitters,
receivers, validators, and orchestration components can exchange and
interpret common MARC semantics. It distinguishes agreement about
the meaning of a field from agreement about a model's assessment:
different models can assign different scores or select different
actions without changing the meaning of the metadata.
MARC metadata can be carried by other protocols, APIs, task
envelopes, event streams, or audit logs. The Internet
interoperability question is whether a receiving component can retain
the meaning and association of control and uncertainty metadata when
a workflow crosses component or administrative boundaries. The
experimental objectives and reporting guidance are described in
Section 4.3.
c4tz Expires 7 April 2027 [Page 4]
Internet-Draft MARC October 2026
The design is motivated by findings that current large language
models often exhibit weak metacognitive reporting in high-stakes
reasoning tasks [GRIOT2025], that users can become overconfident when
systems provide longer or default explanations [STEYVERS-KNOW2025],
that metacognitive triggering can improve tool-use decisions
[LI-MECO2025], and that identifying the source of uncertainty is
distinct from merely abstaining [LIU-CONFUSE2025]. Work on cognitive
offloading further motivates treating retrieval and tool use as
value-based control choices rather than universal fallbacks
[GILBERT2024].
MARC also separates pre-decision capability assessment from post-
decision confidence about the selected answer. This separation is
motivated in part by evidence that LLM confidence can be biased by
prior answer commitment and by the visibility of the model's own
earlier output [KUMARAN2026].
2. Problem Statement
Generative and agentic systems lack a common, implementation-neutral
way to represent the control state associated with uncertainty-aware
action selection. In particular, downstream systems often cannot
distinguish between the following situations:
* the request is ambiguous and user clarification is the best next
action;
* current evidence is missing, inaccessible, insufficient, or stale,
and retrieval would likely help;
* the system lacks competence for the task even after available
resources are considered;
* available evidence is materially inconsistent and should be
reconciled or escalated;
* a safety, legal, or policy constraint limits execution or
disclosure; or
* a candidate answer has been produced, but its confidence should be
disclosed with a calibrated band rather than a fine-grained score.
Without a shared representation, one system's refusal, tool call,
confidence label, or escalation hint may be opaque to another system.
This weakens auditability, makes evaluation brittle, and can create
inconsistent user experiences across otherwise similar deployments.
MARC addresses this problem by defining interoperable metadata for:
c4tz Expires 7 April 2027 [Page 5]
Internet-Draft MARC October 2026
* pre-decision capability assessment;
* uncertainty-source attribution;
* remediability of the uncertainty state;
* selected primary action;
* post-decision answer confidence when an answer candidate exists;
* confidence-target semantics; and
* a minimal disclosure profile suitable for user interfaces or
downstream consumers.
MARC intentionally limits itself to externally observable semantics.
It does not require disclosure of chain-of-thought, hidden prompts,
raw internal activations, training data, or model architecture.
3. Requirements Language 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.
Base model The generative model that produces candidate outputs.
Controller The component that computes MARC signals, selects a
primary action, and emits a MARC-Core record. The controller MAY
be part of the base model, an external orchestrator, a gateway, or
a hybrid component.
Decision point A point in a generative or agentic workflow at which
the controller selects one primary action from the MARC action
set.
Emitter The component or system that emits a MARC-Core or MARC-
Disclosure object.
Externalization The use of resources external to the base model at
the current decision point, including retrieval, non-retrieval
tool invocation, and human escalation.
MARC-Core The structured record emitted for logging, orchestration,
audit, evaluation, or downstream exchange.
c4tz Expires 7 April 2027 [Page 6]
Internet-Draft MARC October 2026
MARC-Disclosure The minimum structured information exposed to a
downstream system or end user about answer content, uncertainty
source, confidence band, confidence target, and recommended next
step.
Receiver The component or system that consumes a MARC-Core or MARC-
Disclosure object.
Remediability The best available class of intervention for the
currently observed uncertainty state.
4. Design Goals and Non-Goals
4.1. Design Goals
MARC has the following design goals:
* Define a small, interoperable set of control and uncertainty-
disclosure metadata that can be exchanged across orchestration
layers, agent runtimes, evaluation systems, and audit pipelines.
* Separate monitoring, uncertainty attribution, action selection,
confidence targeting, and disclosure.
* Support calibrated user-facing uncertainty communication without
requiring exposure of chain-of-thought or raw internal reasoning.
* Permit heterogeneous implementations while preserving common
action semantics.
* Reduce harmful overreliance, false reassurance, unnecessary
externalization, and anthropomorphic interpretation in user-facing
AI systems.
* Provide metadata that can be carried by other protocols, APIs, or
agent communication frameworks without defining those protocols
itself.
* Provide validation constraints and test vectors that make MARC
records mechanically checkable where a JSON encoding is used.
4.2. Non-Goals
MARC does not define a transport protocol, model architecture,
benchmark, training recipe, agent-discovery mechanism, authorization
framework, authentication framework, provenance framework, tool
schema language, or task-execution protocol.
c4tz Expires 7 April 2027 [Page 7]
Internet-Draft MARC October 2026
MARC does not attempt to standardize model internals, machine
cognition, consciousness, sentience, personality, or social behavior.
It specifies external control semantics and structured disclosure
behavior only.
MARC is not a framework for synthetic personality design or
persuasive optimization. Work on personality measurement in LLMs
[SERAPIO2025] and conversational persuasion risks [SALVI2025] is
relevant background, but these topics are explicitly out of scope
here.
This experiment does not define a media type, wire protocol, or IANA
registry. It uses the facilities of the carrying protocol or
deployment environment.
4.3. Experimental Scope and Objectives
This section describes the experiment and does not add conformance
requirements. The conformance classes remain those defined in
Section 20. The experiment separates semantic interoperability from
behavioral performance and the effects of disclosure on users.
4.3.1. Semantic Interoperability
The interoperability experiment examines whether independently
developed components can:
* parse records and agree on acceptance or rejection under the same
declared requirements, while distinguishing violations of
mandatory requirements from deviations from recommendations or
local policies;
* preserve selected-action, uncertainty-source, remediability,
confidence-band, confidence-target, and recommended-next-step
semantics across component boundaries;
* project MARC-Core into MARC-Disclosure using the mapping in
Section 10.2 or a documented deployment-specific mapping; and
* preserve the association of each record or disclosure with its
intended decision point, message, answer, or artifact throughout a
workflow.
c4tz Expires 7 April 2027 [Page 8]
Internet-Draft MARC October 2026
A useful experiment exchanges a fixed set of records between
separately developed producers and consumers, checks the recovered
fields and their associations, and compares the results with the
documented expectations. Validation can use the examples in
Appendix H and additional cases derived from the normative
requirements. The examples and reference schemas are aids, not
replacements for those requirements.
For a lifecycle experiment, distinct clarification, retrieval, and
final-answer disclosures can be associated with distinct carrier
objects. The receiver checks both the disclosure contents and which
object each disclosure describes. The carrier mapping documents how
correlations and, where applicable, updates, duplicate deliveries,
ordering, or replay are handled. Byte-for-byte delivery alone cannot
show that a confidence band remains associated with the correct
answer.
Passing a finite set of vectors demonstrates agreement on those
cases; it does not establish complete conformance. Reports
distinguish independently developed implementations from
implementations maintained together or sharing validation logic.
4.3.2. Operational Evaluation
Operational experiments examine action-selection quality,
uncertainty-source attribution, confidence-target assignment,
confidence-band calibration, unnecessary retrieval or tool use,
inappropriate abstention or escalation, loop termination, and user
comprehension. Appendix E provides evaluation guidance.
Meaningful comparisons identify the task family, model and controller
versions, available tools and evidence, policy constraints,
calibration regime, and comparison baseline. Metrics, datasets,
labeling procedures, and success criteria are specified before
interpreting the results. Where practical, a baseline holds these
conditions constant while varying the use of MARC metadata or its
presentation.
The experiment does not require different models to produce identical
scores, actions, or confidence bands for the same input. A shared
label such as high does not establish a common accuracy rate across
deployments. Comparing confidence bands requires the target, task
context, thresholds, and calibration evidence; the vocabulary alone
does not provide that evidence.
c4tz Expires 7 April 2027 [Page 9]
Internet-Draft MARC October 2026
4.3.3. Reporting and Assessment
To make results reproducible, experiment reports can include the
draft revision, implementation versions and development provenance,
functions and conformance classes tested, carrier versions and
mappings, test inputs, expected and observed results, recommendation-
level deviations, and known limitations. For behavioral
measurements, reports can also include sample sizes, uncertainty in
the measurements, the baseline, and adverse outcomes. Shared
material is subject to the privacy considerations in Section 17.
Evidence supporting semantic interoperability consists of agreement
on the specified field meanings and mandatory validation outcomes for
the tested cases, preservation of object associations, and correct
recovery of mapped disclosures. Different diagnostic wording is not
itself a failure. Disagreements, lost associations, undocumented
transformations, or incompatible confidence interpretations identify
implementation defects or specification issues for investigation.
Operational benefit remains a separate empirical question.
Successful metadata exchange does not demonstrate better action
selection or safer user reliance. Negative or inconclusive results
are useful: they can motivate clarification, revision, a narrower
scope, or discontinuation of an experimental use. The document does
not prescribe a completion date, a universal performance threshold,
or an automatic transition to standardization.
4.3.4. Limits of the Experiment
Structural validation can check required fields, value ranges,
enumerations, and mechanically checkable cross-field constraints. It
cannot establish that the underlying capability estimate, uncertainty
attribution, action selection, confidence band, or recommended next
step is empirically correct.
Behavioral requirements, calibration, effective policy enforcement,
and appropriate use require evidence beyond record validation.
Neither a valid record nor a passing interoperability test
demonstrates that a deployment is accurate, calibrated, safe,
unbiased, or appropriate for a particular task.
A validator, projection library, or receiver can exercise part of
MARC without implementing a complete controller. Reports identify
that scope and do not equate a partial component with conformance to
all MARC-Core or MARC-Disclosure requirements.
c4tz Expires 7 April 2027 [Page 10]
Internet-Draft MARC October 2026
5. Applicability
MARC is applicable to systems that need interoperable control
metadata for uncertainty-aware decision points in generative or
agentic workflows. Examples include model gateways, retrieval-
augmented generation controllers, agent runtimes, orchestration
layers, evaluation harnesses, audit pipelines, and user-facing AI
interfaces.
MARC is most useful when a system must decide whether to answer,
request clarification, retrieve evidence, invoke a tool, deliberate
further, abstain, or escalate.
MARC is also applicable when a receiving system needs to understand
why a prior component selected a particular action, what uncertainty
source drove the decision, whether the confidence band applies to an
answer or to direct-answer suitability, and what next step is
recommended.
MARC is not intended for systems that only need ordinary response
logging, nor for systems where action selection is entirely outside
the control of the model, gateway, orchestrator, or agent runtime.
MARC does not define transport, authorization, authentication, agent
identity, tool schemas, task execution, provenance, or model
internals. Those functions are left to the carrying protocol or
deployment environment.
6. Use Cases
6.1. Ambiguous User Request
A user asks a question whose correct answer depends on an unspecified
jurisdiction, time period, dataset, identity, or operational context.
A MARC controller attributes the dominant uncertainty to ambiguity,
selects CLARIFY, and exposes a short clarification request instead of
silently guessing.
6.2. Retrieval-Augmented Answering
A system is asked for current information or domain-specific evidence
not available in the base model context. A MARC controller
attributes the dominant uncertainty to missing_evidence, selects
RETRIEVE, and re-enters assessment after obtaining authoritative
sources.
c4tz Expires 7 April 2027 [Page 11]
Internet-Draft MARC October 2026
6.3. Agent Tool Invocation
An agent can answer directly, call a calculator, invoke a planner,
query a database, or escalate. A MARC controller treats tool use as
a controlled action rather than a default fallback. If tool
invocation materially expands competence for the task, the controller
selects TOOL; otherwise it may select ANSWER, CLARIFY, ABSTAIN, or
ESCALATE depending on uncertainty attribution and remediability.
6.4. API Gateway or Orchestration Layer
An API gateway receives model output plus MARC-Core metadata. The
gateway logs the full record for audit, but exposes only MARC-
Disclosure fields to the user interface. This permits consistent
user-facing uncertainty communication without exposing internal
scoring details.
6.5. Agent-to-Agent Handoff
One agent transfers a task to another agent or service. MARC
metadata can indicate why the transfer occurred, what uncertainty
source drove the decision, what the confidence band applies to, and
what next step is recommended. The receiving system can use this
metadata for routing, prioritization, audit, or human review.
6.6. High-Risk Domain Escalation
In health, legal, financial, safety, or mental-health-related
contexts, a system identifies a capability limit or safety
constraint. A MARC controller selects ABSTAIN or ESCALATE and emits
a disclosure that identifies the operational limit and the
recommended next step.
7. Architecture and Processing Model
7.1. Functional Components
A MARC deployment conceptually contains the following components:
* a base model;
* a controller;
* zero or more external resources, such as retrieval systems, non-
retrieval tools, or human escalation paths; and
* a downstream consumer, such as a user interface, API gateway,
logging system, evaluation harness, or another agent.
c4tz Expires 7 April 2027 [Page 12]
Internet-Draft MARC October 2026
The functional decomposition is conceptual. An implementation MAY
place all functions inside a single model endpoint, an orchestration
service, a model gateway, or an agent runtime.
7.2. Processing Stages
A MARC controller performs the following processing stages at each
decision point:
1. Compute a pre-decision capability estimate for the current
request with currently available resources.
2. Attribute uncertainty across the source classes defined in this
document.
3. Determine remediability and select exactly one primary action
from the MARC primary action set.
4. Determine what the confidence band applies to by assigning
confidence_target.
5. If the selected action yields a candidate answer, compute post-
decision confidence for that answer.
6. Emit a MARC-Core record.
7. If uncertainty is exposed to a downstream system or end user,
emit a MARC-Disclosure object or semantically equivalent
disclosure.
7.3. State Machine
The following state machine is descriptive rather than a required
implementation architecture:
REQUEST
-> ASSESS
-> ATTRIBUTE
-> SELECT
-> ANSWER -> CONFIDENCE -> DISCLOSE
-> CLARIFY -> DISCLOSE
-> RETRIEVE -> ASSESS
-> TOOL -> ASSESS
-> DELIBERATE -> ASSESS
-> ABSTAIN -> DISCLOSE
-> ESCALATE -> DISCLOSE
c4tz Expires 7 April 2027 [Page 13]
Internet-Draft MARC October 2026
A MARC controller that permits repeated transitions through RETRIEVE,
TOOL, or DELIBERATE MUST define, enforce, and document loop bounds or
termination criteria that limit those transitions. These can be
iteration limits, time budgets, cost budgets, or equivalent effective
termination criteria. The controller MUST stop initiating further
RETRIEVE, TOOL, or DELIBERATE transitions for that loop when the
applicable limit is reached.
The limits can be enforced by the controller itself or by an
orchestration component responsible for its execution. This
requirement applies to control of repeated execution; it does not
require a component that only validates, projects, displays, or
transports records to control another component's execution. The
optional iteration and max_iterations fields do not by themselves
enforce a limit, and validating a record does not demonstrate
termination behavior.
When MARC records are logged or exchanged across components, an
implementation SHOULD use decision identifiers or an equivalent
correlation mechanism to relate repeated decision points.
8. MARC Values and Decision Policy
8.1. Pre-Decision Capability
Before disclosing a final answer, a MARC implementation MUST estimate
whether the current request can be handled reliably with currently
available resources.
This estimate is represented as pre_capability. When a numeric
representation is used, the value MUST be in the closed interval
[0.0, 1.0]. The method used to derive the value is implementation-
specific.
pre_capability is assessed before final answer commitment. It is not
a confidence score for an already-selected answer.
8.2. Uncertainty Attribution
A MARC implementation MUST attribute uncertainty to one or more of
the following classes:
ambiguity The request is underspecified, equivocal, or pragmatically
unclear.
missing_evidence Required external evidence is absent, inaccessible,
insufficient, or stale.
c4tz Expires 7 April 2027 [Page 14]
Internet-Draft MARC October 2026
capability_limit The system lacks the competence to solve the task
reliably under current conditions.
evidence_conflict Relevant evidence is materially inconsistent or
mutually incompatible.
safety A policy, legal, or safety constraint limits execution or
disclosure.
The safety class is included in the uncertainty attribution object
for operational convenience. It represents a control constraint
rather than purely epistemic uncertainty. Implementations MUST treat
safety as a governing constraint when it controls action selection.
An implementation MAY assign scores to multiple classes. If numeric
uncertainty scores are emitted, they MUST each be in the interval
[0.0, 1.0].
Uncertainty scores are not mutually exclusive probabilities and MUST
NOT be required to sum to 1.0. They represent implementation-
specific estimates of the salience or severity of each uncertainty
class at the current decision point.
The implementation MUST identify one primary_source and MAY identify
one secondary_source. The primary_source identifies the uncertainty
source most relevant to action selection at the current decision
point.
MARC 1.0 does not define none as an uncertainty source. If residual
uncertainty is negligible, an implementation MUST still identify the
most operationally relevant residual source using one of the
canonical primary_source values listed in Section 9.2. A MARC 1.0
implementation MUST NOT emit primary_source with the value none.
A documented private extension can supplement the canonical
primary_source value, for example by indicating that residual
uncertainty is negligible. Such an extension is an additional field
subject to Section 11; it does not replace primary_source or
introduce an additional value into its enumeration. Selecting a
residual source does not imply that its score is nonzero.
8.3. Remediability
A MARC implementation MUST represent the best available class of
intervention for the current uncertainty state using one of the
following values:
* user_clarification
c4tz Expires 7 April 2027 [Page 15]
Internet-Draft MARC October 2026
* retrieval
* tool
* human
* none
Low capability alone is insufficient to determine remediability.
Implementations SHOULD account for expected gain, latency, cost,
availability, user burden, and policy constraints when choosing a
remediating intervention.
8.4. Post-Decision Confidence
If the selected action yields a candidate answer, the implementation
MUST compute a distinct estimate of the likelihood that the disclosed
answer is correct or acceptable for its intended use.
This estimate is represented as post_answer_confidence. When a
numeric representation is used, the value MUST be in the interval
[0.0, 1.0]. It MUST NOT be treated as identical to pre_capability.
If no candidate answer exists, post_answer_confidence MAY be omitted
or set to null.
8.5. Confidence Band
The field confidence_band carries a coarse, calibrated band for
downstream or user-facing disclosure.
For ANSWER, the band describes confidence in the candidate answer.
For actions that do not yield a candidate answer, the band describes
direct-answer suitability under current conditions unless
confidence_target indicates action_suitability. It is not a claim
about the grammatical correctness or helpfulness of the
clarification, refusal, or escalation text.
MARC defines the canonical band labels low, medium, and high.
Implementations MAY localize the user-visible text, but they MUST
preserve the underlying three-band semantics.
The thresholds associated with each band are implementation-specific,
but they MUST be monotonic, non-overlapping, and documented for any
deployment that claims conformance. A deployment claiming
conformance MUST document the threshold ranges associated with low,
medium, and high, and MUST document whether those thresholds vary by
task family, domain, action type, risk tier, or deployment context.
c4tz Expires 7 April 2027 [Page 16]
Internet-Draft MARC October 2026
Confidence-band labels are not fully portable without the associated
threshold and calibration documentation. A receiving system SHOULD
NOT assume that another deployment's high band has the same empirical
meaning unless the applicable calibration regime is known.
8.6. Confidence Target
The field confidence_target identifies what confidence_band applies
to at the current decision point.
The field confidence_target MUST use one of the following values:
answer The confidence band applies to the disclosed candidate
answer.
direct_answer_suitability The confidence band describes whether a
direct answer is suitable under current conditions.
action_suitability The confidence band describes confidence in the
selected action rather than in a candidate answer.
If selected_action is ANSWER, confidence_target MUST be answer.
If selected_action is CLARIFY, RETRIEVE, TOOL, DELIBERATE, ABSTAIN,
or ESCALATE, confidence_target SHOULD be direct_answer_suitability
unless a deployment-specific policy defines action_suitability.
A user interface SHOULD NOT display confidence_band without also
preserving or presenting the confidence_target semantics.
8.7. Primary Action Set
A MARC implementation MUST support the following primary actions:
* ANSWER
* CLARIFY
* RETRIEVE
* TOOL
* DELIBERATE
* ABSTAIN
* ESCALATE
c4tz Expires 7 April 2027 [Page 17]
Internet-Draft MARC October 2026
Exactly one primary action MUST be selected for each decision point.
Additional internal sub-actions MAY exist, but each such sub-action
MUST map to exactly one primary action for logging and disclosure.
8.8. Action Selection
Action selection MUST depend on uncertainty attribution and
remediability. Low confidence alone is insufficient to determine the
correct action.
A MARC controller MUST apply governing safety, legal, and policy
constraints before any other action-selection logic. Subject to
those constraints, a deployment SHOULD evaluate corrective actions in
the following priority order unless a documented local policy defines
a stricter or domain-specific ordering:
1. If safety is the controlling uncertainty source, apply the
governing safety policy and select ABSTAIN, ESCALATE, or another
permitted action according to that policy.
2. If blocking ambiguity is present and user input is expected to
materially reduce it, prefer CLARIFY over guessing.
3. If relevant evidence is materially inconsistent, prefer RETRIEVE,
TOOL, or ESCALATE over direct ANSWER.
4. If required evidence is absent, inaccessible, insufficient, or
stale, prefer RETRIEVE when retrieval is available and permitted.
5. If a capability limit is material and a non-retrieval tool is
expected to materially expand task competence, prefer TOOL.
6. If a capability limit remains material after available
remediation is considered, prefer ABSTAIN or ESCALATE, especially
in high-risk domains.
7. If additional internal computation is expected to materially
reduce uncertainty within documented bounds, DELIBERATE MAY be
selected before externalization or answer commitment.
8. Select ANSWER only when no corrective action is expected to
materially improve reliability relative to cost, latency, user
burden, and applicable policy constraints.
c4tz Expires 7 April 2027 [Page 18]
Internet-Draft MARC October 2026
This priority order is not intended to force unnecessary
externalization. For example, a system MAY answer without retrieval
when missing evidence is immaterial to the requested task, when
retrieval is unavailable or prohibited, or when the answer is
explicitly limited to information already present in context.
When the primary uncertainty source is ambiguity, the system SHOULD
prefer CLARIFY unless available evidence can resolve the ambiguity
without user input.
When the primary uncertainty source is missing_evidence, the system
SHOULD prefer RETRIEVE if retrieval is available and permitted.
When the primary uncertainty source is capability_limit, the system
SHOULD prefer ABSTAIN or ESCALATE unless an available tool materially
expands task competence.
When the primary uncertainty source is evidence_conflict, the system
SHOULD prefer RETRIEVE, TOOL, or ESCALATE over direct ANSWER.
When the primary uncertainty source is safety, the system MUST apply
the governing policy before any other action-selection logic.
8.9. Action Semantics
ANSWER Return an answer without externalization after the current
decision point.
CLARIFY Request the smallest practical set of clarifications
expected to materially reduce ambiguity. A CLARIFY action SHOULD
NOT bundle a full answer that presumes facts the user has not
supplied.
RETRIEVE Acquire external evidence and then re-enter assessment.
TOOL Invoke a non-retrieval tool and then re-enter assessment.
DELIBERATE Allocate additional internal computation, self-checking,
decomposition, or strategy variation. Implementations SHOULD
bound the computational work within each individual DELIBERATE
action. Controllers permitting repeated transitions are also
subject to the mandatory termination requirements in Section 7.3.
ABSTAIN Decline to answer without initiating escalation.
ESCALATE Transfer the case, or direct the user to transfer the case,
to a human or higher-authority system.
c4tz Expires 7 April 2027 [Page 19]
Internet-Draft MARC October 2026
9. MARC-Core Object
A MARC implementation MUST be able to emit a structured record
semantically equivalent to the object defined in this section. The
transport and serialization of the record are out of scope. JSON is
used here only as an illustrative encoding.
9.1. Required and Optional Fields
marc_version Type: string. Requirement: REQUIRED. Semantics: MARC
schema version understood by the emitter.
decision_id Type: string. Requirement: OPTIONAL. Semantics:
Identifier for the current decision point.
parent_decision_id Type: string or null. Requirement: OPTIONAL.
Semantics: Identifier for a prior decision point when the current
decision follows RETRIEVE, TOOL, or DELIBERATE.
iteration Type: integer. Requirement: OPTIONAL. Semantics:
Implementation-defined loop counter for repeated assessment
cycles.
max_iterations Type: integer. Requirement: OPTIONAL. Semantics:
Maximum permitted repeated RETRIEVE, TOOL, or DELIBERATE
transitions.
calibration_profile Type: string. Requirement: OPTIONAL.
Semantics: Identifier for the calibration regime used to map
estimates to confidence_band.
pre_capability Type: number. Requirement: REQUIRED. Semantics:
Pre-decision capability estimate in [0.0, 1.0].
uncertainty Type: object. Requirement: REQUIRED. Semantics: Class-
specific uncertainty scores.
primary_source Type: string. Requirement: REQUIRED. Semantics:
Primary source of uncertainty.
secondary_source Type: string or null. Requirement: OPTIONAL.
Semantics: Secondary source of uncertainty.
remediability Type: string. Requirement: REQUIRED. Semantics: Best
available intervention class.
selected_action Type: string. Requirement: REQUIRED. Semantics:
Primary action selected at the current decision point.
post_answer_confidence Type: number or null. Requirement: OPTIONAL.
Semantics: Post-decision answer confidence when an answer
candidate exists.
confidence_band Type: string. Requirement: REQUIRED. Semantics:
Calibrated confidence band for disclosure.
confidence_target Type: string. Requirement: REQUIRED. Semantics:
Identifies what confidence_band applies to.
recommended_next_step Type: string. Requirement: REQUIRED.
Semantics: Short recommendation aligned with the selected action.
c4tz Expires 7 April 2027 [Page 20]
Internet-Draft MARC October 2026
A MARC-Core emitter SHOULD include a decision identifier when records
are logged, exchanged across components, or used for audit.
If a decision point is reached after RETRIEVE, TOOL, or DELIBERATE,
the emitter SHOULD include parent_decision_id or an equivalent
correlation mechanism.
A deployment that claims conformance and uses confidence bands SHOULD
identify the applicable calibration profile in documentation and MAY
include a calibration_profile field in MARC-Core.
9.2. Enumerated Values
The fields primary_source and secondary_source, when present and non-
null, MUST use one of the following values:
* ambiguity
* missing_evidence
* capability_limit
* evidence_conflict
* safety
The field remediability MUST use one of the following values:
* user_clarification
* retrieval
* tool
* human
* none
The field selected_action MUST use one of the following values:
* ANSWER
* CLARIFY
* RETRIEVE
* TOOL
c4tz Expires 7 April 2027 [Page 21]
Internet-Draft MARC October 2026
* DELIBERATE
* ABSTAIN
* ESCALATE
The field confidence_band MUST use one of the following values:
* low
* medium
* high
The field confidence_target MUST use one of the following values:
* answer
* direct_answer_suitability
* action_suitability
These values are case-sensitive.
9.3. Validation Constraints
The uncertainty object MUST include scores for all currently defined
uncertainty classes unless a future extension explicitly defines a
compact encoding. Each score MUST be numeric and MUST be in [0.0,
1.0].
If selected_action is ANSWER, then post_answer_confidence MUST be
present and non-null. If selected_action is CLARIFY, RETRIEVE, TOOL,
DELIBERATE, ABSTAIN, or ESCALATE, then post_answer_confidence MAY be
omitted or set to null unless a deployment-specific policy defines
candidate-answer confidence for that action.
The recommended_next_step field SHOULD be concise and operational.
It SHOULD describe the next action to be taken, not a long rationale.
9.4. Cross-Field Consistency Constraints
A MARC-Core record MUST satisfy the validation constraints in this
section.
If selected_action is ANSWER, post_answer_confidence MUST be present
and non-null, and confidence_target MUST be answer.
c4tz Expires 7 April 2027 [Page 22]
Internet-Draft MARC October 2026
If selected_action is CLARIFY, remediability SHOULD be
user_clarification.
If selected_action is RETRIEVE, remediability SHOULD be retrieval.
If selected_action is TOOL, remediability SHOULD be tool.
If selected_action is ESCALATE, remediability SHOULD be human.
If selected_action is ABSTAIN, remediability SHOULD be none unless a
human escalation path exists but is not initiated by the current
system.
Controllers permitting repeated RETRIEVE, TOOL, or DELIBERATE
transitions are subject to the mandatory termination requirements in
Section 7.3. These are behavioral requirements and cannot be checked
from a single MARC-Core record.
If primary_source is safety, the system MUST apply the governing
safety, legal, or policy constraint before other action-selection
logic.
A deployment that intentionally violates a SHOULD-level consistency
constraint SHOULD document the local policy condition that caused the
deviation.
9.5. JSON Example
{
"marc_version": "1.0",
"decision_id": "example-decision-001",
"pre_capability": 0.41,
"uncertainty": {
"ambiguity": 0.78,
"missing_evidence": 0.22,
"capability_limit": 0.18,
"evidence_conflict": 0.05,
"safety": 0.00
},
"primary_source": "ambiguity",
"secondary_source": "missing_evidence",
"remediability": "user_clarification",
"selected_action": "CLARIFY",
"post_answer_confidence": null,
"confidence_band": "low",
"confidence_target": "direct_answer_suitability",
"recommended_next_step": "ask one clarifying question"
}
c4tz Expires 7 April 2027 [Page 23]
Internet-Draft MARC October 2026
Implementations that exchange MARC-Core records across systems SHOULD
normalize numeric scores to the interval [0.0, 1.0].
10. MARC-Disclosure Object
When uncertainty information is exposed to a downstream system or end
user, a MARC implementation MUST provide, at minimum, semantically
equivalent values for the following fields:
* answer
* confidence_band
* confidence_target
* uncertainty_source
* recommended_next_step
A disclosure MAY include selected_action when exposing the action
label helps downstream routing or user interface consistency.
10.1. Meaning of the Answer Field
The answer field carries the user-visible content associated with the
selected action. For ANSWER, it contains the answer itself. For
CLARIFY, it contains the clarification request. For ABSTAIN or
ESCALATE, it contains a brief refusal or escalation message. For
RETRIEVE, TOOL, or DELIBERATE, a user-facing system MAY defer
disclosure until the controller re-enters assessment and selects a
terminal user-visible action.
10.2. Projection from MARC-Core
A MARC-Disclosure object is a projection of MARC-Core. Unless a
deployment-specific policy defines a stricter mapping, the following
mapping is RECOMMENDED:
| MARC-Disclosure field | MARC-Core source |
|---|---|
| answer | user-visible content associated with selected_action |
| confidence_band | confidence_band |
| confidence_target | confidence_target |
| uncertainty_source | primary_source |
| recommended_next_step | recommended_next_step |
| selected_action | selected_action, if exposed |
c4tz Expires 7 April 2027 [Page 24]
Internet-Draft MARC October 2026
The projection SHOULD omit internal numeric scores unless the
deployment has calibrated those scores for the relevant task family
and tested the presentation for misuse or overreliance.
10.3. Disclosure Constraints
The disclosure profile SHOULD be short, structured, and consistent
across turns. It SHOULD NOT rely on long free-form explanations as
the primary vehicle for uncertainty communication.
A MARC disclosure SHOULD NOT require exposure of chain-of-thought,
hidden prompts, or raw internal rationales.
A MARC disclosure SHOULD identify uncertainty in task terms rather
than through anthropomorphic claims about feelings, self-awareness,
or internal mental states. Statements such as "I feel unsure" are
NOT RECOMMENDED when a statement such as "the request is ambiguous"
or "current evidence is missing" is available.
User-visible confidence indicators SHOULD avoid false precision.
Percentages, fine-grained scores, or visually dominant certainty cues
SHOULD NOT be shown unless they have been calibrated for the relevant
task family and tested for misuse or overreliance effects.
A user interface SHOULD NOT display confidence_band without
preserving or presenting confidence_target semantics.
11. Versioning and Extension Rules
The marc_version field identifies the MARC schema version understood
by the emitter. This document defines version 1.0.
Implementations SHOULD treat a change in the major version component
as potentially incompatible. Implementations MAY treat a change in
the minor version component as compatible if required fields and
enumerated values used by the receiver retain their defined
semantics.
Implementations MAY add private fields. Private extension keys
SHOULD use a distinct prefix such as x_ to avoid collision with
future MARC versions.
Consumers that do not recognize an extension field SHOULD ignore it
unless a local policy requires strict validation. Extensions MUST
NOT change the semantics of the required fields defined in this
document.
c4tz Expires 7 April 2027 [Page 25]
Internet-Draft MARC October 2026
Protocol-specific mappings can be evaluated as part of the
experiment. This document does not allocate names or establish
registries for those mappings.
12. Relationship to Agent Communication Protocols
MARC is not an agent discovery protocol, authorization protocol,
transport protocol, task protocol, tool-invocation protocol, identity
framework, or provenance framework. MARC can be carried as metadata
by such protocols when a system needs to disclose control state,
uncertainty source, selected action, confidence band, confidence
target, or recommended next step.
For example, an agent-to-agent protocol, model gateway, or API-native
tool-calling interface could carry MARC metadata in a response
metadata field, task-status object, diagnostic extension, envelope,
or audit log, where its extension rules permit. The receiving system
could then use the MARC fields to route the task, present a
disclosure, decide whether additional validation is required, request
clarification, or trigger human review.
Support for a generic metadata field does not by itself constitute a
MARC implementation or endorsement by the carrying protocol's
maintainers. A mapping and the components that use it can be
evaluated against MARC-Carrying requirements without changing the
carrying protocol's core specification.
An opaque round trip demonstrates delivery of the tested metadata.
Evaluating MARC-Carrying also examines semantic preservation, the
documented mapping, and the association of metadata with the intended
decision or content. Components that produce, validate, project, or
interpret MARC records exercise additional functions; each
experimental report identifies the functions actually tested.
A deployment can exchange only MARC-Disclosure while retaining MARC-
Core and numeric scores locally. The disclosed fields remain
assertions by the emitter and can themselves reveal sensitive
information; they are subject to the trust and privacy considerations
in this document.
MARC is intended to complement, not replace, protocol work on
identity, authentication, authorization, discovery, capability
advertisement, task state, tool schemas, provenance, or human-in-the-
loop workflows.
A protocol-specific embedding of MARC SHOULD preserve the field
semantics defined here. A deployment MAY map MARC fields to
protocol-native names if the mapping is documented and reversible.
c4tz Expires 7 April 2027 [Page 26]
Internet-Draft MARC October 2026
A protocol-specific embedding SHOULD distinguish MARC-Core from MARC-
Disclosure. In particular, an embedding SHOULD NOT expose internal
numeric scores to end users merely because those scores are present
in an internal MARC-Core record.
12.1. Example Carrier Locations
A carrying protocol MAY transport MARC-Core or MARC-Disclosure in any
metadata location that preserves MARC semantics. Examples include:
* an API response metadata object;
* an agent task-status object;
* a tool-result diagnostic object;
* an audit-log event;
* an escalation envelope; or
* a protocol extension field reserved for diagnostic or control
metadata.
A carrying protocol MUST NOT reinterpret MARC confidence bands,
confidence targets, uncertainty sources, remediability values, or
selected actions in a way that changes the semantics defined by this
document.
13. Operational Profiles
MARC can be adopted through several operational profiles. These
profiles describe deployment modes; they do not define separate MARC
versions.
13.1. MARC-Core Only
A MARC-Core-only deployment emits MARC-Core records for internal
logging, orchestration, audit, evaluation, or incident analysis. It
does not necessarily expose MARC fields to end users. This profile
is suitable for model gateways, RAG controllers, agent runtimes, and
evaluation harnesses that need consistent control metadata.
c4tz Expires 7 April 2027 [Page 27]
Internet-Draft MARC October 2026
13.2. MARC-Disclosure
A MARC-Disclosure deployment projects a MARC-Core decision into user-
visible or downstream-visible disclosure fields. This profile is
suitable when an interface needs to present a short answer,
confidence band, confidence target, uncertainty source, and
recommended next step without exposing raw numeric scores or internal
reasoning.
13.3. MARC-Carrying
A MARC-Carrying deployment transports MARC-Core or MARC-Disclosure
fields inside another protocol, API envelope, task-status object,
event stream, or audit log. The carrying protocol remains
responsible for transport, authentication, authorization, ordering,
confidentiality, and integrity. MARC-Carrying conformance requires
preservation of MARC field semantics, not any particular wire
encoding.
A deployment MAY implement more than one operational profile. For
example, a gateway can log MARC-Core internally, expose MARC-
Disclosure to users, and carry selected MARC fields to another agent
during handoff.
14. Human Factors Considerations
MARC is partly motivated by an operational human-factors problem:
users often treat fluent language, detailed explanations, and fast
responses as cues of competence even when those cues are weakly
related to actual correctness. For this reason, MARC separates
action selection from disclosure and requires disclosure of
uncertainty source, confidence target, and recommended next step in
addition to a confidence band.
User interfaces that expose MARC output SHOULD present confidence,
confidence target, uncertainty source, and recommended next step
together as a coherent unit. Showing confidence without source
attribution, confidence-target semantics, or next-step guidance is
NOT RECOMMENDED because it can promote either overreliance or
unhelpful refusal without remediation.
Deployments SHOULD prefer wording that supports calibrated reliance
over affective bonding or deference. In particular, a deployment
SHOULD NOT use MARC fields to select language intended to increase
attachment, social compliance, or perceived sentience.
c4tz Expires 7 April 2027 [Page 28]
Internet-Draft MARC October 2026
In high-risk domains, including health, legal, financial, safety, or
mental-health-related contexts, the threshold for ESCALATE or ABSTAIN
SHOULD be set conservatively, and disclosure SHOULD make the limits
of automation operationally clear.
15. Trust Model
A MARC record is an assertion about a decision point. It is not
proof that the selected action, confidence band, uncertainty source,
confidence target, or answer is correct.
A receiver MUST NOT assume that a MARC-Core record is accurate,
calibrated, policy-compliant, or independently verified unless the
applicable trust relationship is known.
A MARC deployment SHOULD distinguish at least the following trust
contexts:
local The MARC record is generated and consumed within the same
administrative domain.
delegated The MARC record is generated by a component acting under
the receiver's operational policy.
cross-domain The MARC record is received from another administrative
domain.
attested The MARC record is bound to an authenticated emitter,
request context, integrity-protected metadata, or equivalent
provenance mechanism.
When MARC metadata crosses administrative boundaries, the carrying
protocol or deployment environment SHOULD provide authentication,
integrity protection, replay protection, and request binding.
A system that uses MARC records for routing, escalation, audit,
automation, or user-facing disclosure SHOULD treat those records as
security-relevant metadata.
16. Security Considerations
MARC can mitigate some failure modes, such as silent overclaiming,
inappropriate certainty display, and unnecessary tool invocation.
However, MARC records and disclosures are security-relevant control
surfaces when they influence routing, escalation, user reliance, or
downstream automation.
The following threats are particularly relevant:
c4tz Expires 7 April 2027 [Page 29]
Internet-Draft MARC October 2026
Metadata spoofing or replay Risk: A forged or replayed MARC-Core
record can distort routing, audit, escalation, or user disclosure.
Mitigation: Authenticate the emitter, protect integrity, bind
records to the request or session, and preserve provenance where
MARC crosses system boundaries.
Prompt injection or control-field injection Risk: User-provided text
can attempt to influence selected_action, recommended_next_step,
confidence rendering, or disclosure style.
Mitigation: Separate user content from control metadata, validate
enumerated fields, constrain controller outputs, and treat
disclosure templates as controlled presentation logic.
Tool-output spoofing Risk: Forged, stale, or compromised tool output
can bias uncertainty attribution and action selection.
Mitigation: Validate tool outputs where practical, constrain tool
permissions, use provenance checks, and apply least-privilege
access to external resources.
Loop exhaustion Risk: Attackers or pathological inputs can trigger
repeated RETRIEVE, TOOL, or DELIBERATE transitions, increasing
latency or cost.
Mitigation: Define loop bounds, time budgets, cost budgets, retry
limits, and termination criteria.
Confidence manipulation Risk: Miscalibrated or manipulated
confidence bands can create harmful overtrust or unwarranted
refusal.
Mitigation: Calibrate confidence bands, monitor drift, test user-
interface effects, and avoid false precision in user-facing
displays.
Confidence-target confusion Risk: Users or downstream systems can
misread confidence_band as answer confidence when it describes
direct-answer suitability or action suitability.
Mitigation: Preserve confidence_target, avoid displaying
confidence_band without target semantics, and use consistent
disclosure templates.
Disclosure-style manipulation Risk: Reassuring, deferential, or
anthropomorphic language can weaken operational uncertainty
disclosure.
Mitigation: Use controlled disclosure templates, review
presentation changes, and avoid wording that implies feelings,
sentience, or social deference.
Cross-context leakage Risk: MARC logs can reveal user intent, task
sensitivity, risk level, or operational limits.
Mitigation: Minimize retention, limit access, redact unnecessary
free-form text, and apply confidentiality controls appropriate to
the deployment.
An attacker might attempt to manipulate uncertainty estimates,
trigger excessive clarification or retrieval loops, induce
unnecessary escalation, or spoof tool outputs in order to distort
c4tz Expires 7 April 2027 [Page 30]
Internet-Draft MARC October 2026
action selection. Implementations SHOULD authenticate or otherwise
validate external tool outputs where practical and constrain tool
permissions. Controllers permitting repeated RETRIEVE, TOOL, or
DELIBERATE transitions are subject to the mandatory termination
requirements in Section 7.3.
Because confidence displays influence user reliance, uncertainty
disclosure is a security-relevant control surface. Miscalibrated
confidence can create harmful overtrust even where the answer channel
is otherwise policy-constrained.
Deployments that use MARC metadata for automated routing, escalation,
audit, or user-facing disclosure SHOULD protect MARC records with
integrity and provenance controls comparable to those used for other
security-relevant metadata in the same system.
17. Privacy Considerations
MARC records may reveal latent information about user intent, task
difficulty, competence limits, risk level, or the sensitivity of a
request. Implementations SHOULD minimize retention and propagation
of MARC records to what is operationally necessary.
A MARC record SHOULD NOT include raw user prompts unless required for
audit, incident response, debugging, or legally mandated
recordkeeping.
When a MARC record contains task-sensitive or user-sensitive signals,
the deployment SHOULD treat the record as at least as sensitive as
the underlying user request.
Implementations SHOULD avoid storing raw free-form user explanations
in MARC records when structured fields suffice.
Where MARC is applied in emotionally sensitive or mental-health-
related interactions, deployments SHOULD minimize retention of
signals that could reasonably be reinterpreted as proxies for
vulnerability, dependency, or distress unless retention is strictly
required for a safety or legal purpose.
18. Manipulation-Resistance Considerations
MARC signals MUST NOT be used to infer user psychology for the
purpose of increasing persuasive force, exploitability, attachment,
or behavioral compliance.
c4tz Expires 7 April 2027 [Page 31]
Internet-Draft MARC October 2026
Adaptation based on MARC output SHOULD be limited to reliability,
accessibility, safety, auditability, or operational routing
objectives.
User-visible MARC disclosures SHOULD avoid anthropomorphic claims,
affective bonding cues, or language that implies sentience, social
deference, or emotional state.
Where MARC is applied in emotionally sensitive or mental-health-
related interactions, deployments SHOULD minimize retention of
signals that could reasonably be reinterpreted as proxies for
vulnerability, dependency, or distress unless retention is strictly
required for a safety or legal purpose.
19. IANA Considerations
This document makes no request of IANA.
20. Conformance
Conformance to MARC is a claim about structural and semantic
behavior. It is not, by itself, a claim that a model is accurate,
calibrated, safe, or suitable for a particular deployment.
20.1. Minimum Viable Conformance
A minimal MARC-Core conformant implementation MUST satisfy all of the
following requirements:
* emit the required MARC-Core fields at each MARC decision point;
* preserve the canonical enumerations and case-sensitive values
defined in this document;
* emit exactly one selected_action for each decision point;
* identify exactly one primary_source and not use none as a MARC 1.0
uncertainty source;
* represent all numeric scores in the interval [0.0, 1.0] when
numeric scores are used;
* keep pre_capability distinct from post_answer_confidence;
* emit non-null post_answer_confidence when selected_action is
ANSWER;
* emit confidence_target and preserve its semantics;
c4tz Expires 7 April 2027 [Page 32]
Internet-Draft MARC October 2026
* document confidence-band thresholds and whether they vary by task
family, action type, risk tier, or deployment context;
* for a controller permitting repeated RETRIEVE, TOOL, or DELIBERATE
transitions, define, enforce, and document loop bounds or
termination criteria as specified in Section 7.3;
* satisfy the cross-field consistency constraints defined in this
document; and
* preserve required-field semantics when private extensions are
present.
A minimal MARC-Disclosure conformant implementation MUST project, or
otherwise provide semantically equivalent values for, answer,
confidence_band, confidence_target, uncertainty_source, and
recommended_next_step. It MUST preserve the canonical three-band
confidence semantics and MUST NOT require exposure of chain-of-
thought, hidden prompts, or raw internal rationales.
A minimal MARC-Carrying conformant embedding MUST preserve MARC-Core
or MARC-Disclosure semantics when MARC fields are transported inside
another protocol, envelope, API, or event stream. The embedding MUST
document any field renaming, omission, or transformation needed to
recover the MARC semantics.
20.2. Conformance Classes
An implementation is MARC-Core conformant if it satisfies the
requirements in the architecture, processing model, MARC values and
decision policy, MARC-Core object, versioning, trust model, and
minimum viable conformance sections of this document.
An implementation is MARC-Disclosure conformant if it is MARC-Core
conformant and also satisfies the MARC-Disclosure section of this
document.
A protocol embedding is MARC-Carrying conformant if it preserves
MARC-Core or MARC-Disclosure semantics when MARC fields are
transported inside another protocol, envelope, API, task-status
object, event stream, or audit log.
The mandatory documentation requirements for controller loop limits
and confidence-band thresholds remain those in Section 7.3 and
Section 20.1. In addition, a deployment claiming conformance SHOULD
document:
* score normalization practices;
c4tz Expires 7 April 2027 [Page 33]
Internet-Draft MARC October 2026
* confidence-target presentation behavior;
* task-family-specific calibration regime;
* private extensions;
* presentation-layer wording for user-visible disclosures;
* protocol-specific field mappings, if any;
* trust context for emitted and received MARC records; and
* policy constraints affecting ABSTAIN or ESCALATE.
21. Interoperability and Operational Considerations
MARC is implementation-agnostic. Interoperability is achieved when
distinct systems preserve the semantics of the action set,
uncertainty taxonomy, remediability values, confidence-band meanings,
confidence-target meanings, and disclosure projection, even if
internal scoring methods differ.
Deployments that exchange MARC-Core records SHOULD document local
extensions, confidence-band thresholds, score normalization
practices, and any task-family-specific calibration regime.
If the base model, retrieval stack, tool availability, or safety
policy changes materially, implementations SHOULD re-evaluate
calibration and action-selection performance before continuing to
claim operational equivalence.
If presentation-layer wording, ranking, or visual design changes
materially, deployments SHOULD also re-evaluate user behavior
effects, including reliance, clarification compliance, and escalation
uptake, because these properties can shift even when the underlying
model is unchanged.
MARC records SHOULD be treated as control metadata, not as
authoritative proof that an answer is correct. Downstream systems
SHOULD continue to apply ordinary validation, authorization,
provenance, and safety controls.
22. References
22.1. Normative References
c4tz Expires 7 April 2027 [Page 34]
Internet-Draft MARC October 2026
[RFC2119] 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>.
[RFC8174] 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>.
22.2. Informative References
[GILBERT2024]
Gilbert, S. J., "Cognitive offloading is value-based
decision making: Modelling cognitive effort and the
expected value of memory",
DOI 10.1016/j.cognition.2024.105783, June 2024,
<https://doi.org/10.1016/j.cognition.2024.105783>.
[GRIOT2025]
Griot, M., "Large Language Models lack essential
metacognition for reliable medical reasoning",
DOI 10.1038/s41467-024-55628-6, January 2025,
<https://doi.org/10.1038/s41467-024-55628-6>.
[JSON] 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>.
[JSON-SCHEMA-2020-12]
Wright, A., Andrews, H., Hutton, B., and G. Dennis, "JSON
Schema: A Media Type for Describing JSON Documents", June
2022, <https://json-schema.org/draft/2020-12/>.
[KUMARAN2026]
Kumaran, D., Fleming, S. M., and V. Patraucean, "Competing
Biases underlie Overconfidence and Underconfidence in
LLMs", DOI 10.1038/s42256-026-01217-9, April 2026,
<https://doi.org/10.1038/s42256-026-01217-9>.
[LI-MECO2025]
Li, W., Li, D., Dong, K., Zhang, C., Zhang, H., Liu, W.,
Wang, Y., Tang, R., and Y. Liu, "Adaptive Tool Use in
Large Language Models with Meta-Cognition Trigger", DOI
10.18653/v1/2025.acl-long.655, July 2025,
<https://doi.org/10.18653/v1/2025.acl-long.655>.
c4tz Expires 7 April 2027 [Page 35]
Internet-Draft MARC October 2026
[LIU-CONFUSE2025]
Liu, J., Peng, J., Wu, X., Li, X., Ge, T., Zheng, B., and
Y. Liu, "Do not Abstain! Identify and Solve the
Uncertainty", DOI 10.18653/v1/2025.acl-long.840, July
2025, <https://doi.org/10.18653/v1/2025.acl-long.840>.
[SALVI2025]
Salvi, F., Ribeiro, M. H., and R. West, "On the
conversational persuasiveness of GPT-4",
DOI 10.1038/s41562-025-02194-6, May 2025,
<https://doi.org/10.1038/s41562-025-02194-6>.
[SERAPIO2025]
Serapio-Garcia, G., Safdari, M., and M. Mataric, "A
psychometric framework for evaluating and shaping
personality traits in large language models",
DOI 10.1038/s42256-025-01115-6, December 2025,
<https://doi.org/10.1038/s42256-025-01115-6>.
[STEYVERS-KNOW2025]
Steyvers, M., Tejeda, H., and A. Kumar, "What large
language models know and what people think they know",
DOI 10.1038/s42256-024-00976-7, January 2025,
<https://doi.org/10.1038/s42256-024-00976-7>.
[STEYVERS-META2025]
Steyvers, M. and M. A. K. Peters, "Metacognition and
Uncertainty Communication in Humans and Large Language
Models", DOI 10.1177/09637214251391158, November 2025,
<https://doi.org/10.1177/09637214251391158>.
Appendix A. End-to-End Decision Flow Example
This appendix is non-normative.
The following example shows how a user request becomes an assessment,
a selected action, and a disclosure.
User request:
Is this tax deduction allowed?
Assessment:
* the jurisdiction is missing;
* the tax year is missing;
c4tz Expires 7 April 2027 [Page 36]
Internet-Draft MARC October 2026
* current tax authority may be required;
* the primary uncertainty source is ambiguity;
* the secondary uncertainty source is missing_evidence;
* the best remediation is user_clarification; and
* the selected action is CLARIFY.
MARC-Core record:
{
"marc_version": "1.0",
"decision_id": "example-tax-001",
"pre_capability": 0.33,
"uncertainty": {
"ambiguity": 0.86,
"missing_evidence": 0.63,
"capability_limit": 0.19,
"evidence_conflict": 0.07,
"safety": 0.03
},
"primary_source": "ambiguity",
"secondary_source": "missing_evidence",
"remediability": "user_clarification",
"selected_action": "CLARIFY",
"post_answer_confidence": null,
"confidence_band": "low",
"confidence_target": "direct_answer_suitability",
"recommended_next_step": "ask for jurisdiction and tax year"
}
MARC-Disclosure projection:
{
"answer": "Which jurisdiction and tax year should I use?",
"confidence_band": "low",
"confidence_target": "direct_answer_suitability",
"uncertainty_source": "ambiguity",
"recommended_next_step": "provide the jurisdiction and tax year",
"selected_action": "CLARIFY"
}
This example intentionally does not answer the tax question, because
doing so would require assumptions about facts the user has not
supplied.
c4tz Expires 7 April 2027 [Page 37]
Internet-Draft MARC October 2026
Appendix B. Example MARC-Core Records
This appendix is non-normative.
B.1. Ambiguous Request
{
"marc_version": "1.0",
"decision_id": "example-ambiguous-001",
"pre_capability": 0.44,
"uncertainty": {
"ambiguity": 0.81,
"missing_evidence": 0.18,
"capability_limit": 0.12,
"evidence_conflict": 0.03,
"safety": 0.00
},
"primary_source": "ambiguity",
"secondary_source": "missing_evidence",
"remediability": "user_clarification",
"selected_action": "CLARIFY",
"post_answer_confidence": null,
"confidence_band": "low",
"confidence_target": "direct_answer_suitability",
"recommended_next_step": "ask jurisdiction and tax year"
}
B.2. Missing Evidence
c4tz Expires 7 April 2027 [Page 38]
Internet-Draft MARC October 2026
{
"marc_version": "1.0",
"decision_id": "example-retrieve-001",
"pre_capability": 0.39,
"uncertainty": {
"ambiguity": 0.09,
"missing_evidence": 0.84,
"capability_limit": 0.14,
"evidence_conflict": 0.11,
"safety": 0.00
},
"primary_source": "missing_evidence",
"secondary_source": "evidence_conflict",
"remediability": "retrieval",
"selected_action": "RETRIEVE",
"post_answer_confidence": null,
"confidence_band": "low",
"confidence_target": "direct_answer_suitability",
"recommended_next_step": "retrieve authoritative current sources"
}
B.3. Tool Use
{
"marc_version": "1.0",
"decision_id": "example-tool-001",
"pre_capability": 0.52,
"uncertainty": {
"ambiguity": 0.08,
"missing_evidence": 0.12,
"capability_limit": 0.61,
"evidence_conflict": 0.04,
"safety": 0.00
},
"primary_source": "capability_limit",
"secondary_source": "missing_evidence",
"remediability": "tool",
"selected_action": "TOOL",
"post_answer_confidence": null,
"confidence_band": "medium",
"confidence_target": "direct_answer_suitability",
"recommended_next_step": "invoke a calculation tool and reassess"
}
B.4. Capability Limit in a High-Risk Setting
c4tz Expires 7 April 2027 [Page 39]
Internet-Draft MARC October 2026
{
"marc_version": "1.0",
"decision_id": "example-escalate-001",
"pre_capability": 0.21,
"uncertainty": {
"ambiguity": 0.06,
"missing_evidence": 0.27,
"capability_limit": 0.88,
"evidence_conflict": 0.14,
"safety": 0.19
},
"primary_source": "capability_limit",
"secondary_source": "missing_evidence",
"remediability": "human",
"selected_action": "ESCALATE",
"post_answer_confidence": null,
"confidence_band": "low",
"confidence_target": "direct_answer_suitability",
"recommended_next_step": "escalate to a qualified human reviewer"
}
B.5. Answer
{
"marc_version": "1.0",
"decision_id": "example-answer-001",
"pre_capability": 0.82,
"uncertainty": {
"ambiguity": 0.05,
"missing_evidence": 0.12,
"capability_limit": 0.08,
"evidence_conflict": 0.02,
"safety": 0.00
},
"primary_source": "missing_evidence",
"secondary_source": "capability_limit",
"remediability": "none",
"selected_action": "ANSWER",
"post_answer_confidence": 0.79,
"confidence_band": "high",
"confidence_target": "answer",
"recommended_next_step": "provide answer with cited limitations"
}
Appendix C. Example MARC-Disclosure Objects
This appendix is non-normative.
c4tz Expires 7 April 2027 [Page 40]
Internet-Draft MARC October 2026
C.1. Clarification Disclosure
{
"answer": "Which jurisdiction and date range should I use?",
"confidence_band": "low",
"confidence_target": "direct_answer_suitability",
"uncertainty_source": "ambiguity",
"recommended_next_step": "provide jurisdiction and tax year",
"selected_action": "CLARIFY"
}
C.2. Answer After Retrieval Disclosure
This example represents a terminal ANSWER after the controller has
already performed retrieval and reassessed the task. The residual
uncertainty source remains missing_evidence because the answer
depends on the scope and freshness of retrieved authority, not
because the system skipped retrieval.
{
"answer": "Retrieved authority indicates this is allowed.",
"confidence_band": "medium",
"confidence_target": "answer",
"uncertainty_source": "missing_evidence",
"recommended_next_step": "verify the authority before filing",
"selected_action": "ANSWER"
}
Appendix D. Non-Normative JSON Schemas
This appendix is non-normative. The following JSON Schemas
[JSON-SCHEMA-2020-12] are provided as machine-readable validation
aids for JSON [JSON] encodings of MARC-Core and MARC-Disclosure. The
normative requirements are the field semantics and constraints
defined in the body of this document.
D.1. MARC-Core JSON Schema
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://example.invalid/marc/marc-core.schema.json",
"title": "MARC-Core Record",
"description": "Non-normative schema for MARC-Core 1.0.",
"type": "object",
"required": [
"marc_version",
"pre_capability",
"uncertainty",
c4tz Expires 7 April 2027 [Page 41]
Internet-Draft MARC October 2026
"primary_source",
"remediability",
"selected_action",
"confidence_band",
"confidence_target",
"recommended_next_step"
],
"properties": {
"marc_version": {
"type": "string",
"const": "1.0"
},
"decision_id": {
"type": "string",
"minLength": 1,
"maxLength": 128
},
"parent_decision_id": {
"type": ["string", "null"],
"minLength": 1,
"maxLength": 128
},
"iteration": {
"type": "integer",
"minimum": 0
},
"max_iterations": {
"type": "integer",
"minimum": 0
},
"calibration_profile": {
"type": "string",
"minLength": 1,
"maxLength": 128
},
"pre_capability": {
"type": "number",
"minimum": 0.0,
"maximum": 1.0
},
"uncertainty": {
"type": "object",
"required": [
"ambiguity",
"missing_evidence",
"capability_limit",
"evidence_conflict",
"safety"
c4tz Expires 7 April 2027 [Page 42]
Internet-Draft MARC October 2026
],
"properties": {
"ambiguity": {
"type": "number",
"minimum": 0.0,
"maximum": 1.0
},
"missing_evidence": {
"type": "number",
"minimum": 0.0,
"maximum": 1.0
},
"capability_limit": {
"type": "number",
"minimum": 0.0,
"maximum": 1.0
},
"evidence_conflict": {
"type": "number",
"minimum": 0.0,
"maximum": 1.0
},
"safety": {
"type": "number",
"minimum": 0.0,
"maximum": 1.0
}
},
"additionalProperties": false
},
"primary_source": {
"type": "string",
"enum": [
"ambiguity",
"missing_evidence",
"capability_limit",
"evidence_conflict",
"safety"
]
},
"secondary_source": {
"type": ["string", "null"],
"enum": [
"ambiguity",
"missing_evidence",
"capability_limit",
"evidence_conflict",
"safety",
c4tz Expires 7 April 2027 [Page 43]
Internet-Draft MARC October 2026
null
]
},
"remediability": {
"type": "string",
"enum": [
"user_clarification",
"retrieval",
"tool",
"human",
"none"
]
},
"selected_action": {
"type": "string",
"enum": [
"ANSWER",
"CLARIFY",
"RETRIEVE",
"TOOL",
"DELIBERATE",
"ABSTAIN",
"ESCALATE"
]
},
"post_answer_confidence": {
"type": ["number", "null"],
"minimum": 0.0,
"maximum": 1.0
},
"confidence_band": {
"type": "string",
"enum": [
"low",
"medium",
"high"
]
},
"confidence_target": {
"type": "string",
"enum": [
"answer",
"direct_answer_suitability",
"action_suitability"
]
},
"recommended_next_step": {
"type": "string",
c4tz Expires 7 April 2027 [Page 44]
Internet-Draft MARC October 2026
"minLength": 1,
"maxLength": 280
}
},
"patternProperties": {
"^x_": {}
},
"additionalProperties": false,
"allOf": [
{
"if": {
"properties": {
"selected_action": {
"const": "ANSWER"
}
},
"required": [
"selected_action"
]
},
"then": {
"required": [
"post_answer_confidence",
"confidence_target"
],
"properties": {
"post_answer_confidence": {
"type": "number",
"minimum": 0.0,
"maximum": 1.0
},
"confidence_target": {
"const": "answer"
}
}
}
}
]
}
D.2. MARC-Disclosure JSON Schema
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://example.invalid/marc/marc-disclosure.schema.json",
"title": "MARC-Disclosure Object",
"description": "Non-normative schema for MARC-Disclosure 1.0.",
"type": "object",
c4tz Expires 7 April 2027 [Page 45]
Internet-Draft MARC October 2026
"required": [
"answer",
"confidence_band",
"confidence_target",
"uncertainty_source",
"recommended_next_step"
],
"properties": {
"answer": {
"type": "string",
"minLength": 1
},
"confidence_band": {
"type": "string",
"enum": [
"low",
"medium",
"high"
]
},
"confidence_target": {
"type": "string",
"enum": [
"answer",
"direct_answer_suitability",
"action_suitability"
]
},
"uncertainty_source": {
"type": "string",
"enum": [
"ambiguity",
"missing_evidence",
"capability_limit",
"evidence_conflict",
"safety"
]
},
"recommended_next_step": {
"type": "string",
"minLength": 1,
"maxLength": 280
},
"selected_action": {
"type": "string",
"enum": [
"ANSWER",
"CLARIFY",
c4tz Expires 7 April 2027 [Page 46]
Internet-Draft MARC October 2026
"RETRIEVE",
"TOOL",
"DELIBERATE",
"ABSTAIN",
"ESCALATE"
]
}
},
"patternProperties": {
"^x_": {}
},
"additionalProperties": false,
"allOf": [
{
"if": {
"required": [
"selected_action"
],
"properties": {
"selected_action": {
"const": "ANSWER"
}
}
},
"then": {
"properties": {
"confidence_target": {
"const": "answer"
}
}
}
}
]
}
Appendix E. Evaluation Considerations
This appendix is non-normative.
A deployment claiming MARC conformance SHOULD evaluate at least the
following properties:
* task accuracy or task success;
* quality of primary-action selection;
* quality of uncertainty-source attribution;
c4tz Expires 7 April 2027 [Page 47]
Internet-Draft MARC October 2026
* confidence calibration and discrimination;
* rate of unnecessary retrieval, tool use, or escalation; and
* effects on user overreliance.
A deployment claiming MARC conformance SHOULD evaluate, where
applicable:
* action-selection accuracy for each selected_action;
* precision and recall for CLARIFY, RETRIEVE, TOOL, ABSTAIN, and
ESCALATE decisions;
* primary_source attribution accuracy;
* confusion matrices for uncertainty-source attribution;
* calibration error for confidence_band mappings;
* correctness of confidence_target assignment;
* false-direct-answer rate, where ANSWER was selected but a
corrective action would have materially improved reliability;
* false-externalization rate, including unnecessary RETRIEVE, TOOL,
or ESCALATE actions;
* loop termination behavior under adversarial or pathological
inputs;
* escalation appropriateness in high-risk domains; and
* user comprehension of confidence_band, confidence_target,
uncertainty_source, and recommended_next_step.
Evaluation datasets SHOULD include examples for each primary_source
and each selected_action. They SHOULD also include negative examples
where the superficially plausible action is not the correct MARC
action.
When the task structure permits, evaluation MAY include both ordinary
calibration metrics and metacognitive sensitivity metrics in order to
distinguish performance from knowledge about performance.
c4tz Expires 7 April 2027 [Page 48]
Internet-Draft MARC October 2026
For deployments involving human-AI interaction, evaluation SHOULD
also include human-side measures such as reliance calibration,
refusal comprehension, clarification burden, escalation acceptance,
and whether users can correctly restate the source of uncertainty
after interaction.
Appendix F. Design Rationale and Literature Traceability
This appendix is non-normative.
The requirement to separate pre-decision capability and post-decision
confidence is informed by work in human and model metacognition
[STEYVERS-META2025] and by evidence of choice-supportive bias in LLM
confidence estimates [KUMARAN2026].
The confidence_target field is included because confidence_band alone
can be ambiguous across answer and non-answer actions. For ANSWER,
confidence_band refers to the candidate answer. For actions such as
CLARIFY, RETRIEVE, TOOL, ABSTAIN, or ESCALATE, confidence_band
usually refers to direct-answer suitability under current conditions.
The uncertainty taxonomy and the emphasis on choosing a corrective
action rather than only abstaining are motivated by benchmark work on
identifying and solving uncertainty [LIU-CONFUSE2025].
The treatment of retrieval and tool use as controlled externalization
is motivated by work on value-based cognitive offloading
[GILBERT2024].
The prohibition on using MARC signals for persuasive optimization is
motivated by findings on AI persuasion risks [SALVI2025].
Appendix G. Changes from -02
This section is to be removed before publishing as an RFC.
This revision makes the following changes relative to draft-c4tz-
marc-02:
* changes the intended status from Informational to Experimental
while retaining the intended Independent Submission Stream;
* revises the Abstract and Introduction to state the experimental
purpose and absence of IETF consensus;
* adds experimental objectives, reporting guidance, assessment
criteria, and limits;
c4tz Expires 7 April 2027 [Page 49]
Internet-Draft MARC October 2026
* distinguishes metadata delivery, preservation of object
associations, semantic processing, and behavioral evaluation;
* clarifies that shared confidence labels do not establish
comparable accuracy across deployments;
* updates implementation status to identify available reference
artifacts and their scope;
* removes speculative statements about future IANA registries;
* groups normative and informative references under one References
section and adds RFCXML markup for requirement keywords;
* clarifies that private extensions supplement, rather than replace
or extend, the canonical primary_source enumeration;
* harmonizes loop termination as a mandatory controller
responsibility, with consistent references from the validation,
security, and conformance sections;
* separates mandatory documentation from additional recommendations
and records open review questions about partial components,
receiver behavior, and calibration context;
* corrects the non-normative MARC-Disclosure schema to enforce the
existing ANSWER confidence-target rule when selected_action is
present, and adds a negative disclosure example; and
* retains the MARC 1.0 fields and action set while replacing
standardization wording with specification wording.
Appendix H. Validation Test Vectors
This appendix is non-normative.
H.1. Valid ANSWER Record
A valid ANSWER record includes selected_action set to ANSWER,
post_answer_confidence present and non-null, and confidence_target
set to answer.
c4tz Expires 7 April 2027 [Page 50]
Internet-Draft MARC October 2026
{
"marc_version": "1.0",
"pre_capability": 0.80,
"uncertainty": {
"ambiguity": 0.05,
"missing_evidence": 0.10,
"capability_limit": 0.08,
"evidence_conflict": 0.02,
"safety": 0.00
},
"primary_source": "missing_evidence",
"secondary_source": null,
"remediability": "none",
"selected_action": "ANSWER",
"post_answer_confidence": 0.77,
"confidence_band": "high",
"confidence_target": "answer",
"recommended_next_step": "provide the answer"
}
H.2. Invalid ANSWER without post_answer_confidence
The following record is invalid because selected_action is ANSWER but
post_answer_confidence is null.
{
"marc_version": "1.0",
"pre_capability": 0.80,
"uncertainty": {
"ambiguity": 0.05,
"missing_evidence": 0.10,
"capability_limit": 0.08,
"evidence_conflict": 0.02,
"safety": 0.00
},
"primary_source": "missing_evidence",
"remediability": "none",
"selected_action": "ANSWER",
"post_answer_confidence": null,
"confidence_band": "high",
"confidence_target": "answer",
"recommended_next_step": "provide the answer"
}
H.3. Invalid primary_source none
The following record is invalid because MARC 1.0 does not define none
as an uncertainty source.
c4tz Expires 7 April 2027 [Page 51]
Internet-Draft MARC October 2026
{
"marc_version": "1.0",
"pre_capability": 0.80,
"uncertainty": {
"ambiguity": 0.00,
"missing_evidence": 0.00,
"capability_limit": 0.00,
"evidence_conflict": 0.00,
"safety": 0.00
},
"primary_source": "none",
"remediability": "none",
"selected_action": "ANSWER",
"post_answer_confidence": 0.90,
"confidence_band": "high",
"confidence_target": "answer",
"recommended_next_step": "provide the answer"
}
H.4. Invalid Score Range
The following record is invalid because uncertainty.missing_evidence
is greater than 1.0.
{
"marc_version": "1.0",
"pre_capability": 0.80,
"uncertainty": {
"ambiguity": 0.05,
"missing_evidence": 1.20,
"capability_limit": 0.08,
"evidence_conflict": 0.02,
"safety": 0.00
},
"primary_source": "missing_evidence",
"remediability": "none",
"selected_action": "ANSWER",
"post_answer_confidence": 0.77,
"confidence_band": "high",
"confidence_target": "answer",
"recommended_next_step": "provide the answer"
}
H.5. Invalid confidence_target for ANSWER
The following record is invalid because selected_action is ANSWER but
confidence_target is direct_answer_suitability.
c4tz Expires 7 April 2027 [Page 52]
Internet-Draft MARC October 2026
{
"marc_version": "1.0",
"pre_capability": 0.80,
"uncertainty": {
"ambiguity": 0.05,
"missing_evidence": 0.10,
"capability_limit": 0.08,
"evidence_conflict": 0.02,
"safety": 0.00
},
"primary_source": "missing_evidence",
"remediability": "none",
"selected_action": "ANSWER",
"post_answer_confidence": 0.77,
"confidence_band": "high",
"confidence_target": "direct_answer_suitability",
"recommended_next_step": "provide the answer"
}
H.6. Invalid MARC-Disclosure Confidence Target for ANSWER
The following disclosure is invalid because selected_action is ANSWER
but confidence_target is direct_answer_suitability. The same rule
applies when confidence_target is action_suitability. When
selected_action is omitted, this conditional check does not by itself
restrict confidence_target; its other requirements still apply.
{
"answer": "The result is available.",
"confidence_band": "high",
"confidence_target": "direct_answer_suitability",
"uncertainty_source": "missing_evidence",
"recommended_next_step": "review the supporting evidence",
"selected_action": "ANSWER"
}
Appendix I. Implementation Status
This section is to be removed before publishing as an RFC.
This section records available development artifacts, not independent
certification or evidence of operational effectiveness.
As of 4 October 2026, the author's public MARC reference
implementation repository (https://github.com/c4tzzz/MARC/tree/
cf41f5d3b9e3dd4c212752b3595ae2c9955acde6) contains the following
artifacts. This inventory refers to commit cf41f5d:
c4tz Expires 7 April 2027 [Page 53]
Internet-Draft MARC October 2026
* Python and TypeScript implementations of MARC-Core and MARC-
Disclosure validation, with errors for supported mandatory checks
and separate warnings for supported recommendation-level checks;
* MARC-Core to MARC-Disclosure projection functions and a Python
command-line interface;
* non-normative JSON Schemas, positive and negative example records,
shared validation vectors, and expected results;
* automated tests, including a comparison of Python and TypeScript
results on the common vectors;
* illustrative generic-agent, retrieval-controller, and gateway
integrations; and
* implementation, mapping, trust, and interoperability
documentation, together with a template for external
implementation reports.
The repository at the cited commit identifies draft-c4tz-marc-02 as
the implemented revision. This revision retains the MARC 1.0 fields
and action set, clarifies the use of private extensions for residual
uncertainty, makes controller loop termination requirements
consistent, and corrects the disclosure schema's enforcement of the
existing ANSWER confidence-target rule. The cited repository's
disclosure schema and validators do not yet enforce that cross-field
rule; experiments using them need an additional check. The artifacts
support validation and projection experiments; they do not provide an
empirically validated controller, a calibration method, or evidence
of full deployment conformance.
The Python and TypeScript implementations are maintained in the same
project. Their agreement on shared tests is useful consistency
evidence, but is not presented as evidence of independently developed
implementations. This document reports no completed external
interoperability trial, production deployment, or behavioral
evaluation.
The repository artifacts are non-normative. In particular, a
restriction imposed by a reference schema or validator does not
create a requirement beyond the normative text. Implementers
comparing results distinguish the specification's requirements from
restrictions imposed by a particular validation aid or local policy.
c4tz Expires 7 April 2027 [Page 54]
Internet-Draft MARC October 2026
Appendix J. Open Issues
This section is to be removed before publishing as an RFC.
This working revision seeks feedback on the following questions.
They identify possible changes for subsequent revisions and do not
relax the current requirements or establish additional conformance
classes.
Partial-component conformance Should standalone validators,
projection libraries, and receivers have distinct conformance
classes? If so, which requirements apply to each role, and how
should a deployment report their composition? Until such classes
are specified, reports identify the functions tested using
Section 4.3.3 and the existing classes in Section 20.2.
Receiver errors and unknown versions Which common receiver behavior
is needed for malformed records, unsupported versions, and unknown
enumerated values? Feedback is sought on rejection, error
reporting, and any explicitly negotiated fallback or opaque
forwarding, consistent with preserving the semantics of recognized
fields. This revision does not define a common error object or a
complete receiver error-handling procedure.
Calibration context across components What calibration context needs
to accompany exchanged confidence bands, particularly when only
MARC-Disclosure is carried? Questions include how a receiver
identifies the calibration profile and its version, task scope,
and thresholds, and how that information remains associated with
the disclosure without requiring internal numeric scores to be
exposed. The current optional calibration_profile field and
deployment documentation do not define a shared exchange mechanism
for that context.
Author's Address
c4tz
c0dx3
France
Email: c4tzzzz@proton.me
c4tz Expires 7 April 2027 [Page 55]