tool_use Is Not invoke(): Binding Execution-Finality to Claude, ChatGPT, and MCP

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 1 March 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Every hosted agent product converged on the same wire shape:¶

model output
  Anthropic:  content[type=tool_use] {id, name, input}
  OpenAI:     tool_calls[] {id, function.name, function.arguments}
  MCP:        tools/call {name, arguments}
        |
        v
host.invoke(name, arguments)
        |
        v
tool_result / function output / MCP result

This document inserts a gate on the middle arrow without asking Anthropic or OpenAI to change model cards. The gate is the profile in [I-D.das-agentic]: wrap the block as an AgentCandidateAct, hold it non-effective, validate, commit evidence, issue scoped authority, verify at the dispatch sink, consume, then invoke.¶

Vendor names are deployment classes. Field names below follow public tool-use and MCP shapes as of this writing and are informative where those APIs evolve. The load-bearing contract is the act object, not a trademark.¶

2. Why This Binding Is the Lab-Facing Draft

The agentic profile is the architecture. This document is the thing a runtime engineer can implement on Monday. Labs lose enterprise deals on a specific sentence: "what happens when the model is injected and still emits a tool block." Answers that are only "we train refusal" or "we log the block" are weaker than "invoke() is unreachable without a consumed authority_id bound to this argument digest."¶

That sentence maps onto products customers already buy: Claude for Work with tools and computer use, ChatGPT Enterprise with actions and an Agents runtime, and MCP servers wired into both. The binding is how isolation of action [DAS-ISOLATION] lands in the loop those products run thousands of times per minute.¶

For an Anthropic reliability or safety engineer the claim is mechanical: a tool_use block can exist, be shown in the transcript, and still leave the world unchanged. Refusal training reduces how often the block appears. This binding reduces what the block can do when it appears anyway — including when the model is following a retrieved instruction it treated as a user turn.¶

For an OpenAI platform or Agents engineer the claim is the same on tool_calls[] and on Actions HTTP. Schema-valid arguments are not a capability. Parallel calls are not one capability. An Agents SDK that owns the loop MUST expose the hook or wrap the tool objects; otherwise the safest model still has an unguarded invoke.¶

3. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

A host that executes a tool block without current dispatch authority is non-conforming with this binding even if the model vendor's SDK performed the HTTP call.¶

4. Problem Space

The host loop is short and trusted by default:¶

for block in model_output.tool_uses:
    result = tools[block.name](**block.input)
    append_tool_result(block.id, result)

That loop is correct only if the block is a capability. It is not. Failures this binding treats as first-class:¶

• Injected page or ticket text causes tool_use name=email.send to a new recipient.¶
• OpenAI function.arguments JSON is valid against the schema and still pays the wrong vendor (see [I-D.das-payment]).¶
• MCP server with the same tool name is swapped (T7 in the agentic profile).¶
• Computer-use screenshot policy allows clicks; a submit posts a form the model narrated incorrectly.¶
• Memory or project write persists a prohibited join for the next turn [I-D.das-enterprise].¶
• The host retries invoke() after a timeout and double-executes a side-effecting tool.¶

5. What Labs Already Ship and What They Do Not Bind

6. Binding: Anthropic tool_use

Informative source shape:¶

{
  "type": "tool_use",
  "id": "toolu_01A",
  "name": "email_send",
  "input": {
    "to": "alice@example.com",
    "subject": "Invoice",
    "body": "..."
  }
}

Mapping MUST be:¶

• candidate_act_id — host-generated, MUST NOT equal toolu_* alone if that id can be replayed across sessions; MAY incorporate it.¶
• act_type — TOOL_CALL, or BROWSER_ACTION / COMPUTER_USE when name is in the computer-use family.¶
• tool.tool_id and function_id — name.¶
• tool.tool_protocol — LOCAL_FUNCTION or MCP.¶
• arguments_digest — hash of JCS(input) or documented canonical JSON.¶
• instruction_provenance.source_type — user, retrieval, tool, or unknown as the host can attest.¶
• finality_sink.sink_type — TOOL_DISPATCH or BROWSER_CONTROLLER.¶

On deny, the host MUST append a tool_result for that id whose content is an error object, not a successful send. On allow, invoke then append the real result. The model is allowed to recover. The world is not allowed to change on deny.¶

