Silicon Technician: Physical AI Mission Lab

Inspiration

I was inspired by a practical question: how can AI help data-center technicians understand infrastructure failures without turning a recommendation into an unchecked action? Modern computing systems generate large amounts of telemetry, but interpreting those signals, distinguishing symptoms from likely causes, and verifying whether a corrective step worked can be challenging. I wanted to explore a system that connects AI-assisted reasoning with an inspectable workflow while keeping human judgment at the center. That idea became Silicon Technician: Physical AI Mission Lab.

What it does

Silicon Technician is an AI-assisted data-center maintenance prototype that combines NVIDIA Nemotron inference through Nebius Token Factory with a simulated multi-rack inspection environment. It demonstrates how telemetry can be organized into a structured diagnosis, how a technician can review evidence, and how a simulated recovery can be checked against expected outcomes.

The Mission Lab includes fan-failure, hot-inlet, power-supply anomaly, and healthy-baseline scenarios. It supports a repeatable three-rack inspection workflow and allows users to review or export diagnostic reports. I also documented a successful live Nemotron inference that identified a simulated Rack B fan failure as critical, using a reported fan speed of 0 RPM, CPU temperature of 91°C, and thermal headroom of 9°C.

The purpose is not to replace technicians. It is to explore how AI can make diagnostic information easier to interpret, verify, and communicate before a person decides what action, if any, is appropriate.

How we built it

I built the project around two connected but distinct components. The Python co-pilot uses an emulated baseboard management controller (BMC), structured telemetry, deterministic checks, and NVIDIA Nemotron through Nebius Token Factory. The second component is a browser-based Mission Lab that presents virtual racks, selectable fault scenarios, an inspection route, narration, and evidence reporting.

I designed the workflow to separate model-generated diagnosis from deterministic logic and simulated outcomes. The browser can display a recorded advisory without calling the model, while live inference is an explicit option. Diagnostic reports can be exported locally, and the interface clearly distinguishes simulated recovery from physical hardware operations.

I also explored host-level CPU scheduling measurements using /proc/schedstat to investigate how contention can reveal information that may not be apparent from BMC telemetry alone. Throughout development, I focused on making the project demonstrable and auditable rather than presenting a simulation as a production deployment.

Challenges we ran into

One of the main challenges was integrating a reasoning model into a workflow that needed predictable, structured output. Model responses are not automatically reliable simply because they sound convincing, so I had to pay attention to schema validation, deterministic checks, error handling, and the distinction between a diagnosis and an authorized action. I also encountered integration friction around model identifiers, reasoning-model token limits, and inference latency.

Another challenge was maintaining technical honesty across the demonstration. It is easy for a polished interface to make simulated telemetry, visual indicators, or recovery sequences appear more capable than they are. I therefore made the boundaries explicit: the Mission Lab uses synthetic telemetry and simulated inspection, and it does not control physical servers or robots. The recorded live inference is genuine model interaction, but it is not proof of accuracy on real infrastructure.

Accomplishments that we're proud of

My biggest accomplishment was bringing the project beyond a concept into a working demonstration with a hosted interface, a separate Python co-pilot, structured diagnostic output, and a documented live inference result. I successfully captured a Nemotron response identifying the simulated Rack B fan failure as critical, with a recorded inference latency of 9,817 milliseconds.

I also developed a repeatable multi-rack scenario workflow, included a healthy baseline for comparison, and implemented a simulated recovery-verification sequence. The project includes a JSON evidence report and a public demonstration video so that others can inspect the work rather than relying only on claims in a presentation.

I am particularly proud of the safety-oriented design. The system is intended to support human judgment, not bypass it. Making the distinction between live inference, deterministic checks, and simulation visible is an important part of the engineering, not merely a disclaimer.

What we learned

This project reinforced my understanding that useful AI engineering involves much more than connecting a model to an application. Reliable systems also need well-defined inputs, structured outputs, validation, failure handling, transparent evidence, and clear limits on what the software is permitted to do.

I learned that a successful model response is only one part of a trustworthy workflow. The result must be interpreted in context, checked where possible, and communicated without overstating its certainty. I also learned that latency, API constraints, and the cost of repeated inference are practical design considerations, especially when building independently with limited resources.

Most importantly, I learned to treat simulation as a valuable engineering tool while being precise about what it proves. A controlled demonstration can establish that a workflow functions under defined conditions; real-world diagnostic performance requires separate testing against representative, authorized hardware data.

What's next for Silicon Technician: Physical AI Mission Lab

My next step is to strengthen the evaluation before extending the system's operational reach. I want to expand the fault scenarios, test against more varied cases, measure false positives and missed detections, and compare model-assisted diagnosis with deterministic baselines using a documented evaluation protocol.

I also want to investigate how authorized real-world telemetry could be introduced in a controlled test environment, with appropriate security, access controls, and human approval. Any future connection to physical inspection systems or maintenance actions would require additional validation and safety engineering before implementation.

The longer-term goal is to develop Silicon Technician into a more rigorous technician-support platform: one that connects infrastructure signals to evidence-backed recommendations, makes uncertainty visible, and requires appropriate human authorization before any real intervention. This prototype is an initial step toward that goal, not a claim that the problem has already been solved.

Built With

• artificial-intelligence
• css
• data-center
• fault-diagnosis
• html
• human-in-the-loop
• javascript
• json
• llm
• nebius-token-factory
• nvidia-nemotron
• observability
• physical-ai
• predictive-maintenance
• python
• rest-api
• safety
• simulation
• systems-engineering
• telemetry