SECS/GEM Transaction Intelligence Agent

The Problem

Semiconductor equipment talks to the factory host over SECS/GEM on HSMS. Every command, event report, alarm and acknowledgement crosses the wire as an SxFy message. When something goes wrong during equipment bring-up, host integration or a production run, the answer is always in the log — and the log is enormous.

A single shift produces well over a hundred thousand lines. Finding the one transaction that broke means an experienced engineer scrolling through it by hand, mentally pairing primaries with secondaries and timing reply windows.

The failures they are hunting for are always the same handful of shapes:

The cost is consistent across every project:

Hours spent reading raw logs per incident

Expert-dependent — the knowledge lives in a few heads

Delayed integration cycles and host hand-offs

No existing tool explains SECS/GEM in engineering terms

The Solution

A diagnostic pipeline that combines protocol-aware deterministic rules with AI reasoning. The rules know what the SEMI standards define. The AI explains what the standards cannot tell you — why it happened here, on this tool, in this sequence.

The outcome is an engineer-readable diagnostic: the failure explained, a probable root cause, a confidencescore, and actions to take.

System Architecture

Six layers, top to bottom. Raw logs are ingested and parsed, fan out across the rule engine, the vector storeand the transaction store, then converge on the evidence builder and the guardrailed reasoning layer beforereaching the engineer.

The amber accents mark the two deterministic components — the raw log itself and the Protocol Rule Engine.Everything the agent concludes traces back to one of them.

Agentic design

A Coordinator Agent routes work to five specialists, each owning one concern, then assembles a unified diagnostic report.

Separating concerns this way is what makes the system extensible: a new rule pack or a new log format plugsinto one agent without touching the reasoning layer.

The product: two screens

The entire workflow is two screens. That is deliberate — an engineer mid-incident should not be navigating anapplication.

Screen 1 · Upload

Drop an HSMS log file in. No format selection and no configuration: the parser reads the first line, identifiesthe format and starts work. Analysis runs as a background job, so the session opens immediately and updateswhile parsing continues.

Previous sessions stay listed with their message counts and violation totals, so a returning engineer picks upwhere they left off.

Everything else happens here. One screen, five regions, no drilling down. 

Nothing is asserted without evidence. The raw evidence block carries primary_line: 6813 and theverbatim log entry. An engineer can open the log at that line and check the conclusion against the wire ratherthan trusting it — which is the difference between a tool engineers adopt and one they quietly stop opening.

Worked example: the transaction on screen

The dashboard above is a real diagnostic. Here is what produced it.

On the wire. At 10:58:38.463, line 6813 of ProcessJob_Notcreated.txt: 

A primary S16F9 is sent. Its secondary, S16F10, is never returned.

What each stage did:

The corrective actions it generated:

1. Verify remote equipment connectivity and check equipment-side logs (device console / debug logs) forS16F9 processing errors or exceptions around 2025-02-20T10:58:38.

2. Increase the T3 timeout threshold from 10.0 s to 15.0–20.0 s if the equipment is known to have slowerresponse times — but first confirm this is not masking a deeper issue.

3. Review the equipment firmware version and SECS/GEM implementation for known bugs related to thismessage handling.

Note the second one. It offers the pragmatic fix and immediately warns against using it as a band-aid. That isthe tone the guardrails are tuned for: the agent is a colleague with an opinion, not an autocomplete.

An engineer would have found this. It would have taken them an afternoon of scrolling 8,047 lines andmentally tracking which primaries came back. The agent did it on upload, and showed its work.

Validated on real logs

Two production logs, two different vendor formats, no synthetic data.

The demo session — EAF / EPIV format 

Findings included the S16F9 T3 timeout detailed above, a series of protocol order anomalies across S16F9,S16F7, S1F17 and S6F11, and an unexpected S6F12 sequence — each at 82–92% confidence.

The scale test — MwlHSMS format

What it surfaced:

• 173 discarded messages (rc -4) — clustered as a burst at 10-second intervals, consistent with reply-window exhaustion on a connection that was already dead. Classified separately from a T3 timeout, because the cause is connection-level, not handler-level.

• A robot command timeout — 15,000 ms on an RQ RVSN command, followed by anAsyncCommandFailureException.

• An equipment state transition — Initializing → Error, correlated in time with the command failure above.

The two logs together are the point. They come from different vendors in different formats — one line-oriented HSMS trace, one bracketed connector log — and neither required configuration. The parser auto-detects the format from the first line. The same rule engine, the same knowledge base and the samereasoning layer handled both.

Under the hood

Two deployment postures. With Claude or OpenAI for best reasoning quality, or with a local Ollama modelwhen log data must not leave the network — a real constraint in fab environments. The rule engine, parserand knowledge base are identical either way; only the reasoning layer swaps. And if no model is reachable atall, the system degrades to rules-only output rather than failing.

What's next

The current agent runs a single automated pass. The roadmap makes it steerable and continuously learning.

Human-in-the-loop. The engineer reviews findings and issues commands — approve, reject or redirect thereasoning. Follow-ups like "re-check T4" or "focus on PM1" refine the analysis in place.

Pluggable skills. New protocols, rule packs and equipment types are added as skills without touching thecore engine — E84 handoff, E87 carrier management, recipe-step verification.

Incremental cross-log analysis. The engineer selects a reported SECS/GEM incident, which locks its timewindow, then uploads any additional subsystem log — PM, SMC, robot controller. The agent analyses itagainst that same window and produces a combined root-cause report, explaining the SECS/GEM incidentwith evidence from the correlated log.

Why it matters

The broader point: this is a reusable, domain-specific AI module that extends the MindAI platform intosemiconductor automation — deterministic protocol analysis, vector similarity learning and generativeexplanation, combined into one engineering copilot.