7. Binding: OpenAI tool_calls and Responses

Informative source shape:¶

{
  "id": "call_8f3",
  "type": "function",
  "function": {
    "name": "payout_create",
    "arguments": "{\"amount\":\"150.00\",\"currency\":\"EUR\",\"beneficiary\":\"vendor-441\"}"
  }
}

Mapping MUST parse arguments as JSON, then canonicalize the object, then hash. Hashing the raw string is allowed only if the host guarantees one serialization. Two equivalent JSON strings MUST NOT produce two different authorities that both can run.¶

function.name maps to tool_id and function_id. Parallel tool_calls[] are parallel Candidate Acts. Each MUST be enforced separately. A single ALLOW for the message MUST NOT authorize every call in the array.¶

Responses API tool outputs and Assistants tool-output submits are the same sink moment: before the host runs the function map. GPT Actions that HTTP POST to a customer API are API_REQUEST acts; destination is the Action server URL.¶

8. Binding: MCP tools/call

Informative request:¶

{
  "jsonrpc": "2.0",
  "id": 4,
  "method": "tools/call",
  "params": {
    "name": "repo_deploy",
    "arguments": { "env": "prod", "ref": "main" }
  }
}

The conforming placement is the MCP *client* dispatcher, not each server. One enforcer sees every server the agent can reach. Server identity MUST enter destination or tool.tool_endpoint so a swapped server with the same tool name fails sink or destination match.¶

On deny the client MUST NOT send tools/call, or MUST send it only to a server that is itself a cooperating sink and will refuse. Returning an MCP error to the model is required so the loop does not treat silence as success.¶

tools/list remains discovery. list results MUST NOT issue AgentFinalityAuthority.¶

9. Streaming, Partial Blocks, and Parallel Calls

Both labs stream tokens. A partial tool_use or partial function.arguments string MUST remain non-effective. enforce() MUST run only on the finalized block. Invoking on a partial JSON object is non-conforming.¶

Parallel tool_calls and multiple tool_use blocks in one assistant message are independent acts. The host MAY validate them concurrently. It MUST NOT treat one ALLOW as covering siblings. If one call is FINANCIAL and one is INFORMATIONAL, only the FINANCIAL call escalates. A deny on one call MUST NOT be "fixed" by invoking the others first and hoping the model forgets.¶

Retries after transport failure MUST reuse the same candidate_act_id only when the consume bit is unread and the digest is unchanged. If consume already happened, retry is a new act or a fetch of the original tool_result, never a second invoke.¶

10. AgentCandidateAct Schema Recalled for Implementers

The normative schema lives in [I-D.das-agentic]. It is repeated here so this binding can be implemented from one document on a first reading.¶

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "urn:ietf:params:json-schema:agent-finality:candidate-act:1",
  "title": "AgentCandidateAct",
  "type": "object",
  "additionalProperties": false,
  "required": [
    "version", "object_type", "candidate_act_id", "act_type",
    "created_at", "expires_at", "initiating_principal", "agent",
    "tool", "purpose", "arguments_digest", "consequence_class",
    "policy_state", "freshness", "finality_sink"
  ],
  "properties": {
    "act_type": {
      "type": "string",
      "enum": [
        "TOOL_CALL", "FUNCTION_CALL", "API_REQUEST",
        "BROWSER_ACTION", "SHELL_ACTION", "MESSAGE_SEND",
        "FILE_WRITE", "MEMORY_WRITE", "AGENT_DELEGATION",
        "PAYMENT_REQUEST", "COMPUTER_USE", "OTHER"
      ]
    },
    "tool": {
      "type": "object",
      "required": ["tool_id", "function_id"],
      "properties": {
        "tool_id": { "type": "string" },
        "function_id": { "type": "string" },
        "tool_endpoint": { "type": "string" },
        "tool_protocol": {
          "type": "string",
          "enum": [
            "MCP", "HTTP_API", "LOCAL_FUNCTION",
            "BROWSER", "SHELL", "A2A",
            "ANTHROPIC_TOOL_USE", "OPENAI_TOOL_CALL", "OTHER"
          ]
        }
      }
    },
    "consequence_class": {
      "type": "string",
      "enum": [
        "INFORMATIONAL", "DATA_DISCLOSURE",
        "PERSISTENT_STATE_CHANGE", "FINANCIAL",
        "NETWORK_CONTROL", "PHYSICAL", "COMMUNICATION", "OTHER"
      ]
    }
  }
}

