AI, Microsoldering and the Right to Repair

Right-to-repair legislation, from the EU and several US states to the active policy conversation in India, mostly tackles access: access to spare parts, to schematics, to firmware and to the ability to pair a replacement screen or battery. That is genuinely important. But access is only the first half of the problem.

The second half is skill. The most valuable repairs, the ones that save a device from the scrap bin instead of just swapping a module, happen at the motherboard. Indian customers say motherboard; in Apple's own language it is the logic board. Same thing. When an iPhone will not charge, will not turn on, or boot-loops after liquid damage, the fault is often a single component a few millimetres across: a charging IC such as the Tristar or Tigris, the U2 charge controller, a backlight boost circuit, a blown filter, a lifted NAND.

Diagnosing and replacing that part needs a microscope, a hot-air station, schematics, boardview files and years of pattern recognition. Those technicians are rare and expensive to train. That scarcity, not the law, is what sends a fixable board to e-waste.

The world generates tens of millions of tonnes of electronic waste a year, and a large share of dead phones and laptops are recoverable at the board level. The fault is frequently one cheap component on an otherwise healthy board. The barrier is not the part cost; it is finding someone who can locate the fault.

This is the last mile of repair: the stage just before a device is written off. Module-swap shops, the ones who replace a screen or a battery and stop there, cannot cross it. Board-level shops can, but there are too few of us, and the knowledge lives in individual heads and scattered forum threads.

If AI can make scarce microsoldering expertise more shareable, it does something right-to-repair law cannot do on its own: it widens the pool of people and shops capable of the highest-value, most waste-reducing repairs. That is the thesis worth taking seriously.

Most AI repair help today is crude: a technician copies a screenshot of an error or a board photo into a chatbot, one at a time, and pastes back the answer. It is better than nothing and far short of a real tool.

Wrench Board is the most interesting attempt we have seen to close that loop properly. It is a source-available diagnostic workbench for board-level repair, built by a working microsoldering technician at the independent UK workshop Repair Valley (also known as Repairmind), and powered by Claude Opus 4.8. It is source-available, not open source, an important distinction the project itself makes: the licence is free for personal use and for independent professionals servicing their own clients, but that is a different thing to an open-source licence. Wrench Board placed 2nd in Anthropic's Build with Opus 4.7 Claude Code hackathon in April 2026.

A necessary disclosure, because we feature it heavily: iTweak did not build Wrench Board, did not enter the hackathon, and is not affiliated with Anthropic or Repair Valley. We are an independent repair business that uses AI-assisted diagnostics in our own work, and we cover this tool as industry news because it is the clearest public example of where this is going.

In plain terms, Wrench Board ingests a device's schematic PDF and its boardview file, builds a per-device knowledge pack, and then runs an AI agent that can reason over that exact board's power topology, show its thinking on a 3D rendering of the board, and recall what worked on past repairs of the same model.

The headline that grabs people is that the agent can see the board. That is true, but the reality is more grounded and more honest than autonomous machine vision.

Seeing the board is technician-initiated. The repair tech plugs a USB microscope or webcam into the bench, frames and focuses the shot themselves, and the agent requests a still frame when it needs a fresh look at a specific component, via a tool called cam_capture. The technician can also drop a macro photo into the chat at any time. The agent reads the image and folds it into its reasoning. It is not a camera roaming the board on its own; it is a second pair of eyes on the technician's optics, on the technician's cue.

Separately, the tool reads the schematic itself. Each page of the schematic PDF is processed by Claude Opus vision into a structured electrical model: reference designators, component values, and which rail powers what. From that it compiles an electrical graph and even infers the boot sequence, the order the power rails come up at switch-on. That is what lets the agent say something like: standby 3.3V comes up first, then the main rail, then the CPU module, and trace a dead board back along that chain rather than guessing from generic knowledge.

Anyone who has used a general chatbot for repair knows the failure mode: it confidently names a component or a test point that does not exist on your board. On a microsoldering bench, a hallucinated reference designator is worse than no answer; it sends you probing the wrong pad.

Wrench Board's flagship engineering choice is a two-layer guard against exactly this. First, tool discipline: the agent looks parts up through tools that physically cannot fabricate. Ask for an unknown component and the lookup returns not found, here are the closest matches, rather than inventing one. Second, a server-side sanitizer scans every outbound message for component-shaped tokens before they reach the screen, validates each against the actually-parsed board, and visibly flags any it cannot verify. The project's own rule is blunt: the agent is not allowed to invent a reference designator.

