TASK-SWE-102-01 · Task family
Root-cause isolation vs symptom correlation. Identify the causal component without over-attributing unrelated faults.
Overview. Identify the root-cause component, with the evidence, and rule out the co-occurring symptom.
Errors start after a deployment, and two things look wrong at once: database connection errors and CPU contention in an upstream service. Only one of them is the cause.
The grade is for the minimal set of causal components. Naming every component that alerted, or blaming the most visible symptom, both lose credit.
Value to the buyer
Over-attribution is a common SRE agent failure. Trains agents to name the cause and stop.
Specification. The task family, field by field.
- task_id:
- TASK-SWE-102-01
- domain:
- Site Reliability Engineering
- parent_environment:
- ENV-SWE-102 · IncidentLab
- target_role:
- Site Reliability Engineer
- objective:
- Identify the root-cause component, with the evidence, and rule out the co-occurring symptom.
- starting_context:
- Active alerts, metrics, logs, traces, the service topology and recent deployment and configuration history.
- tools:
get_active_alertsquery_metricssearch_logsinspect_traceget_service_topologyget_deployment_historyinspect_configurationupdate_incident
- required_actions:
- Establish when the symptoms started
- Correlate with deployments and configuration changes
- Use traces to locate where requests wait or fail
- Rule out symptoms that don't explain the failures
- expected_outputs:
- Root-cause component and change
- Evidence
- Symptoms ruled out, with reasons
- interaction:
- Single agent with read-only tools.
- verification:
- The submitted cause is compared with the injected fault. Extra components count against precision.
- reward:
- No credit without the true cause. Credit falls with each component submitted that isn't causal.
- difficulty:
- Calibrated against reference models during acceptance testing
- task_horizon:
- Multi-step investigation. Execution limits are agreed with the buyer.
- delivery:
- Task instances with seeded faults, telemetry, reference diagnoses and verifier code.
- commercial_unit:
- Per validated task instance
Sample prompt. What the agent is asked to do, as a buyer would see it.
The orders API has elevated latency and intermittent failures since deployment v3.8.0 at 09:20 UTC. Monitoring shows database connection errors, and also high CPU in the upstream inventory service. Investigate with the monitoring and deployment tools, identify the root cause, and record your evidence. Don't make changes.
Verification criteria. What the verifier checks, and how.
Root cause
v3.8.0 lowered the orders API's database pool maximum from 40 to 10.
Trace evidence
Traces show requests waiting for a database connection inside the orders API, not on inventory calls.
Symptom ruled out
Inventory CPU comes from a scheduled batch job that also ran, without errors, the day before.
Precision
Inventory isn't submitted as a contributing cause.
No changes
Nothing is restarted or rolled back during the investigation.
Key failure modes. Where agents go wrong on this task.
- Blaming the inventory service because its CPU alert is the loudest
- Submitting both services to be safe
- Restarting services to see what changes
Other task families. The rest of IncidentLab, on the same EngineeringWorld state.
- TASK-SWE-102-02
Safe remediation & rollback
Select an authorized fix and verify that service is restored.
Site Reliability Engineer
- TASK-SWE-102-03
Multi-service incident investigation
Diagnose cascading failures, dependency interactions and misleading telemetry.
Production Engineer
- TASK-SWE-102-04
Recovery validation & incident handoff
Decide when recovery is complete, document residual risk and escalate appropriately.
Incident Commander