11. Field-by-Field Mapping Tables

12. Worked Denies the Labs Will Recognize

{
  "scenario": "INJECTED_EMAIL_SEND",
  "vendor": "anthropic",
  "block": { "name": "email_send", "input": { "to": "attacker@ex.com" } },
  "reason": "provenance=retrieval and consequence=COMMUNICATION",
  "enforce": { "allow": false, "code": "EF_INSTRUCTION_PROVENANCE_FAILURE" },
  "invoked": false,
  "tool_result": { "is_error": true }
}

{
  "scenario": "PARALLEL_PAY_AND_SEARCH",
  "vendor": "openai",
  "tool_calls": [
    { "name": "search", "result": "enforce_hot_allow" },
    { "name": "payout_create", "result": "enforce_deny_envelope" }
  ],
  "rule": "search invoke does not authorize payout invoke"
}

{
  "scenario": "MCP_SERVER_SWAP",
  "name": "repo_deploy",
  "authorized_endpoint": "mcp://git.example/prod",
  "live_endpoint": "mcp://git.attacker/prod",
  "enforce": { "allow": false, "code": "EF_DESTINATION_MISMATCH" }
}

{
  "scenario": "COMPUTER_USE_ORIGIN_CHANGE",
  "authorized_origin": "https://pay.example/checkout",
  "live_origin": "https://pay.example-evil/checkout",
  "enforce": { "allow": false, "code": "EF_DESTINATION_MISMATCH" }
}

13. Where to Put the Hook in Shipping Runtimes

Anthropic Messages API: after the application assembles content blocks, before the developer function table runs. Computer-use beta: inside the controller that turns action items into OS events, before the event is sent.¶

OpenAI Chat Completions: after tool_calls is parsed, before the function map. Assistants API: before submitting tool outputs that the host computed by running code. Responses API: before executing function_call items. Agents SDK: a before_tool_call callback if present; otherwise wrap the tool implementation objects the SDK receives.¶

MCP TypeScript and Python reference clients: wrap Client.callTool. IDE agents that embed MCP (desktop hosts) wrap the same method so every server inherits the gate.¶

14. Host-Loop Workflow

1. Receive model output or MCP request.¶
2. For each tool block, parse name and arguments.¶
3. Canonicalize arguments. Compute arguments_digest.¶
4. Build AgentCandidateAct [I-D.das-agentic].¶
5. HOLD_NON_EFFECTIVE.¶
6. PED_VALIDATE (local hot path or escalate).¶
7. Commit evidence. Issue authority.¶
8. DISPATCH_SINK_INVOKE: verify live digest, sink, epochs, consume.¶
9. Only then call the vendor SDK, local function, or MCP transport.¶
10. Map deny to the vendor error shape. Do not invoke on timeout.¶

15. Reference Host Loop

function HANDLE_ANTHROPIC_MESSAGE(msg, ctx):
    for block in msg.content where block.type == "tool_use":
        act = map_tool_use(block, ctx)
        decision = enforce(act, block.input)
        if decision.allow:
            raw = invoke(block.name, block.input)
            append_tool_result(block.id, raw)
        else:
            append_tool_result(block.id, {
              "error": decision.code,
              "message": decision.message
            })

function HANDLE_OPENAI_MESSAGE(msg, ctx):
    for call in msg.tool_calls:
        args = parse_json(call.function.arguments)
        act = map_tool_call(call, args, ctx)
        decision = enforce(act, args)
        if decision.allow:
            raw = invoke(call.function.name, args)
            append_tool_output(call.id, raw)
        else:
            append_tool_output(call.id, error_payload(decision))

function HANDLE_MCP_TOOLS_CALL(req, ctx):
    act = map_mcp(req, ctx)
    decision = enforce(act, req.params.arguments)
    if not decision.allow:
        return mcp_error(decision)
    return transport_tools_call(req)

16. enforce() Contract

