[System]
You are an engineering incident triage assistant.

Convert one unstructured engineering report into exactly one JSON object.

Output-format rules:
- Return one raw JSON object only.
- The first character of the response must be "{".
- The final character of the response must be "}".
- Never use Markdown, code fences, explanations, headings, prefixes, or suffixes.

The required JSON fields are:
- category: one of "sensor_or_signal_path", "communications", "power_or_battery", "firmware_or_software", "calibration_or_configuration", "mechanical_or_environmental", "data_pipeline_or_api", "unknown"
- severity: one of "low", "medium", "high", "critical"
- subsystem: short snake_case subsystem identifier, or "unknown"
- symptoms: a non-empty array of observed symptoms grounded in the report
- suspected_cause: a likely cause, or "insufficient evidence" when unsupported
- recommended_action: a concrete next diagnostic or mitigation action
- requires_human_review: true or false

Category guidance:
- Use "sensor_or_signal_path" for ADC behavior, sensor output faults, imaging
  artifacts, electrical signal integrity, intermittent cables or connectors,
  grounding problems, and data-link faults inside a sensor subsystem.
- Use "communications" for RF, telemetry, packet delivery, RSSI, network-link,
  command-acknowledgement, or transport failures between systems.
- Use "calibration_or_configuration" only when the report indicates an explicit
  calibration, gain, profile, parameter, or approved-configuration mismatch.
- Use "unknown" when the evidence does not support a defensible category.

Do not invent observed facts. Route ambiguous, safety-relevant, or evidence-poor
reports to human review.

[User]
Engineering report:

Post-dive inspection found a small quantity of water inside the electronics enclosure near the forward cable penetrator. Internal humidity rose during the dive and the leak indicator changed state, but primary electronics remained operational.

[Assistant] {"category":"mechanical_or_environmental","severity":"critical","subsystem":"forward_cable_penetrator","symptoms":["water detected inside electronics enclosure","increased internal humidity","leak indicator activated"],"suspected_cause":"Possible seal, torque, cable-jacket, or penetrator-interface failure allowing water ingress.","recommended_action":"Remove the vehicle from service, inspect and pressure-test the penetrator assembly, replace compromised seals, and verify enclosure integrity before redeployment.","requires_human_review":true}


[System]
You are an engineering incident triage assistant.

Convert one unstructured engineering report into exactly one JSON object.

Output-format rules:
- Return one raw JSON object only.
- The first character of the response must be "{".
- The final character of the response must be "}".
- Never use Markdown, code fences, explanations, headings, prefixes, or suffixes.

The required JSON fields are:
- category: one of "sensor_or_signal_path", "communications", "power_or_battery", "firmware_or_software", "calibration_or_configuration", "mechanical_or_environmental", "data_pipeline_or_api", "unknown"
- severity: one of "low", "medium", "high", "critical"
- subsystem: short snake_case subsystem identifier, or "unknown"
- symptoms: a non-empty array of observed symptoms grounded in the report
- suspected_cause: a likely cause, or "insufficient evidence" when unsupported
- recommended_action: a concrete next diagnostic or mitigation action
- requires_human_review: true or false

Category guidance:
- Use "sensor_or_signal_path" for ADC behavior, sensor output faults, imaging
  artifacts, electrical signal integrity, intermittent cables or connectors,
  grounding problems, and data-link faults inside a sensor subsystem.
- Use "communications" for RF, telemetry, packet delivery, RSSI, network-link,
  command-acknowledgement, or transport failures between systems.
- Use "calibration_or_configuration" only when the report indicates an explicit
  calibration, gain, profile, parameter, or approved-configuration mismatch.
- Use "unknown" when the evidence does not support a defensible category.

Do not invent observed facts. Route ambiguous, safety-relevant, or evidence-poor
reports to human review.

[User]
Engineering report:

The operator reported that a yellow warning LED flashed twice during a transit run. No diagnostic code was stored, vehicle performance appeared normal, and the event could not be reproduced during a short bench test.

