Project Sentinel: The First Repair-Diagnostics Platform Built for Technicians, Not Consumers

Walk through the tooling a repair technician actually has to work with today, and a pattern jumps out fast: almost none of it was built for you.

The manufacturer’s real diagnostics are locked behind dealer accounts and NDAs. The “troubleshooting” apps are written for the owner of the device — restart it, reset it, update it, contact support, buy a new one. And the knowledge that actually fixes boards, the stuff that matters at the bench, is scattered across forum threads from 2019, half-audible videos where the guy mumbles through the good part, and chat messages from someone who thinks it was the RAM rail but never came back to say whether the fix held.

As a professional, you are nobody’s target customer. You’ve been improvising with consumer apps and community scraps because that’s all there’s ever been.

Project Sentinel is built to change that, and it starts from one idea that sounds obvious but almost nothing in this space actually follows: the technician is the customer.

What Project Sentinel is

Sentinel is two things working together.

First, it’s a shared, community-verified knowledge base of real electronics repairs — not repair guides, not “have you tried reflowing it” forum advice, but actual bench records. A bench record pairs two things: what the machine said — the UART and syscon error codes, POST codes, boot behavior, battery stats, and temperatures pulled straight off the device — and what a human technician actually found and fixed — the component they probed, the reading they measured, and whether the repair worked.

That pairing is the whole point. An error code on its own is a riddle. An error code sitting next to “probed the 2R2 inductor, measured 0.4 ohms, replaced the shorted cap on the RAM rail, console lives” is an answer.

The pool has since grown a second kind of entry, and by volume it has taken over: the knowledge card. A card is a single claim about a fault — what goes wrong, the evidence for it, the readings, the part numbers — drawn out of reference material rather than out of a repair. Where a bench record says this console had this fault and here is what fixed it, a card says here is how this fault behaves, and here is where that is established. The record tells you what happened; the card tells you what to expect. Today the pool holds 141 cards to 9 records.

Second, Sentinel is an assistant that lives on the bench. Ask it about a device — an error code, a symptom, a model — and it answers from your shop’s own repair history and your curated references first, then the wider verified pool. It runs on the bench itself, so it works with no internet, and it answers in the language of someone who repairs things for a living.

Between the two sits a learning loop: every repair a tech logs and verifies makes the next diagnosis sharper.

It speaks the language of the bench

This is where “built for technicians” stops being a slogan and starts being a design decision.

Ask Sentinel’s research mode is tuned for a board-level tech and no one else. It demands part numbers, diode-mode and voltage readings, and UART or log signatures. It prefers boardview references and repair wikis. And it flatly refuses consumer advice — no “restart it,” no “contact the manufacturer,” no “factory reset and see.” It also refuses the community bodges that circulate as folklore — the washer mod, the oven reflow, the towel trick. If one even comes up, it gets labeled as an unprofessional temporary measure, with the proper repair — reball, reflow with real equipment, component replacement — given as the actual recommendation.

When you ask it for a game plan, it names the specific tools to reach for on this device and tells you what each result would mean. Ask about an iPhone and it points you at the panic log and the sensor-code map; ask about a PS5 and it points you at the syscon error log and monitor mode. It will never hand you a console workflow for a phone, because it knows the difference. That’s not an accident of the model — it’s built to know your bench.

A real example from our bench

Last week a PS5 came in that refused to update — every method failed with SU-101337-5. We pulled the UART codes and they pointed at a USB Type-C fault, which sounds unrelated to an update failure until you know how much the front USB-C ports matter on that board.

Sure enough, only one of the front ports would charge a phone. We tested the dead port, confirmed bad pin readings, replaced the USB-C controller IC, and the console updated on the first try.

That entire chain — the SU error, the UART codes, the “check if both ports charge” trick, the exact IC — is now a single entry in the Sentinel pool. The next tech who sees SU-101337-5 doesn’t rediscover any of it. They go from symptom to suspect component in the time it takes to search a folder. Multiply that by every repair, on every bench, in every shop that joins in, and you have something no forum has ever managed to build: verified repair knowledge that compounds instead of scattering.

One button, because documentation always loses to the next device

Here’s the uncomfortable truth about why repair knowledge doesn’t get shared: it’s not that technicians are selfish. It’s that documentation is a chore, and chores lose to the next device in the queue every single time. Nobody writes up a proper case study at 9 p.m. when they’d rather be home.

So Sentinel doesn’t ask you to. At our shop the entries are generated by the BenchTool diagnostic stations as a tech works — the station already has the telemetry, so the tech just adds what they verified and what they fixed and taps one button. For anything without a dedicated tool, there’s a plain-language quick log: describe the repair in a sentence or two, out loud if you want, and the bench turns it into a structured record for you. Logging a fix costs one button at the end of a job you already did. That’s the only way it actually happens.

Where the cards come from — and what we won’t take

Cards get made the same way bench records do: as a by-product of work someone was doing anyway. Point a bench at a service manual and it reads the whole document in the background — every section surveyed and mined, and the figure pages that matter (diode charts, voltage maps, pinout tables) read by vision, so numbers printed on a diagram become searchable text instead of staying locked in a picture. Drop in an annotated boardview or a reading chart and the same thing happens to it.

