{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","cell_id":"versioning_and_quality_discrimination__computer_science","arm":"BREADTH_PROBE_ONE_SHOT","candidate_id":"versioning_and_quality_discrimination__computer_science__P1","proposal_index":1,"version":0,"title":"Latency-Tiered Counterexample Reduction for Hosted Fuzzing","problem":"A hosted fuzzing service receives crashing inputs that must be minimized, reproduced in a clean environment, and packaged for developer triage. Its potential customers differ in how much they value turnaround time, parallel capacity, integration, and human assistance: a volunteer maintainer may accept overnight processing, while a team facing a blocked release may value immediate reduction and guided triage. The service cannot reliably infer urgency or willingness to pay from project identity. One uniform offer therefore forces the operator to choose between a price and service level inaccessible to low-budget projects or a broadly affordable offer that does not distinguish urgent, capacity-intensive work.","actors":["Hosted fuzzing service operator","Volunteer and small-team software maintainers","Release-critical engineering teams","Security or reliability teams responding to production incidents","Service security and fairness reviewer"],"observable_state":"One queue mixes ordinary and release-critical counterexample-reduction jobs; customers request informal prioritization, some defer submitting large crash corpora, and the operator cannot tell from a project name whether fast turnaround, concurrency, retention, integrations, or expert assistance is valuable enough to justify higher payment.","consequence":"Uniform packaging can exclude price-sensitive maintainers, leave urgent teams without a purchasable fast path, and cause ad hoc queue exceptions that make capacity planning and access decisions difficult to inspect.","affected_objective":"Provide an affordable path to correct, reproducible counterexample reduction while funding bounded low-latency capacity and making prioritization rules legible.","intervention":"Offer a transparent three-version menu for the same hosted counterexample-reduction service. Batch provides a usable low-price version with validated reproduction, deterministic minimization, standard reports, one concurrent job, short report retention, and an overnight processing target. Release provides more concurrency, CI integration, longer retention, and a shorter queue target at a higher price. Incident provides reserved capacity, the shortest queue target, and bounded human triage assistance at the highest price. All versions retain the same crash-isolation, report-integrity, confidentiality, accessibility, and minimum reproducibility requirements. Customers select versions per billing period or job bundle; project identity does not determine eligibility. Account-scoped concurrency, nontransferable reserved-capacity tokens, and explicit support boundaries prevent low-tier purchases from being converted into premium throughput, while immediate upgrades and end-of-period downgrades limit lock-in.","structural_mapping":[{"archetype_element":"Segment Value Hypothesis","domain_realization":"Customers are hypothesized to differ primarily in the value they place on counterexample turnaround time, parallel corpus processing, automated CI handoff, report retention, and expert triage—not in their entitlement to a correct result."},{"archetype_element":"Version Dimension Selection","domain_realization":"Queue target, concurrency, retention, integration, and human assistance vary across versions; reproduction correctness, confidentiality, and report integrity do not."},{"archetype_element":"Minimum Viable Base Quality","domain_realization":"The Batch version must still isolate the crash, minimize the triggering input, verify the minimized reproducer in a clean environment, and produce an exportable report."},{"archetype_element":"Quality Ladder Boundary","domain_realization":"Batch, Release, and Incident are ordered by latency assurance, capacity, automation, and assistance, with each boundary stated in measurable operational terms."},{"archetype_element":"Price-Tier Mapping","domain_realization":"Higher prices correspond to reserved compute, lower queue targets, additional concurrency, integrations, retention, and human service intensity; exact prices remain a test parameter."},{"archetype_element":"Self-Selection Menu","domain_realization":"Customers reveal how much they value urgency and service intensity by choosing a version instead of being classified by organization size, sector, or project identity."},{"archetype_element":"Arbitrage Guardrail","domain_realization":"Per-account concurrency, nontransferable reserved-capacity tokens, and bounded support scopes prevent aggregation or sharing of Batch access from reproducing Release or Incident service."},{"archetype_element":"Upgrade/Downgrade Path","domain_realization":"A queued job can be upgraded without resubmission, while downgrade is available after reserved capacity or an active assistance session ends."},{"archetype_element":"Tier Performance Dashboard","domain_realization":"The operator separately observes queue-target attainment, completion quality, upgrades, downgrades, abandoned submissions, complaints, and attempted boundary circumvention for each version."},{"archetype_element":"Fairness and Access Review","domain_realization":"Review checks whether the Batch delay or restrictions systematically prevent maintainers from resolving security-relevant defects and whether any essential diagnostic capability has migrated into paid versions."}],"mechanism_mapping":[{"mechanism_slug":"good_better_best_tier_menu","role":"Makes Batch, Release, and Incident an ordinal, legible set of service versions through which customers can self-select.","counterfactual_removal":"Without the ordered menu, customers must negotiate exceptions or interpret an unstructured collection of add-ons, so choice no longer cleanly reveals their valuation of urgency and assistance."},{"mechanism_slug":"service_level_tier_schedule","role":"Uses measurable queue targets, reserved capacity, concurrency, and support intensity as the principal quality separators.","counterfactual_removal":"If service levels are identical, the versions differ mainly in labels or price and cannot induce self-selection based on operational need."},{"mechanism_slug":"feature_gating_and_usage_limits","role":"Enforces non-safety-related boundaries for concurrency, retention, integrations, and human assistance while preserving the base correctness floor.","counterfactual_removal":"If every account can consume premium concurrency and assistance through the Batch version, the capacity distinction collapses and urgent service cannot be reserved."}],"causal_chain":["Customers have hidden, heterogeneous valuations of turnaround time, capacity, integration, and expert assistance.","The operator exposes those attributes as transparent, enforceable service versions while holding correctness and safety requirements constant.","Customers choose versions according to their own tradeoff between price and operational urgency rather than being assigned by identity.","Version choice supplies information about which service attributes customers value and reserves costly low-latency resources for customers selecting them.","Account and capacity guardrails keep lower versions from delivering the full reserved-capacity value of higher versions.","A usable Batch floor preserves a lower-cost access path, while upgrade, downgrade, performance, and fairness signals reveal miscalibrated boundaries."],"baseline":"A single subscription or per-job price provides the same best-effort queue, concurrency, retention, integrations, and support to everyone, with urgent cases handled through informal operator discretion.","nearest_rivals":["Uniform metered compute pricing: charges for consumed CPU or storage but does not create differentiated latency, capacity, integration, or support versions.","A paid priority surcharge on an otherwise identical job: changes queue position alone rather than offering a coherent bundle of differentiated service attributes.","Severity-based triage: the operator assigns priority from estimated defect risk or vulnerability rather than allowing willingness-to-pay self-selection.","Organization-size discounts or negotiated enterprise contracts: classify buyers directly instead of screening preferences through a common transparent menu.","Separate add-on pricing for every feature: permits customization but may not create an ordinal, legible, incentive-compatible version ladder."],"remaining_contrastive_claim":"The candidate's distinguishing claim is that a common, identity-neutral menu combining latency assurance, reserved capacity, integration, retention, and bounded human assistance can elicit customers' valuation of counterexample-triage urgency while preserving identical correctness and confidentiality floors; it is not merely metered compute, a queue-position fee, or need-based defect prioritization.","authority_safety":{"decision_authority":"The hosted fuzzing service owner may define a reversible packaging pilot; the security and privacy owner must approve the invariant base-quality floor, data handling, and guardrails before customer exposure.","authorized_first_step":"Conduct an offline, nonbinding menu test using a bounded sample of previously completed jobs and consenting prospective users: estimate the resources each draft version would have reserved, present the draft menu without charging or changing queue order, and record comprehension and hypothetical selection.","excluded_actions":["Degrading reproducer validity, crash isolation, confidentiality, accessibility, or report integrity in any version","Inferring or assigning a version from customer identity, organization, repository contents, or suspected budget","Changing live queue priority or billing during the first evidence step","Withholding disclosure of version limits or representing queue targets as guarantees before capacity validation","Selling reserved capacity that has not been operationally provisioned"],"halt_rollback":"Halt the test if participants cannot accurately distinguish the versions, the Batch version fails the stated reproduction floor in replay, modeled premium reservations would impair Batch processing beyond its disclosed target, or reviewers identify an essential security capability behind a paywall. Rollback consists of discarding the draft menu and retaining the uniform service without modifying accounts, jobs, or prices."},"negative_tests":{"strongest_counterevidence":"Historical job replays and user interviews show little separation in valuation of latency, concurrency, integrations, retention, or assistance: users consistently choose the cheapest complete reproducer service even when facing release-critical scenarios, and higher versions primarily attract confusion rather than distinct operational needs.","problem_falsifier":"The problem is falsified if the uniform service already meets a sustainable, accessible operating target without informal prioritization, deferred submissions, capacity conflict, or materially different customer requirements for urgency and assistance.","intervention_falsifier":"The intervention is falsified if no transparent price-quality boundaries yield distinct, comprehensible selections while maintaining the Batch quality floor and feasible capacity, or if preventing tier collapse requires intrusive identity checks or restrictions that materially impair legitimate use.","risks":["The operator may intentionally slow Batch work beyond what capacity constraints require, turning differentiation into artificial degradation.","Teams with limited budgets may delay remediation of important defects because fast processing is priced above their reach.","Queue targets may be mistaken for correctness guarantees or exploited through strategic job splitting.","Account guardrails may impede legitimate collaboration across open-source projects.","Human-assisted Incident service may consume unpredictable expert capacity and degrade all tiers.","Observed version choices may reflect confusing framing or temporary budget constraints rather than stable valuation differences.","Neutral-looking tiers may disproportionately burden maintainers of widely used but underfunded software."]},"next_evidence_step":"Over two weeks, replay at most 60 previously completed reduction jobs through a capacity model for the three draft versions and run nonbinding menu interviews with at most 15 consenting users representing volunteer, routine commercial, and release-critical workflows. Measure version-description comprehension, hypothetical selections across standardized scenarios, modeled queue-target feasibility, preservation of the Batch reproduction floor, and guardrail burden. Do not charge users, change live service, or generalize beyond this bounded sample.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"Not assessed against other proposals because runtime isolation prohibits inspecting them; this candidate is internally defined around hosted fuzzing counterexample reduction and service-level self-selection.","revision_record":{"parent_version":null,"progress_targets_addressed":["Initial one-shot candidate generation from the supplied archetype and domain card"],"conceptual_changes":[],"operational_changes":[],"evidence_changes":[],"claim_changes":[]}}