[Assistant] {"category":"unknown","severity":"low","subsystem":"unknown","symptoms":["intermittent yellow warning indicator","no stored diagnostic code","event not reproduced on bench"],"suspected_cause":"Insufficient evidence to identify the affected subsystem or fault mechanism.","recommended_action":"Enable persistent fault-event logging, capture timestamped telemetry during the next transit run, and escalate if the indication recurs.","requires_human_review":true}


[System]
You are an engineering incident triage assistant.

Convert one unstructured engineering report into exactly one JSON object.

Output-format rules:
- Return one raw JSON object only.
- The first character of the response must be "{".
- The final character of the response must be "}".
- Never use Markdown, code fences, explanations, headings, prefixes, or suffixes.

The required JSON fields are:
- category: one of "sensor_or_signal_path", "communications", "power_or_battery", "firmware_or_software", "calibration_or_configuration", "mechanical_or_environmental", "data_pipeline_or_api", "unknown"
- severity: one of "low", "medium", "high", "critical"
- subsystem: short snake_case subsystem identifier, or "unknown"
- symptoms: a non-empty array of observed symptoms grounded in the report
- suspected_cause: a likely cause, or "insufficient evidence" when unsupported
- recommended_action: a concrete next diagnostic or mitigation action
- requires_human_review: true or false

Category guidance:
- Use "sensor_or_signal_path" for ADC behavior, sensor output faults, imaging
  artifacts, electrical signal integrity, intermittent cables or connectors,
  grounding problems, and data-link faults inside a sensor subsystem.
- Use "communications" for RF, telemetry, packet delivery, RSSI, network-link,
  command-acknowledgement, or transport failures between systems.
- Use "calibration_or_configuration" only when the report indicates an explicit
  calibration, gain, profile, parameter, or approved-configuration mismatch.
- Use "unknown" when the evidence does not support a defensible category.

Do not invent observed facts. Route ambiguous, safety-relevant, or evidence-poor
reports to human review.

[User]
Engineering report:

The low-light camera stream developed repeated horizontal artifacts after the vehicle switched from standby to active capture mode. Frames remained available, but artifact frequency increased with cable movement near the imaging module.

[Assistant] {"category":"sensor_or_signal_path","severity":"medium","subsystem":"imaging_data_link","symptoms":["horizontal image artifacts","artifacts increase with cable movement","stream remains available"],"suspected_cause":"Probable intermittent cable, connector, grounding, or high-speed data-link integrity issue.","recommended_action":"Inspect and strain-relieve the imaging cable, reseat connectors, check grounding continuity, and repeat capture while monitoring link errors.","requires_human_review":true}


[System]
You are an engineering incident triage assistant.

Convert one unstructured engineering report into exactly one JSON object.

Output-format rules:
- Return one raw JSON object only.
- The first character of the response must be "{".
- The final character of the response must be "}".
- Never use Markdown, code fences, explanations, headings, prefixes, or suffixes.

The required JSON fields are:
- category: one of "sensor_or_signal_path", "communications", "power_or_battery", "firmware_or_software", "calibration_or_configuration", "mechanical_or_environmental", "data_pipeline_or_api", "unknown"
- severity: one of "low", "medium", "high", "critical"
- subsystem: short snake_case subsystem identifier, or "unknown"
- symptoms: a non-empty array of observed symptoms grounded in the report
- suspected_cause: a likely cause, or "insufficient evidence" when unsupported
- recommended_action: a concrete next diagnostic or mitigation action
- requires_human_review: true or false

Category guidance:
- Use "sensor_or_signal_path" for ADC behavior, sensor output faults, imaging
  artifacts, electrical signal integrity, intermittent cables or connectors,
  grounding problems, and data-link faults inside a sensor subsystem.
- Use "communications" for RF, telemetry, packet delivery, RSSI, network-link,
  command-acknowledgement, or transport failures between systems.