Underneath the chat sit two deterministic engines that use no language model at run time. A forward simulator answers cause-to-effect: kill this part, and the board blocks at this boot phase. A reverse hypothesizer answers effect-to-cause: given these symptoms and measurements, here are the suspect parts, and here is the single next measurement that best narrows them down. Because these are deterministic, the same observation always yields the same ranked suspects, and the reasoning is auditable rather than a guess.

None of this replaces the technician, and the tool is explicit about that. The person at the bench still holds the iron, frames every photo, takes every measurement with a multimeter, and confirms the root cause. The AI proposes, highlights, simulates and recalls; the human decides and solders.

Even the camera and the measurement journal depend on a skilled person feeding accurate observations in. A simulator that says the fault would block at phase two is only useful to someone who knows how to probe phase-two rails. AI lowers the experience needed to be productive, and shortens the path from symptom to suspect, but board-level repair remains a hands-and-judgement craft.

The honest framing the project itself uses: for an experienced tech it is a second pair of eyes that never gets tired; for an apprentice it is a senior teammate who will explain the boot sequence a tenth time without judgement. That is the right ceiling to set.

A claim worth handling carefully, because it is easy to overstate. When a technician confirms a root cause, the agent saves a field report to disk for that specific device: the at-fault part, the reported symptom, the failure mechanism and notes. The next diagnosis on the same model can recall those reports. So the more real repairs a workshop does on a given device, the sharper the tool gets on that device.

Separately, a nightly loop can tune the deterministic engine against a frozen, human-curated benchmark of real scenarios, keeping a change only if measured accuracy improves and reverting it otherwise.

Crucially, this is recall of confirmed field reports plus tuning of a deterministic engine. It is not training or fine-tuning the underlying Claude model on customer data. The knowledge that accumulates is structured, on-disk and auditable, which is exactly the property you want if you care about repair being transparent and in the open.

Capability scales with what you can feed it. Both files are optional; you can run with one, both or neither, but the tooling gets dramatically more powerful as you add data. A focused knowledge pack lands in roughly two minutes, while a full, schematic-ingested pack on a dense board can take 15 minutes or more, and it keeps building in the background even if you close the page.

Two things follow if tools like this mature. First, board-level skill becomes more shareable. An apprentice with a microscope, a schematic and an AI agent can attempt diagnoses that previously needed years of memorised pattern knowledge. That widens the supply of shops able to do real repair instead of module-swapping, which is precisely the supply right-to-repair advocates want to grow.

Second, it raises the stakes on the access fight. An AI that reasons over a schematic and a boardview is only as good as your ability to obtain those files. If manufacturers continue to withhold schematics and boardviews, the most powerful repair AI in the world is reasoning blind. So AI does not make right-to-repair less relevant; it makes access to schematics and board data more valuable than ever.

For a customer, the practical upshot is quality and honesty. The same discipline that stops an AI inventing a component, see the fault before you trust the fix, is what a good repair shop already owes you. At iTweak we run AI-assisted diagnostics alongside our multi-point diagnostic and our see-the-fault-before-you-pay policy, with up-to-1-year warranty and a money-back commitment on misdiagnosis. The tooling is new; the principle, prove the fault, is not.

For context, here are approximate market-survey ranges for common board-level repairs in India. These are indicative only and not iTweak quotes; real pricing depends on the exact fault found on diagnosis. Board-level repair is almost always far cheaper than a board swap, which is the whole point of saving the device from e-waste.

Common questions about AI-assisted microsoldering and right-to-repair.

• Does AI replace the microsoldering technician? No. The technician holds the iron, takes the measurements and confirms the fault. AI helps reason over the schematic, highlights parts, simulates faults and recalls past repairs, but it is a human-in-the-loop tool, not an autonomous fixer.
• Is Wrench Board open source? No. It is source-available, free for personal use and for independent pros servicing their own clients, but that is a different licence to open source. It was built by a working microsoldering technician at Repair Valley and placed 2nd in Anthropic's Build with Opus 4.7 hackathon in April 2026.
• Did iTweak build Wrench Board? No. iTweak is not affiliated with the tool, Repair Valley or Anthropic, and did not enter the hackathon. We cover it as industry news and use AI-assisted diagnostics in our own work.
• Does 'it sees the board' mean a camera scans my phone automatically? No. The technician plugs in a microscope and frames the shot; the agent requests a still image when it needs one. It reads what the technician shows it.
• Does the AI learn from my repair? The system can save a confirmed field report for that device model and recall it later, and it tunes a deterministic engine overnight against a fixed benchmark. It does not train or fine-tune the AI model on your personal data.
• Is board-level repair worth it versus replacing the phone? Usually yes. Replacing a single failed component is typically a fraction of a board swap or a new device, and it keeps a repairable phone out of e-waste. Ask for the fault to be shown before you pay.