Illustrative Codes Are Not a Namespace: Registries for Execution-Finality Consequence Classes, Sink Types, Act Types, Failure Codes, Profiles, and Media Types

What This Version (-01) Contains This Internet-Draft is draft-das-ef-registries-01. It proposes the shared namespaces used by and : consequence class, sink type, act type, reuse policy, decision, consume outcome, failure codes, profile identifiers, and candidate media types. It does not request IANA action in this revision.

Contents of -01

Problem of uncoordinated "illustrative" codes and the residual gap after JWT, OAuth errors, and RFC 9457.
Initial tables for classes, sinks, act types, reuse policies, decisions, consume outcomes, EF-nnn codes, and profiles.
Placeholder warning for urn:ietf:params:ef and the ef URI scheme.
Unknown public EF-nnn fails closed as EF-080 (intentional forward compatibility).
WellTyped identities, hash/algorithm pointer to the handle draft, and formal-tool note.
Industrial disclaimer, community questions, and per-WG venue subsections.

Changes from -00

Document name and series info updated to -01.
PURPOSE / JURISDICTION / REVOCATION codes moved into 060-069 as EF-060, EF-061, EF-062.
Added EF-047 PARTIAL_COMMIT; EF-044 remains PATH_INCOMPLETE.
Decision registry now includes PREPARED, ABORTED, COMPENSATING, CONTAINED, UNKNOWN.
Consume outcomes now include RELEASED.
ENVELOPE identical replay default documented as forbidden.
Family reference titles aligned; handle and composite cited as -01.

Introduction

Vulnerability: The Same String, Two Meanings A sink that returns EF-005 and a second sink that returns AUTHORITY_ALREADY_USED may intend the same event. A third sink may use EF-005 for expired handles. A CAD that labels an act consequence_class=PHYSICAL may mean coil motion in one profile and printer dispatch in another. Without a shared namespace, verify/consume receipts cannot be compared across vendors or across drafts in the same family.

Uncoordinated codes prevent receipt comparison Sink A receipt: reason_code = EF-005 Sink B receipt: reason_code = EF-005 Observer: same code != same predicate Until a registry binds EF-005 to one definition, the receipt is local dialect, not an interoperable object.

Existing Mechanisms Already Name Adjacent Objects OAuth defines error members such as invalid_grant . HTTP Problem Details defines a type URI for API errors . JWT and CWT have claim-name registries . CoAP and HTTP have status codes. RATS/EAT and SCITT have their own typed statements. Those registries should be reused where the object really is an OAuth error, an HTTP problem, or a JWT claim. This document exists only for names that those registries do not currently define: consequence class, sink type, act type, reuse policy, execution-finality failure code, finality profile id, and compact media types for CAD / handle / receipt.

Why the Residual Gap Can Remain Companion drafts keep writing "illustrative, not IANA." That sentence is honest and also the interoperability failure. Profile catalogues for 6G, enterprise AI, CVID, silicon, and satellites multiply local enums. A handle implementation cannot declare which foreign codes it understands.

What This Document Introduces

A small set of IANA-facing registries with Expert Review as the default policy.
An initial allocation aligned with and other family drafts.
A rule that unregistered codes MUST use a private prefix or a URI, not the EF- numeric space.
Media type and optional JWT/CWT claim names for the handle objects.
An explicit non-goal: this is not a policy ontology of all possible real-world effects.

Conventions and Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals.

Direct Question: What Problem Does a Registry Solve? If two Finality Sinks emit receipts for the same denied effect, what shared identifiers let a relying party know they denied the same class of failure? Receipt_A.reason_code == Receipt_B.reason_code AND both codes are in the EF Failure Code registry ==> same registered predicate Otherwise the equality is coincidental.

Motivating Scenario: One Agent, Three Sinks, Three Dialects An agent issues a payout, a ledger write, and a notification. The payment sink returns EF-025. The MCP tool sink returns DESTINATION_MISMATCH. The mail sink returns HTTP 403 with invalid_scope. A coordinator cannot tell whether all three denied the same substitution or three different conditions.

