Network Working Group K. McGuinness Internet-Draft Independent Intended status: Experimental 4 October 2026 Expires: 7 April 2027 Mission Consumption Metering draft-mcguinness-mission-metering-latest Abstract Mission-Bound Authorization for OAuth 2.0 bounds an agent's authority by resources, actions, and constraints, and its runtime enforcement profile evaluates each consequential action at the point of use. Neither bounds how much of an approved authority a Mission may consume. This document defines an experimental consumption-metering extension: four cumulative consumption bounds a Mission Intent may carry (max_budget, max_calls, max_duration, and max_egress_volume), an exclusivity control (exclusive, separation of duty), the runtime metering semantics that enforce them (atomic check-and-decrement, reserve and commit postures, duration leases, and settlement), and the AuthZEN wire representation for lease renewal and settlement. A consumption bound is consented at approval and enforced only by a runtime deployment that implements this profile; a deployment that does not meter a bound must refuse rather than silently ignore it. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://mcguinness.github.io/mission-bound-authorization/draft- mcguinness-mission-metering.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- mcguinness-mission-metering/. Source for this draft and an issue tracker can be found at https://github.com/mcguinness/mission-bound-authorization. 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 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. 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 2. Promotion Criteria 3. Relationship to the Issuance and Runtime Profiles 4. Conventions and Terminology 5. Mission Substrate 6. Consumption Bounds 6.1. Consent Integrity 7. Consumption Metering 7.1. Exactness and Topology 7.2. Retry, Idempotency, and Reserve/Commit Posture 8. Exclusivity and Separation of Duty 8.1. Exclusivity Across Missions 9. Capacity Across Missions 10. Aggregate Bounds 11. Metering Evidence 12. AuthZEN Wire Representation 12.1. Settlement Exchange 12.1.1. Settlement Submission Contract 12.1.2. Settlement by Evidence State 12.1.3. Duration-Lease Renewal 13. Conformance 14. Security Considerations 15. Privacy Considerations 16. IANA Considerations 17. References 17.1. Normative References 17.2. Informative References Appendix A. Document History Acknowledgments Author's Address 1. Introduction Mission-Bound Authorization for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission] (the "issuance profile") bounds what an agent may do; the runtime enforcement profile ([I-D.draft-mcguinness-mission-runtime]) enforces each consequential action at the point of use. A long-running agentic task also needs bounds on how much: cumulative spend, call volume, and wall-clock activity. Those are not per-action constraints; they are counters that deplete across the life of the Mission, and enforcing them is a metering problem with reserve, commit, retry, and distributed- consistency concerns of its own. This document defines that metering layer: * the consumption-bounds vocabulary a Mission Intent carries, * the metering semantics a runtime deployment enforces, and * the AuthZEN wire representation ([I-D.draft-mcguinness-mission-authzen]) for settlement and duration-lease renewal. This document is optional and experimental: adopt it for evaluation, not as a stable interface. Metering cumulative bounds exactly under distributed decision points is a distributed-counting problem, and the reserve, commit, lease, and settlement machinery here is expected to evolve with implementation experience. A deployment that does not implement this document carries no consumption bounds on its Missions and is fully conformant to the issuance and runtime profiles. The derivation limits profile's derivation_limit is not a consumption bound: it is enforced by the issuing Authorization Server at each derivation and needs none of this document ([I-D.draft-mcguinness-oauth-mission-derivation-limits]). The consent-integrity rule of Section 6.1 is the boundary that makes this safe to omit: a bound is rendered to an Approver only where it is actually metered. 2. Promotion Criteria This section is informative. Promotion moves this accounting model from optional evaluation toward the architectural baseline for any Mission carrying a consumption bound, so the bar is exercised machinery, not elapsed time. Meeting these criteria supplies implementation and deployment evidence for a deliberate decision, through the applicable IETF process, about changing this document's intended status or moving selected mechanisms into a Standards Track profile; it does not itself change either status, and no criterion, met or unmet, changes anything automatically. A catalog or inventory maturity label is distinct from an IETF stream decision and follows one rather than substituting for one. Implementation listings and test reports belong in an Implementation Status section per [RFC7942], removed before RFC publication; this section states the durable criteria. Promotion is gated per feature by the applicable rows: +===============================+===================+ | Gate | Applies to | +===============================+===================+ | Retry, atomicity, settlement, | Every consumption | | and crash recovery | bound | +-------------------------------+-------------------+ | Exact or qualified topology | Every claimed | | behavior | topology profile | +-------------------------------+-------------------+ | Currency and debit/refund | max_budget | | behavior | | +-------------------------------+-------------------+ | Call classification and | max_calls | | counting point | | +-------------------------------+-------------------+ | Measurement, renewal, skew, | max_duration | | and stop behavior | | +-------------------------------+-------------------+ | Payload dereference and | max_egress_volume | | message accounting | | +-------------------------------+-------------------+ | Cross-Mission counter | Aggregate bounds | | consistency | | +-------------------------------+-------------------+ | Atomic latch and release | exclusive | +-------------------------------+-------------------+ | Independent interoperation | Each promoted | | | wire profile | +-------------------------------+-------------------+ Table 1: Promotion gates Each gate passes on named evidence: *Retry, atomicity, settlement, and crash recovery.* For each promoted bound class, a reproducible test suite with no skipped cases demonstrates exactly-once accounting under Section 7.2 and Section 12.1: a retry under the same idempotency key or decision identifier consumes once; a redelivered settlement neither double- commits nor double-releases; a conflicting redelivery fails closed; a crash between reserve and commit resumes to a consistent balance; and every evidence state of Section 12.1.2 is exercised. This is the decrement-side counterpart of the exactly-once reservation machinery the family's Mission-creating surfaces carry for creation. *Exact or qualified topology behavior.* Each claimed enforcement profile of Section 7.1 is demonstrated against its own guarantee: the Exact profile never over-consumes under concurrent near-exhaustion attempts; the Bounded-consistency profile stays within its published overshoot and staleness bound and reconciles orphaned reservations on the published cadence, including a non-idempotent reservation held until affirmative evidence of non-execution. Only Exact-profile evidence qualifies a bound for promotion as a baseline hard cap; Bounded-consistency evidence qualifies only the qualified form, the cap together with its published bound, rendered per Section 6.1. Artifacts: the Enforcement Scope Statement naming the profile per counter, and the reconciliation record. *Currency and debit/refund behavior* (max_budget). Exact decimal arithmetic with no floating-point accumulation; refusal on a currency the counter does not carry, or the deployment's documented conversion rule; debit, refund, and release paths returning exact amounts. *Call classification and counting point* (max_calls). The call_class mapping of Section 6 exercised across implementations, the same consequential action counted against the same class, and the counting point proven: the count consumed at decision, the disposition confirmed at settlement (Section 12.1.1). *Measurement, renewal, skew, and stop behavior* (max_duration). The duration rules of Section 7 exercised: bounded reservation or lease for an unknown duration, renewal through context.prior_evaluation_id ahead of expiry by the skew margin, stop-or-new-permit before exhaustion, the in-flight handling of an action that cannot be safely stopped, and measured_duration commit with release of the unused reservation. *Payload dereference and message accounting* (max_egress_volume). The Operation Profile measurement exercised for both bytes and messages, including a reference-typed parameter measured by its dereferenced payload or its action class excluded from a claimed bytes bound (Section 7). *Cross-Mission counter consistency* (aggregate bounds, Section 10). A lineage-keyed budget identifier and its authoritative shared counter metering a root Mission and its Child Missions in the counter's own consistency domain: a lineage-wide quota_exceeded refusal from Child Mission consumption, a Child Mission's released reservation returned to the shared counter, and no consent surface or Enforcement Scope Statement rendering an aggregate bound the deployed counter does not back. Artifacts: the refusal's Decision Evidence carrying a metering entry (Section 11) whose requested, remaining, counter_scope, and counter_id prove the accounting invariant rather than only the asserted refusal. *Atomic latch and release* (exclusive). Concurrent consequential actions matching different selectors of one group latch exactly one selector, atomically with the permit; the affirmative-non-execution release restores the group; refusals carry exclusivity_latched in Decision Evidence; the latch domain is named in the Enforcement Scope Statement (Section 8). exclusive is, and remains, a Mission Intent member this document defines and owns (Section 6); an earlier plan to adopt it into the issuance profile's controls vocabulary lapsed when that vocabulary was retired (a family migration that relocated every member below out of controls without changing this document's ownership of any of them, [I-D.draft-mcguinness-oauth-mission]). This gate, met or not, therefore changes only whether exclusive keeps its EXPERIMENTAL marking here, never where it is defined. A 2026-08 promotion assessment against this and the independent-interoperation gate below found every applicable row NOT MET (issue #117): no reference implementation of the latch domain, the settlement-intake path, or an independently interoperating counterpart exists, so exclusive stays EXPERIMENTAL and unpromoted. *Independent interoperation.* Two distinct results, both required for each promoted wire profile, aligning with the implementation and interoperation reporting convention of [RFC7942]: * Operational experience: at least one deployment not operated by the implementer. * Interoperability: an independently implemented PEP and PDP exchange the profiled messages, including duplicate delivery and failure cases, under the settlement submission contract (Section 12.1.1). Across every gate, promotion additionally requires the promoted wire surface unchanged in name, shape, and semantics across two consecutive published revisions of this document while the evidence accumulated: the Mission Intent members of Section 6, quota_exceeded, exclusivity_latched, context.prior_evaluation_id, measured_duration, the metering evidence member (Section 11), and the settlement submission contract of Section 12.1.1. The #636 controls-retirement cut relocated every member of Section 6 from controls. to a flat top-level Mission Intent member: that is a wire-shape change to this exact surface, so the two-consecutive-revisions window restarts at this revision (zero of two), regardless of how long the pre- relocation shape had otherwise held. Selective promotion means the applicable rows: promoting a per- Mission bound class does not require the aggregate or exclusive gates, and promoting the exclusive control does not require the bound-class gates; every promotion includes the rows that apply to each consumption bound it covers, its claimed topology profiles, and its wire profile. The criteria are sized to be satisfiable by a reference implementation, one deployment not operated by its implementer, and one independently implemented counterpart component; they demand exercised machinery and stable surfaces, not adoption counts. 3. Relationship to the Issuance and Runtime Profiles This document depends normatively on the issuance profile and the runtime profile and is not implementable alone. It defines its consumption bounds as named top-level Mission Intent members, using the extension seam the issuance profile provides for a companion profile to add explicit, named members; they are carried on the Mission and committed by intent_hash exactly as any other Intent member. Metering is performed by the runtime profile's PDP within a documented enforcement scope; this document adds metering semantics to the runtime profile's decision contract and changes no issuance protocol, though it does add consent-surface obligations on the Mission Issuer (Section 6.1) and a child-creation rule (Section 9). 4. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Consumption bound: A cumulative bound on Mission activity that depletes as the Mission is used, as distinct from a per-action constraint that is evaluated independently on each action. 5. Mission Substrate This profile is defined against the Mission model rather than against OAuth 2.0 mechanics: it is a substrate-neutral consumer, and this section is its consumption declaration under the rule of Mission Substrate Requirements ([I-D.draft-mcguinness-mission-substrate]) that a substrate-neutral profile declare the kernel functions and optional capabilities it consumes. From the contextual-governance kernel it consumes the Mission Identifier and issuer, the kernel's Mission Reference and Controller, which key every consumption counter; and the immutable Approved Context, of which the bounds are part as named Mission Intent members. The kernel requires no particular integrity anchors: intent_hash is the OAuth binding's commitment to that approved value, and it commits the bounds like any other Intent member (Section 3). It consumes these optional capabilities: +=============+===========+=================================================+ |Capability |Consumption|Scope of consumption | +=============+===========+=================================================+ |Lifecycle- |required |Inherited scope: metering is performed by the | |Gated | |runtime profile's PDP within a documented | |Authorization| |enforcement scope (Section 3), so every metered | | | |decision is already gated on the only-active- | | | |permits rule; this document adds counters to that| | | |gate and defines no second one | +-------------+-----------+-------------------------------------------------+ |Structured |required |Two consumers. A call_class value SHOULD be | |Authority |when a call|drawn from the actions identifiers of the entry's| | |class or an|mission_resource_access, so the metered class | | |exclusive |maps to evaluated actions; a deployment that | | |selector is|meters a coarser or cross-entry class defines | | |drawn from |that class's membership, and such a class is not | | |the |interoperable (Section 6). The exclusive control| | |Authority |consumes it even then: its selectors are | | |Set's |interpreted in the identifier space of the | | |identifiers|approved Authority Set entries and compared with | | | |each consequential action, resource by equality | | | |and the invoked action by membership in actions, | | | |per group and per Mission; selector semantics are| | | |owned by this document (Section 6, Section 8) | +-------------+-----------+-------------------------------------------------+ |State- |not |Mission state is established by the runtime | |Observable |consumed |decision this document adds counters to, under | | | |that profile's freshness rules, not by this | | | |document ([I-D.draft-mcguinness-mission-runtime])| +-------------+-----------+-------------------------------------------------+ |Monotonic |not |Ancestor charging and escrowed allocations | |Derivation |consumed |(Section 9) and lineage-keyed counters | | | |(Section 10) read a Mission's lineage to choose | | | |its counters; they compare remaining capacity, | | | |not authority, and add nothing to the no-broader-| | | |than comparison | +-------------+-----------+-------------------------------------------------+ |Credential- |not |This document defines no binding of its own: | |Bound |consumed |enforcement composes through the runtime | | | |profile's Mission binding establishment step | | | |([I-D.draft-mcguinness-mission-runtime]) | +-------------+-----------+-------------------------------------------------+ |Independently|not |This document defines no verification artifact of| |Verifiable |consumed |its own; metered outcomes enter the runtime | | | |evidence records and inherit their verification | | | |([I-D.draft-mcguinness-mission-runtime-evidence])| +-------------+-----------+-------------------------------------------------+ |Portable |not |This document defines no evidence artifact of its| |Evidence |consumed |own; metered refusals and settlement are carried | | | |in the runtime evidence records through the | | | |coordinated metering member (Section 11, | | | |[I-D.draft-mcguinness-mission-runtime-evidence]) | +-------------+-----------+-------------------------------------------------+ Table 2: Metering profile capability consumption The portability claim is capability-scoped rather than substrate-wide for the reason the substrate's Capability Confusion consideration states: every property this profile requires matches an explicit capability claim and its scope, never the generic statement that a binding supports Missions. Hosting under another binding also requires a representation mapping: the bounds carried inside the binding's own Approved Context and covered by its own commitment mechanism, as the OAuth binding carries them in the Mission Intent and commits them through intent_hash. 6. Consumption Bounds This document defines these Mission Intent top-level members ([I-D.draft-mcguinness-oauth-mission]), under that document's rule that a companion profile may add a named member coordinated with it: max_budget: OPTIONAL. An object. A hard cap on cumulative monetary spend under the Mission. It carries the same {amount, currency} shape as the max_amount Common Constraint the issuance profile seeds, so the per-action cap and this cumulative cap read alike. Has the members: amount: REQUIRED. A string. A decimal number. currency: REQUIRED. A string. An ISO 4217 currency code. max_calls: OPTIONAL. An array of objects. Hard caps on the count of consequential call events. Each object has the members: call_class: REQUIRED. A string. The named call class to meter. A call_class value SHOULD be drawn from the actions identifiers of the entry's mission_resource_access ([I-D.draft-mcguinness-oauth-mission]), so the metered class maps to evaluated actions; a deployment that meters a coarser or cross-entry class defines that class's membership, and such a class is deployment-defined and not interoperable, like a deployment-defined constraint. (Named call_class rather than scope to avoid collision with the OAuth scope parameter and claim.) count: REQUIRED. An integer. 1 or greater. max_duration: OPTIONAL. A string. An ISO 8601 duration (for example, PT8H), matching the duration rule in Appendix A of [RFC3339], bounding cumulative wall-clock consequential activity under the Mission. It is distinct from the Mission's expires_at, which bounds issuance rather than activity. max_egress_volume: OPTIONAL. An object with one or both members bytes and messages, each an integer, 1 or greater: hard caps on cumulative egress under the Mission across consequential external- communication and external-commitment actions ([I-D.draft-mcguinness-mission-runtime]), as the total size in bytes of those actions' bound payload parameters and the count of such actions. It bounds the volume of within-scope laundering; it does not detect it. exclusive: OPTIONAL and EXPERIMENTAL (unlike the four bounds above, this member is not yet promotion-ready: a 2026-08 assessment against Section 2 found every applicable gate NOT MET, issue #117). An array of exclusivity groups, each an array of two or more selectors. A selector is an object with resource (REQUIRED, a string) and actions (OPTIONAL, an array of strings); it matches a consequential action whose resource equals resource and, when actions is present, whose invoked action is within it. Within a group, the selectors name authority the Approver consents MUST NOT be combined under this Mission or any Mission derived from it, absent an explicitly approved relaxation (Section 8). The bounds are carried on the Mission and committed by intent_hash. They are not enforced by the Authorization Server at issuance; they are enforced by the runtime layer at the point of use (Section 7). The one issuance-time step is the child-creation rule of Section 9. Example Mission Intent carrying three of the four bounds alongside the issuance profile's members: { "goal": "Reconcile Q3 invoices and post adjustments under $500.", "target_resources": ["https://erp.example.com"], "expires_at": "2026-12-31T23:59:59Z", "max_budget": { "amount": "5000.00", "currency": "USD" }, "max_calls": [ { "call_class": "journal-entries.write", "count": 50 } ], "max_duration": "PT8H" } 6.1. Consent Integrity A consumption bound is part of what the Approver consents to. Where a deployment records Consent Evidence ([I-D.draft-mcguinness-oauth-mission-consent-evidence]), the rendered authority summary MUST include the consumption bounds the Mission carries. A deployment MUST NOT render a consumption bound to the Approver as enforced unless the bound is within a runtime enforcement scope that meters it under this document. A Mission Issuer whose deployment does not meter a bound MUST refuse an Intent that carries it at intake. Such an Issuer MUST NOT render the bound as an enforced limit. A deployment that accepts the bounds into the Intent but does not meter them presents an unenforced promise at the consent surface. Under a multi-PDP topology (Section 7.1), a consented hard cap the deployment renders as enforced MUST either: * be enforced under the Exact enforcement profile, for example as per-PDP sub-budgets that sum to the cap; or * be rendered with the named qualifier of the Bounded-consistency enforcement profile the counter operates under (Section 7.1). Either way the Approver consents to the guarantee the deployment can meet rather than to a hard number it cannot. 7. Consumption Metering Consumption bounds are enforced by the runtime profile's PDP ([I-D.draft-mcguinness-mission-runtime]), not at issuance: * max_budget: the PDP performs an atomic reserve-or-charge against the remaining balance for each consequential action and MUST refuse when the remaining balance is insufficient. * max_calls: the PDP increments an atomic counter for the named call_class and MUST refuse a call past count. * max_egress_volume: the PDP adds the action's bound payload size and increments the action count atomically with the permit and MUST refuse an action that would exceed either cap. Payload size is measured over the parameter bytes committed by parameter_digest ([I-D.draft-mcguinness-mission-runtime]); the Operation Profile defines the measurement so PDPs accumulate consistently. For a reference-typed parameter, one that carries an attachment identifier or URL whose referent egresses while the pointer is what parameter_digest commits, the Operation Profile MUST measure the dereferenced payload size, or the deployment MUST exclude such actions from a claimed bytes bound. Counting the pointer bytes alone understates the egress. * max_duration: the PDP accumulates the duration of consequential activity it reserves, commits, or permits, under these rules: 1. The PDP MUST refuse once the accumulated total would exceed the bound. 2. The PDP MUST accumulate max_duration as the sum of per-action measured durations, not the union of activity intervals, so concurrent actions each count against the bound. 3. For an action whose duration is not known before execution, the PDP MUST either reserve a bounded maximum duration or issue a duration lease that expires unless renewed. 4. The PEP MUST stop the action or obtain a new permit before the reservation or lease is exhausted. 5. Lease boundaries MUST carry a clock-skew margin: the PEP renews or stops ahead of expiry by at least the deployment's skew bound, so a renewal in flight does not race the expiry it extends. 6. For an action that cannot be safely stopped mid-execution, lease exhaustion is handled as an in-flight outcome under the orchestration profile's dispatched_not_committed or unknown classes ([I-D.draft-mcguinness-mission-orchestration]), not by severing the action. 7. After execution, the PEP MUST report the measured duration so the PDP can commit actual use and release any unused reservation. The Operation Profile defines how a single action's duration is measured so that PDPs accumulate consistently. A per-entry constraints value that expresses a cumulative consumption bound is metered the same way. When an applicable entry or the Mission Intent itself carries such a bound, the PDP MUST meter use against it. The PDP MUST refuse a consequential action that would exceed it. The runtime profile's fail-closed rule stands beneath all of this: an unmetered or unrecognized consumption bound MUST cause refusal rather than silent pass-through ([I-D.draft-mcguinness-mission-runtime]). 7.1. Exactness and Topology The exactness of a consumption bound depends on the decision topology, and this profile does not overpromise. A deployment enforces each counter under one of two named enforcement profiles: Exact enforcement profile: The check and decrement are atomic against the authoritative balance: a single serializing PDP for the counter, a shared linearizable counter, or per-PDP sub-budgets that are structurally exact because they sum to the cap. The bound never over-consumes; it is a hard cap. Bounded-consistency enforcement profile: Multiple or distributed PDPs (for example, Resource Server-hosted PDPs) share the counter without linearizable coordination, a distributed-counting problem. The deployment MUST publish, per bound class, the maximum overshoot and staleness it operates under (for example, a bounded reconciliation window), and the effective guarantee is the cap plus that published bound, not exact-to-the-call enforcement. The published qualifier is part of the bound's enforced semantic and is rendered per Section 6.1. A deployment MUST name the enforcement profile per counter in its Enforcement Scope Statement, and MUST NOT advertise exact consumption enforcement it cannot meet under its chosen topology. The consistency bound is part of the runtime enforcement scope the runtime profile requires a deployment to document ([I-D.draft-mcguinness-mission-runtime]). 7.2. Retry, Idempotency, and Reserve/Commit Posture For a metered permit, the PDP and PEP MUST define retry and idempotency behavior. * A retry of the same normalized action under the same idempotency key or single-use decision identifier MUST NOT consume the bound twice. * Reuse of an idempotency key or decision identifier for a different normalized action MUST cause refusal. * For irreversible actions and external commitments, a deployment MUST define whether metering is reserved before execution and committed after success, or committed before execution. * It MUST NOT leave the decrement ambiguous: a reservation settles on the evidence state (Section 12.1.2), never on a generic failure signal. * For a metered action in the runtime profile's high-consequence classes, the declared idempotency horizon ([I-D.draft-mcguinness-mission-runtime]) MUST extend at least to the Mission's expires_at, so a duplicate the Mission could still admit always resolves against the recorded key. The reserve/commit posture fixes when consumption is charged; the evidence state fixes how the charge settles. 8. Exclusivity and Separation of Duty The exclusive control (Section 6) is not a consumption bound: it is a stateful separation-of-duty rule enforced with the same machinery. Within an exclusivity group, the first permitted consequential action matching a selector latches the group to that selector, atomically with the permit. From then on the PDP MUST refuse a consequential action matching any other selector of the same group, under any Mission bound to the group, except an action within the scope of a relaxation recorded for that Mission (Section 8.1). The latch is per group, not per Mission, and is PDP-side operational state like a consumption counter (Section 7). The latch tracks execution, not permit issuance: a permit whose action is affirmatively not executed never combined the group's authority. The PDP releases the latch only when Execution Evidence, within the strongly consistent latch domain, reports affirmative non- execution for every permitted action that matched the latched selector under any Mission bound to the group. One action's non- execution never releases a group another action exercised, and an outstanding or indeterminate action keeps the latch. Absent that, the latch does not unlatch: narrowing by exercise is monotonic, like every other narrowing in the family. This settlement release is distinct from a relaxation (Section 8.1), which never unlatches the group. The latch is exempt from the Bounded-consistency enforcement profile of Section 7.1. A counter degrades gracefully under a per-PDP sub- budget or a reconciliation window; a separation-of-duty rule violated once is violated permanently, and two PDPs can latch the same group to opposite selectors within the window. Therefore: * An exclusivity group MUST be enforced under the Exact enforcement profile of Section 7.1, in a single strongly consistent latch domain that spans every Mission bound to the group. The runtime profile's Mission-sharding guidance does not partition it ([I-D.draft-mcguinness-mission-runtime]). * A group MUST NOT be divided into independently enforced allocations across Missions or PDPs, as a consumption bound may be: opposite branches never receive competing permits. * The Bounded-consistency enforcement profile MUST NOT be applied to exclusive. * The deployment MUST name the latch domain in its Enforcement Scope Statement. Exclusivity turns the quarantine deployment pattern ([I-D.draft-mcguinness-mission-architecture]) into consented, enforceable structure: an Approver can approve a Mission that may read a sensitive store or communicate externally, but never both without an explicitly approved relaxation (Section 8.1). The groups are consented at the approval event, committed by intent_hash with the other Mission Intent members this document defines, and rendered in the consent disclosure (Section 6.1 applies unchanged). In the AuthZEN profile, a refusal under a latched group is denied with exclusivity_latched, an extension of the runtime denial set under the AuthZEN profile's coordinated-extension conventions ([I-D.draft-mcguinness-mission-authzen]), and recorded as the denial_reason in Decision Evidence. A PDP that cannot establish a group's latch state fails closed for the actions the group covers, per the runtime profile's availability posture. 8.1. Exclusivity Across Missions An exclusivity group binds the delegation it is approved for, as a consumption bound does (Section 9), but it cannot be divided: a group is one restriction with one live latch state, never a set of independent copies. * *Shared binding.* A group has a stable identity, fixed by the Mission whose approval created it. Every Mission derived from a Mission bound to the group is bound to it as well: Child Missions and their descendants, Expansion successors, and Child Delegation carryover replacements. A derived Mission is bound to the group's authoritative latch state, not to a snapshot of it: two children created while the group is unlatched share it, so the first matching action under either latches one selector for both. A derived Mission whose authority matches only one selector is still bound. Renaming, reordering, splitting, or omitting a group in a derived Intent does not create a new group; a group a derived Intent adds is an additional restriction and never replaces an inherited one. * *Atomic establishment.* The Mission Issuer MUST establish a derived Mission's binding to every inherited group before that Mission can issue usable authority: at child creation, and at successor activation in the same atomic step as the expansion profile's activation check ([I-D.draft-mcguinness-oauth-mission-expansion], Section "Concurrent Expansion Reconciliation"), including a group that latched while the successor's approval was pending. A Mission Issuer that cannot establish and consistently enforce the binding MUST refuse the creation or activation. * *Retention.* A latch persists while any Mission bound to the group holds usable authority, beyond the lifetime of the Mission whose approval created the group. * *Relaxation.* An approval does not undo an action already executed, and the latch remains. What a relaxation changes is enforcement: an Approver authorized to relax the originating group may explicitly approve a relaxation scoped to named Missions or branches and to named authority, and the PDP then permits that authority under those Missions despite the latch. The relaxation's consent disclosure MUST name the group and its latched selector, the relevant execution history and any unresolved permits, the additional authority the relaxation enables, and the Missions or branches it affects. The relaxation is recorded for those Missions or branches only; the historical latch remains, and every other Mission bound to the group stays restricted. An ordinary approval of a child, an approval of unrelated authority, a ceiling renewal, or an approval of only part of the affected authority relaxes the group for nothing it does not name. * *Template instances.* A Mission dispatched from a Mission Template ([I-D.draft-mcguinness-oauth-mission-template]) is a separately scoped standing-consent instance: its groups bind that instance and the Missions derived from it, not sibling instances. The template's consent rendering MUST state that the exclusion holds per instance. The consent promise is therefore "never both without an explicitly approved relaxation", across the delegated work the Approver approved. 9. Capacity Across Missions A consumption bound limits the delegation it is approved for, not a credential or record derived from it. Tokens, permits, and instances under one Mission draw on one Mission-keyed counter. A Mission created from another Mission draws on that Mission's counters and never receives a fresh copy of the bound: * *Child Mission.* A consequential action under a Child Mission ([I-D.draft-mcguinness-oauth-mission-child-delegation]) is charged to the child's own bound, where it carries one, and to the same bound of every ancestor that carries it. The PDP MUST refuse the action when any of those counters would be exceeded. Where an ancestor's counter is outside the child's consistency domain, the deployment instead reserves the child's bound against the ancestor's counter when the child is created, as an escrowed allocation that MUST NOT exceed the ancestor's remaining quantity. When the child becomes terminal, the deployment closes the child's allocation so that every later reservation against it fails, even one a PDP permits on a cached active state within its staleness bound ([I-D.draft-mcguinness-mission-runtime]). The unconsumed remainder MUST NOT return to the ancestor before that closure is confirmed, and quantity held by the child's unsettled reservations stays charged until they settle (Section 12.1.2). A Mission Issuer whose deployment can do neither MUST refuse to create a Child Mission under a Mission that carries a consumption bound. Two children that each carry a bound of 60,000 under a parent bound of 100,000 together consume at most 100,000. * *Successor and carryover replacement.* An Expansion successor ([I-D.draft-mcguinness-oauth-mission-expansion]) and a Child Delegation carryover replacement continue the counters of the Mission they replace: consumption to date carries forward, and the successor's bound caps the cumulative consumption of the chain. A successor raises a bound when it carries a larger or incomparable value, or omits a bound, a max_calls class, or a max_egress_volume dimension its predecessor carries. A successor adjudicated by policy rather than by a fresh human approval MUST NOT raise a bound. Where a successor raises a bound, its approval rendering MUST include the consumption to date (Section 6.1). A Mission dispatched from a Mission Template ([I-D.draft-mcguinness-oauth-mission-template]) is created from a standing consent, not from another Mission, and has its own counters. One template consent therefore admits up to max_active times an instance's bound at once, and more over time at the template's dispatch_rate. Unless the deployment meters an aggregate bound spanning the template's instances (Section 10), the template's consent rendering MUST present the bound as per instance, together with max_active and dispatch_rate. 10. Aggregate Bounds The bounds of this document are Mission-keyed. A deployment MAY additionally meter the same bound classes across Missions, keyed by the Mission's subject, by the approved client_id, or by a lineage- keyed budget identifier shared by a root Mission and every Child Mission derived from it, so a fleet operator can cap what an agent identity, a Subject, or a Mission's whole derivation lineage consumes in total rather than per task. The counter semantics, reserve/commit postures, and refusal behavior are unchanged; only the key differs. A lineage-keyed budget identifier and its authoritative shared counter meter, as deployment policy, across every Mission a derivation lineage contains. They are distinct from the ancestor charging of Section 9, which enforces the bound an Approver consented to on one Mission across that Mission's descendants. A Child Mission's derivation counter is independent of its parent's, is not a consumption bound, and bounds nothing beyond that Child Mission itself ([I-D.draft-mcguinness-oauth-mission-child-delegation]). This document is experimental (Section 1), so a deployment running only the stable issuance and runtime profiles has no lineage-wide aggregate bound in force at all. A deployment MUST NOT render, in an Enforcement Scope Statement or at any consent surface, a lineage-wide or subtree aggregate bound as in force unless it is enforced under Section 9 or by a lineage-keyed budget identifier and shared counter meeting this section's requirements. An aggregate bound is deployment policy: it is carried on no single Mission Intent, is committed by no intent_hash, and is disclosed through the deployment's Enforcement Scope Statement rather than the approval event. A refusal under an aggregate bound is carried as quota_exceeded, and its Decision Evidence metering entry records the aggregate key class in counter_scope and the counter in counter_id (Section 11). Aggregate keying crosses the family's per-Mission consistency domains: a subject-keyed or lineage-keyed counter is shared by every Mission the key spans, so it cannot be sharded by Mission Identifier and is provisioned as its own consistency domain ([I-D.draft-mcguinness-mission-runtime]). 11. Metering Evidence A metered decision is auditable only where the evidence exposes the counter state the decision asserted. This document defines one coordinated evidence member, metering, carried in Decision Evidence and Execution Evidence under the runtime evidence companion's extension conventions ([I-D.draft-mcguinness-mission-runtime-evidence]). metering: An array of one or more entries, one per bound the evaluation metered. In a deployment claiming this profile, a Decision Evidence record emitted for a metered evaluation, permit or refusal, MUST carry it, and an Execution Evidence record MUST carry it where the committed quantity is conveyed by consumed (Section 12.1.1). Each entry has the members: bound: REQUIRED. A string. The metered bound: a Mission Intent member name this document defines (Section 6) or the applicable per-entry constraint name (Section 7). counter_scope: REQUIRED. A string. The counter's key class: mission for the Mission-keyed bounds of this document, or subject, client, or lineage for an aggregate bound (Section 10). counter_id: REQUIRED. A string. A stable identifier of the counter, the same value on every record the counter's decisions and settlements produce. It is committed or pseudonymous: a sensitive key (a subject or lineage identifier the record does not otherwise carry) appears only as a commitment, for example a sha-256: digest of the deployment's counter key, never raw. requested: REQUIRED in Decision Evidence, absent otherwise. The quantity the evaluation sought to consume, in the bound's native unit shape: {amount, currency} for max_budget, an integer count for max_calls, an ISO 8601 duration for max_duration, and an object of bytes and messages for max_egress_volume. reserved: CONDITIONAL. The same shape. The quantity reserved; REQUIRED in the Decision Evidence of a permitted action under a reserving posture (Section 7.2). remaining: REQUIRED in Decision Evidence, absent otherwise. The same shape. The counter's remaining quantity after the decision; after a refusal, the unchanged remaining quantity the request exceeded. consumed: CONDITIONAL. The same shape. Execution Evidence only: the actual quantity for the PDP to commit, per the bound-class conveyance rules of Section 12.1.1. settlement_state: CONDITIONAL. A string. Decision Evidence of a permitted metered action only: the decision-time posture, reserved or committed (Section 7.2). The terminal disposition, commit, release, hold, or conflict, is applied under Section 12.1.2 and joined through evaluation_id; it is not restated in the immutable record. The member turns a metered refusal into a checkable claim rather than an assertion: the refusal's entry shows requested exceeding remaining on a named counter, and the counter's accounting history is the join of the entries sharing its counter_id. A lineage-wide refusal under an aggregate bound reads: { "metering": [ { "bound": "max_budget", "counter_scope": "lineage", "counter_id": "sha-256:t7RnQ2xV9kM4wB1sJ6eL3yP8cA5fH0dZu2gN7bXq4Ss", "requested": { "amount": "25.00", "currency": "USD" }, "remaining": { "amount": "10.00", "currency": "USD" } } ] } 12. AuthZEN Wire Representation Where the runtime deployment uses the AuthZEN profile ([I-D.draft-mcguinness-mission-authzen]), this section defines the wire representation of metering. It defines no new metering semantics and no new constraint. The requirements of this section and Section 12.1 apply only to a deployment that adopts the AuthZEN profile under that profile's conformance; for every other deployment the AuthZEN profile remains an informative reference. When metering a bound would exceed it, the PDP MUST deny with quota_exceeded ([I-D.draft-mcguinness-mission-authzen]) instead of returning a permit. The PDP MUST record quota_exceeded as the denial_reason in Decision Evidence. Whether a metered permit is reserved at decision time and committed on settlement, or committed at decision time, follows the deployment's documented reserve/commit posture (Section 7.2); this representation fixes neither. In a batch (boxcar) evaluation, consumption metering applies per item in request order. The exactness of the bound is the consistency bound of Section 7.1, not a property of this wire binding. 12.1. Settlement Exchange The metering rules require the PEP to signal actual use so the PDP commits consumption and releases any reservation. In the AuthZEN profile, delivery of the Execution Evidence Object ([I-D.draft-mcguinness-mission-runtime-evidence]) to the PDP is that commit-or-release signal: on receipt the PDP settles the linked action's consumption per Section 12.1.2, keyed to the Execution Evidence's evaluation_id. 12.1.1. Settlement Submission Contract The settlement transport is the runtime evidence companion's Execution Evidence delivery contract, profiled rather than a second channel: exactly one Execution Evidence Object exists per final disposition of a permit, delivery is at-least-once, and the receiver deduplicates on execution_id ([I-D.draft-mcguinness-mission-runtime-evidence]). This profile adds: * *Intake and audience.* The deployment MUST name the settlement intake, the PDP evidence-submission path or the event or evidence API it profiles, in its Enforcement Scope Statement. The intake MUST feed the consistency domain that holds the counter (Section 7.1, Section 10). * *Authentication.* The intake MUST accept a settlement only as an Execution Evidence Object in the evidence companion's integrity envelope, verified against the emitter key, scope, and audience binding claimed in the Enforcement Scope Statement ([I-D.draft-mcguinness-mission-runtime-evidence]). * *Acknowledgement.* The intake MUST acknowledge a settlement only after the commit or release is durably applied; an unacknowledged delivery is retried under the at-least-once contract. * *Duplicate delivery.* A redelivered record, the same execution_id with the same settlement-relevant content, MUST be acknowledged without applying the settlement again: the commit is idempotent on evaluation_id, so a redelivered settlement neither double-commits the consumption nor double-releases the reservation. * *Conflicting redelivery.* A record naming an evaluation_id whose settlement is applied but differing in settlement-relevant content (outcome, measured_duration, or a metering entry), or a second execution_id for the same evaluation_id, MUST fail closed: the applied settlement is unchanged, the conflicting record is retained as evidence, and the conflict is surfaced on the deployment's audit and alarm path. The committed quantity is conveyed per bound class: * max_calls: intrinsic. The class counter is consumed at decision time, one consequential call per evaluation_id; settlement confirms the disposition only. * max_duration: the Execution Evidence measured_duration member. * max_budget: the Execution Evidence metering entry's consumed member, as {amount, currency} (Section 11). * max_egress_volume: the Execution Evidence metering entry's consumed member, as bytes and messages, measured per the Operation Profile rules of Section 7, including the dereferenced-payload rule. Where an action class defines no actual measure for a bound, the Operation Profile MUST state that the reserved quantity commits. 12.1.2. Settlement by Evidence State A reservation settles on the evidence state, never on a generic failure signal: * *Affirmative non-execution* (outcome suppressed): the action was permitted but affirmatively not attempted. The PDP releases the reservation and returns the quantity to the counter. It releases an exclusivity latch only when, within the strongly consistent latch domain, every permitted action that matched the latched selector under any Mission bound to the group is affirmatively not executed (Section 8); one suppressed action never releases a latch another action exercised or still holds. * *Completed execution* (outcome completed): the PDP commits the conveyed actual quantity, or the reserved quantity where the class defines no actual measure, and releases any reserved excess. * *Attempted but failed* (outcome failed): not affirmative non- execution, because the attempt may have consumed real resources. The Operation Profile MUST define the commit-or-refund rule per metered action class; absent a defined rule the reservation remains charged and reconciles as an unknown outcome. * *Unknown outcome* (no evidence within the reservation lease): a reservation MUST carry a bounded lease so a crashed or abandoned reservation does not consume the budget permanently. On lease expiry without settlement the PDP reconciles the reservation through the runtime profile's orphaned-evidence process ([I-D.draft-mcguinness-mission-runtime]), which queries the resource and matches evidence. An unsettled reservation remains charged against the bound until it is reconciled, and is released only on affirmative evidence of non-execution; timeout alone never releases a reservation, in any action class. An idempotent action class makes a retry safe, not the first attempt void, and reversing a reversible action is a compensation action ([I-D.draft-mcguinness-mission-orchestration]), not evidence that the original did not execute. * *Conflicting settlement*: fail closed per Section 12.1.1. The applied settlement is unchanged; the conflict is audited, never adjudicated by the intake. A containment overlay's contain transition ([I-D.draft-mcguinness-oauth-mission-containment]) is not settlement evidence: an open reservation or duration lease still settles under the evidence states above, unaffected by contain, and contain narrows only forward draw, a new reservation or a lease renewal, through the ordinary permit check against the narrowed Effective Authority Set. The operational consequence: a lossy evidence channel accumulates reservations against max_budget and max_calls until the Mission starves on quota_exceeded, a self-inflicted denial of service. A deployment SHOULD run orphaned-evidence reconciliation on a published cadence sized to its evidence-channel loss rate; the reconciliation window it publishes is how long leaked budget stays leaked. 12.1.3. Duration-Lease Renewal For a duration-metered action the PEP reports the measured duration in the Execution Evidence measured_duration member, and the PDP commits that duration against max_duration. A duration-lease renewal is a new re-evaluation request that carries the prior permit's evaluation_id in context.prior_evaluation_id, so the PDP continues the same metered activity rather than opening a new reservation. The PDP MUST verify that the renewal's Mission, subject, action, and audience match the evaluation named by prior_evaluation_id. A deployment sizes lease intervals to amortize renewals: an interval materially shorter than the action class's staleness bound adds decision load without tightening the revocation cutoff. This exchange requires one request member and one evidence member: context.prior_evaluation_id: OPTIONAL. A string. Present on a duration-lease renewal request, carrying the evaluation_id of the permit being renewed. Absent on an initial request. measured_duration (Execution Evidence): REQUIRED for a duration- metered action, otherwise absent. A string containing an ISO 8601 duration (the duration rule in Appendix A of [RFC3339]): the PEP's measured duration for the executed action. A renewal repeats the evaluation-request envelope for the same activity and adds context.prior_evaluation_id. Here a long-running, duration-metered ledger reconciliation renews its lease before the prior permit expires; the action is not parameter-bound, so no parameter_digest is carried: { "subject": { "type": "user", "id": "user_3p2q8mN1a0kV7tR", "properties": { "iss": "https://idp.example.com" } }, "resource": { "type": "ledger", "id": "ledger_main", "properties": { "audience": "https://erp.example.com" } }, "action": { "name": "reconciliation.run" }, "context": { "mission": { "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-", "issuer": "https://as.example.com" }, "mission_state_observation": { "state": "active", "mode": "fresh", "freshness_at": "2026-11-02T08:44:00Z" }, "actor": { "client_id": "s6BhdRkqt3" }, "credential": { "issuer": "https://as.example.com", "expires_at": "2026-11-02T09:14:00Z" }, "prior_evaluation_id": "dec_0Rt5nB8xW2qK7mJ4vS1pL9eYc" } } 13. Conformance A runtime deployment that claims this profile MUST: * meter every consumption bound a governed Mission carries per Section 7, within its documented runtime enforcement scope ([I-D.draft-mcguinness-mission-runtime]); * refuse a consequential action that would exceed a bound, and refuse on any bound it cannot meter; * enforce every consented exclusivity group with a latch atomic with the permit (Section 8); * charge a Child Mission's actions to its ancestors' bounds, or settle its escrowed allocation, and continue a successor's counters per Section 9; * where aggregate bounds are configured, meter and disclose them per Section 10; * emit the metering evidence member on the records Section 11 requires; * publish its consistency bound under a multi-PDP topology (Section 7.1); * define and document its retry, idempotency, and reserve/commit posture (Section 7.2); and * where the AuthZEN profile is in use, implement the settlement exchange of Section 12.1. A Mission Issuer in a deployment claiming this profile MUST carry the consented bounds on the Mission record committed by intent_hash. It MUST render them at the approval event per Section 6.1, and MUST apply the child-creation, successor, and template rules of Section 9. 14. Security Considerations Consumption bounds limit the blast radius of a compromised or runaway agent in a dimension authority narrowing cannot: a Mission whose every action is individually authorized can still be drained by volume. Their enforcement, however, is only as good as the metering: * *Unenforced bounds are consent theater.* A bound rendered at approval but not metered anywhere misleads the Approver about the Mission's exposure. The consent-integrity rule (Section 6.1) exists for this: it forbids a deployment that cannot meter a bound from rendering it as enforced. * *Distributed undercounting.* Under a multi-PDP topology, an attacker who can spread actions across decision points exploits the consistency gap. The published consistency bound (Section 7.1) is the honest statement of that exposure; per-PDP sub-budgets bound it structurally. * *Settlement honesty.* The PDP commits what the PEP reports. Execution Evidence is integrity-protected and signed by the PEP ([I-D.draft-mcguinness-mission-runtime-evidence]); a compromised PEP can under-report duration or spend, which is within the runtime profile's trusted-base assumptions for PEPs. * *Lease abandonment.* An agent that stops renewing a duration lease and keeps acting is stopped by the PEP, which Section 7 requires to stop the action or obtain a new permit before the lease is exhausted. * *Reservation starvation.* An attacker who opens reservations and never settles them can consume a budget with no executed action, denying the Mission its remaining authority. The bounded reservation lease (Section 12.1) caps this: an unsettled reservation is reconciled on lease expiry, and reconciliation that finds no effect at the resource returns the budget. An outcome reconciliation cannot establish stays charged and is escalated, never released by a timer. * *Latch burning.* Because the first matching action latches an exclusivity group, an injected agent can try to burn a group by driving the side it wants foreclosed, denying the Mission the other side. Releasing the latch when every participating action is affirmatively not executed (Section 8) keeps unexecuted attempts from foreclosing the group permanently. 15. Privacy Considerations Metering state (spend, call counts, activity durations) is a fine- grained record of Mission activity over time. It SHOULD be retained under the same access controls and retention windows as runtime enforcement evidence ([I-D.draft-mcguinness-mission-runtime]), and disclosed in decision responses only as refusals, not as remaining- balance oracles. The metering evidence member records remaining inside those access-controlled records (Section 11), never in a decision response. The refusal boundary is itself a coarse balance oracle: the point at which a bound flips from permit to refusal reveals the remaining margin. A deployment SHOULD bound this probing with the AuthZEN profile's denial-oracle controls ([I-D.draft-mcguinness-mission-authzen]), per-Mission rate-limiting of access requests and evidence-logging of request provenance, so a compromised agent mapping a balance by repeated probes is visible to the humans adjudicating it. 16. IANA Considerations This document registers the following in the issuance profile's "Mission Intent Members" registry: max_budget, max_calls, max_duration, and max_egress_volume as stable, and exclusive as experimental (not promoted; a 2026-08 assessment against this document's own promotion criteria, Section 2, found every applicable gate unmet). Each is a named top-level Mission Intent member this profile defines, produces, and enforces in full under the issuance profile's Mission-Intent extension seam ([I-D.draft-mcguinness-oauth-mission]); the registration records ownership only. context.prior_evaluation_id is AuthZEN extension data carried per the AuthZEN profile's conventions ([I-D.draft-mcguinness-mission-authzen]), needing no separate registration; measured_duration and metering are coordinated evidence members under the runtime evidence companion's extension conventions ([I-D.draft-mcguinness-mission-runtime-evidence]), likewise outside this registry. 17. References 17.1. Normative References [I-D.draft-mcguinness-mission-authzen] McGuinness, K., "Mission-Bound Runtime Enforcement: AuthZEN Profile", 2026, . [I-D.draft-mcguinness-mission-runtime] McGuinness, K., "Mission-Bound Runtime Enforcement", 2026, . [I-D.draft-mcguinness-mission-runtime-evidence] McGuinness, K., "Mission Runtime Evidence", 2026, . [I-D.draft-mcguinness-mission-substrate] McGuinness, K., "Mission Substrate Requirements", 2026, . [I-D.draft-mcguinness-oauth-mission] McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-consent-evidence] McGuinness, K., "Mission Consent Evidence for OAuth 2.0", 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 17.2. Informative References [I-D.draft-mcguinness-mission-architecture] McGuinness, K., "An Architecture for Mission-Bound Authorization", 2026, . [I-D.draft-mcguinness-mission-orchestration] McGuinness, K., "Mission Orchestration and Unwinding", 2026, . [I-D.draft-mcguinness-oauth-mission-child-delegation] McGuinness, K., "Mission Child Delegation for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-containment] McGuinness, K., "Mission Containment for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-derivation-limits] McGuinness, K., "Mission Derivation Limits for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-expansion] McGuinness, K., "Mission Expansion for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-template] McGuinness, K., "Mission Template for OAuth 2.0", 2026, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . Appendix A. Document History [[ To be removed from the final specification ]] * Exclusivity Across Missions (Section 8.1): an exclusivity group is one shared latch across the delegation (children, descendants, successors, carryover replacements), established atomically before a derived Mission issues usable authority, retained while derived authority remains usable, and relaxed only by an explicit, scoped, disclosed approval that keeps the historical latch. Settlement releases a latch only when every participating action is affirmatively not executed. Template instances are scoped per instance, with that limit disclosed. * Capacity Across Missions (Section 9): a Child Mission is charged to every ancestor's bound or holds an escrowed allocation whose remainder returns only after the allocation is closed, a successor or carryover replacement continues its predecessor's counters, a policy successor keeps every bound, and a template consent renders the per-instance bound with max_active and dispatch_rate. Lease expiry no longer releases an unsettled reservation for an idempotent or reversible action class (Section 12.1.2), and a metered high-consequence idempotency horizon reaches the Mission's expires_at (Section 7.2). * Controls taxonomy retirement (#636, #117): max_budget, max_calls, max_duration, max_egress_volume, and exclusive move from controls. to named top-level Mission Intent members, since the issuance profile retires the controls bucket entirely ([I-D.draft-mcguinness-oauth-mission]); this is a wire-shape change to that surface, so the wire-surface-stability window (Section 2) restarts at this revision. The earlier plan to adopt exclusive into the issuance profile's core controls vocabulary is retired along with that vocabulary; exclusive stays an ordinary member of this document. A 2026-08 promotion assessment of exclusive against Section 2 found every applicable gate NOT MET (issue #117): it remains EXPERIMENTAL and unpromoted, now explicitly marked as such at its own definition (Section 6). max_derivations renamed to derivation_limit in cross-references to the issuance profile. * One informative cross-reference in Settlement by Evidence State (Section 12.1.2): a containment overlay's contain transition is not settlement evidence. An open reservation or duration lease still settles unchanged under the existing evidence-state rules, and contain narrows only forward draw, a new reservation or a lease renewal, through the ordinary permit check against the narrowed Effective Authority Set. No new settlement state (#670). Acknowledgments This document is part of the Mission-Bound Authorization work and defines its experimental consumption-metering layer. Author's Address Karl McGuinness Independent Email: public@karlmcguinness.com