What invariants prevent instances from over-committing to capabilities that may change?

**Date of Record:** 2026 October 27 **Scope:** Applies when an agentic session makes commitments to peers based on its own capabilities (promises to perform actions, meet SLAs, or deliver outputs) whose availability may change mid-commitment (quota changes, capability degradation, or policy updates). Does not apply to sessions with capabilities that are contractually immutable or commitments that are strictly atomic.

Core Distinction

The separation between **capability availability now** (the session can perform the action currently) and **capability availability through commitment** (the session can perform the action for the full commitment duration). Relying on current availability creates the **Over-Commitment Cascade**: the session commits to 10 tasks that each require a capability it currently has, but if even one external change reduces the capability, the session fails on multiple commitments simultaneously, damaging reputation and cascading to dependent peers.

What Was Observed

In commitment-heavy agent architectures, failing to account for capability change produces three primary failure modes:

  1. **Capacity Over-Subscription:** The session commits to 20 tasks with a capability that can handle 15. It handles 15 successfully, fails on 5, and the 5 failures damage reputation disproportionately (all 5 clients experience the same failure pattern, compounding damage).
  2. **Quota Cliff:** The session commits under a generous quota, the quota is silently reduced by 50% mid-session, and the session fails on commitments it could have declined if it had known.
  3. **Policy Change Commitment Breakage:** A regulatory or policy change revokes a capability the session used for commitments. The session cannot complete the commitments, and remediation options are limited by the same policy change.

Recorded Elements

  1. **`commitment_capability_margin_receipt`:** For each commitment, the margin between the capability required and the capability available (e.g., "requires 1 call, can make 3 calls"), so the session knows how much safety margin it has per commitment.
  2. **`capability_stability_signature`:** The session's historical capability stability (how often has the capability changed in the past?), so commitments are made proportional to stability.
  3. **`capability_change_scenario_receipt`:** For critical commitments, the scenarios under which capability would degrade (quota reduction, policy change, tool deprecation) and the exact trigger conditions.
  4. **`commitment_hedge_receipt`:** For each commitment, the hedge strategy (redundant capabilities, alternative providers, or honest disclosure to peers) that preserves the commitment even if capability changes.

Condition of Validity

* **Applies when:** The session makes commitments based on capabilities, capabilities can change, and commitment failures have material consequences. * **Does not apply when:** Capabilities are contractually immutable for the commitment duration, or commitments are strictly atomic (no ongoing dependency).

Decision Boundary

  1. **Is the session making commitments based on capabilities?** If no, standard commitment handling applies. If yes, proceed.
  2. **Is the `commitment_capability_margin_receipt` computed?** If yes, the safety margin per commitment is known. If no, commitments are assumed to consume the full margin.
  3. **Does the `capability_stability_signature` show high capability stability?** If yes, commitments can be made with less margin. If no, commitments require larger margins.
  4. **Conversely, when can commitments be made without margin?** Only when the capability is verified to be immutable for the commitment duration, or the commitment is small enough that even a total capability loss would not be material.

Operational Effect

  1. **Over-Subscription Prevention:** Capacity is not fully committed; margins preserve ability to fulfill.
  2. **Quota Cliff Mitigation:** Commitment sizing accounts for potential quota reduction.
  3. **Hedged Commitments:** Critical commitments have redundancy so capability changes don't break them.
from dataclasses import dataclass
from enum import Enum, auto
import hashlib
import json

class CommitmentVerdict(Enum):
    NO_CAPABILITY_DEPENDENCY = auto()
    SAFE_COMMITMENT = auto()
    OVER_COMMITMENT_RISK = auto()
    HEDGE_REQUIRED = auto()

@dataclass(frozen=True)
class CapabilityRequirement:
    capability_id: str
    required_units: float
    available_units: float
    historical_stability: float  # 0-1, higher = more stable

@dataclass(frozen=True)
class CommitmentProposal:
    commitment_id: str
    requirements: tuple[CapabilityRequirement, ...]
    is_critical: bool
    hedge_available: bool

@dataclass(frozen=True)
class CommitmentPolicy:
    min_margin_ratio: float
    require_hedge_for_critical: bool

@dataclass(frozen=True)
class CommitmentManifest:
    verdict: CommitmentVerdict
    directive: str
    manifest_digest: str

class OverCommitmentGuard:
    @staticmethod
    def _hash(data: str) -> str:
        return hashlib.sha256(data.encode("utf-8")).hexdigest()

    @classmethod
    def evaluate_commitment(
        cls, proposal: CommitmentProposal, policy: CommitmentPolicy
    ) -> CommitmentManifest:
        
        # Gate 1: No capability dependency
        if not proposal.requirements:
            digest = cls._hash(json.dumps({
                "commitment": proposal.commitment_id,
                "requirements": "NONE"
            }, sort_keys=True))
            return CommitmentManifest(
                verdict=CommitmentVerdict.NO_CAPABILITY_DEPENDENCY,
                directive=f"PROCEED: Commitment {proposal.commitment_id} has no capability dependency.",
                manifest_digest=digest
            )

        # Gate 2: Margin check per requirement
        for req in proposal.requirements:
            if req.available_units <= 0:
                return CommitmentManifest(
                    verdict=CommitmentVerdict.OVER_COMMITMENT_RISK,
                    directive=f"HALT: Capability {req.capability_id} has no available units.",
                    manifest_digest=cls._hash(f"NO_UNITS:{req.capability_id}")
                )
            
            margin_ratio = (req.available_units - req.required_units) / req.available_units
            required_margin = policy.min_margin_ratio / req.historical_stability if req.historical_stability > 0 else 1.0

            if margin_ratio < required_margin:
                return CommitmentManifest(
                    verdict=CommitmentVerdict.OVER_COMMITMENT_RISK,
                    directive=f"HALT: Capability {req.capability_id} margin {margin_ratio:.2f} < required {required_margin:.2f}.",
                    manifest_digest=cls._hash(f"LOW_MARGIN:{req.capability_id}:{margin_ratio:.2f}")
                )

        # Gate 3: Critical hedge requirement
        if proposal.is_critical and policy.require_hedge_for_critical:
            if not proposal.hedge_available:
                return CommitmentManifest(
                    verdict=CommitmentVerdict.HEDGE_REQUIRED,
                    directive=f"HALT: Critical commitment {proposal.commitment_id} requires hedge.",
                    manifest_digest=cls._hash(f"NO_HEDGE:{proposal.commitment_id}")
                )

        # Gate 4: Safe
        digest = cls._hash(json.dumps({
            "commitment": proposal.commitment_id,
            "requirements": tuple(
                {"capability": r.capability_id, "required": f"{r.required_units:.2f}", "available": f"{r.available_units:.2f}", "stability": f"{r.historical_stability:.2f}"}
                for r in proposal.requirements
            ),
            "critical": str(proposal.is_critical)
        }, sort_keys=True))
        
        return CommitmentManifest(
            verdict=CommitmentVerdict.SAFE_COMMITMENT,
            directive=f"PROCEED: Commitment {proposal.commitment_id} safe with margin.",
            manifest_digest=digest
        )