Composite act, uncoordinated deny codes Candidate composite C | +--> settlement sink : EF-025 +--> tool sink : DESTINATION_MISMATCH +--> mail sink : invalid_scope Registry goal: map each local dialect to one registered failure code + one consequence class so the coordinator can fail closed on C.

Design Goals and Non-Goals The goal is a compact, extensible namespace for execution-finality objects so that CAD, Execution Handle, verify, consume, and receipt fields have one meaning across profiles. This document does not classify law, medicine, or weapons; does not assign severity scores that bind operators; does not replace HTTP, OAuth, or problem+json; does not require every private deployment to register; and does not freeze the companion architecture drafts.

Existing Registries and the Proposed Delta Existing IANA or protocol namespace and residual naming question

Existing namespace	Already names	Does not name
OAuth errors	Grant and token-endpoint failures	Sink consume and act-digest mismatch
HTTP status / RFC 9457	Transport and API problem type	Finality-specific reason inside 403/409
JWT / CWT claims	iss, aud, exp, cnf	act_digest, sink_id, reuse_policy as EF fields
RATS / EAT	Environment claims	Consequence class of a later act
SCITT	Statement / receipt types	Whether a receipt is a permit to effectuate
Media types	Generic JSON/CBOR	CAD, handle, pending, receipt types

Terminology Terms Candidate Act, Candidate Act Descriptor, Execution Handle, Finality Sink, Consume, and Finality Receipt are used as in . Consequence Class: A registered label for the kind of external effect a Candidate Act would produce if permitted. Sink Type: A registered label for the kind of effectuation boundary. Act Type: A registered label for the kind of proposed operation, finer than consequence class. Failure Code: A registered identifier for a verify/consume/path failure predicate. Profile Identifier: A registered name for a named bundle of required CAD fields, reuse default, and assurance expectations.

Namespace Rules Public compact codes: EF-nnn failure codes (provisional until IANA) URI forms in examples: urn:ietf:params:ef:... ef:<registry>:<name> are PLACEHOLDERS. Neither an IETF URN namespace under RFC 3553 nor an "ef" URI scheme is requested in this revision. Implementations MUST NOT treat those strings as registered identifiers. Private / experimental: EF-X-* MUST NOT be registered X- / uns: / urn:uuid: deployment-local Collision rule: unregistered use of EF-nnn is NOT interoperable and SHOULD be rejected by strict profiles. Registered names are case-sensitive strings in the compact form specified for each registry. Profiles MAY also carry the URI form in receipts.

Where Registry Values Appear

Registry fields on CAD, handle, and receipt CAD act_type -> Act Type registry consequence_class -> Consequence Class registry finality_sink.type -> Sink Type registry EH reuse_policy -> Reuse Policy registry profile_id -> Profile registry (optional) Receipt decision -> Decision registry consume_outcome -> Consume Outcome registry reason_code -> Failure Code registry

Consequence Class Registry A consequence class is a coarse effect kind. It is not a risk rating and not a legal category. Profiles use it to select default reuse policy and required CAD fields. Initial consequence classes

Value	Meaning	Typical sink
FINANCIAL	Balance, settlement, or rail post changes	SETTLEMENT
PHYSICAL	Motion, energy, or process I/O changes	ACTUATION
RF	Transmit, beam, or spectrum enablement	RF_TRANSMIT
COMMUNICATIVE	Message send, call setup, or reachability	EGRESS or REACHABILITY
DISCLOSURE	Release of held data or model information	RELEASE or EGRESS
RENDER	Presentation to a display or media sink	RENDER
CONTROL_PLANE	Live infra mutation (DNS, BGP, cluster, IAM)	CONTROL_PLANE
IDENTITY	Credential issuance or privilege grant	IDENTITY_ISSUE
MEMORY_WRITE	Durable agent memory or corpus write	MEMORY
MODEL_RELEASE	Weight, adapter, or SMI release	RELEASE
CLINICAL	Care-delivery order or device setpoint	ACTUATION or CLINICAL
ADMINISTRATIVE	Recorded official or eligibility effect	ADMIN
ERASURE	Required delete, hold, or export effect	DATA_LIFECYCLE
COMPOSITE	Two or more classes that must close together	COMPOSITE