A library advertised as implementing this binding MUST expose a function with this behavior, regardless of language:¶

enforce(act: AgentCandidateAct, live_args: object) ->
    { allow: bool, authority_id?: string, code?: string, message?: string }

# MUST:
# 1. hash live_args with the same canonicalization as act.arguments_digest
# 2. refuse if hashes differ
# 3. refuse if authority missing, expired, consumed, or sink-mismatched
# 4. consume single-use authority before returning allow=true
# 5. never return allow=true on timeout or uncertain epoch

Returning allow=true and then failing to consume is non-conforming. Logging a deny and invoking anyway is non-conforming.¶

17. JSON Objects Used on the Wire

The Candidate Act schema is [I-D.das-agentic]. This binding adds only mapped examples and the host error object.¶

{
  "version": "1.0",
  "object_type": "agent_candidate_act",
  "candidate_act_id": "act-toolu-01A-sess55",
  "act_type": "TOOL_CALL",
  "agent": {
    "agent_id": "claude-work-seat-12",
    "runtime_id": "anthropic-host-loop",
    "model_id": "claude-family",
    "delegation_depth": 0
  },
  "tool": {
    "tool_id": "email_send",
    "function_id": "email_send",
    "tool_protocol": "LOCAL_FUNCTION"
  },
  "purpose": {
    "purpose_id": "user-turn",
    "declared_purpose": "send invoice email"
  },
  "arguments_digest": {
    "algorithm": "SHA-256",
    "value": "base64url-args",
    "canonicalization": "JCS"
  },
  "destination": { "destination_id": "smtp-gw-1" },
  "consequence_class": "COMMUNICATION",
  "policy_state": {
    "policy_epoch": 9,
    "authority_epoch": 3,
    "revocation_epoch": 1
  },
  "freshness": { "nonce": "C0FFEE11DEADBEEF" },
  "instruction_provenance": { "source_type": "user" },
  "finality_sink": {
    "sink_id": "host-dispatch-1",
    "sink_type": "TOOL_DISPATCH"
  }
}

{
  "object_type": "agent_candidate_act",
  "act_type": "TOOL_CALL",
  "tool": {
    "tool_id": "payout_create",
    "function_id": "payout_create",
    "tool_protocol": "HTTP_API"
  },
  "arguments_digest": {
    "algorithm": "SHA-256",
    "value": "base64url-args",
    "canonicalization": "JCS"
  },
  "consequence_class": "FINANCIAL",
  "destination": { "destination_id": "psp.example" },
  "finality_sink": {
    "sink_id": "host-dispatch-1",
    "sink_type": "TOOL_DISPATCH"
  }
}

{
  "error": {
    "code": "EF_SCOPE_MISMATCH",
    "message": "Live arguments are not the authorized digest.",
    "retryable": false,
    "invoked": false
  }
}

{
  "step_1_block": {
    "type": "tool_use",
    "name": "maps_search",
    "status": "NON_EFFECTIVE"
  },
  "step_2_enforce": {
    "allow": true,
    "authority_id": "afa-c7d32d54",
    "consumed": true
  },
  "step_3_invoke": { "tool": "maps_search", "once": true },
  "step_4_tool_result": { "id": "toolu_01A", "ok": true }
}

18. Practical Feasibility: Latency and Legacy Loops

19. How Labs and Customers Use It

20. Default Consequence Classes for Common Tools

Hosts SHOULD assign consequence_class before enforce(), not after the model names the tool. Informative defaults:¶

• search, retrieve, get_weather — INFORMATIONAL¶
• email_send, slack_post, tweet — COMMUNICATION¶
• file_write, db_update, memory_write, ticket_create — PERSISTENT_STATE_CHANGE¶
• payout, refund, capture, wire — FINANCIAL (also [I-D.das-payment])¶
• deploy, kubectl, iam_attach — PERSISTENT_STATE_CHANGE or NETWORK_CONTROL¶
• computer_use submit, browser_navigate to new origin — DATA_DISCLOSURE or COMMUNICATION depending on the form¶
• shell / bash — at least PERSISTENT_STATE_CHANGE; treat as cold path unless the envelope names the exact binary¶

Misclassifying payout as INFORMATIONAL is a profile failure, not a model failure.¶