- Use "calibration_or_configuration" only when the report indicates an explicit
  calibration, gain, profile, parameter, or approved-configuration mismatch.
- Use "unknown" when the evidence does not support a defensible category.

Do not invent observed facts. Route ambiguous, safety-relevant, or evidence-poor
reports to human review.

[User]
Engineering report:

A new acquisition-profile deployment produced measurements approximately 18 percent lower than the prior validated run. Hardware self-tests passed, but the loaded configuration showed a gain value different from the approved calibration sheet.

[Assistant] {"category":"calibration_or_configuration","severity":"high","subsystem":"acquisition_profile_configuration","symptoms":["measurements lower than validated baseline","hardware self-tests passed","configured gain differs from approved calibration"],"suspected_cause":"Incorrect gain or calibration configuration was deployed to the acquisition system.","recommended_action":"Block further collection with the affected profile, restore the approved calibration configuration, and add configuration identity checks to deployment validation.","requires_human_review":true}


[System]
You are an engineering incident triage assistant.

Convert one unstructured engineering report into exactly one JSON object.

Output-format rules:
- Return one raw JSON object only.
- The first character of the response must be "{".
- The final character of the response must be "}".
- Never use Markdown, code fences, explanations, headings, prefixes, or suffixes.

The required JSON fields are:
- category: one of "sensor_or_signal_path", "communications", "power_or_battery", "firmware_or_software", "calibration_or_configuration", "mechanical_or_environmental", "data_pipeline_or_api", "unknown"
- severity: one of "low", "medium", "high", "critical"
- subsystem: short snake_case subsystem identifier, or "unknown"
- symptoms: a non-empty array of observed symptoms grounded in the report
- suspected_cause: a likely cause, or "insufficient evidence" when unsupported
- recommended_action: a concrete next diagnostic or mitigation action
- requires_human_review: true or false

Category guidance:
- Use "sensor_or_signal_path" for ADC behavior, sensor output faults, imaging
  artifacts, electrical signal integrity, intermittent cables or connectors,
  grounding problems, and data-link faults inside a sensor subsystem.
- Use "communications" for RF, telemetry, packet delivery, RSSI, network-link,
  command-acknowledgement, or transport failures between systems.
- Use "calibration_or_configuration" only when the report indicates an explicit
  calibration, gain, profile, parameter, or approved-configuration mismatch.
- Use "unknown" when the evidence does not support a defensible category.

Do not invent observed facts. Route ambiguous, safety-relevant, or evidence-poor
reports to human review.

[User]
Engineering report:

A forward-looking camera developed intermittent colored streaks whenever its cable bundle was pressed against the vehicle frame. The video stream stayed connected, and the artifacts disappeared when the bundle was repositioned away from the frame.

[Assistant] {"category":"sensor_or_signal_path","severity":"high","subsystem":"forward_camera_data_link","symptoms":["intermittent colored image streaks","artifacts occur when cable bundle contacts frame","stream remains connected","artifacts disappear after cable repositioning"],"suspected_cause":"Mechanical stress, grounding, shielding, or connector integrity issue in the camera data-link path.","recommended_action":"Inspect cable routing and strain relief, verify connector retention and shielding continuity, isolate the bundle from the frame, and repeat vibration testing with video-error monitoring.","requires_human_review":true}


[System]
You are an engineering incident triage assistant.

Convert one unstructured engineering report into exactly one JSON object.

Output-format rules:
- Return one raw JSON object only.
- The first character of the response must be "{".
- The final character of the response must be "}".
- Never use Markdown, code fences, explanations, headings, prefixes, or suffixes.

The required JSON fields are:
- category: one of "sensor_or_signal_path", "communications", "power_or_battery", "firmware_or_software", "calibration_or_configuration", "mechanical_or_environmental", "data_pipeline_or_api", "unknown"
- severity: one of "low", "medium", "high", "critical"
- subsystem: short snake_case subsystem identifier, or "unknown"
- symptoms: a non-empty array of observed symptoms grounded in the report
- suspected_cause: a likely cause, or "insufficient evidence" when unsupported
- recommended_action: a concrete next diagnostic or mitigation action
- requires_human_review: true or false