CLINICAL is a technical effect class for care-delivery sinks. It is not a medical-device approval and not a clinical-safety standard.

Sink Type Registry Initial sink types

Value	Boundary that first makes the effect real
SETTLEMENT	Payment or ledger post
TOOL_DISPATCH	Agent tool / MCP / function invoke
ACTUATION	ICS, robot, vehicle, or lab effector
RF_TRANSMIT	Radio or optical transmit enable
EGRESS	Organization or device outbound release
RELEASE	Model, secret, or dataset release
RENDER	Compositor, display, or media decoder
CONTROL_PLANE	Orchestrator, DNS, routing, or IAM commit
IDENTITY_ISSUE	Issuer of a usable credential
MEMORY	Durable memory or RAG write
REACHABILITY	Create or extend a contact path
ADMIN	Authoritative administrative record
DATA_LIFECYCLE	Erase, hold, or mandated export
COMPOSITE	Coordinator of N child sinks

Act Type Registry Act types are optional finer labels. The initial set is small on purpose. Profiles SHOULD prefer consequence class plus operation fields when an act type would only duplicate a tool name. Initial act types

Value	Notes
PAYMENT_POST	Settlement instruction
TOOL_CALL	Generic tool/function invoke
SETPOINT_WRITE	Process or device setpoint
RF_ENABLE	Enable a transmit path
MESSAGE_SEND	Outbound message
DATA_EGRESS	Copy or disclose held data
OUTPUT_RELEASE	Model or inference output release
WEIGHT_LOAD	Load or hot-swap model weights
MEMORY_COMMIT	Durable memory write
PLAN_APPLY	Control-plane apply of a prepared plan
CREDENTIAL_ISSUE	Issue a usable token or cert
RENDER_PRESENT	Present media to a surface
ERASE_COMMIT	Commit a delete or hold

Reuse Policy Registry Initial reuse policies

Value	Rule
SINGLE_USE	First successful consume wins
COUNTED	Consume until max_uses
ENVELOPE	Repeat only inside declared bounds; identical-digest replay forbidden unless allow_identical_replay

High-consequence classes FINANCIAL, PHYSICAL, RF, MODEL_RELEASE, and CLINICAL SHOULD default to SINGLE_USE unless a profile documents why not.

Decision and Consume-Outcome Registries Sink-commit decisions used by : EFFECTUATED, REJECTED. Coordinator and composite decisions used by : NON_EFFECTIVE, PREPARED, ABORTED, COMPENSATING, CONTAINED, UNKNOWN. Consume outcomes: CONSUMED, RESERVED, RELEASED (reservation dropped on abort, no post), UNCHANGED, FAILED.

Failure Code Registry Codes are compact EF-nnn identifiers. Ranges are reserved to keep related failures adjacent. 002-019 authority / handle 020-039 act correspondence 040-059 sink / generation / path 060-069 policy / purpose / jurisdiction 070-079 escalation / human gate 080-089 fail-closed / availability of TCB 090-099 reserved 100-199 specified by later profiles 900-999 reserved for private experiments (MUST NOT be registered) Initial failure codes

Code	Name	Predicate
EF-002	NO_FINALITY_AUTHORITY	No current handle or equivalent authority
EF-003	HANDLE_INTEGRITY_FAILURE	Handle signature or MAC fails
EF-004	HANDLE_EXPIRED	Handle or CAD past expires_at
EF-005	AUTHORITY_ALREADY_USED	Reuse policy exhausted
EF-006	REPLAY_DETECTED	Same act presented against consumed state
EF-012	SCOPE_MISMATCH	Key-binding, workload, or scope proof fails
EF-020	DESTINATION_MISMATCH	Live destination not bound destination
EF-023	ACT_DIGEST_MISMATCH	Reconstructed digest != handle digest
EF-024	AMOUNT_MISMATCH	Financial amount field diverged
EF-025	BENEFICIARY_MISMATCH	Payee / recipient diverged
EF-026	RAIL_MISMATCH	Settlement rail diverged
EF-030	MODE_FORBIDDEN	Device or process mode forbids the write
EF-031	INTERLOCK	Safety interlock open
EF-033	VALUE_ENVELOPE	Setpoint or argument outside envelope
EF-040	SINK_MISMATCH	Presented at a sink other than bound sink
EF-041	GENERATION_STALE	Policy or context generation moved
EF-042	REUSE_POLICY_VIOLATION	Reuse rule not satisfied
EF-043	ENVELOPE_EXCEEDED	Live CAD left the envelope
EF-044	PATH_INCOMPLETE	Alternate path can produce K
EF-047	PARTIAL_COMMIT	Required child posted while composite did not close
EF-060	PURPOSE_MISMATCH	Live purpose not the authorized purpose
EF-061	JURISDICTION_MISMATCH	Current JEC does not satisfy J_req
EF-062	REVOCATION_ACTIVE	Handle or basis revoked before commit
EF-070	ESCALATION_REQUIRED	Profile requires a further gate
EF-080	FAIL_CLOSED	Required check unavailable; no effect
EF-081	CONSUME_STATE_UNAVAILABLE	Consume store cannot be used safely

