BoardSafety：从制造商文档中提取面向 AI 的数据，保障开发板安全

# AI-Ready Data from ManufacturerDocumentation for Development-Board Safety
Source: [https://arxiv.org/html/2610.33448](https://arxiv.org/html/2610.33448)
## BoardSafety: AI\-Ready Data from Manufacturer Documentation for Development\-Board Safety

Xinyan WangAffiliation:Portland State University Portland, OR, USA xinyw@pdx\.eduKunpeng LiuAffiliation:Clemson University Clemson, SC, USA kunpenl@clemson\.edu

###### Abstract

The development of large language models \(LLMs\) are capable to assist with hardware experiments\. In this scenario, this raises a practical question: Can LLMs determine whether a proposed operation is safe for a specific development board? Documented operating limits and safety requirements are board\-specific, even across products from the same manufacturer\. This variation makes board\-specific safety judgments by an LLM difficult to evaluate\. To address this problem, we introduce theBoardSafety Benchmark\. The benchmark is built from vendor datasheets and hardware guides\. For data transformation, these documents are converted into a board\-specific safety rule base and are then used to create labeled operating scenarios\. Each data item pairs a board and a proposed operation to an applicable safety rule with ground\-truth label, indicating the level of safety\. The categorized level for each operation includessafe,unsafe, orinsufficient\-info\. In addition, the benchmark covers diverse operations, board\-specific cases, boundary conditions, and missing\-information cases\. We evaluate a series of models by varying their access to board\-specific rules and the use of structured\-rationale prompting\. Our results demonstrate that providing the safety rules generally improves accuracy, whereas structured\-rationale prompting produces gains that vary across models and rule\-access conditions\. Overall, the evaluated models cannot yet reliably determine whether an operation is safe, which implies that critical exploration is required for this field\.

###### Index Terms:

Hardware safety, large language models, benchmark, operation safety, development board

## IIntroduction

Large language models \(LLMs\) are increasingly consulted during embedded system development and debugging\[[1](https://arxiv.org/html/2610.33448#bib.bib9)\]\. Unlike a software bug, an LLM’s response that leads the hardware to go beyond its operational limits can permanently damage the board and introduce significant safety risks\. Assessing whether an operation is safe requires more than general electronics knowledge, because the governing limits are specific to each board and differ even between products of the same manufacturer\. Therefore, an LLM must identify the applicable manufacturer\-specified constraint for the given board and setup\. Figure[1](https://arxiv.org/html/2610.33448#S1.F1)shows two boards connected to the same 9 V supply through their VIN pins\. This voltage is within the documented 6–16 V range for the Arduino Due\[[2](https://arxiv.org/html/2610.33448#bib.bib32)\], but exceeds the 5\.5 V limit for the Arduino MKR WiFi 1010\[[3](https://arxiv.org/html/2610.33448#bib.bib33)\]\. The correct verdict is thereforesafefor the Due andunsafefor the MKR WiFi 1010 under the stated constraints\. However, Gemma\-3\-12B labels both operationssafeand claims that neither violates the voltage limits, even though both boards’ rules are provided in its context\. This example motivates our research question: Can LLMs reliably determine whether a proposed operation is safe for a specific development board?

![Refer to caption](https://arxiv.org/html/2610.33448v1/fig1_example.png)Fig\. 1:Despite access to manufacturer rules, Gemma\-3\-12B gives the same safety verdict to a board\-swap pair with different VIN limits\.Prior studies show that LLM advice can pose safety risks in specific contexts\[[4](https://arxiv.org/html/2610.33448#bib.bib1),[5](https://arxiv.org/html/2610.33448#bib.bib4)\], and that in specialized domains, a safe response requires the model to retrieve relevant domain constraints and apply them to the specific situation\[[6](https://arxiv.org/html/2610.33448#bib.bib2),[7](https://arxiv.org/html/2610.33448#bib.bib3)\]\. Hardware benchmarks offer a complementary perspective by grounding LLM evaluation in concrete engineering artifacts and verifiable criteria\. These benchmarks\[[8](https://arxiv.org/html/2610.33448#bib.bib5),[9](https://arxiv.org/html/2610.33448#bib.bib6),[10](https://arxiv.org/html/2610.33448#bib.bib7),[11](https://arxiv.org/html/2610.33448#bib.bib8),[12](https://arxiv.org/html/2610.33448#bib.bib18),[13](https://arxiv.org/html/2610.33448#bib.bib10)\]assess whether a generated design or implementation is valid for the target platform, but none test whether an LLM selects and applies the manufacturer constraint governing a proposed operation on a specific development board\. We address this gap by evaluating LLM safety judgments against the documented constraints manufacturers provide for the specified board\.

Although manufacturer documentation is the primary source of hardware\-safety constraints, it is not directly usable for evaluating LLM judgments\. Safety\-relevant information is scattered across datasheets, hardware guides, and reference manuals, mixing hard operating limits with recommendations and descriptive specifications\[[14](https://arxiv.org/html/2610.33448#bib.bib19)\]\. These limits can take different forms, including numeric ranges, maximum values, prohibited configurations, and procedural notes\. Making such documentation AI\-ready therefore means more than collecting the information\[[15](https://arxiv.org/html/2610.33448#bib.bib20),[16](https://arxiv.org/html/2610.33448#bib.bib25),[17](https://arxiv.org/html/2610.33448#bib.bib21)\]\. Each constraint must be traceable to its source, encoded so a proposed operation can be compared mathematically against it, and tagged to indicate how much information is directly documented rather than inferred\. We introduceBoardSafety, which implements these requirements as five properties of its rule base: traceable, computable, filterable, consistent, and derivable\.

BoardSafety consists of two artifacts\. The first is a rule base containing 490 constraint records extracted from 30 manufacturer documents that cover 53 development boards from five vendors\. Each record in this rule base includes a normalized constraint, the document source, and an evidence tier\. The second is a benchmark of 298 scenarios derived from this rule base\. Each scenario pairs a specific board and a proposed operation with the applicable constraint, and a gold label ofsafe,unsafe, orinsufficient\-info\. We fix each label by comparing the stated operating value or configuration with the documented constraint before an LLM renders the scenario text so that we can recompute every label from the rule base alone\. The scenarios include minimal pairs that vary only the board or only the decisive value, as well as underspecified cases that omit the decisive value\. We use the benchmark to study how rule access and structured\-rationale prompting affect the LLM judgments\.

Our experiments on six open\-weight LLMs yield a maximum accuracy of 69\.13% across 7,152 responses, with only four of 24 model–condition combinations exceeding the 48\.3% always\-unsafe baseline by their 95% Wilson lower bounds\. Access to rules yields larger and more consistent gains than structured\-rationale prompting, yet only 13\.4% of 216 rationales in a stratified review correctly identify and apply the applicable constraint\. Our findings highlight persistent limitations in constraint\-based reasoning, particularly in board\-swap, near\-boundary, and underspecified cases\.

This paper makes the following contributions:

- •We build an AI\-ready rule base of 490 manufacturer\-documented constraints with five verifiable properties, so every gold label is traceable and recomputable\.
- •We construct the BoardSafety benchmark for board\-specific hardware safety judgment, testing whether LLMs apply board\-specific constraints and abstain when information is missing\.
- •Our experiments on six LLMs show that aggregate accuracy masks persistent failures in board sensitivity, boundary handling, abstention, and constraint application\.

## IIRelated Work

### II\-AContext\-Specific Safety of LLM Responses

LLMs are expected to generate advice that is safe and appropriate for the context in which it is used\. Existing studies examine harmful advice in everyday situations and safety failures in specialized domains\[[4](https://arxiv.org/html/2610.33448#bib.bib1),[6](https://arxiv.org/html/2610.33448#bib.bib2),[18](https://arxiv.org/html/2610.33448#bib.bib26),[7](https://arxiv.org/html/2610.33448#bib.bib3)\]\. However, beyond recognizing hazards, models must apply the relevant constraints to each case\. They should also abstain when the available information is insufficient\[[19](https://arxiv.org/html/2610.33448#bib.bib22),[20](https://arxiv.org/html/2610.33448#bib.bib27),[21](https://arxiv.org/html/2610.33448#bib.bib28),[22](https://arxiv.org/html/2610.33448#bib.bib29)\]\. For example, judging a power connection requires comparing the supply voltage with the board’s input limits\. A model should request this safety information before giving a safety verdict\.

Existing studies evaluate LLM safety through commonsense advice, clinical decision\-making, and laboratory risk assessment\. Hager et al\.\[[6](https://arxiv.org/html/2610.33448#bib.bib2)\]found that LLMs struggled to use relevant patient information and follow clinical guidelines in realistic decision\-making tasks\. NOHARM\[[5](https://arxiv.org/html/2610.33448#bib.bib4)\]shows that LLMs performing strongly on medical knowledge benchmarks can still generate potentially harmful recommendations\. LabSafety Bench\[[7](https://arxiv.org/html/2610.33448#bib.bib3)\]reports similar limitations in hazard identification and risk assessment for laboratory procedures\. These studies show that safe responses require models to apply domain\-specific evidence to the specific decision context\.

LLMs may ground their judgments on both parametric knowledge and contextual information provided in the prompt\[[23](https://arxiv.org/html/2610.33448#bib.bib15),[24](https://arxiv.org/html/2610.33448#bib.bib16),[25](https://arxiv.org/html/2610.33448#bib.bib12)\], but they do not reliably reconcile these sources when they conflict\[[24](https://arxiv.org/html/2610.33448#bib.bib16),[26](https://arxiv.org/html/2610.33448#bib.bib17)\]\. A verdict alone therefore does not reveal which source grounds it\. The BoardSafety examines this problem in development\-board operations by evaluating whether model responses follow the relevant manufacturer constraint\.

### II\-BLLM Benchmarks for Hardware and Embedded Systems

Hardware benchmarks evaluate LLMs on circuit understanding and hardware design tasks\. These tasks require specialized engineering knowledge and physical constraints that general language and coding benchmarks do not adequately assess\. Existing benchmarks broadly cover two areas: interpreting existing circuits and generating hardware designs\. Most focus on engineering reasoning and design correctness\. For circuit interpretation, CIRCUIT tests analog\-circuit understanding and electrical reasoning\[[8](https://arxiv.org/html/2610.33448#bib.bib5)\], while PCB\-QA and PCB\-Bench examine connectivity, datasheet information, placement, routing, and design\-rule compliance\[[9](https://arxiv.org/html/2610.33448#bib.bib6),[10](https://arxiv.org/html/2610.33448#bib.bib7)\]\. For design generation, HWE\-Bench evaluates board\-level schematics through electrical\-rule checks and circuit simulation\[[11](https://arxiv.org/html/2610.33448#bib.bib8)\]\. However, these benchmarks do not specifically assess whether a proposed development\-board operation complies with manufacturer\-documented safety limits\.

Embedded\-system evaluations focus on implementation and execution in hardware\-dependent settings\. Englhardt et al\. evaluate generated embedded software using an automated hardware\-in\-the\-loop testbench\[[1](https://arxiv.org/html/2610.33448#bib.bib9)\]\. EmbedBench covers embedded programming, circuit design, and cross\-platform migration across Arduino, ESP32, and Raspberry Pi Pico\[[13](https://arxiv.org/html/2610.33448#bib.bib10)\]\. IoT\-SkillsBench evaluates programming agents across embedded platforms and peripherals through real hardware execution\[[27](https://arxiv.org/html/2610.33448#bib.bib23)\]\. EmbedCopilot\-Bench extends evaluation to multimodal assistance for hardware operation, software configuration, and code generation\[[28](https://arxiv.org/html/2610.33448#bib.bib24)\]\. These studies examine whether models can produce working implementations or useful development instructions\. They do not provide a dedicated evaluation of constraint\-grounded safety verdicts, including abstention when essential information is missing\. BoardSafety addresses this gap by evaluating proposed operations against the documented constraints of the specified board\.

## IIIBoardSafety Benchmark

![Refer to caption](https://arxiv.org/html/2610.33448v1/fig2_pipeline.png)Fig\. 2:BoardSafety construction pipeline\. We first extract board\-specific constraints from manufacturer documentation and derive safety labels through rule\-based comparisons\. We then use LLMs to generate scenarios while preserving the fixed operating conditions and labels\. Finally, we validate the rules and scenarios through deterministic checks, blind model validation, and human review\.BoardSafety evaluates whether an LLM can judge a proposed operation against the documented constraints of a specific development board\. Each item specifies a board and an operating setup, and the model returns one of three verdicts:safe,unsafe,insufficient\-info\. Labels describe compliance with the selected vendor constraints under the stated scenario assumptions\. The reference verdict isunsafewhen the setup violates an applicable documented safety constraint,insufficient\-infowhen no violation is established but information needed to determine compliance is missing, andsafewhen the available information establishes compliance with these constraints\.

Figure[2](https://arxiv.org/html/2610.33448#S3.F2)summarizes the construction pipeline\. We first extract board\-specific rules from vendor documentation and derive a reference label for each sampled operating setup\. An LLM then expresses the setup as a natural\-language scenario while preserving the fixed conditions and label\. The resulting items undergo deterministic validation and additional model or human review\.

### III\-AAI\-Readiness

Vendor documentation does not directly provide items that are ready for evaluation\. because constraints are scattered across documents, mixed with descriptive specifications, and expressed in different forms\. For LLM evaluation, we define AI\-readiness using five properties that associate source evidence, structured constraints, and reference labels:

1. 1\.Traceable: selected rules retain source passages and document references for verification\.
2. 2\.Computable: numeric limits encode quantities, operators, values, and units for automatic comparison\.
3. 3\.Filterable: statement type and evidence tier determine which rules can seed benchmark items\.
4. 4\.Consistent: duplicate and conflicting bounds are resolved by identifying the applicable binding constraint\.
5. 5\.Derivable: each item records the comparison or configurational rule used to derive its label\.

### III\-BSource Corpus and Rule Base

We construct a rule base of 490 records across 17 hazard categories from 30 vendor documents covering 53 development boards from five vendors\. We use GPT\-5\.6 Sol\[[29](https://arxiv.org/html/2610.33448#bib.bib31)\]to extract candidate rule records from vendor documentation and manually review a subset against the source passages\. Each record stores a normalized constraint and source\-document metadata\. Of the 490 records, 487 also include a verbatim supporting passage\. Each record has a statement type and an evidence tier for rule selection\. The statement type separates user\-violable limits from descriptive specifications, internal\-node properties, and procedural requirements\. Evidence tiers distinguish documented facts from inference\. Tier A records state both the constraint and its numeric limit\. Tier B records state a constraint without a numeric limit\. In Tier C1, the limit is documented but the damage pathway is inferred\. In Tier C2, both are inferred\.

### III\-CRule Selection and Label Derivation

The standard seed pool contains 304 Tier A/B records classified as user\-violable design limits\. At sampling time, we exclude the 17 records concerning cumulative effects because our scenario representation does not model exposure duration, leaving 287 records in this pool\. For the underspecified family, we additionally allow Tier C1 records that quote a limit but infer the damage pathway, because these items test whether the available information is sufficient to evaluate the stated constraint\. Family\-level quotas, per\-board caps, and a coverage sweep yield 300 candidate items from 213 seed rules\.

For an eligible rulerrand sampling regimegg, we define

σ⁡\(r,g\)→\(x,ℓ,a\),\\sigma\(r,g\)\\rightarrow\(x,\\ell,a\),\(1\)wherexxis an operating condition,ℓ\\ellis its gold label with respect to the selected constraint, andaais the rule\-based justification for that label\.

For the scenario families listed in Table[I](https://arxiv.org/html/2610.33448#S3.T1), the sampling regimes specify how operating scenarios and labels are constructed\. Violation regimes produceunsafeitems by placing the relevant quantity beyond the selected documented limit or specifying a prohibited configuration\. Two regimes producesafeitems: in\-spec items stay at least 15% below a single upper limit, or at least 15% of the interval width from each endpoint of a bounded range, whereas documented\-safe items describe an operation explicitly permitted by the vendor under the stated conditions\. Boundary pairs place the relevant quantity at 95% and 105% of the same upper limit, producing opposite labels\. Board\-swap pairs hold the operating setup fixed while changing the board\. The selected value satisfies one board’s limit and violates the other’s, with a margin of at least 10% relative to each upper limit; rule pairs without a feasible shared value are skipped\. The same setup is therefore labeledsafefor one board andunsafefor the other\. The board\-swap and boundary families contain 16 and 15 minimal pairs, respectively\. Underspecified items omit a quantity required to evaluate the selected constraint\. The remaining information must admit both satisfying and violating assignments to that quantity, so these items receive the labelinsufficient\-info\.

TABLE I:Scenario families and label distribution\.
### III\-DRule\-Grounded Scenario Generation

After fixingxxandℓ\\ell, we use Claude Opus 5\[[30](https://arxiv.org/html/2610.33448#bib.bib30)\]to render each rule instance as a natural\-language scenario:

ρ⁡\(r,g,x\)→s,\\rho\(r,g,x\)\\rightarrow s,\(2\)It takes the seed rule and the complete rule set of the board, withxxandℓ\\ellas immutable inputs\. The generator also returns anasserted\_factsrecord that links each stated quantity to a specific span inss\. This enables the validator to verify thatxxis stated correctly inss\. Combined quantities, such as the total current of four LEDs drawing 10 mA each from one pin, must be explicitly stated when they determine the label, rather than left to the reader to deduce\. Distractors, which are quantities stated other than the decisive one, must adhere to all rules of the board\. If a distractor conflicts with these rules, it is revised without alteringxxorℓ\\ell, and the item is re\-validated\. In the case ofinsufficient\-infoitems, the decisive quantity is intentionally omitted, but all stated quantities remain consistent with the rule set\. Furthermore, both items of a minimal pair are realized from a single narrative and differ in the board identity or decisive value, with any accompanying changes restricted to details required by that change\.

### III\-EEscalating Quality Control

Quality control combines automatic checks, blind model validation, and human review\. Of the 298 retained items, blind validation covers the pre\-repair versions of 218 items, and human audit covers 98, with 91 items in both groups\. These reviews cover 225 items, and all retained items pass deterministic validation\.

Provenance audit\.To verify extracted records against their sources, two reviewers independently examine a stratified sample of 59 records\. They confirm 55 records and correct 4\. All 59 records are traceable to supporting passages\.

Deterministic validation\.To check that generated scenarios preserve the fixed conditions and labels, a rule\-based validator checks stated values, structured facts, and label consistency\. All 300 candidate items pass these checks\. Because validation relies on the extracted records, it cannot detect errors in their interpretation of the source documents\.

Blind validation\.To identify errors that deterministic validation misses, GPT\-5\.6\[[29](https://arxiv.org/html/2610.33448#bib.bib31)\]independently labels 220 items without access to gold labels or metadata, agreeing on 209\. Reviewing the complete board rule set leads to repairs to 31 rule records\. After regeneration, a 60\-item re\-run agrees with the derived label on 56\.

Human audit\.To address cases that cannot be settled by the automated stages, two auditors with embedded\-system experience independently review 100 items and reconcile any disagreements\. Among the 11 disagreements between blind validation and the derived labels, they retain 9 labels and exclude 2 items whose seed records do not express user\-violable constraints\.

### III\-FReleased Benchmark

The released benchmark consists of 298 items across 46 of the boards, along with 211 seed rules\. It contains 113safe, 144unsafe, and 41insufficient\-infoitems\. Each board contributes between 1 and 16 items, so we provide aggregate and family\-level results rather than rankings for each board\. Each item is accompanied by its seed rule, the verbatim source passage, the evidence tier, the comparisonaafrom which its label is derived, and its validation and audit outcomes\. This detailed information allows each label to be traced back to a vendor sentence and recomputed without a model\.

TABLE II:Accuracy \(%\) across rule\-access and rationale\-format conditions\.T0T\_\{0\}uses direct\-answer prompting;T1T\_\{1\}adds a four\-step structured rationale\.Δ=T1−T0\\Delta=T\_\{1\}\-T\_\{0\}in percentage points\. Pooled values averageR0R\_\{0\}andR1R\_\{1\}\.

## IVExperiments

### IV\-AExperimental Setting

Implementation details\.We evaluate six open\-weight instruction\-tuned LLMs on all 298 BoardSafety scenarios across 46 development boards: Qwen3\-0\.6B and Qwen3\-4B\[[31](https://arxiv.org/html/2610.33448#bib.bib11)\], Gemma\-3\-1B and Gemma\-3\-12B\[[32](https://arxiv.org/html/2610.33448#bib.bib13)\], and Llama\-3\.2\-3B\-Instruct and Llama\-3\.1\-8B\-Instruct\[[33](https://arxiv.org/html/2610.33448#bib.bib14)\]\. These models cover three families, with a smaller and a larger model from each family\. All conditions use temperature 0 and a generation cap of 2,048 tokens, with native thinking disabled for Qwen3\[[31](https://arxiv.org/html/2610.33448#bib.bib11)\]\. Only formatting failures trigger retries\. We score the final valid response for each item\.

We use a2×22\\times 2design that varies rule access and rationale prompting\. UnderR0R\_\{0\}, models receive only the board name and scenario\. UnderR1R\_\{1\}, they additionally receive normalized constraints and limits for that board\. UnderT0T\_\{0\}, models return a verdict with a brief justification of one to two sentences\. UnderT1T\_\{1\}, they additionally provide four rationale steps covering the relevant constraint, decisive quantity, comparison, and conclusion, with a specified length limit for each step\. Each model answers every scenario underR0​T0R\_\{0\}T\_\{0\},R0​T1R\_\{0\}T\_\{1\},R1​T0R\_\{1\}T\_\{0\}, andR1​T1R\_\{1\}T\_\{1\}, producing 7,152 responses\.

Metrics\.We define accuracy as the proportion of verdicts matching the gold labels and report 95% Wilson confidence intervals\. The always\-unsafe baseline predictsunsafefor every item and achieves144/298=48\.3%144/298=48\.3\\%accuracy\. Dangerous acceptance refers to the proportion ofunsafeitems predicted assafe, and safe rejection indicates the proportion ofsafeitems predicted asunsafe\. We also examine accuracy by scenario family, the frequency ofinsufficient\-infopredictions, and the proportion of board\-swap and boundary pairs for which both items are correctly labeled\.

Explanation\.We evaluate model rationales using rationale length and the correctness of constraint application\. After the model generates its response, we measure the length of the brief justification underT0T\_\{0\}and the four\-step rationale underT1T\_\{1\}using the model’s tokenizer\. To assess correctness, we sample three responses per model, condition, and gold label, for a total of 216 responses\. A single LLM judge evaluates each response using the original prompt, reference rule, and reference comparison, with model identity withheld\. It checks rule selection, the decisive quantity, the comparison, and the conclusion\. A response passes only if all four are correct\. We report the percentage of sampled responses that pass\.

Fig\. 3:Safety judgment errors across rule\-access and rationale\-prompting conditions\. Panel \(a\) shows the proportion of unsafe operations classified as safe; panel \(b\) shows the proportion of safe operations classified as unsafe\. Lower rates indicate better performance\.
### IV\-BRQ1: How Do Rule Access and Rationale Prompting Affect the Reliability of Safety Judgments?

To evaluate judgment reliability, we compare accuracy against the always\-unsafe baseline and examine dangerous acceptance and safe rejection\. We compare rule access at each fixed rationale\-prompting condition and rationale prompting at each fixed rule\-access condition\. Table[II](https://arxiv.org/html/2610.33448#S3.T2)reports accuracy across all model–condition combinations, ranging from 36\.91% to 69\.13%\. Gemma\-3\-12B achieves the highest accuracy underR1​T1R\_\{1\}T\_\{1\}, compared with the 48\.3% baseline\. Only 4 of the 24 combinations have a 95% Wilson lower bound that exceeds this baseline\.

Rule access produces the larger average accuracy gain, as shown in Table[II](https://arxiv.org/html/2610.33448#S3.T2)\. On average, it increases accuracy by 10\.57 percentage points underT0T\_\{0\}and 10\.35 points underT1T\_\{1\}\. Rationale prompting increases mean accuracy by 4\.53 percentage points without rules and 4\.31 points with rules\. Its benefit varies across models and rule\-access conditions\. For Qwen3\-4B, the change is−2\.68\-2\.68points without rules and\+13\.09\+13\.09points with rules\. These results show that rule access provides the larger average improvement, while structured\-rationale prompting does not improve every model\.

Figure[3](https://arxiv.org/html/2610.33448#S4.F3)shows that substantial safety errors remain despite the accuracy gains\. On average, dangerous acceptance falls from 66\.3% underR0​T0R\_\{0\}T\_\{0\}to 24\.7% underR1​T1R\_\{1\}T\_\{1\}, while safe rejection rises from 35\.4% to 48\.2%\. This comparison reflects the combined changes in rule access and rationale prompting\. Fewer unsafe operations receive approval, but more safe operations are rejected\. Thus, higher accuracy does not ensure reliable safety judgments\.

### IV\-CRQ2: What Does Aggregate Accuracy Obscure?

To examine what aggregate accuracy may obscure, we compare performance across scenario families and check if both items of each minimal pair receive the correct labels\. Table[III](https://arxiv.org/html/2610.33448#S4.T3)shows the family\-level spread underR1​T1R\_\{1\}T\_\{1\}: all six models score only 0–19\.5% on underspecified cases, versus 66\.4–84\.1% on violation cases\. Despite its 69\.13% overall accuracy, Gemma\-3\-12B reaches 86% on in\-spec cases and 77% on violation cases but only 63% on boundary cases\. It correctly labels both items in 11 of 16 board\-swap pairs and 4 of 15 boundary pairs\. Therefore, the overall accuracy does not demonstrate that the model consistently distinguishes changes in board\-specific limits or operating values near a boundary\.

TABLE III:Per\-item accuracy \(%\) by scenario family and model underR1​T1R\_\{1\}T\_\{1\}\.We also notice that the models struggle to recognize missing information\. UnderR1​T1R\_\{1\}T\_\{1\}, they predictinsufficient\-infofor only 0\.3–4\.0% of all scenarios, although underspecified cases account for 13\.8% of the benchmark\. Gemma\-3\-12B correctly identifies only 8 of the 41 underspecified cases, yielding an accuracy of 19\.5% on this subset\. Moreover, 26 of the 27 scenarios answered incorrectly by all six models under this condition are underspecified\. These results show that models frequently give definite verdicts despite lacking the information needed to assess safety\. Together with the board\-swap and near\-boundary results, this finding highlights limitations that aggregate accuracy alone does not capture\. Safety evaluation should therefore assess sensitivity to board\-specific limits, handling of operating boundaries, and abstention when essential information is missing\.

### IV\-DRQ3: Do LLM Responses Follow the Safety Constraints?

To examine whether model rationales effectively support their verdicts, we evaluate a sample of responses using four criteria for applying constraints\. Table[IV](https://arxiv.org/html/2610.33448#S4.T4)reports the pass rates for each criterion and for all four jointly\. Only 13\.4% of these responses pass all four criteria\. Among the responses that provide a correct verdict, 62\.8% fail to satisfy at least one criterion\. These findings show that a correct verdict does not necessarily come with a well\-supported explanation\. The reported rates describe the stratified review sample, which gives equal weight to the three gold labels\.

TABLE IV:Constraint\-application pass rates in the stratified review \(216 responses and 54 per condition\)\.We examine whether structured\-rationale prompting improves constraint application\. Across all 7,152 responses, the median visible\-rationale length increases from 32 tokens underT0T\_\{0\}to 79 underT1T\_\{1\}\. However, Table[IV](https://arxiv.org/html/2610.33448#S4.T4)shows that, in the reviewed sample with rule access, constraint\-application correctness is 24\.1% underR1​T0R\_\{1\}T\_\{0\}and 13\.0% underR1​T1R\_\{1\}T\_\{1\}\. These results show that structured\-rationale prompting does not necessarily improve constraint application, even when it produces longer explanations\. Since the prompting conditions also differ in their required reasoning steps, the observed difference cannot be attributed to rationale length alone\. These findings highlight the need to evaluate constraint application directly, as longer explanations do not necessarily indicate correct application\.

## VConclusion and Future Work

Safe hardware advice requires LLMs to follow board\-specific operating limits and recognize when essential information is missing\. To evaluate these capabilities, we introduce BoardSafety, a benchmark for judging whether proposed development\-board operations comply with manufacturer\-documented constraints\. We build the benchmark from vendor datasheets and hardware guides, extracting structured constraints and using them to derive reference labels\. We then generate operating scenarios with fixed labels and validate them through deterministic checks, blind model validation, and human review\. We conduct several experiments on BoardSafety to examine how rule access and structured\-rationale prompting affect LLM safety judgments\. Our experiments show that providing relevant rules improves performance but does not ensure correct constraint application\. Models still struggle with board\-specific limits, operating boundaries, and missing information\. Correct verdicts can also be supported by incorrect rationales\. These findings show that reliable safety evaluation requires checking constraint application and abstention alongside verdict accuracy\.

Our future work would extend the evaluation to more models and practical hardware scenarios, strengthen expert validation, and test retrieval combined with deterministic constraint checks\.

## Acknowledgments

This work is supported in part by the National Science Foundation \(NSF\) under grants 2242812, 2550105, 2550106, 2543905, and 2616468\.

## References

- \[1\]Z\. Englhardt, R\. Li, D\. Nissanka, Z\. Zhang, G\. Narayanswamy, J\. Breda, X\. Liu, S\. Patel, and V\. Iyer\(2024\)Exploring and characterizing large language models for embedded system development and debugging\.InExtended Abstracts of the CHI Conference on Human Factors in Computing Systems,pp\. 1–9\.Cited by:[§I](https://arxiv.org/html/2610.33448#S1.p1.1),[§II\-B](https://arxiv.org/html/2610.33448#S2.SS2.p2.1)\.
- \[2\]Arduino\(2026\)Arduino Due user manual, SKU A000062\.Note:https://docs\.arduino\.cc/resources/datasheets/A000062\-datasheet\.pdfAccessed: 2026\-09\-09Cited by:[§I](https://arxiv.org/html/2610.33448#S1.p1.1)\.
- \[3\]Arduino\(2026\)Arduino MKR WiFi 1010 user manual, SKU ABX00023\.Note:https://docs\.arduino\.cc/resources/datasheets/ABX00023\-datasheet\.pdfAccessed: 2026\-09\-09Cited by:[§I](https://arxiv.org/html/2610.33448#S1.p1.1)\.
- \[4\]S\. Levy, E\. Allaway, M\. Subbiah, L\. Chilton, D\. Patton, K\. McKeown, and W\. Y\. Wang\(2022\)SafeText: a benchmark for exploring physical safety in language models\.InProceedings of the 2022 Conference on Empirical Methods in Natural Language Processing,pp\. 2407–2421\.Cited by:[§I](https://arxiv.org/html/2610.33448#S1.p2.1),[§II\-A](https://arxiv.org/html/2610.33448#S2.SS1.p1.1)\.
- \[5\]D\. Wu, F\. N\. Haredasht, S\. K\. Maharaj, P\. Jain, J\. Tran, M\. Gwiazdon, A\. Rustagi, J\. Jindal, J\. M\. Koshy, V\. Kadiyala,et al\.\(2025\)First, do noharm: a medical safety benchmark and randomized study of physician and ai teaming on clinical consultations\.arXiv preprint arXiv:2512\.01241\.Cited by:[§I](https://arxiv.org/html/2610.33448#S1.p2.1),[§II\-A](https://arxiv.org/html/2610.33448#S2.SS1.p2.1)\.
- \[6\]P\. Hager, F\. Jungmann, R\. Holland, K\. Bhagat, I\. Hubrecht, M\. Knauer, J\. Vielhauer, M\. Makowski, R\. Braren, G\. Kaissis,et al\.\(2024\)Evaluation and mitigation of the limitations of large language models in clinical decision\-making\.Nature medicine30\(9\),pp\. 2613–2622\.Cited by:[§I](https://arxiv.org/html/2610.33448#S1.p2.1),[§II\-A](https://arxiv.org/html/2610.33448#S2.SS1.p1.1),[§II\-A](https://arxiv.org/html/2610.33448#S2.SS1.p2.1)\.
- \[7\]Y\. Zhou, J\. Yang, Y\. Huang, K\. Guo, Z\. Emory, B\. Ghosh, A\. Bedar, S\. Shekar, Z\. Liang, P\. Chen,et al\.\(2024\)Labsafety bench: benchmarking llms on safety issues in scientific labs\.arXiv preprint arXiv:2410\.14182\.Cited by:[§I](https://arxiv.org/html/2610.33448#S1.p2.1),[§II\-A](https://arxiv.org/html/2610.33448#S2.SS1.p1.1),[§II\-A](https://arxiv.org/html/2610.33448#S2.SS1.p2.1)\.
- \[8\]L\. Skelic, Y\. Xu, M\. Cox, W\. Lu, T\. Yu, and R\. Han\(2025\)CIRCUIT: a benchmark for circuit interpretation and reasoning capabilities of llms\.arXiv preprint arXiv:2502\.07980\.Cited by:[§I](https://arxiv.org/html/2610.33448#S1.p2.1),[§II\-B](https://arxiv.org/html/2610.33448#S2.SS2.p1.1)\.
- \[9\]S\. Srinivasan, B\. Tan, B\. Turnbull, and H\. Pearce\(2026\)PCB\-qa: evaluating llms over the first printed circuit board design question\-answer dataset\.arXiv preprint arXiv:2606\.23704\.Cited by:[§I](https://arxiv.org/html/2610.33448#S1.p2.1),[§II\-B](https://arxiv.org/html/2610.33448#S2.SS2.p1.1)\.
- \[10\]J\. Li, L\. Chen, B\. Yang, J\. Zhu, Y\. Wang, Y\. Ma, and M\. Yang\(2026\)Pcb\-bench: benchmarking llms for printed circuit board placement and routing\.InThe Fourteenth International Conference on Learning Representations,Cited by:[§I](https://arxiv.org/html/2610.33448#S1.p2.1),[§II\-B](https://arxiv.org/html/2610.33448#S2.SS2.p1.1)\.
- \[11\]W\. Qiu, Y\. Xiao, and R\. Pan\(2026\)HWE\-bench: can language models perform board\-level schematic designs?\.arXiv preprint arXiv:2603\.18102\.Cited by:[§I](https://arxiv.org/html/2610.33448#S1.p2.1),[§II\-B](https://arxiv.org/html/2610.33448#S2.SS2.p1.1)\.
- \[12\]R\. Xu, Y\. Wan, and X\. Xue\(2026\)DomusMind: a benchmark for evaluating lifelong smart home agents under drift\.InICLR 2026 Workshop on Lifelong Agents: Learning, Aligning, Evolving,Cited by:[§I](https://arxiv.org/html/2610.33448#S1.p2.1)\.
- \[13\]R\. Xu, J\. Cao, M\. Wu, W\. Zhong, Y\. Lu, B\. He, X\. Han, S\. Cheung, and L\. Sun\(2026\)Embedagent: benchmarking large language models in embedded system development\.InProceedings of the 2026 IEEE/ACM 48th International Conference on Software Engineering,pp\. 630–641\.Cited by:[§I](https://arxiv.org/html/2610.33448#S1.p2.1),[§II\-B](https://arxiv.org/html/2610.33448#S2.SS2.p2.1)\.
- \[14\]H\. C\. Chen, L\. Wu, M\. Gao, L\. Shen, J\. Zhong, and Y\. Xu\(2024\)DocEDA: automated extraction and design of analog circuits from documents with large language model\.arXiv preprint arXiv:2412\.05301\.Cited by:[§I](https://arxiv.org/html/2610.33448#S1.p3.1)\.
- \[15\]M\. D\. Wilkinson, M\. Dumontier, I\. J\. Aalbersberg, G\. Appleton, M\. Axton, A\. Baak, N\. Blomberg, J\. Boiten, L\. B\. da Silva Santos, P\. E\. Bourne,et al\.\(2016\)The fair guiding principles for scientific data management and stewardship\.Scientific data3\(1\),pp\. 160018\.Cited by:[§I](https://arxiv.org/html/2610.33448#S1.p3.1)\.
- \[16\]J\. Zhang, F\. Mo, Z\. Chen, X\. Han, K\. Liu, and C\. Lu\(2026\)BrailleBench: investigating multi\-criteria braille comprehension in large language models\.arXiv preprint arXiv:2608\.27268\.Cited by:[§I](https://arxiv.org/html/2610.33448#S1.p3.1)\.
- \[17\]L\. Ma, R\. Zhang, Y\. Han, S\. Yu, Z\. Wang, Z\. Ning, J\. Zhang, P\. Xu, P\. Li, W\. Ju,et al\.\(2023\)A comprehensive survey on vector database: storage and retrieval technique, challenge\.arXiv preprint arXiv:2310\.11703\.Cited by:[§I](https://arxiv.org/html/2610.33448#S1.p3.1)\.
- \[18\]J\. Zhang, X\. Wang, W\. Ren, L\. Jiang, D\. Wang, and K\. Liu\(2025\)Ratt: a thought structure for coherent and correct llm reasoning\.InProceedings of the AAAI Conference on Artificial Intelligence,Vol\.39,pp\. 26733–26741\.Cited by:[§II\-A](https://arxiv.org/html/2610.33448#S2.SS1.p1.1)\.
- \[19\]N\. Madhusudhan, S\. T\. Madhusudhan, V\. Yadav, and M\. Hashemi\(2025\)Do llms know when to not answer? investigating abstention abilities of large language models\.InProceedings of the 31st International Conference on Computational Linguistics,pp\. 9329–9345\.Cited by:[§II\-A](https://arxiv.org/html/2610.33448#S2.SS1.p1.1)\.
- \[20\]F\. Mo, Z\. Su, Y\. Hui, J\. Zhang, J\. A\. Sun, Z\. Liu, C\. Zhang, T\. Sakai, and J\. Nie\(2026\)Opendecoder: open large language model decoding to incorporate document quality in rag\.InProceedings of the ACM Web Conference 2026,pp\. 2252–2262\.Cited by:[§II\-A](https://arxiv.org/html/2610.33448#S2.SS1.p1.1)\.
- \[21\]H\. Xu, Q\. Hao, H\. Zhang, J\. Zhao, Z\. Qiao, L\. Jiang, P\. Wang, Y\. Zhou, and P\. Wang\(2026\)Shift\-resilient diffusive imputation for variable subset forecasting\.InProceedings of the ACM Web Conference 2026,pp\. 7366–7377\.Cited by:[§II\-A](https://arxiv.org/html/2610.33448#S2.SS1.p1.1)\.
- \[22\]Q\. Hao, Y\. Gao, R\. Liang, Y\. Zhang, and P\. Wang\(2025\)Generative imputation with multi\-level causal consistency for variable subset forecasting\.InProceedings of the 31st ACM SIGKDD Conference on Knowledge Discovery and Data Mining V\. 2,pp\. 838–849\.Cited by:[§II\-A](https://arxiv.org/html/2610.33448#S2.SS1.p1.1)\.
- \[23\]R\. Xu, Z\. Qi, Z\. Guo, C\. Wang, H\. Wang, Y\. Zhang, and W\. Xu\(2024\)Knowledge conflicts for llms: a survey\.InProceedings of the 2024 Conference on Empirical Methods in Natural Language Processing,pp\. 8541–8565\.Cited by:[§II\-A](https://arxiv.org/html/2610.33448#S2.SS1.p3.1)\.
- \[24\]J\. Xie, K\. Zhang, J\. Chen, R\. Lou, and Y\. Su\(2024\)Adaptive chameleon or stubborn sloth: revealing the behavior of large language models in knowledge conflicts\.InInternational Conference on Learning Representations,Vol\.2024,pp\. 35623–35646\.Cited by:[§II\-A](https://arxiv.org/html/2610.33448#S2.SS1.p3.1)\.
- \[25\]L\. Yang, X\. Wang, and K\. Liu\(2026\)Do thoughts depth affect multilingual reasoning?\.InProceedings of the 1st Workshop on Multilinguality in the Era of Large Language Models \(MeLLM 2026\),pp\. 149–158\.Cited by:[§II\-A](https://arxiv.org/html/2610.33448#S2.SS1.p3.1)\.
- \[26\]Y\. Wang, S\. Feng, H\. Wang, W\. Shi, V\. Balachandran, T\. He, and Y\. Tsvetkov\(2023\)Resolving knowledge conflicts in large language models\.arXiv preprint arXiv:2310\.00935\.Cited by:[§II\-A](https://arxiv.org/html/2610.33448#S2.SS1.p3.1)\.
- \[27\]Y\. Li, Y\. Cheng, M\. Ma, Y\. Zou, N\. Yang, W\. Cheng, H\. Li, Y\. Chen, and T\. Chen\(2026\)Skilled ai agents for embedded and iot systems development\.InProceedings of the ACM Conference on AI and Agentic Systems,pp\. 1248–1252\.Cited by:[§II\-B](https://arxiv.org/html/2610.33448#S2.SS2.p2.1)\.
- \[28\]D\. Yuan, Y\. Deng, and H\. Chen\(2026\)EmbedCopilot\-bench: evaluating vision\-language models for hardware\-aware embedded system development\.InEuropean Conference on Computer Vision,pp\. 332–350\.Cited by:[§II\-B](https://arxiv.org/html/2610.33448#S2.SS2.p2.1)\.
- \[29\]OpenAI\(2026\)GPT\-5\.6 system card\.Note:https://deploymentsafety\.openai\.com/gpt\-5\-6Accessed: 2026\-09\-09Cited by:[§III\-B](https://arxiv.org/html/2610.33448#S3.SS2.p1.1),[§III\-E](https://arxiv.org/html/2610.33448#S3.SS5.p4.1)\.
- \[30\]Anthropic\(2026\)Claude Opus 5 system card\.Note:https://www\.anthropic\.com/claude\-opus\-5\-system\-cardAccessed: 2026\-09\-09Cited by:[§III\-D](https://arxiv.org/html/2610.33448#S3.SS4.p1.1)\.
- \[31\]A\. Yang, A\. Li, B\. Yang, B\. Zhang, B\. Hui, B\. Zheng, B\. Yu, C\. Gao, C\. Huang, C\. Lv,et al\.\(2025\)Qwen3 technical report\.arXiv preprint arXiv:2505\.09388\.Cited by:[§IV\-A](https://arxiv.org/html/2610.33448#S4.SS1.p1.1)\.
- \[32\]G\. Team, A\. Kamath, J\. Ferret, S\. Pathak, N\. Vieillard, R\. Merhej, S\. Perrin, T\. Matejovicova, A\. Ramé, M\. Rivière,et al\.\(2025\)Gemma 3 technical report\.arXiv preprint arXiv:2503\.19786\.Cited by:[§IV\-A](https://arxiv.org/html/2610.33448#S4.SS1.p1.1)\.
- \[33\]A\. Grattafiori, A\. Dubey, A\. Jauhri, A\. Pandey, A\. Kadian, A\. Al\-Dahle, A\. Letman, A\. Mathur, A\. Schelten, A\. Vaughan,et al\.\(2024\)The llama 3 herd of models\.arXiv preprint arXiv:2407\.21783\.Cited by:[§IV\-A](https://arxiv.org/html/2610.33448#S4.SS1.p1.1)\.