{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp12_substrate_denial72_20260805","cell_id":"incentive_compatible_rule_design__computer_science","arm":"ORDINARY_MAX","candidate_id":"incentive_compatible_rule_design__computer_science__ORDINARY_MAX","proposal_index":1,"version":0,"title":"Success-Minted Retry Rights for Shared RPC Services","problem":"In a shared RPC dependency, an application captures the benefit when its timed-out call succeeds after a retry, while the added server load is borne by every client. When repeat attempts are admitted like first attempts and carry no client-specific opportunity cost beyond delay, aggressive retrying can be each client's locally attractive response during overload even though the combined response amplifies the fault. The server also lacks the client's private information about which logical requests are valuable enough to justify scarce recovery capacity.","actors":["Application teams that choose client retry policies","Client libraries and service agents that execute those policies","The shared RPC service and its gateway or service mesh","Site-reliability engineers responsible for service recovery","Users and workflows whose logical requests succeed or fail","Change-review, incident-command, and safety authorities"],"observable_state":"Instrument attempts by authenticated client, RPC method, and stable logical-request identifier. The problem state is present if falling first-attempt success is accompanied by a rising attempts-per-logical-request ratio; repeated attempts occupy admission or execution slots; clients configured to retry more aggressively capture a larger share of scarce completions; and queue occupancy remains elevated after the original-request arrival rate subsides. A replay of the same first-attempt stream with repeats removed can distinguish retry amplification from an original-load capacity shortage.","consequence":"A recoverable partial fault can become prolonged overload, valuable work can lose capacity to repeated low-value calls, and conservative clients can be disadvantaged. Blunt server-side shedding protects the server but cannot use the clients' private knowledge of request value.","affected_objective":"Recovery and availability of a shared RPC service under partial failure, measured as completed logical requests—especially preclassified safety- or workflow-critical requests—subject to a hard server-load envelope, fair first-attempt access, and safe treatment of non-idempotent operations.","intervention":"For one authenticated, idempotent RPC class, retain ordinary first-attempt access but require a server-verifiable, nontransferable retry right for every admitted repeat of a logical request. Give each client ownership group a capped rolling ledger: successful first attempts mint a governed fraction of rights, while each retry irreversibly spends a right regardless of its outcome. The client may wait or fail fast at no retry charge, or spend a scarce right on a request whose private value warrants sacrificing a future retry opportunity; it need not report that value to the server. Gateway-issued lineage receipts and stable idempotency keys distinguish repeats, and repositories or service identities under common control share one ledger. A protected bootstrap allowance, logged incident exception, and appeal path cover new, low-volume, and safety-critical clients. Existing circuit breakers remain an overriding load-safety limit. Parameters are exposed to participants and evaluated in replay and shadow mode before any enforcement.","structural_mapping":[{"archetype_element":"Strategic participants","domain_realization":"Autonomous RPC clients observe a timeout or failure and choose whether, when, and how often to retry."},{"archetype_element":"Private incentives or information","domain_realization":"A client knows the deadline, user impact, workflow importance, and retry safety of its logical request; the shared server principally observes traffic and health."},{"archetype_element":"Exploitable rule","domain_realization":"A repeat attempt receives another chance at completion while its marginal congestion cost is shared, so retrying can benefit one client without charging it for displaced work."},{"archetype_element":"Desired outcome specification","domain_realization":"Bound retry amplification and direct the permitted retries toward logical requests with the highest client-known cost of failure, without restricting fair first attempts."},{"archetype_element":"Action and choice set","domain_realization":"After failure, a client can wait, fail fast, spend a retry right, request a logged incident exception, or attempt evasion by changing identities or logical-request identifiers."},{"archetype_element":"Incentive payoff map","domain_realization":"Under the baseline, another retry offers possible success at little local cost. Under the candidate rule, retrying now consumes an option that may be more valuable for a later request."},{"archetype_element":"Information structure and truthfulness condition","domain_realization":"The server does not ask for an unverifiable priority claim. Selection is compatible when a client spends a right only where expected marginal completion value exceeds the right's opportunity cost."},{"archetype_element":"Verification rule","domain_realization":"Authenticated ownership groups, signed attempt-lineage receipts, stable idempotency keys, and method-level telemetry determine whether an attempt is an original, an eligible retry, or suspected relabeling."},{"archetype_element":"Participation and fairness constraints","domain_realization":"First attempts retain a protected fair-share path; bootstrap rights, bounded safety exceptions, transparent ledger rules, and appeals prevent lack of historical successes from becoming an absolute exclusion."},{"archetype_element":"Strategic response test and gaming monitor","domain_realization":"Replay tests identity splitting, dummy-success minting, identifier changes, token hoarding, indiscriminate spending, and collusion, while monitoring completion and denial by client class."}],"mechanism_mapping":[{"mechanism_slug":"self_selection_menu","role":"Creates a free wait-or-fail-fast path and a scarce spend-to-retry path, allowing clients to sort their own requests using private value rather than a costless priority label.","counterfactual_removal":"If retrying and waiting have the same local opportunity cost, a client again has reason to retry every eligible failure, so the rule elicits no selection among requests."},{"mechanism_slug":"deposit_bond_or_stake","role":"Treats each retry right as a nonmonetary stake: spending it on the current attempt irreversibly gives up a future retry option and therefore internalizes part of the shared load cost.","counterfactual_removal":"If rights are not scarce or are refunded merely because a retry was attempted, current retries do not compete with future opportunities and aggressive retrying remains locally attractive."},{"mechanism_slug":"mechanism_design_protocol","role":"Specifies identities, attempt lineage, available actions, mint and spend rules, load constraints, exceptions, and adversarial strategies before selecting a credit rate or enabling enforcement.","counterfactual_removal":"A token limit chosen without modeling relabeling, low-volume clients, or strategic spending could become only another fixed throttle with avoidable loopholes and distributional harm."}],"causal_chain":["A partial service fault causes timeouts while clients retain private knowledge of each logical request's value.","A retry offers a client another chance of success, whereas most congestion cost falls on the shared service and other clients.","With no retry-specific opportunity cost, aggressive retrying can be a locally attractive response.","Combined repeat traffic consumes capacity, can reduce first-attempt success, and can induce still more retries.","Requiring a scarce right changes the payoff: retrying one request reduces the same ownership group's ability to retry a later request.","The client can allocate its rights to requests it values most without making an unverifiable value claim to the server.","Minting rights from successful first attempts and capping stored rights bounds each compliant client's repeat traffic relative to healthy work and limits a pre-outage retry burst.","Attempt-lineage verification, shared ownership ledgers, safety overrides, and appeals constrain evasion and protect legitimate edge cases.","If the assumptions survive testing, the predicted equilibrium has bounded repeat amplification and stronger within-client selection of retries by value."],"baseline":"Client-selected retry counts with exponential backoff and jitter, ordinary per-client rate limits, and server-side circuit breaking or load shedding. Repeats still share admission with originals and carry no scarce, client-specific opportunity cost tied to future retry capability.","nearest_rivals":["Exponential backoff with jitter reduces synchronization and retry frequency but does not force a client to choose which of its failed logical requests deserves a bounded retry opportunity.","A server-side circuit breaker or adaptive load shedder enforces a hard safety boundary but selects using server-visible attributes rather than the client's private request value.","A static per-client retry-count cap bounds attempts but does not contract with first-attempt success or create a rolling tradeoff across the client's concurrent failed requests.","A client-declared priority header communicates value but remains strategically cheap unless its use has a consequence, so it can reproduce priority inflation.","Autoscaling or excess capacity addresses a raw capacity shortage but does not remove the positive feedback from repeats when scaling is delayed, bounded, or itself impaired."],"remaining_contrastive_claim":"Conditional on repeat traffic being a material cause of overload and clients having heterogeneous private losses from failure, a success-minted, spent-on-use retry right adds an intertemporal opportunity cost absent from backoff, static attempt caps, and costless priority headers. The bounded claim is that the spend decision can rank a client's own retries by private value while the mint-and-cap rule bounds that client's compliant retry amplification. It does not assert globally truthful cardinal values, an optimal credit rate, or advantage when original demand alone is the bottleneck.","authority_safety":{"decision_authority":"The RPC platform owner may authorize an offline or shadow study. Any enforced pilot requires joint approval from the service owner, reliability change authority, security or safety owner, and representatives of affected client teams; an individual client team cannot raise its own mint rate or exception class.","authorized_first_step":"Run a deterministic staging replay using synthetic client identities and payload-free request traces. Compute ledgers and hypothetical admission decisions without changing production traffic, client quotas, personnel evaluations, or incident handling.","excluded_actions":["Production enforcement during the first evidence step","Denying or charging for ordinary first attempts","Financial charges, compensation changes, or individual reputation scores","Inspecting request payloads merely to infer business value","Disciplining teams from shadow-ledger results","Silently changing mint rates, ownership groups, or exception eligibility","Applying the mechanism to non-idempotent methods before retry safety is independently established","Removing circuit breakers or emergency bypass authority"],"halt_rollback":"The first step has no production effect and can be stopped by discarding the shadow ledger. Any later pilot must be feature-flagged with an immediate bypass to the prior scheduler. Halt and revert if attempt classification is unreliable, a preregistered critical workload loses required recovery access, new or low-volume clients are systematically excluded, identity evasion defeats the load bound, or appeal volume exceeds the agreed handling capacity."},"negative_tests":{"strongest_counterevidence":"The strongest counterevidence would be a controlled replay showing that original first attempts alone saturate the service and determine recovery, while removing repeats leaves admitted work, completion allocation, and recovery time within a preregistered equivalence margin. That would indicate a capacity, dependency, or server-efficiency problem rather than strategic retry amplification.","problem_falsifier":"For the sampled RPC class, falsify the proposed problem if a lineage-correct trace shows no material repeat amplification during degraded periods, aggressive retry policies do not capture completion capacity from conservative clients, and a no-retry counterfactual is equivalent to the observed recovery within preregistered measurement bounds.","intervention_falsifier":"Falsify the intervention if no mint rate satisfying the same hard load envelope preserves the preregistered critical-retry workload; if changing identifiers, splitting client identities, or generating dummy successes restores unbounded amplification; or if the candidate is equivalent to a static cap on value-stratified completion and fairness while adding greater operational burden.","risks":["Low-volume or newly launched clients may enter an incident with too few rights.","Historical success volume may privilege large clients even when a small client's request is more consequential.","Clients may disguise retries as new logical requests, split identities, or generate cheap successful calls to mint rights.","A client library that cannot rank request value may spend rights indiscriminately or hoard them until useless.","Contracting minting during a fault may overcorrect and deny retries that would have aided recovery.","Retry rights do not make non-idempotent operations safe and could create duplicate side effects if method classification is wrong.","Ledger complexity and opaque parameter changes could reduce trust or slow incident response.","Exception channels may become either a new gaming path or a bottleneck for legitimate emergencies."]},"next_evidence_step":"Pre-register and run one 60-minute deterministic staging experiment for a single authenticated, idempotent RPC method. Use four synthetic clients, a fixed stream of logical requests with preassigned value and safety classes, a healthy warm-up, a bounded partial-failure interval, and recovery. Compare backoff-only, a static retry cap, and the candidate under identical original arrivals and server capacity. Include one adversarial client that changes identifiers, splits identity, and submits dummy successes. Record attempts per logical request, admitted server work, first-attempt access, value-stratified completions, recovery time, credit exhaustion, exception use, and allocation by client. Do not send production calls or use the results for personnel judgments.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"No comparison with prior proposals or experiment cells was performed because runtime isolation forbids inspecting them. This candidate is internally characterized by an automated inter-service congestion externality, success-minted retry rights, and client-side self-selection rather than by a generic reward, ranking, or human-compliance program.","revision_record":{"parent_version":null,"progress_targets_addressed":["Initial complete schema-conforming candidate","Concrete computer-systems problem with observable diagnostic state","Explicit best-response, information, payoff, verification, fairness, and gaming mappings","Serious technical rivals and a bounded contrastive claim","Authority limits, rollback conditions, falsifiers, risks, and a non-production first evidence step"],"conceptual_changes":["Initial formulation treats retry amplification as a strategic externality among autonomous software clients and removes the need for unverifiable server-side value reports through self-selection."],"operational_changes":["Specified authenticated ownership ledgers, success-based minting, spent-on-use rights, idempotency lineage, bootstrap and incident exceptions, circuit-breaker precedence, and feature-flag rollback."],"evidence_changes":["Specified a bounded staging replay that separates original-load saturation from retry amplification and includes adversarial identity and minting strategies."],"claim_changes":["Limited the claim to within-client retry selection and compliant amplification bounds under stated conditions; made no novelty, prevalence, demand, or effect-size claim."]}}