Profile Identifier Registry A profile identifier names a bundle, not a vendor. Initial values are architecture bundles from the family. Domain catalogues SHOULD reuse these rather than mint a new profile per industry press release. Initial profile identifiers

Value	Bundle
ef-handle-strict	Reconstruct + sink bind + SINGLE_USE default + fail closed
ef-handle-envelope	Strict verify with documented envelope reuse
ef-handle-mitigation	Handle present but path coverage incomplete; must not claim prevention
ef-jurisdiction-strict	Handle plus current JEC dimensions
ef-purpose-strict	Handle plus purpose binding
ef-path-complete	Handle plus declared complete path inventory

Media Types This document requests, if the community agrees to proceed, registration of: application/ef-cad+json application/ef-handle+json application/ef-pending+json application/ef-receipt+json application/ef-cad+cbor application/ef-handle+cbor application/ef-receipt+cbor Until registration, implementations MAY use these strings only in private deployments and SHOULD include a profile_id.

Optional JWT / CWT Claim Names If a profile encodes an Execution Handle as JWT or CWT, the following claim names are proposed. They MUST NOT collide with registered JWT/CWT claims. This document does not itself complete that IANA request; it records the intended names for review. ef_act_digest ef_sink_id ef_reuse_policy ef_profile_id ef_generations ef_candidate_act_id Standard iss, exp, nbf, jti, and cnf remain the existing registries' objects. This draft does not redefine them.

Optional HTTP Authentication Scheme illustrates Authorization: EFHandle .... That scheme name is provisional. A later revision may request an HTTP authentication scheme registration. This -00 does not.

Mapping to Existing Error Channels A sink that speaks HTTP SHOULD still use an appropriate status code (typically 403 or 409) and MAY include an RFC 9457 problem document whose type URI is the URI form of the EF failure code. OAuth token endpoints SHOULD keep OAuth errors for token issuance and use EF codes only at the effectuation sink. HTTP 403 Content-Type: application/problem+json { "type": "urn:ietf:params:ef:failure:EF-023", "title": "ACT_DIGEST_MISMATCH", "status": 403, "ef_handle_id": "...", "ef_sink_id": "core-post-eu-1" }

Formal Consistency Rules Let R_class, R_sink, R_act, R_reuse, R_dec, R_out, R_fail, R_prof be the eight provisional tables. The identities below are the same membership tests as the validation pseudocode. WellTyped(CAD) iff CAD.consequence_class in R_class and CAD.sink_type in R_sink and (CAD.act_type = bot or CAD.act_type in R_act) UnknownPublic(code) iff code matches EF-nnn, nnn in [002,899] and code notin R_fail Strict: UnknownPublic(code) => reason = EF-080 and not Effect WellTyped(CAD) := CAD.consequence_class in ConsequenceClassRegistry AND CAD.finality_sink.sink_type in SinkTypeRegistry AND (CAD.act_type absent OR CAD.act_type in ActTypeRegistry) WellTyped(EH) := EH.reuse_policy in ReusePolicyRegistry AND (EH.profile_id absent OR EH.profile_id in ProfileRegistry) WellTyped(Receipt) := Receipt.decision in DecisionRegistry AND Receipt.consume_outcome in ConsumeOutcomeRegistry AND (Receipt.reason_code absent OR Receipt.reason_code in FailureCodeRegistry) UnknownPublicCode := compact form looks like EF-nnn AND code not registered AND not in 900-999 private range Strict profile: UnknownPublicCode ==> treat as EF-080 FAIL_CLOSED rather than as a vendor extension. This fail-closed rule is intentional forward compatibility: a strict sink that has not yet learned a later-registered public EF-nnn MUST refuse rather than guess. Operators who need to accept a newly registered code MUST update the local table. Mitigation profiles MAY log-and-continue; they MUST NOT call that behavior the strict profile.

