{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp12_substrate_denial72_20260805","research_id":"eoa_inverse_innovation_exp12_light_screen_20260805","cell_id":"incentive_compatible_rule_design__computer_science","search_lanes":{"direct_problem_and_intervention":{"queries":["RPC retry tokens success minted retry rights","distributed systems retry budget token success","\"retry rights\" RPC tokens success minted","\"retry credits\" distributed systems overload"],"source_ids":["SRC1","SRC2","SRC3"],"no_result_note":null},"synonyms_and_historical_terms":{"queries":["retry storm positive feedback overload RPC","cascading failure retries server overload","client retry throttling successful responses tokens"],"source_ids":["SRC1","SRC2","SRC3"],"no_result_note":null},"products_practices_and_standards":{"queries":["AWS SDK retry quota token bucket successful first request","gRPC retry throttling maxTokens tokenRatio","Envoy retry budget circuit breaker"],"source_ids":["SRC2","SRC3","SRC4"],"no_result_note":null},"component_combination":{"queries":["idempotency key authenticated client retry credit ledger","successful first attempts earn retry tokens","RPC retries private request value priority tokens mechanism design","retry budget identity splitting dummy successes"],"source_ids":["SRC2","SRC3"],"no_result_note":"No retained source disclosed the complete combination of server-verifiable ownership-group accounting, stable logical-request lineage, minting limited to successful first attempts, nonrefundable spend on every admitted repeat, and deliberate client-side allocation by private request value."}},"sources":[{"source_id":"SRC1","title":"Addressing Cascading Failures","publisher":"Google Site Reliability Engineering","url":"https://sre.google/sre-book/addressing-cascading-failures/","source_type":"OFFICIAL_GUIDANCE","claims_supported":["Timed-out RPCs can be retried and add still more load to an overloaded server.","Retry volume can grow through positive feedback, reduce first-attempt success, destabilize the service, and persist after original traffic falls.","Established mitigations include randomized exponential backoff, per-request limits, server-wide retry budgets, early rejection, and overload testing."]},{"source_id":"SRC2","title":"Retry","publisher":"gRPC Authors","url":"https://grpc.io/docs/guides/retry/","source_type":"OFFICIAL_GUIDANCE","claims_supported":["gRPC supports per-method retry policy, exponential backoff, retry throttling, and retry observability.","Its retry-throttling design maintains a capped per-server client token count: failed RPCs reduce it, successful RPCs replenish it, and retries pause below a threshold.","This is close success-conditioned retry-capacity prior art, although it is not the proposal's authenticated server ledger or private-value allocation mechanism."]},{"source_id":"SRC3","title":"Retry behavior - AWS SDKs and Tools","publisher":"Amazon Web Services","url":"https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html","source_type":"FIRST_PARTY_PRODUCT","claims_supported":["AWS standard retry mode uses a capped retry-quota token bucket while never blocking or delaying the initial request.","Every retry deducts tokens; a first-attempt success restores one token; and retry success restores the last retry's token cost.","Token depletion suppresses retries and reduces retry traffic during sustained disruption."]},{"source_id":"SRC4","title":"Circuit breaking","publisher":"Envoy Project","url":"https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/circuit_breaking","source_type":"OFFICIAL_GUIDANCE","claims_supported":["Envoy provides network-level circuit-breaking limits and backpressure.","It can bound active retries and recommends retry budgets so retry volume cannot explode into cascading failure.","These load-safety controls are established overriding safeguards but do not implement success-minted ownership ledgers."]}],"problem_evidence":{"status":"SUPPORTED","finding":"The core problem is directly visible: authoritative guidance describes timed-out RPC retries increasing overload, producing positive feedback, reducing useful first-attempt work, and sometimes keeping a backend overloaded after demand declines. The sources establish the retry-amplification problem, though they do not independently demonstrate the proposal's narrower strategic claim that more aggressive clients capture a larger share of completions.","source_ids":["SRC1","SRC3","SRC4"]},"closest_prior_art":[{"name":"AWS SDK retry quota","source_ids":["SRC3"],"overlap":"Initial requests remain unaffected, retry capacity is capped, every retry spends tokens, successful first attempts replenish tokens, and depletion causes fail-fast behavior. This substantially overlaps the success-minted, spent-on-retry core.","remaining_difference":"AWS documents a local SDK quota rather than a gateway-verified ledger shared across authenticated identities under common ownership. It also refunds the last retry's cost when that retry succeeds, whereas the proposal spends every retry right irreversibly and mints only from first-attempt success."},{"name":"gRPC retry throttling","source_ids":["SRC2"],"overlap":"A capped token count is maintained per server, failures reduce it, successful calls replenish it, and low token balance pauses retries while preserving ordinary RPC operation.","remaining_difference":"The documented throttle is automatic client-side resilience control, not a nontransferable server-issued right tied to stable logical-request lineage or an explicit menu through which an application allocates retries according to private request value."},{"name":"Google server-wide retry budget","source_ids":["SRC1"],"overlap":"Retry attempts are treated as a bounded scarce allowance to contain amplification and preserve recovery.","remaining_difference":"The budget is an aggregate rate constraint, not a success-conditioned banked ledger partitioned by authenticated ownership group, and it does not implement private-value self-selection."},{"name":"Envoy retry budgets and retry circuit breaking","source_ids":["SRC4"],"overlap":"Retries are bounded independently from ordinary work by mesh-level admission controls that remain effective during overload.","remaining_difference":"Envoy's mechanism is a concurrency/load guard rather than success-minted, request-lineage-aware credits allocated by each client across its failed logical requests."}],"prior_art_disposition":"SUBSTANTIAL_COLLISION","contrastive_claim_remaining":"Relative to AWS SDK and gRPC success-conditioned retry quotas at the same hard load envelope, a gateway-enforced ledger grouped by authenticated common ownership, minting only from successful first attempts and never refunding an admitted repeat, will resist identity and lineage relabeling and let a value-aware client improve completion of its own higher-private-loss requests without reducing protected first-attempt access.","contrastive_claim_falsifier":"Falsify the remaining contrast if the candidate's admission and value-stratified completion outcomes are equivalent to an AWS-style retry quota or gRPC retry throttle under matched capacity; if clients do not preferentially spend rights on higher-value requests; or if identifier changes, identity splitting, or dummy successful calls defeat the claimed ownership-group load bound.","gates":{"adequate_source_search":{"status":"PASS","rationale":"The bounded search covered direct terminology, retry-storm and cascading-failure language, official SDK and RPC retry-token mechanisms, mesh retry budgets, idempotency and identity combinations, and private-value allocation. Four opened authoritative sources from four publisher identities were retained.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"supported_problem":{"status":"PASS","rationale":"Google's operational account directly describes RPC retry amplification, declining first-attempt usefulness, persistent overload, and cascading failure; AWS and Envoy independently describe suppressing retries to aid recovery.","source_ids":["SRC1","SRC3","SRC4"]},"distinct_testable_claim":{"status":"PASS","rationale":"Although the success-earned retry-token core substantially collides with deployed AWS and gRPC mechanisms, a narrower contrast remains around authenticated ownership aggregation, first-attempt-only minting, nonrefundable repeat spend, lineage verification, evasion resistance, and private-value allocation. Those differences produce measurable comparative outcomes.","source_ids":["SRC2","SRC3"]},"bounded_next_test":{"status":"PASS","rationale":"The proposed 60-minute deterministic staging experiment is limited to one idempotent method, synthetic identities, fixed traces, matched server capacity, and shadow admission. It can compare the candidate directly with backoff, static caps, AWS-style quota behavior, and gRPC-style throttling while testing relabeling and dummy-success attacks.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"no_obvious_safety_or_authority_stop":{"status":"PASS","rationale":"The first test has no production enforcement, payload inspection, personnel consequence, or non-idempotent traffic. It preserves circuit breakers, uses synthetic identities and payload-free traces, and requires broader authority before any later production pilot.","source_ids":["SRC4"]}},"screen_survival":false,"world_novelty_boundary":"This bounded four-source public-web screen finds substantial collision with established success-conditioned retry-token mechanisms and therefore does not pass the specified screen. It cannot establish world novelty, patentability, market size, expert acceptance, realized value, or absence of closer academic, patent, standards, source-code, or historical prior art."}