The diagnostic system that gets smarter about your machine with every visit
S-Ray is a diagnostic intelligence system I invented, designed, and built from scratch. It runs on every machine that comes through my lab. And it finds things that no amount of manual inspection or off-the-shelf scanning would catch—because it was never designed to replace those things. It was designed to do something fundamentally different.
Most diagnostic tools check one thing at a time. They'll tell you your drive is healthy, your memory passes, your CPU runs cool. They check their box and move on. The problem is that the most damaging issues in the real world don't live inside a single box. They live in the connections between them—a thermal pattern that correlates with a driver timeout that correlates with a stability event that traces back to a firmware regression nobody noticed three months ago.
That's the kind of problem S-Ray was built to find.
What S-Ray Actually Does
When I run S-Ray on your machine, it collects detailed system telemetry—not your personal data, but the under-the-hood operational information your system generates constantly—across dozens of technical domains. Hardware health, software state, driver configurations, crash history, thermal behavior, storage diagnostics, security posture, browser integrity, startup chains, and more. It gathers all of it using collection tools I built specifically for this purpose.
Then it does the part that matters: leveraging carefully-curated LLM-based analysis of the programmatically pre-collected metrics, it correlates findings across every domain simultaneously, looking for patterns that connect seemingly unrelated observations into coherent diagnostic narratives. A thermal anomaly in isolation might be cosmetic. A driver warning in isolation might be benign. But when S-Ray identifies that the thermal anomaly coincides with a specific driver's load pattern, and that pattern correlates with intermittent stability exceptions concentrated during a particular time window—now you have a root cause that no isolated tool would ever surface.
Every finding S-Ray reports is backed by specific evidence citations from your machine's own telemetry. Nothing generic. Nothing speculative. If S-Ray flags it, the data is there to support it.
The Service History Advantage
Here's where things get interesting—and where S-Ray becomes something that genuinely cannot be replicated by anyone who hasn't been doing this work for a very long time.
If your machine has been serviced by Triple-S before, S-Ray automatically integrates your complete service history into the analysis. Not just a note that you were here last year—but the full diagnostic context from every prior visit: what was found, what was fixed, what was recommended, what the machine's health metrics looked like at each point in time.
This transforms the analysis in ways that are difficult to overstate. S-Ray can identify whether a problem that appeared last visit was actually resolved or merely masked. It can detect hardware degradation trends that only become visible when you compare snapshots taken months or years apart. It can surface recurring patterns that keep coming back under different guises. And it can catch the early stages of a failure trajectory—a trajectory that's only visible because there's a historical baseline to measure against.
Think of it like the difference between a single doctor's visit and a relationship with a physician who has your complete medical history going back fifteen years. The snapshot has value. The longitudinal picture has exponentially more.
Quick Aside: If you're wondering how this is possible... my clients have long grown accustomed to extraordinarily detailed 4 - 12 page Service Reports I provide at the end of every single service detailing precisely what was done, what changed, what was removed and added, and the narrative logic behind all of it. This is an effort to provide complete transparency for my clients, and it is made possible by programs I wrote over 15 years ago that I use during service to keep track of my progress. The structure of this data has remained very consistent over this past decade and a half; and now, the whole of it has been carefully parsed, converted, and baked into the logic and rules that run the proprietary S-Ray system. I've often been told I'm crazy for spending so much time on client documentation—but in retrospect, it's a good thing I did!
What S-Ray is Built on:
Taking Lessons from History
But S-Ray doesn't just benefit from your personal machine history: it benefits from the longitudinal, aggregate knowledge of repairs I've performed on every single machine I've ever serviced. So if you're struggling with an issue related to a particular program or error message, and that error message has been encountered before by me in my repair history (and, of course, painstakingly documented—as it always is with me), S-Ray immediately surfaces this knowledge selectively and applies it to its recommendations to assist me in rectifying this similar situation.
It might also notice that this error always appears alongside some other specific sets of constraints or conditions that would otherwise not have been obvious to expert-level human techs (even *rubs nails on shirt* world-class pros like yours truly). In this case, it has the power to automatically update its knowledge and flag the updates for validation by me to ensure they're rational and effective. This growth and refinement happens automatically by design—and as S-Ray continues to accumulate additional scenarios with intersecting conditions, it continues to learn and integrate those lessons into its future analyses.
Yes—it actually works. It's being used right now, every day, by me.
A Real Example: The Drive That Wasn't There
A client brought in their laptop for a routine tune-up. They mentioned a printer issue. The machine was otherwise "fine."
S-Ray found something the client didn't know about—and couldn't have known about. The analysis flagged a pattern of escalating hardware failures on an external storage device, their primary backup drive, based on error patterns the laptop had recorded over the preceding two weeks. The drive had been trying to complete maintenance operations and failing each time, with the failure rate accelerating.
The drive was never connected during my entire service window. It was at the client's home. But the traces it left behind in the system told a clear story, and S-Ray knew exactly how to read them.
At any other shop, this visit would have ended with a faster laptop and a fixed printer. The client would have gone home with no idea their only backup was quietly dying. When that drive eventually failed—and drives in that condition always do—they'd have reached for their safety net and found nothing.
Professional data recovery on a failed external drive runs $300 to $1,500 or more. In many cases, it isn't possible at all.
That's the difference between checking boxes and understanding what the machine is actually telling you.
Read the full case study on the blog »
Why It Took Years to Build—and Why That Matters
There's a common misconception that you can build a system like this by pointing an AI at raw system data and letting it figure things out. You can't. I know, because I tried that early on, and the result was clinically useless.
The fundamental problem is noise. A modern Windows machine generates an enormous volume of telemetry, and the vast majority of it is meaningless. OEM services throwing routine errors on the hardware they shipped with. Cosmetic event log entries that look alarming but indicate nothing. SMART attributes whose interpretation varies by manufacturer and model. Driver warnings that are artifacts of specific Windows builds. Registry entries that appear suspicious but are standard for certain software configurations.
If you point even the most sophisticated AI at this data without telling it what to ignore, it will flag hundreds of "findings" per machine—almost all of them false positives. At 6,000+ machines, even a 1% false positive rate creates catastrophic noise. Clients lose trust. The technician wastes time investigating phantom issues. The system becomes a liability instead of an asset.
The thing that makes S-Ray work isn't the analysis engine. It's the institutional knowledge that governs the analysis engine.
That knowledge lives in the noise-limitation calibration—the continuously maintained, field-validated understanding of what to expect across thousands of different hardware configurations, software environments, and OEM ecosystems. It lives in the correlation rules—the patterns that connect symptoms across domains, refined through years of observing what actually matters versus what merely looks like it matters. And it lives in the historical service corpus—the accumulated context from 8,000+ service visits that teaches the system what "normal" looks like for a given machine at a given stage of its lifecycle.
None of this can be bootstrapped. You can't download a dataset that teaches you which Lenovo services are expected to throw Event ID 10016 errors on specific ThinkPad models, or which SMART attribute on a particular Samsung drive family actually indicates a genuine concern versus a known firmware reporting quirk, or which Windows Update KB articles historically introduced driver compatibility regressions in specific hardware generations. That knowledge was built one service at a time, over 15+ years, across 6,000+ machines. It is the accumulated diagnostic intelligence of an entire career—encoded into a system that applies it automatically, exhaustively, and consistently to every machine that comes through the lab.
This is what I mean when I say S-Ray gets smarter with every visit. It's not just learning about your machine. It's learning about all of them—and every lesson improves every future analysis.
The Baseline Advantage for New Clients
There's a less obvious but significant benefit for clients who are new to Triple-S or who purchase a new PC through me.
When S-Ray analyzes a machine for the first time—especially a freshly configured new PC—it captures the system's health profile in a known-good, fully optimized state. Think of it like establishing a complete blood panel when you're healthy: the snapshot itself is useful, but the real value is what every future comparison reveals. Drift, degradation, early warning signs—all of these become visible precisely because there's a clean baseline to measure against.
Clients who start with a Triple-S setup carry that compounding diagnostic advantage through every future service visit. It's one of the reasons issues get caught earlier and resolved faster over time.
What S-Ray Does Not Do
S-Ray does not access your personal files, photos, documents, emails, passwords, or browsing history. It collects only system-level operational telemetry—the kind of information your operating system generates constantly for its own internal use. Think of it as reading the instrument panel of your car, not opening the glovebox.
S-Ray does not allow an AI to access your PC. The specific metrics and markers that are collected are done not with AI, but with very sophisticated programs that I designed to collect only what is necessary for reliable diagnosis. All the AI LLM sees is what I provide it with.
S-Ray does not install any persistent software on your machine. The entire system runs from my portable toolkit during the service visit. When I'm done, nothing remains on your PC except the changes I made to render it a healthier machine.
S-Ray does not guess. If it can't support a finding with specific evidence from your machine's own data, it doesn't report it. Period.
Every machine that passes through my lab receives an S-Ray analysis.
It's included with every Triple-S Tune-Up, every new PC setup, and every major service. There's no extra charge and no upsell. It's simply how I work now—because once you have a system that finds things this effectively, it would be irresponsible not to run it.
Frequently Asked Questions
How is S-Ray different from running a diagnostic scan?
Traditional diagnostic tools check individual subsystems in isolation: storage health, memory integrity, CPU thermals. S-Ray operates across all of these domains simultaneously and looks for connections between them. A thermal event, a driver timeout, and a stability exception might look like three separate minor issues to isolated tools—but S-Ray can identify them as symptoms of a single root cause. It also integrates your complete service history, enabling pattern detection across visits spanning years.
Does S-Ray access my personal files or data?
No. S-Ray collects only system-level operational telemetry—hardware health metrics, system event logs, driver states, installed software inventory, and configuration data. It never accesses, reads, or transmits user documents, photos, passwords, browsing history, or any personal content.
Does S-Ray install anything on my computer?
No. S-Ray runs entirely from my portable toolkit during the service visit. No persistent software is installed on your machine for the purpose of S-Ray analysis.
Can S-Ray really detect problems with devices that aren't connected?
Yes. S-Ray analyzes the system's recorded interactions with all devices it has communicated with, including external drives and peripherals. If your system logged a pattern of failures involving a device that isn't currently present, S-Ray can identify and flag that pattern. The external backup drive case study is a documented example of exactly this capability.
Is it risky to use an AI-based tool like S-Ray on a PC?
No, because S-Ray was designed from the ground up so that the LLM is only used for the targeted analysis of programmatically, deterministically-collected data bundles. The LLM never has any direct access to the machine, and it never unilaterally performs "repair" operations on the machine; it merely pulls out items of concern and brings them to my attention for my expert approval and response. In AI nomenclature, this latter part is called "human-in-the-loop" processing, meaning that a human (in this case, me) is directly involved in the completion of each step of the process.
Why is service history so important to S-Ray?
Because the most informative diagnostic insights come from change over time, not from static snapshots. A SMART metric that reads "acceptable" today might be perfectly fine—or it might represent significant degradation from where it was six months ago. A recurring browser hijacker might look like a new infection—or it might be the third time the same root cause has resurfaced. Service history transforms isolated observations into a diagnostic narrative that reveals things a single visit never could.
Is S-Ray available at other repair shops?
No—S-Ray is exclusive to Triple-S Computers clients.
Why can't someone else just build one?
They can try. The AI analysis engine is one component. The part that took years is everything else: the noise-limitation calibration tuned across 6,000+ diverse machine configurations, the correlation heuristics validated against real-world diagnostic outcomes, and—most of all—the longitudinal service history spanning 15+ years that teaches the system what "normal" looks like across the full spectrum of hardware and software environments. Without that foundation, the analysis engine produces noise, not intelligence. This isn't a technology problem—it's a data and experience problem, and I've discovered that there aren't shortcuts to be taken.
Is S-Ray how you produce those famous Service Reports?
No; in fact, it's the other way around. S-Ray was made possible by the existence of these Service Reports that take me so long to craft, as well as the vast corpus of technical data that accompanies each and every one of them. This is the primary source of its intelligence—and the reason why it's so far ahead of anything else I've seen in the industry today.
Does S-Ray cost extra?
No. Every machine that comes through my lab receives a full S-Ray analysis as part of the standard service. It's how I work—not an add-on.
Does anyone else anywhere have anything like this?
I'm really not sure; I've been asking myself the same question for a while now. I think the answer might actually be no.