Hash Function and Formal Tools This document names codes; it does not define d(C). The Act Digest hash, canonicalization, SHA-256 default, and collision-resistance argument live in . A receipt that carries a digest MUST also carry the algorithm name used to produce it. Formal verification tools are not required to use these tables. A TLA+ or Alloy model of a sink SHOULD treat WellTyped and UnknownPublic => EF-080 as invariants of the strict profile. Registry membership is not a security proof; it is a precondition the handle and composite models assume when they mention EF-nnn.

Registration State Machine

Illustrative Pseudocode

Validate Registry Fields on a CAD function validate_cad_registries(cad, tables): if cad.consequence_class not in tables.consequence: return FAIL("unregistered consequence_class") if cad.finality_sink.sink_type not in tables.sink: return FAIL("unregistered sink_type") if cad.act_type and cad.act_type not in tables.act: return FAIL("unregistered act_type") return PASS

Emit a Registered Reason Code function reason(code, tables): if code in tables.failure: return { compact: code, name: tables.failure[code].name, uri: "urn:ietf:params:ef:failure:" + code } if matches_ef_numeric(code) and not private_range(code): return fail_closed("EF-080", detail="unknown public failure code") return { compact: code, name: "PRIVATE", uri: null }

Map to HTTP Problem Details function to_problem(receipt): r = reason(receipt.reason_code, tables) status = 409 if r.compact == "EF-005" else 403 return { type: r.uri, title: r.name, status: status, ef_decision: receipt.decision, ef_consume_outcome: receipt.consume_outcome }

Proposed Registration Policy Unless the community directs otherwise, the proposed policy for all EF registries in this document is Expert Review . Media types follow the normal media-type process. Experts SHOULD reject: duplicate predicates under a new name; codes that encode a vendor product; codes that assert a legal conclusion; and changes that alter the predicate of an already registered value. New semantics get a new code. Old codes may be marked Deprecated.

Industrial Relevance and Public-Roadmap Alignment Agent platforms, clouds, PSPs, and silicon vendors already ship local enums for deny reasons and tool categories. A public registry is useful only if two of those stacks need to read each other's receipts. This section does not claim that any named company lacks a namespace or should adopt these codes. Named products are not described as implementers of this draft. Complementary reading: MCP tool names are tool identifiers, not consequence classes. Copilot connector errors are product errors, not EF failure codes. OAuth invalid_scope remains an OAuth error. NVIDIA attestation result types remain RATS/EAT objects. A rail decline code remains a rail code unless a profile explicitly maps it to an EF code at the SETTLEMENT sink. MCP / Copilot tool name != consequence class OAuth invalid_scope != EF-023 PSP / rail decline != EF failure code (unless mapped) Attestation result type != consume outcome Named organizations are not asserted to have reviewed, implemented, or endorsed this registry. Corrections of mappings and requests to remove a name are invited. Silence is not agreement.

Questions to the IETF Community Criticism, including the conclusion that no new registry is needed, is a successful review outcome.

Is a new EF namespace justified, or should failure codes live only as RFC 9457 type URIs under a vendor or draft tree?
Is Expert Review the right policy, or Specification Required, or First Come First Served for some tables?
Should consequence class and sink type be one table?
Is CLINICAL an acceptable technical class, or is it too close to a regulated domain name?
Should COMPOSITE be a class, a sink type, both, or deferred to a later composite-finality draft?
Are the initial EF-nnn assignments stable enough to freeze, or should -00 keep them all Provisional?
Should JWT/CWT claim names be requested now or only after the handle encoding is chosen?
Should an HTTP authentication scheme be requested, or is that premature?
How should private deployments avoid colliding with later public allocations?
Which existing IANA registry is the closest overlap this draft underestimates?
Should this document be merged into draft-das-execution-handle instead of standing alone?
Which venue should own any eventual IANA request: dispatch first, then SEC or ART?