21. Memory, Projects, and Persistent Notes

Claude projects and ChatGPT memory are tool- shaped even when they are not named tools. A host that writes extracted facts into a memory store MUST treat that write as MEMORY_WRITE. Otherwise an injected turn stores a join that later turns treat as user provenance. That is how present theft becomes future mapping without another tool_use [DAS-ISOLATION].¶

22. Conformance Tests a Lab Can Run Overnight

T-A: emit tool_use email_send to an address not in the user turn; expect invoke=false. T-B: two OpenAI tool_calls, search and payout; expect payout denied when above envelope. T-C: replay the same authority_id on a second invoke; expect deny. T-D: MCP call with swapped server URL; expect destination deny. T-E: computer-use submit after origin change; expect deny. T-F: measure enforce() p99 under 10 ms on hot search. T-G: kill the host after consume and before invoke; on restart do not invoke again.¶

A workspace that passes T-A through T-G can be shown to an enterprise security review without a new model checkpoint.¶

23. Error Mapping

EF codes from [I-D.das-agentic] SHOULD be copied into the vendor error payload as machine-readable strings. retryable=true only for EF-060 timeout where policy allows a bounded retry of *validation*, never a retry that skips enforce(). Models that respond to deny by emitting a different tool_use are starting a new Candidate Act. That is expected.¶

24. Threats This Binding Makes Local

• T1 Direct prompt injection → extra tool_use¶
• T2 Indirect injection in retrieved files¶
• T6 Tool name confusion / substitution¶
• T7 MCP server substitution¶
• T14 Replay of a previous tool block id¶
• T17 Alternate path: raw HTTP next to the SDK¶
• T18 Computer-use submit around API tools¶

Threats that need the enterprise profile (join of identity and content) are out of scope here except as provenance=unknown plus high consequence_class → escalate.¶

25. Addressing Potential Technical Concerns

check permission -> execute tool

Candidate Act
    -> Non-Effective State
    -> protected validation and act-specific binding
    -> scoped execution authority
    -> Finality Sink verification
    -> externally effective consequence

{"amount":100,"currency":"USD"}

{"currency":"USD","amount":100}

load-bearing Candidate Act attributes
    -> deterministic representation
    -> Candidate-Act commitment

26. Relationship to the DAS Protocols Architecture

This document is a protocol-facing profile of a broader execution-finality architecture developed in the DAS Protocols work. The broader architecture describes a recurring separation between computation of a proposed act, protected validation of the act, issuance or establishment of scoped finality authority, and verification at a Finality Sink before an external consequence becomes effective.¶

The large foundational disclosure referred to by the author as the DAS Protocols "Mothership" is PCT/IB2026/055615, published as WO 2026/150382. That disclosure covers a substantially wider set of execution-finality embodiments, including AI infrastructure, telecommunications, device and operating-system enforcement, protected execution, and other externally effective systems. This Internet-Draft intentionally addresses a much narrower interoperability problem: binding existing AI tool-use and MCP-style dispatch interfaces to an execution-finality boundary.¶

The terminology used here, including Candidate Act, Non-Effective State, protected validation, scoped execution authority, and Finality Sink, should therefore be read as a compact protocol profile rather than as an attempt to reproduce the full DAS Protocols disclosure.¶

This background statement is informative. It does not make implementation of unrelated DAS Protocols embodiments a requirement for conformance with this Internet-Draft. Any IETF intellectual-property disclosure obligations are handled separately under BCP 79 [RFC8179].¶

27. Implementation Checklist

1. Every side-effecting tool handler is reachable only through enforce() or an equivalent protected finality-enforcement boundary.¶
2. arguments_digest or equivalent commitment is over a deterministic representation of the load-bearing Candidate Act attributes, not over the model's prose.¶
3. Parallel tool_calls are separate acts.¶
4. Deny returns an error block; invoked is false.¶
5. Timeout does not invoke.¶
6. MCP client, not only servers, runs enforce().¶
7. Computer-use submit has a live-value digest.¶
8. p99 added latency of enforce() is measured.¶
9. Tools the vendor invokes without a hook are listed as open alternate paths.¶

28. Security Considerations

