Arc Skills / Interfaces
Diagnose an integration failure from test evidence
A command log proves a message was sent, but it may not prove the actuator received power. Arc Skills takes run evidence and configuration and returns a timeline, competing hypotheses and targeted checks.
Use this skill
Use Arc Skills to diagnose my observed integration failure.
Inputs:
- Expected behavior, symptom, exact test configuration and recent changes
- Logs, measurements, timestamps and each instrument's clock basis
- Interface path, component revisions and a comparable passing run if available
Return the first evidence-backed divergence, an aligned timeline, competing hypotheses and the least disruptive checks that distinguish them. Do not assign root cause while several explanations still fit.What you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Run logs and observations | Locates the earliest proven divergence | Evidence-backed event timeline |
| Configuration and clock bases | Controls comparisons across devices | Bounded interpretation of sequence |
| Path diagram and prior run | Connects hypotheses to possible failed links | Discriminating check plan |
Valve does not open after a logged command
Illustrative engineering example.
The fictional integration run records a controller send event but no receiver acknowledgment or actuator movement. Logs and bench instrument timestamps use different unsynchronized clocks, so exact sub-second ordering cannot yet be trusted.
Controller log: command sent at local t=12.0 s
Receiver log: no acknowledgment in 2 s window
Observation: valve remains closed
Voltage at controller and actuator connectors: not yet measured| Evidence or check | Cable fault hypothesis | Controller output hypothesis | What result distinguishes |
|---|---|---|---|
| Send log exists | Still possible | Still possible | Software log does not prove pin voltage |
| No acknowledgment | Consistent | Consistent | Could also be receiver or timing issue |
| Measure controller output pin under approved bench procedure | May show correct output | May show absent output | Separates upstream drive from downstream path |
| If output present, measure actuator connector | Could show loss through harness | Less likely for missing downstream voltage | Localizes drop or connection issue |
The first established divergence is between the logged send and the missing physical/receiver response, not at a measured wire segment. A continuity or voltage check at the controller connector is therefore more informative than replacing the actuator. If voltage is present there but absent at the actuator end, the harness or connector becomes the stronger hypothesis.
Clock uncertainty means the logs can establish a missing acknowledgment within a broad window but not a precise causal ordering between separate instruments. Record time bases and configuration before comparing this run to a passing one. These checks are proposed diagnostic steps, not a claim that either component has failed.
Find the first proven divergence
- Fix expected behavior, exact hardware/software configuration and time bases.
- Build a timeline that separates logged intent from measured physical results.
- Trace the end-to-end path and list hypotheses that each fit current evidence.
- Choose the least disruptive measurement that yields different predictions for the hypotheses.
Questions about this task
Why not replace the cable first?
A replacement may make the symptom disappear without proving whether the cable, connector or controller output caused it. A targeted measurement preserves diagnostic information.
What if the clocks cannot be synchronized?
Keep ordering claims coarse and use common instrument triggers or correlated events in a repeat run.
Sources and further reading
- NASA Systems Engineering Handbook: product realization: Interface definition, integration sequence and verification context.
- NASA Systems Engineering Handbook: technical management: Technical assessment and decision records.