Before a photonic chip is fabricated, its layout is checked against the foundry’s set of design rules. These rules set constraints on the geometry, such as the narrowest a waveguide can be and the closest two shapes can sit. This process is called design rule checking (DRC). Every rule violation is flagged with a marker on the layout, and must be fixed or waived before the design can be cleared for manufacture.
One DRC violation and its fix. The gap between a ring and a waveguide is 100 nm, but the rule asks for at least 150 nm, so the check marks it in red. Moving the waveguide out to 200 nm clears it. The marker is computed by KLayout’s spacing check.
Engineers run DRC using a tool such as KLayout, which can be called through a layout and circuit simulation tool like PhotonForge, as these examples show for various devices: DRC guide, transceiver example. Although the checks themselves only take a few seconds, fixing the violations can take much longer. The violation markers show which rule broke and where, but not what caused it. Therefore, cleaning up these violations is tedious work, with engineers traditionally needing to trace each one by hand, or write scripts to automate the simple cases. For many production chips, there can be thousands of such violations making this extremely time consuming.
In recent work, we showed that AI agents can design photonic devices autonomously. The process involves defining the desired device performance and letting agents propose a design, simulate it and optimize it until it meets the goal (Kharel, Khavasi, Chen and Hughes, 2026). As DRC is a verifiable task, it is a natural task for agents to handle, and we have started using agents for it. For example, we recently had agents build 14 photonic circuits from published papers with SiPhoPDK, a photonic process design kit (a library of components and design rules) that we created for testing. As the figure below shows, agents not only designed these chips but also performed their own DRC cleanup as part of the process.
An agent fixes four DRC markers on a photonic circuit it built. The device outlines around two waveguides overlap, although the silicon itself meets the rules. The agent rebuilds the waveguides without outlines, and the check passes 32 s after it failed. The panel on the right paraphrases the agent’s log.
While this approach works reliably, agents are still relatively slow at these tasks. The three fixes we timed took 19 to 64 s each, while the check itself took only a few seconds. Most of that time went to the agent rereading its layout code, the DRC report, and its logs before each change. Furthermore, each fix used thousands of tokens. While all of this is acceptable for 14 small circuits, it becomes untenable for large production devices with thousands of violations. At this rate, 1,000 violations that each need their own fix would take 5 to 18 hours.
Decision models, such as Jev from TypeSafe, are a variant of AI model built to be much faster and cheaper than traditional LLMs. Like a large language model, Jev can ingest long and complex inputs, but rather than returning text, it returns a selection over a set of options you define, as well as a confidence measure. As such, while decision models are less flexible than a traditional LLM, they are potentially well suited for many tasks where the full capability of an LLM is unnecessary.
We applied decision models to DRC repair and found that they fill a useful slot in the violation cleanup process. We compared three ways of choosing DRC fixes: (a) hand-written rules, (b) a large language model (LLM), and (c) a decision model that triages. The decision model reads the possible fixes and picks one, and when it is not confident, it hands the choice to the LLM. We tested this on a digital and a photonic DRC benchmark. On both, the LLM found the best fixes, but with the decision model in front of it, we kept nearly all of the LLM’s quality at under half the cost.
The study
We compared three ways to choose DRC fixes for a given violation:
- (a) Hand-written rules. A fixed rule picks one of the proposed fixes.
- (b) Large language model. An LLM (GPT-6 Astra) reads a full description of the violations and of each proposed fix, and picks one.
- (c) Decision model. A decision model (Jev) reads the proposed fixes and picks one, with a confidence score. When its confidence was below a cutoff, we handed the choice to Astra. We also ran Jev alone, without the hand-off.
Three ways to fix DRC markers. (a) A designer or a script applies a fixed rule. (b) An AI agent or large model reads the report and picks a targeted fix. (c) A decision model picks a fix from a list and hands the cases it is unsure about to a large model.
We tested all three on two benchmarks, one digital and one photonic.
The digital benchmark uses 7 digital chip layouts from the public DAC26 DRC benchmark, with 1,628 DRC violations in total. For each layout, we ran 20 rounds of the same loop:
- Run DRC and list the violations that remain.
- A script proposes 16 small edits that might fix one of them, such as widening or moving a metal shape, or resizing a via to match the metal around it.
- The method under test picks one edit.
- We apply the edit and run DRC again. The edit stays only if violations go down and the circuit stays connected. Otherwise we undo it.
After 20 rounds, we count the violations each method removed. We count only edits that changed real shapes on the chip, because some edits lower the count just by splitting shapes differently. With only 20 rounds per layout, no method fixes every violation, so the count compares how well each method uses the same rounds.
The photonic benchmark is one we built from SiPhoPDK. It has 60 groups of violations, mostly planted on two ring test chips, plus the three real ones from the agent build above. Here the choice is less about nudging one shape and more about where and whether to fix it. The options include changing the project’s own copy of a component or the shared design kit, rebuilding a route, asking a person, or waiving it as a test structure. The right choice often depends on design intent that the markers don’t show, so each group comes with a short design note and 3 to 6 possible fixes. We checked every fix in advance, so each pick is simply right or wrong.
To see how much results vary, we ran each model three times on each benchmark; the charts show the range.
Results
Real fixes and time spent choosing on the digital benchmark. For (b) and (c), bars show the average over three runs and whiskers show the range. For (a), the bar is the average of the two rules and the whisker spans them.
The LLM (b) found the most fixes, 125 per run, about 10% more than the hand-written rules (a). However, it spent about 36 minutes per run choosing the right fixes. The decision model (c) on its own did about as well as the simple rules (a) and took under half a minute. However, when it handed its low-confidence choices to the LLM, it found nearly as many fixes as (b), 121 to 125 against 125, in under half the time spent choosing (16 minutes against 36) and at about 40% of the cost ($12 against $31 per run, at estimated API prices).
In short, the decision model alone matches simple rules. But with an LLM behind it, it gets close to the LLM’s results in under half the time spent choosing.
On the photonic benchmark, we see the same result.
Correct fixes picked and cost on the photonic benchmark. Bars show the average over three runs, and whiskers show the range. The dashed line marks a random pick.
We left out the hand-written rules here. We generated these test cases from known problems, so rules written for them already encode the answers. Otherwise the pattern holds: the decision model alone falls short of the LLM, and with the LLM behind it, it matches the LLM at under half the cost.
Discussion
Decision models look promising for DRC repair. Paired with a large model, they act as triage. They handle the easy choices and send the hard ones up, which kept nearly all of the large model’s quality on both benchmarks at under half its cost.
They are not always the right tool. When a simple rule already picks well, as it did on the digital benchmark, the rule is free, and a decision model adds neither speed nor accuracy. When a fix needs new code or a judgment call that none of the listed fixes covers, an agent is the right tool. A decision model also needs clear facts, not raw data. When we gave Jev raw layout coordinates instead of a short summary, it found far fewer fixes. On the photonic layouts, it needed more than a short summary: without the design note and other details, Jev did no better than a random pick.
The hand-off cutoff also depends on the problem. It was 0.2 on the digital layouts, but we had to raise it to about 0.6 for the photonic ones, so it has to be set for each new problem on cases with known answers. We set the photonic cutoff on the same cases we report, but it held up on cases left out of the tuning. Our photonic benchmark is also small and built by us. Next, we plan to repeat the comparison on large photonic layouts with problems we did not plant ourselves, and to try other decision models, such as OpenAI’s new Decisions API and open models that run on a laptop.
The same idea applies well beyond DRC, because many engineering workflows sit between a fixed script and a full AI agent. Whenever analysis is complex but the next steps can be formulated as a short list of options, a decision model makes sense to try as a faster, cheaper, middle step, with an agent behind it for cases it can’t handle confidently.