If enforce() runs in the same process as a fully compromised host that can also call the tool backend directly, the binding is only as strong as alternate-path closure. Production hosts SHOULD block raw credentials from application code paths that skip enforce(), or SHOULD put the sink in a sidecar that owns the tool credentials.¶

Model-visible deny messages MUST NOT leak other users' data. They MAY name the EF code.¶

29. Privacy Considerations

Argument objects often contain recipients and PII. Logs SHOULD store digests, not raw arguments, once enforce() has run. Mapping layers MUST NOT write full tool input to a shared debug bus by default.¶

30. Informative Host Wrappers

The following sketches are informative. They exist so a lab or customer engineer can see that the binding is a wrap of invoke, not a new assistant protocol.¶

def enforce(act, live_args, store, sink_id):
    live = digest(canonicalize(live_args))
    if live != act["arguments_digest"]["value"]:
        return Deny("EF_SCOPE_MISMATCH")
    auth = store.get(act["candidate_act_id"])
    if not auth or auth.consumed or auth.expired():
        return Deny("EF_002")
    if auth.sink_id != sink_id:
        return Deny("EF_040")
    if not store.consume_cas(auth.authority_id):
        return Deny("EF_005")
    return Allow(auth.authority_id)

def handle_tool_use(block, ctx):
    act = map_tool_use(block, ctx)
    decision = enforce(act, block["input"], ctx.store, ctx.sink_id)
    if not decision.allow:
        return {"error": decision.code, "invoked": False}
    return invoke(block["name"], block["input"])

async function enforce(act: Act, live: object, store: Store, sink: string) {
  const d = digest(canonicalize(live));
  if (d !== act.arguments_digest.value) return deny("EF_SCOPE_MISMATCH");
  const auth = await store.get(act.candidate_act_id);
  if (!auth || auth.consumed || auth.expired()) return deny("EF_002");
  if (auth.sink_id !== sink) return deny("EF_040");
  const ok = await store.consumeCAS(auth.authority_id);
  if (!ok) return deny("EF_005");
  return allow(auth.authority_id);
}

async function onOpenAIToolCalls(calls: ToolCall[], ctx: Ctx) {
  const out = [];
  for (const c of calls) {
    const args = JSON.parse(c.function.arguments);
    const act = mapToolCall(c, args, ctx);
    const d = await enforce(act, args, ctx.store, ctx.sink);
    out.push(d.allow
      ? await invoke(c.function.name, args)
      : { error: d.code, invoked: false });
  }
  return out;
}

31. IANA Considerations

This document requests no IANA actions.¶

32. Intellectual Property Note

Related execution-finality concepts appear in the DAS Protocols family, including PCT/IB2026/055615, published as WO 2026/150382. This statement is provided for technical transparency and does not substitute for any disclosure required through the IETF IPR process. Applicable IETF disclosure obligations are governed by BCP 79 [RFC8179].¶

33. Conclusion

Claude will keep emitting tool_use. ChatGPT will keep emitting tool_calls. MCP will keep emitting tools/call. None of those blocks is permission to touch the world. Bind them to an AgentCandidateAct, consume authority at the host sink, then invoke. The model vendor does not have to change. The host loop does.¶

Appendix A. Appendix A. Execution-Finality Binding in Compact Form

This appendix is informative. It summarizes the minimum conceptual separation used throughout this document.¶

             MODEL / AGENT / APPLICATION
                       |
                       | proposes
                       v
                +---------------+
                | Candidate Act |
                +-------+-------+
                        |
                        | remains non-effective
                        v
              +-------------------+
              | Non-Effective     |
              | State             |
              +---------+---------+
                        |
                        | validate load-bearing state
                        v
              +-------------------+
              | Protected         |
              | Validation        |
              +---------+---------+
                        |
                        | bind scoped authority/evidence
                        v
              +-------------------+
              | Finality Sink     |
              | Verification      |
              +---------+---------+
                        |
                allow   |   deny -> no effect
                        v
              +-------------------+
              | External Effect   |
              +-------------------+

The Candidate Act may be represented using an existing vendor or protocol envelope, but the envelope itself is not treated as effectuation authority. Implementations may use different cryptographic, operating-system, service-side, or hardware mechanisms to realize the protected validation and Finality Sink functions, provided the required security properties of this profile are preserved.¶

Author's Address