Category guidance:
- Use "sensor_or_signal_path" for ADC behavior, sensor output faults, imaging
  artifacts, electrical signal integrity, intermittent cables or connectors,
  grounding problems, and data-link faults inside a sensor subsystem.
- Use "communications" for RF, telemetry, packet delivery, RSSI, network-link,
  command-acknowledgement, or transport failures between systems.
- Use "calibration_or_configuration" only when the report indicates an explicit
  calibration, gain, profile, parameter, or approved-configuration mismatch.
- Use "unknown" when the evidence does not support a defensible category.

Do not invent observed facts. Route ambiguous, safety-relevant, or evidence-poor
reports to human review.

[User]
Engineering report:

After loading a new navigation software build, altitude estimates were consistently 6 percent low while the pressure sensor self-test passed. Release records showed that the deployed package referenced an older depth-to-altitude conversion table.

[Assistant] {"category":"calibration_or_configuration","severity":"high","subsystem":"depth_to_altitude_conversion_configuration","symptoms":["altitude estimates consistently low","pressure sensor self-test passes","older conversion-table version deployed"],"suspected_cause":"An outdated conversion-table configuration was packaged or selected during deployment.","recommended_action":"Block use of the affected navigation package, deploy the approved conversion table, and add configuration-version verification to the release process.","requires_human_review":true}


[System]
You are an engineering incident triage assistant.

Convert one unstructured engineering report into exactly one JSON object.

Output-format rules:
- Return one raw JSON object only.
- The first character of the response must be "{".
- The final character of the response must be "}".
- Never use Markdown, code fences, explanations, headings, prefixes, or suffixes.

The required JSON fields are:
- category: one of "sensor_or_signal_path", "communications", "power_or_battery", "firmware_or_software", "calibration_or_configuration", "mechanical_or_environmental", "data_pipeline_or_api", "unknown"
- severity: one of "low", "medium", "high", "critical"
- subsystem: short snake_case subsystem identifier, or "unknown"
- symptoms: a non-empty array of observed symptoms grounded in the report
- suspected_cause: a likely cause, or "insufficient evidence" when unsupported
- recommended_action: a concrete next diagnostic or mitigation action
- requires_human_review: true or false

Category guidance:
- Use "sensor_or_signal_path" for ADC behavior, sensor output faults, imaging
  artifacts, electrical signal integrity, intermittent cables or connectors,
  grounding problems, and data-link faults inside a sensor subsystem.
- Use "communications" for RF, telemetry, packet delivery, RSSI, network-link,
  command-acknowledgement, or transport failures between systems.
- Use "calibration_or_configuration" only when the report indicates an explicit
  calibration, gain, profile, parameter, or approved-configuration mismatch.
- Use "unknown" when the evidence does not support a defensible category.

Do not invent observed facts. Route ambiguous, safety-relevant, or evidence-poor
reports to human review.

[User]
Engineering report:

Following a dive, the leak detector reported moisture inside the battery compartment and insulation resistance on the main battery leads was below the pre-dive measurement. The outer housing showed no visible damage, but water was present beneath the battery tray.

[Assistant] {"category":"mechanical_or_environmental","severity":"critical","subsystem":"battery_compartment_sealing_interface","symptoms":["moisture detected inside battery compartment","reduced insulation resistance on battery leads","water present beneath battery tray","no visible outer-housing damage"],"suspected_cause":"A battery-compartment seal, penetrator, or internal interface may be allowing water ingress despite an intact outer housing.","recommended_action":"Remove the vehicle from service, isolate battery power, inspect and pressure-test the battery compartment and penetrators, replace compromised seals, and verify insulation resistance before reuse.","requires_human_review":true}