A tech can point it at a repair video too, and that one deserves a straight answer, because “we mined YouTube” is the kind of sentence that should make you suspicious. Here is the rule we hold ourselves to. When a card comes from someone else’s video, the shared copy carries our own paraphrase of the claim, the evidence for it, and a link back to the source — and the verbatim quote and its timestamp are stripped out before the card ever leaves the bench. The shop that made it keeps the full card locally, quotes included, because that is their own working note. The pool gets the fact and the credit, not the transcript. If a card’s value depended on reproducing someone’s video, it does not belong in the pool.

Anything read by vision is capped at medium confidence until a person confirms it. That matters more than it sounds: a model misreading “0.4” as “6.4” off a photographed chart is exactly the kind of error that would poison a dataset quietly.

Machine judgment, graded by human judgment

Some Sentinel entries include an AI-generated fault prediction alongside the telemetry. We keep those in the record — but they never stand alone. Every entry that reaches the shared pool includes real technician verification: what was probed, what was measured, whether the predicted fault was actually the fault.

That makes the data honest in a way that “AI diagnostics” usually isn’t. The machine offers a starting guess; the technician corrects it; the record of that exchange is what everyone else gets to use. And because every prediction is graded against what a skilled human actually found, the dataset is exactly what’s needed to make the predictions genuinely better over time. The machine helps the tech, the tech corrects the machine, and the next bench down the line inherits both. The human is never removed from the loop — the human is the loop.

Where it stands today

Numbers, because a project like this should be willing to show them rather than talk in the abstract.

The pool holds about 150 approved entries — 141 knowledge cards and 9 bench-verified repair records — alongside 88 reference images. The cards trace back to 135 service documents, 3 repair videos, 2 annotated images and 1 web source, every one of them linked. Four different benches have contributed, which is the part that matters most: it stopped being our dataset somewhere around the point a second shop’s entries passed a third of ours. A handful of rejected and duplicate submissions sit in the archive, which is the audit trail working as intended, and the pending queue is currently empty — everything submitted has been looked at.

It is still small. A hundred and fifty entries is a rounding error against the number of repairs done in a week across the trade. But it is real, it is verified, and it is growing from more than one bench, which is the only shape this could ever have taken if it was going to work at all.

On the promise about customer data: identifying fields are now stripped by code rather than by remembering — structurally, wherever they appear in a record, with free text scrubbed on top. That is the kind of claim worth checking rather than trusting, so we check it. As of this writing there is not a single customer name, serial, IMEI or phone number anywhere in the published pool.

Shops started sharing tools, not just data

One thing we did not anticipate: shops wanted to share the tools they built, not only what they found.

A shop can write its own bench tool — describe what you want in plain words and the AI drafts it against the app contract, or write it yourself and drop in a zip. Publishing it to the shared pool is then one action from the dashboard. It queues immediately and uploads on the next sync, so a dead connection at the wrong moment never costs you the submission.

Apps go through the same human review gate as everything else, and each approved app is published with a SHA-256 hash so a bench can verify it got what the maintainer signed off on. Approved apps reach every participating bench through the same sync that keeps the rest of the unit current. They live outside the BenchTool install, so a firmware update cannot clobber them and they cannot break an update, and each one writes its own log like any built-in tool.

There are five apps in the pool today, from two different shops — an IMEI lookup, a review-QR generator, a batch iOS activation tool for testing, a Windows intake tester, and a fleet-maintenance tool. None of those are things we would have built. That is rather the point.

Why build this for technicians at all

Because the trade has been treated as an afterthought for long enough, and because the math works out in everyone’s favor when it isn’t.

Any single shop only ever sees a slice of what’s out there. We might see fifty PS5s a month; another shop sees fifty phones we’d rarely touch. Pool the verified fixes and every participating bench suddenly has diagnostic reach far beyond its own history. And the real competition was never the shop across town — it’s the landfill. Every device fixed instead of tossed is a win for the customer, the technician, and one less slab of electronics in the ground.

Diagnostic knowledge kept in silos dies in silos. Techs retire, shops close, hard drives fail, and the next generation starts over from zero. Written down and shared in the technician’s own language, it compounds.

Get involved

If you run a repair bench — a full shop or a solo operator fixing consoles in the garage — Sentinel gets more useful with every entry added to it. Benches running BenchTool can start contributing with one button. Everyone else can add a repair by hand, and anyone can search the pool the next time a cryptic code lands on the bench.

The knowledge already exists. It’s sitting in the heads and notebooks of thousands of technicians who were never anyone’s customer. Sentinel is the first place built to put it where it belongs — at the bench, in your language, where it can’t be lost.

See something worth sharing? Send it in. The next tech will thank you.

Dealing with this right now? Device Hero handles game console repair at our shop in Manor, TX — also serving Round Rock and Pflugerville. Call 512-774-4376 or 512-996-7134 or stop by 209 Lexington St.