Motherboard diagnostics, structured instead of improvised.

Why random probing is so expensive

A modern motherboard is thousands of components and dozens of interdependent power rails. Probing at random means hours lost, and sometimes a second fault created along the way. Senior techs don’t probe at random: they walk a mental fault tree. No LED? Input voltage first. Present? The fuse. Intact? The first regulator in the chain. Every measurement eliminates an entire branch.

The problem: that tree lives in senior techs’ heads and in scattered forum threads. WrenchBoard makes it executable.

The method: symptom → rules → graph → protocol

A WrenchBoard diagnostic session moves in four beats:

1. The symptom, in plain language. “Board dead, no LED, 24 V adapter plugged in.” No forms, no codes: you describe what you see at the bench.
2. The device’s failure rules. The per-device knowledge base maps symptoms to known causes, each with a confidence score. An input fuse blocking the main rail comes out on top with its probability.
3. The electrical graph. If the schematic has been ingested, the agent checks its hypotheses against the real topology: which components drop if this rail drops, what must come up before what in the boot sequence. It can simulate a failure cascade before you touch the board.
4. The measurement protocol. The hypothesis lands as ordered, typed steps: continuity across F1, voltage at R49, diode-mode reading on the suspect rail. The boardview zooms onto each probe point the moment the agent sends you there.

With every reported result the hypothesis tightens or pivots. The repair journal keeps everything: readings, before/after diffs, confirmed cause.

An agent that doesn’t embroider

The value of an AI agent in a diagnostic loop depends entirely on its reliability. An assistant that invents a test point costs more time than it saves. WrenchBoard applies strict discipline, detailed on the AI for electronics repair page:

• every cited refdes is validated against the parsed board: a non-existent component is flagged, never asserted;
• proposed causes come from the device’s audited rules or the compiled electrical graph, not from the model’s memory;
• when the agent steps outside established rules to reason on topology alone, it says so.

From one-off diagnosis to shop memory

A diagnosed fault is only useful if it serves the next one. At the end of a session the confirmed cause is recorded; recurring patterns and diagnostic playbooks are shared across devices. The tenth board of the same model with the same symptom is diagnosed in minutes: the agent starts from what already worked.

It’s the same logic that makes WrenchBoard a complete microsoldering software rather than a lookup tool: knowledge accumulates where the work happens.

Start on a covered board

The free plan gives access to devices covered by the knowledge base, in the browser, no install. Describe a real symptom and watch the agent walk its fault tree, the two-minute demo on the home page shows a full session on a real board.