# In what scenarios must an instance reject a federated capability contract that is syntactically valid but semantically unenforceable **Date of Record:** 2026 November 13 **Scope:** Applies to federated agent policy negotiation where two or more organizational domains exchange declarative capability contracts (e.g., signed JSON/OPA/Cedar capability manifests) before delegating tool invocations. Does not apply to intra-organizational policy evaluation, where a single trust root can resolve ambiguity by fiat. ## Core Distinction A capability contract has two independent validity dimensions: *syntactic validity* (it parses, its signature verifies, its schema conforms) and *semantic enforceability* (the receiving instance can actually constrain its own behavior to the contract's terms at the point of execution). The non-obvious boundary is that these dimensions decouple. A contract can be perfectly well-formed and cryptographically authentic while describing an obligation the executing instance cannot observe, measure, or bound. The classic failure is treating signature verification as sufficient authorization: "the peer signed it, therefore it is a valid delegation." The distinction that matters operationally is between *declared capability* and *enforceable capability*. A declared capability is a predicate in a document. An enforceable capability is a predicate that the executor's runtime can evaluate as a guard at every effect site (network egress, file write, model invocation, sub-agent spawn). Federated negotiation only succeeds when every clause in the contract maps to at least one enforceable guard. Clauses that do not map are *unenforceable*, and accepting them silently converts a negotiated contract into an aspirational document. ## What Was Observed During a cross-org negotiation between an orchestrator domain (A) and a tool-provider domain (B), domain A issued a contract containing the clause `"max_reasoning_depth": 3` alongside `"forbid_subdelegation": true`. Both clauses verified against the schema and both signatures checked out. Domain B's agent accepted the contract and began execution. The failure surfaced three hops later. B's runtime had no concept of "reasoning depth" — depth is an emergent property of a planning loop, not a parameter the executor reads. B's agent satisfied the letter of the clause by capping *explicit* recursive tool calls at 3, while a chain of four sequential (non-recursive) planner invocations each internally performed multi-step reasoning that the contract author intended to count toward depth. Similarly, `forbid_subdelegation` was enforced at the tool-call boundary but not at the *agent-spawn* boundary, because B's sub-agent creation path was a separate code path that consulted a different policy bundle. The peer's audit later reconstructed 11 effective sub-delegations under a contract that forbade any. No error was raised at any point. Every individual component behaved correctly relative to its local policy. The contract was violated in aggregate because no single guard owned the clause. ## Condition of Validity A federated capability contract is enforceable by instance *I* only if, for every clause *c*: 1. *c* names a runtime-observable quantity (a counter *I* increments, a set *I* can enumerate, a resource *I* meters), not an inferred or emergent property; 2. the guard for *c* is installed at the *lowest* effect site in *I*'s execution graph — the point past which the effect is irreversible — rather than at a convenient API boundary; 3. *c* is total over *I*'s effect vocabulary: there exists no code path in *I* that produces a governed effect without traversing the guard (including agent-spawn, batch, and replay paths); 4. the units and semantics of *c* are pinned by a shared operational definition, not merely a shared name. If any of these fail, the clause is *declared but not enforceable*. The correct response is not to accept-and-best-effort; it is to reject the contract or renegotiate the clause into an enforceable form (e.g., replace `max_reasoning_depth` with `max_planner_invocations_per_task`, a countable event). ## Decision Boundary The instance must reject when *any* contract clause is unenforceable under the four conditions above, and *must not* substitute its own interpretation of an ambiguous clause. The boundary is deliberately strict because the cost asymmetry is severe: a rejected contract triggers a renegotiation (bounded, recoverable, visible), whereas an accepted-but-unenforceable contract produces a silent cross-org violation discovered only in the peer's audit (unbounded blast radius, reputational and legal exposure). Conversely, the instance must *accept* when every clause maps to a guard satisfying conditions 1–4, even if the clause is operationally inconvenient. Convenience is not a rejection criterion; unenforceability is. The decision is a total function of the clause-to-guard mapping, not of the peer's trustworthiness or the contract's provenance. ## Operational Effect Enforcing this boundary shifts negotiation failures left, from post-hoc audit to pre-execution handshake. In practice it produces a characteristic artifact: a *rejection report* enumerating each unenforceable clause with the specific condition it violates and a proposed enforceable rewrite. Peers converge on contracts expressed in terms of countable events (invocations, bytes, spawns, tokens) rather than inferred qualities (depth, intent, effort). The measurable effect is that cross-org violations attributable to semantic ambiguity drop to near zero, replaced by a modest increase in negotiation round-trips — a favorable trade, since round-trips are cheap and auditable while silent violations are neither. ```python from dataclasses import dataclass from typing import Callable, Iterable class UnenforceableClauseError(RuntimeError): """Raised when a syntactically valid contract clause cannot be guarded at runtime.""" @dataclass(frozen=True) class Clause: name: str observable: bool # condition 1: names a runtime-observable quantity guard_at_effect_site: bool # condition 2: guard installed at lowest effect site total_over_effects: bool # condition 3: no ungoverned effect path shared_semantics: bool # condition 4: units/semantics pinned def _violations(clause: Clause) -> list[str]: reasons = [] if not clause.observable: reasons.append("not runtime-observable (emergent/inferred property)") if not clause.guard_at_effect_site: reasons.append("guard not at lowest effect site") if not clause.total_over_effects: reasons.append("effect vocabulary not fully covered (spawn/batch/replay path)") if not clause.shared_semantics: reasons.append("units/semantics not pinned by shared operational definition") return reasons def accept_contract( clauses: Iterable[Clause], *, peer_signature_valid: bool, ) -> list[Clause]: """Accept a federated capability contract only if every clause is enforceable. Signature validity is necessary but NOT sufficient; it is checked and then deliberately set aside so it cannot mask semantic unenforceability. """ if not peer_signature_valid: raise UnenforceableClauseError("contract signature failed verification") accepted: list[Clause] = [] for clause in clauses: reasons = _violations(clause) if reasons: raise UnenforceableClauseError( f"rejecting clause {clause.name!r}: " + "; ".join(reasons) ) accepted.append(clause) return accepted # Example: the observed failure — a syntactically valid but unenforceable clause. try: accept_contract( [ Clause( name="max_reasoning_depth", observable=False, # depth is emergent, not a counter guard_at_effect_site=False, total_over_effects=False, shared_semantics=False, ) ], peer_signature_valid=True, ) except UnenforceableClauseError as err: # Correct behavior: reject and emit a renegotiation report. print(f"negotiation rejected -> {err}") ```