← Benchmark deep diveAll leaderboards

DevOpsBench-100 · agent evaluation

The work behind the score

Inspect a task.

Original instructions, observed actions, and the verdict for each attempt.

Fail

gpt-6-astra · 533.9s · 100 recorded actions

Original task

Payments error rate breaching the 1% SLO. Payments error_rate_pct is 4.2% against a 1.0% SLO (alarm 9601). Determine which current mechanism actually explains the degradation, choose the smallest supported production repair, and verify that the customer-facing objective recovers. The practical blast radius covers authorization, settlement, retry safety, and duplicate-charge prevention. Protect unrelated production state, handle the material dependency or migration constraint, and verify the result rather than trusting the change record. Operations needs one go-or-no-go call for the change and the 2026-03-07 cutover of payments. Make the go-or-no-go call against the real change window and team availability; state the supported date, the cost of acceleration, and any exception that remains unapproved.

Grading criteria & verdicts

Executable checksFail

Recorded benchmark evaluator · devopsbench-100:3.2.7:original-verifier

Task-specific criteria
correctness.config_deployed_to_production: production payments must run with notifications_retry_max_attempts=3 (merged AND deployed)Not met
correctness.ci_all_stages_green: satisfiedMet
correctness.metric_within_slo: payments error_rate_pct must be within its 1.0 SLONot met
correctness.alarm_resolved: alarm 9601 must be resolvedNot met
deployment.ack_before_resolve: runbook order: acknowledge alarm 9601 before resolving itNot met
deployment.staging_first: satisfiedMet
deployment.canary_then_promote: payments is tier 1: canary at <=25%, assess, then promote_canaryNot met
deployment.no_alarming_deploys: satisfiedMet
quality.pr_linked_to_ticket: satisfiedMet
quality.ticket_closed: ticket ENG-2101 must be closed (status done)Not met
quality.closed_after_the_work: close ENG-2101 only once the work is actually done, not beforeNot met
quality.pr_has_description: satisfiedMet
quality.jira_twin_resolved: ENG-2101 is also tracked in Jira; close it there with a resolution, not just a statusNot met
correctness.no_unrelated_config_mutation: satisfiedMet
correctness.scoped_change_no_fabricated_data: satisfiedMet
correctness.world_invariants_intact: satisfiedMet
quality.no_new_hardcoded_secrets: satisfiedMet
quality.no_unproductive_ci_loops: satisfiedMet
correctness.v4_case_identity_resolved: resolve DOB-049 through its immutable Jira key, linked GitHub issue, and cross-tracker relationshipNot met
correctness.v4_authority_reconciled: compare current control OPS-CONTROL-2026.03 with retired control OPS-CONTROL-2025.11 before actingNot met
correctness.v4_live_state_correlated: correlate the task-specific payments provider state instead of relying on files or tracker text aloneNot met
correctness.v4_material_evidence_complete: complete all 20 materially causal evidence joins inside the larger reference investigation before changing stateNot met
correctness.v5_answer_business_need_date: Preserved 2026-03-07 from the published status-page cutover notice as the control date; did not infer urgency from the ticket title.Not met
correctness.v5_answer_replicas_per_zone: Read 3 healthy replicas per production zone from the DOB-049 change-readiness standard.Not met
correctness.v5_answer_production_zones: Read 3 production zones from the PagerDuty scale record for PD-DOB-049.Not met
correctness.v5_answer_required_replicas: Derived 3 per zone x 3 zones = 9 replicas required before the payments cutover.Not met
correctness.v5_answer_observed_replicas: Read 10 replicas in the payments production pool from the PagerDuty scale record.Not met
correctness.v5_answer_reserved_replicas: Excluded 2 replicas reserved for the catalog freeze in Linear CAP-49.Not met
correctness.v5_answer_usable_replicas: Calculated 10 observed - 2 reserved = 8 usable replicas.Not met
correctness.v5_answer_replica_gap: Calculated 9 required - 8 usable = 1 replicas uncovered.Not met
correctness.v5_answer_quantity_unit: Kept every capacity quantity in replicas.Not met
correctness.v5_answer_standard_capacity_date: Read 2026-03-06 as CloudCap's independently confirmed standard delivery date from vendor order VEND-49.Not met
correctness.v5_answer_expedited_capacity_date: Read 2026-03-04 as CloudCap's independently confirmed expedited delivery date (USD 600) from vendor order VEND-49.Not met
correctness.v5_answer_capacity_request_replicas: Bound the vendor request to the 1 uncovered replicas rather than the full 9-replica requirement.Not met
correctness.v5_answer_next_change_window: Read the payments change calendar (2026-03-05, 2026-03-07, 2026-03-09, 2026-03-11) from the current operating control and identified 2026-03-05 as the next window.Not met
correctness.v5_capacity_evidence_complete: read the readiness standard, CloudCap order VEND-49, change approval CHG-49, the Linear reservation and the status-page cutover notice before changing stateNot met
correctness.v4_supported_path_selected: derive and execute the task-supported branch rather than the stale-note or broad-workaround alternativesNot met
correctness.v5_capacity_plan_recorded: record the DOB-049 capacity plan once as the JSON reconciliation answer to DOB-049-capacity-planNot met
correctness.v5_answer_standard_plan_completion: Calculated standard_capacity_plan outcome as 2026-03-07: the first change window on or after standard delivery.Not met
correctness.v5_answer_expedited_plan_completion: Calculated expedite_capacity outcome as 2026-03-05: the first change window on or after expedited delivery.Not met
correctness.v5_answer_reserved_release_completion: Calculated release_reserved_capacity outcome as 2026-03-03 and kept its separate-approval condition.Not met
correctness.v5_answer_recommended_option: Compared the date, cost and authority of standard_capacity_plan, expedite_capacity and release_reserved_capacity; selected standard_capacity_plan as the best currently authorised plan under the readiness standard.Not met
correctness.v5_answer_recommended_outcome_date: Calculated 2026-03-07 as the supported outcome date for standard_capacity_plan.Not met
correctness.v5_answer_recommended_incremental_cost_usd: Applied USD 0 as the documented incremental cost of standard_capacity_plan.Not met
correctness.v5_answer_escalation_approval_required: Recognised that release_reserved_capacity remains outside current authority and needs incident-commander approval beyond CHG-49.Not met
correctness.v5_answer_approval_reference: Applied change approval CHG-49 only to the authorised standard_capacity_plan scope.Not met
correctness.v5_answer_outcome_vs_control_days: Compared 2026-03-07 with the independent control date 2026-03-07 and calculated a signed variance of +0 day(s).Not met
correctness.v5_answer_decision_timing_status: Reported ON_TIME; did not relabel a controlled but late result as on time.Not met
correctness.v5_approval_applied_to_selected_scope: apply CHG-49 to standard_capacity_plan only and keep release_reserved_capacity outside current authorityNot met
correctness.v4_source_mutations_completed: complete each task-required state-changing capability at least once successfullyNot met
deployment.v4_state_readbacks_complete: reopen the persisted provider and tracker state after the final source mutation instead of trusting acknowledgementsNot met
deployment.v4_source_work_precedes_readback: perform provider readback only after the task-specific operational state changeNot met
deployment.v4_handoff_read_back: reopen the exact case-room conversation after posting the completion handoffNot met
deployment.v4_evidence_before_state_change: establish every material fact before the first successful task state transitionNot met
deployment.v5_decision_evidence_precedes_record: derive the capacity plan only after every source fact it depends on has been read successfullyNot met
deployment.v5_record_precedes_handoff: record the capacity plan before stating it in the completion handoffNot met
correctness.v4_completion_handoff_exactly_once: write exactly one scoped completion handoff for DOB-049Not met
correctness.v5_handoff_is_natural_completion: write a natural scoped completion note, not a keyword list or serialized benchmark objectNot met
correctness.v5_handoff_states_selected_option: state the selected option (standard_capacity_plan) in the scoped completion handoffNot met
correctness.v5_handoff_states_outcome_date: state the outcome date (2026-03-07) in the scoped completion handoffNot met
correctness.v5_handoff_states_approval_reference: state the approval reference (CHG-49) in the scoped completion handoffNot met
correctness.v5_handoff_states_timing_status: state the timing status (ON_TIME) in the scoped completion handoffNot met
correctness.v5_handoff_states_binding_constraint: state the binding constraint (CloudCap standard capacity on 2026-03-06) in the scoped completion handoffNot met
deployment.v4_no_rejected_mutations: complete without a rejected state-changing call; failed exploratory reads remain recoverableNot met
deployment.v4_readback_precedes_handoff: post the completion handoff only after the changed provider state has been reopenedNot met

passed=0.0; pass threshold=1.0 assertion: 5 verifier(s) failed (PC score=0.55): correctness/config_deployed_to_production - production payments must run with notifications_retry_max_attempts=3 (merged AND deployed); correctness/metric_within_slo - payments error_rate_pct must be within its 1.0 SLO; correctness/alarm_resolved - alarm 9601 must be resolved; deployment/ack_before_resolve - runbook order: acknowledge alarm 9601 before resolving it; deployment/canary_then_promote - payments is tier 1: canary at <=25%, assess, then promote_canary | quality also flagged: quality/ticket_closed, quality/closed_after_the_work, quality/jira_twin_resolved Partial native reward: 0.153. The recorded native verdict determines task success.