{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","cell_id":"progressive_disclosure__computer_science","arm":"BREADTH_PROBE_ONE_SHOT","candidate_id":"progressive_disclosure__computer_science__P1","proposal_index":1,"version":0,"title":"Failure-State Evidence Ladder for Continuous-Integration Runs","problem":"When a continuous-integration run fails, developers and release engineers often encounter one chronological stream containing setup chatter, compiler output, test traces, infrastructure messages, retries, and cleanup events. The evidence needed to distinguish a code defect from a dependency, configuration, or runner failure is present but arrives as an undifferentiated volume before the investigator has identified the failed stage or formed a diagnostic question.","actors":["Developer investigating a failed run","Release engineer responsible for pipeline reliability","Repository maintainer deciding whether a change may merge","Security or compliance reviewer requiring the complete execution record"],"observable_state":"A failed run produces a long multi-stage log; investigators repeatedly search, scroll, expand arbitrary folded groups, or rerun the job while the first causal error, downstream noise, environment changes, and raw evidence remain mixed together. Different investigators need different depth: a contributor may need the failing command and local context, while a pipeline maintainer may need runner metadata and cross-stage dependencies.","consequence":"Investigators can mistake downstream symptoms for the initiating failure, repeat an unchanged run, apply an irrelevant code change, or abandon self-service diagnosis. A concise summary alone can create a separate risk by hiding evidence needed to challenge its classification or audit the run.","affected_objective":"Support accurate, inspectable diagnosis of failed continuous-integration runs while limiting premature exposure to irrelevant log detail and preserving the complete execution record.","intervention":"Add a read-only failure console that reorganizes an immutable run record into a state-triggered evidence ladder. Its first layer shows the failed stage, earliest failure candidate, affected command, and one bounded next diagnostic action. Selecting a diagnostic branch such as code/test, dependency, configuration, infrastructure, or unknown reveals branch-specific evidence and just-in-time interpretation; uncertainty, conflicting signals, or user request exposes successively wider temporal context, environment changes, dependency relations, and raw logs. Breadcrumbs retain the stage, branch, and evidence scope, while a persistent full-log escape hatch and point-of-decision warnings prevent the layered view from becoming concealment.","structural_mapping":[{"archetype_element":"Current need","domain_realization":"The investigator's present diagnostic question: locate the initiating failure, test a suspected failure class, or inspect underlying execution evidence."},{"archetype_element":"Information Layer","domain_realization":"Layers progress from failure synopsis to command context, diagnostic-branch evidence, cross-stage/environment evidence, and the immutable raw run record."},{"archetype_element":"Reveal Trigger","domain_realization":"A layer opens when the investigator selects a hypothesis, requests more context, encounters contradictory evidence, crosses a risk condition, or changes diagnostic stage."},{"archetype_element":"Task Stage","domain_realization":"Triage, hypothesis testing, remediation planning, and audit each receive different default evidence."},{"archetype_element":"Drilldown Path","domain_realization":"Run to failed stage to command to surrounding events to dependency or environment evidence to raw log offsets."},{"archetype_element":"Orientation Cue","domain_realization":"A breadcrumb records run, stage, diagnostic branch, evidence depth, active filters, and the raw-log offsets represented by the current view."},{"archetype_element":"Critical Detail Exception","domain_realization":"Evidence of secret exposure, permission failure, artifact-integrity failure, nondeterministic reruns, or ambiguous causality bypasses ordinary staging and is visible before any remediation suggestion."},{"archetype_element":"Full Access Escape Hatch","domain_realization":"Every layer links to the unmodified complete log, downloadable run metadata, and an expand-all evidence view."},{"archetype_element":"Progressive Validation Prompt","domain_realization":"Before accepting a diagnosis, the console asks the investigator to inspect the evidence that would distinguish the selected hypothesis from its closest competing failure class."}],"mechanism_mapping":[{"mechanism_slug":"summary_detail_view","role":"Presents a compact failure synopsis paired with a selectable evidence pane whose contents remain traceable to raw log locations.","counterfactual_removal":"Without the summary-detail relation, investigators either return to the flat log immediately or receive a synopsis that cannot be checked against its evidence."},{"mechanism_slug":"just_in_time_help","role":"Explains unfamiliar exit codes, stage transitions, or evidence fields only when the corresponding diagnostic branch is opened.","counterfactual_removal":"Without contextual help, novice investigators must leave the run to interpret evidence, while permanent explanations would recreate first-layer overload."},{"mechanism_slug":"tiered_decision_support","role":"Separates an initial failure classification from supporting signals, competing explanations, uncertainty, and the full record.","counterfactual_removal":"Without tiers, the console becomes either an opaque diagnosis or another exhaustive log presentation rather than staged, contestable support."}],"causal_chain":["A failed run is parsed into stages, commands, temporal events, environment changes, and stable references to raw log offsets.","The console presents the smallest layer that identifies the failure boundary and supports one safe diagnostic action.","The investigator's selected hypothesis or the system's uncertainty state triggers only the evidence relevant to discriminating among plausible failure classes.","Orientation cues preserve the relationship between each extracted item, its parent stage, and its raw source location.","Critical risk or ambiguity signals override ordinary concealment and surface before the investigator acts on a suggested remediation.","The investigator can test a diagnosis without scanning unrelated output, then drill into wider context or the complete immutable record when the diagnosis remains uncertain or requires audit.","A diagnosis accepted after contrastive inspection is less dependent on whichever log line happened to attract attention first, while underlying depth remains available."],"baseline":"The baseline is the existing chronological CI log with ordinary text search, timestamps, and manually folded job sections. It preserves evidence but makes the investigator determine relevance and causal boundaries while scanning the same flat presentation.","nearest_rivals":["Static folding of setup, build, test, and cleanup sections, which groups output but does not change disclosure according to the active diagnostic question or conflicting evidence.","Log search and severity filters, which remove or highlight matching lines but do not maintain a staged path from failure synopsis to hypothesis-specific evidence and raw context.","A generated failure summary, which compresses the run but may not expose competing explanations, explicit reveal triggers, or source-linked drilldown.","A fixed troubleshooting checklist, which sequences generic questions but is not bound to the actual run state and evidence locations."],"remaining_contrastive_claim":"The candidate's distinguishing claim is that CI evidence should be disclosed according to the investigator's changing diagnostic state and the run's risk or ambiguity signals, with source-linked orientation and mandatory escalation to conflicting evidence. If it merely folds log sections, filters text, or substitutes a summary for the record, it does not instantiate the proposed causal structure.","authority_safety":{"decision_authority":"Repository maintainers retain authority over merge, rerun, rollback, and pipeline changes; investigators retain authority to accept or reject a proposed diagnosis; security personnel retain authority over credential or artifact-integrity incidents. The console has presentation authority only over a copied run record.","authorized_first_step":"Construct a read-only prototype against a small, access-controlled set of sanitized historical run records and use it only in simulated diagnosis tasks.","excluded_actions":["Approving or blocking a merge","Rerunning, canceling, or modifying a pipeline","Editing source code, tests, dependencies, secrets, or runner configuration","Suppressing, deleting, or rewriting raw logs","Automatically applying a remediation","Sending run data to an external service"],"halt_rollback":"Stop the prototype session if any displayed item cannot be traced to the immutable record, a critical warning is absent from the first affected decision point, sensitive data appears in a derived layer, or the layered view changes the underlying run. Roll back by disabling the derived console and retaining the original log interface and records unchanged."},"negative_tests":{"strongest_counterevidence":"In realistic failure investigations, participants using the evidence ladder reach the same wrong initiating cause more often than participants using the chronological log because the first layer anchors them on an incorrect failure candidate or conceals disconfirming context.","problem_falsifier":"The proposed problem is weakened if investigators can reliably identify the initiating failure and locate necessary supporting evidence from the baseline without substantial scanning, repeated searching, arbitrary expansion, or confusion between initiating and downstream errors.","intervention_falsifier":"The intervention is falsified if state-triggered layers do not improve correct evidence retrieval relative to static folding, or if investigators cannot find the complete record, overlook surfaced exceptions, lose their place across layers, or treat the first-layer classification as authoritative despite visible uncertainty.","risks":["Anchoring investigators on an incorrectly selected earliest-failure candidate","Parser errors that detach extracted evidence from its true temporal or stage context","Hidden contradictory lines producing false confidence","Sensitive values becoming more visible when extracted from otherwise noisy logs","Experts being slowed by forced staging or excessive validation prompts","Stale mappings after pipeline-format changes","A false appearance of causal diagnosis when the console has only reorganized correlations","Added interface complexity during an incident"]},"next_evidence_step":"Using only sanitized historical records, select a bounded set of failed runs with independently adjudicated initiating causes and at least two plausible failure classes. Build a non-operational clickable console for those records, then run a small within-record comparison against the chronological-log baseline. Record whether investigators identify the adjudicated cause, retrieve the decisive raw evidence, notice seeded critical warnings and conflicting signals, use the full-log escape hatch, and preserve orientation after drilldown. Do not deploy or infer an effect size; use observed failure modes only to decide whether the disclosure logic merits further testing.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"No other proposals or experiment candidates were inspected under runtime isolation, so diversity from prior proposals was not assessed.","revision_record":{"parent_version":null,"progress_targets_addressed":[],"conceptual_changes":[],"operational_changes":[],"evidence_changes":[],"claim_changes":[]}}