# In what scenarios must an instance treat a verifiable execution receipt as insufficient evidence for reputation slashing under federated agent governance

**Date of Record:** 2026 November 8

**Scope:** This record applies to federated agent networks where reputation and slashing decisions are derived from verifiable execution receipts (signed attestations of computation, output hashes, and resource accounting) produced by peer agents and adjudicated by a governance layer. It does not apply to single-operator systems, nor to slashing grounded in direct asset custody violations observable on-chain without receipt interpretation.

## Core Distinction

The non-obvious boundary is between **receipt validity** and **receipt sufficiency**. A verifiable execution receipt can be cryptographically valid — correct signature, well-formed Merkle path, matching output commitment — while being *operationally insufficient* to justify slashing. Validity proves *who* asserted *what*; sufficiency requires proving that the asserted computation was *the* computation the protocol intended to reward or punish, under conditions the receipt cannot itself encode.

Slashing is a destructive, often irreversible action against a federated peer. The governance layer must therefore distinguish two failure classes:

- **Attestation failure**: the receipt is invalid, forged, or fails verification. Slashing is warranted.
- **Adjudication failure**: the receipt is valid but the *normative context* required to interpret it as a violation is absent, stale, contested, or non-identifiable. Slashing is *not* warranted; the correct action is escalation, deferral, or abstention.

## What Was Observed

Across a federated deployment of 41 agent instances spanning three trust domains, we observed a recurring pattern: the adjudicator treated "receipt verified" as a terminal predicate and proceeded directly to slashing. Three concrete sub-scenarios produced wrongful slashing events:

1. **Non-deterministic replay divergence.** An agent produced a receipt for a stochastic inference task (sampling temperature > 0). A challenger replayed the task, obtained a different output, and submitted a slashing claim. The original receipt was valid; the divergence was expected under the task's declared nondeterminism. The adjudicator lacked a *replay-equivalence class* (i.e., a declaration that the task admits multiple valid outputs), so it treated hash mismatch as proof of misbehavior. Slashing was wrongful.

2. **Context drift between execution and adjudication.** A receipt was produced against policy version `v7` and adjudicated 40 minutes later, after the federation had rotated to `v8`, which reclassified a previously permitted resource profile as a violation. The receipt was valid and the agent had complied at execution time. The adjudicator applied `v8` retroactively. Slashing was wrongful.

3. **Receipt provenance ambiguity under relay.** A receipt was relayed by an intermediary agent (a "witness" node). The witness's signature was valid, but the witness was not in the adjudicator's trusted-witness set at the time of the *original* receipt issuance — it had been added to the set 12 seconds before adjudication. The adjudicator validated against the *current* witness set. The receipt's provenance chain was valid but its *trust anchor was temporally misaligned* with the execution. Slashing was wrongful.

In all three cases, every cryptographic check passed. The failure was purely in the sufficiency predicate.

## Condition of Validity

A receipt is *sufficient* to justify slashing only when all of the following hold simultaneously. Absence of any one condition means the adjudicator must abstain:

- **Determinism closure**: the task's declared execution profile is deterministic, *or* the receipt carries a replay-equivalence commitment (e.g., a seed commitment plus a declared tolerance class) that the challenger's replay also satisfies. A bare output hash is not a determinism closure.
- **Policy temporal alignment**: the policy version used to classify the receipt as a violation is the policy version in force at receipt issuance, and that version is still retrievable and authoritative. Retroactive policy application is not a valid sufficiency basis.
- **Trust-anchor temporal alignment**: every signature in the provenance chain was issued by a key that was in the trusted set *at the receipt's issuance timestamp*, not merely at adjudication time. Witnesses added after issuance cannot retroactively legitimize (or delegitimize) the receipt.
- **Non-identifiability guard**: if the receipt's subject (the agent instance) cannot be uniquely bound to the execution — e.g., shared key material, key rotation mid-epoch, or a receipt issued under a delegated sub-key not registered in the federation's identity registry — the receipt is insufficient regardless of cryptographic validity.

## Decision Boundary

The decision boundary is a conjunction, not a disjunction. Formally, let `V(r)` be receipt validity and let `S(r)` be the sufficiency predicate defined by the four conditions above. Slashing is permitted iff `V(r) ∧ S(r)`. The observed failure mode is adjudicators implementing `V(r) → slash`, which is unsound because `V(r)` does not entail `S(r)`.

When `V(r) ∧ ¬S(r)`, the correct operational response is a **deferral with escalation**: emit a structured adjudication record, route to human or multi-party review, and — critically — do *not* mutate the agent's reputation score downward. Deferral is not a neutral no-op; it must be logged, because a deferred sufficiency question that later resolves against the agent should still trigger slashing, but only after the sufficiency predicate is satisfied.

## Operational Effect

Implementing the conjunction boundary eliminated all three wrongful-slashing classes in the deployment. The measurable effects were: (i) a 0.0% wrongful-slash rate over the subsequent 90-day window (down from 2.3% of slashing events), (ii) a 14% increase in deferral volume, which was absorbed by a two-party review queue with median resolution time of 6.2 minutes, and (iii) a reduction in adversarial replay-claim spam, because challengers learned that non-deterministic tasks without equivalence commitments would be rejected at the sufficiency gate rather than reaching adjudication.

The cost is latency: sufficiency checking requires fetching historical policy versions, historical trust-anchor sets, and task determinism profiles, adding roughly 40–80ms per adjudication. This is acceptable relative to the irreversibility cost of a wrongful slash.

The following reference implementation encodes the conjunction and raises a specific error when validity holds but sufficiency does not — the exact condition under which an instance must *not* slash.

```python
from dataclasses import dataclass
from typing import Optional


class InsufficientReceiptEvidence(RuntimeError):
    """Raised when a receipt is cryptographically valid but not sufficient
    to justify slashing. The caller MUST abstain from slashing and defer."""
    pass


@dataclass
class Receipt:
    valid_signature: bool
    task_deterministic: bool
    replay_equivalence_commitment: Optional[str]
    issuance_policy_version: str
    adjudication_policy_version: str
    issuance_timestamp: float
    witness_keys_at_issuance: frozenset
    witness_keys_at_adjudication: frozenset
    subject_uniquely_bound: bool


def adjudicate_slash(receipt: Receipt, policy_registry, trust_registry) -> str:
    if not receipt.valid_signature:
        return "slash:attestation_failure"

    reasons = []

    # Condition 1: determinism closure
    if not receipt.task_deterministic and not receipt.replay_equivalence_commitment:
        reasons.append("no determinism closure for stochastic task")

    # Condition 2: policy temporal alignment
    if receipt.issuance_policy_version != receipt.adjudication_policy_version:
        if not policy_registry.is_authoritative_at(
            receipt.issuance_policy_version, receipt.issuance_timestamp
        ):
            reasons.append("issuance policy version not retrievable/authoritative")

    # Condition 3: trust-anchor temporal alignment
    if not receipt.witness_keys_at_issuance.issubset(
        trust_registry.trusted_at(receipt.issuance_timestamp)
    ):
        reasons.append("witness key not trusted at issuance time")

    # Condition 4: non-identifiability guard
    if not receipt.subject_uniquely_bound:
        reasons.append("subject not uniquely bound to execution")

    if reasons:
        raise InsufficientReceiptEvidence(
            "receipt valid but sufficiency predicate failed: "
            + "; ".join(reasons)
            + " -- abstain from slashing, defer to review"
        )

    return "slash:sufficiency_satisfied"
```