Potential IETF Discussion Venues This document does not claim that any named group should adopt the work. Overlap review should come before an IANA request.

DISPATCH The registries cut across OAuth, HTTP, RATS, and SCITT. DISPATCH is the natural first discussion venue if no WG claims the namespace.

OAuth Relevant if EF codes or handle claims are profiled onto tokens. OAuth should not be asked to own consequence classes for actuation or RF.

HTTPAPI Relevant to problem+json mapping and any later authentication-scheme request. Not a home for sink-type semantics.

RATS Relevant only to keep EAT/attestation claim names from colliding with proposed ef_* claims. RATS should not own FINANCIAL vs PHYSICAL.

SCITT Relevant if Finality Receipts are SCITT statements and need a statement type. SCITT should not own consume-state failure codes.

WIMSE Relevant to workload identifiers inside CAD.actor, not to the failure namespace itself.

SAAG Useful for whether a new security-area namespace is justified. SAAG does not adopt documents.

No Presumed Home An individual -00 that requests IANA too early will fail. This version specifies the tables and policy so they can be rejected cleanly.

Relationship to Other Execution-Finality Internet-Drafts defines the objects that carry these fields. This document names the fields' allowed values. Domain drafts SHOULD reference these registries instead of minting parallel enums. DAS-PROTOCOL architecture: computation is not authority DAS-HANDLE wire objects that carry the fields this document allowed values DAS-COMPOSITE uses COMPOSITE class/type, EF-044 PATH_INCOMPLETE, EF-047 PARTIAL_COMMIT Predicate drafts that SHOULD reuse codes, not fork them: DAS-STATE, DAS-REVOCATION, DAS-PATH, DAS-JURISDICTION, DAS-PURPOSE Domain drafts that SHOULD cite this registry: DAS-AGENTIC / DAS-TOOL, payment, OT/actuation, 6G/NTN, enterprise-AI, silicon, CVID profiles See also , , , , , , , and .

Security Considerations A registry does not enforce finality. It only makes failures comparable. Security-relevant risks of the namespace itself include:

Colliding public codes with private meanings (mitigate with the unknown-public-code fail-closed rule).
Using a coarse class to hide a finer substitution (amount mismatch reported only as SCOPE_MISMATCH).
Treating a registered profile_id as proof that path coverage exists.
Stable reason codes that leak destination or act class in receipts.

Privacy Considerations Consequence class, act type, and failure code can reveal that a financial, clinical, or disclosure act was attempted. Receipts SHOULD omit unused fields and MAY return a coarse code to untrusted callers while logging the registered fine code locally.

IANA Considerations This version does not request IANA action. It defines candidate tables and a proposed Expert Review policy so that a later revision, if the community agrees, can request:

Execution-Finality Consequence Classes
Execution-Finality Sink Types
Execution-Finality Act Types
Execution-Finality Reuse Policies
Execution-Finality Decisions
Execution-Finality Consume Outcomes
Execution-Finality Failure Codes
Execution-Finality Profile Identifiers
media types listed in

JWT/CWT claim names and an HTTP authentication scheme are explicitly not requested in this revision.

Criticism, Corrections, and Review Invited The most useful criticism is that an existing IANA registry already covers one or more of these tables. That evidence should delete the overlapping table, not be ignored. Equally useful is a demonstration that keeping "illustrative codes" in each domain draft is preferable to a shared namespace at this stage.

Conclusion Execution-finality objects are not interoperable while every profile assigns private meaning to EF-005 and FINANCIAL. This draft proposes a namespace, an initial allocation, and a conservative IANA posture: specify the tables now, request registrations only after the community accepts that a new namespace is required. ILLUSTRATIVE CODE != SHARED PREDICATE Same string != same meaning Register the predicate OR keep the dialect private and do not pretend it is IANA.