Source-linked AI summary
BoardSafety: AI-Ready Data from Manufacturer Documentation for Development-Board Safety
Linjian Yang, Xinyan Wang, Kunpeng Liu
TL;DR
Board-specific operating limits make it difficult to evaluate whether LLMs can judge proposed development-board operations safely. BoardSafety converts manufacturer constraints into a rule base and labeled scenarios, then tests models with and without rules and structured-rationale prompts. Across six models, rule access yields more consistent accuracy gains than rationale prompting, but safety judgments remain unreliable.
Problem
Manufacturer operating limits vary by board, making it difficult to evaluate whether LLMs can determine if a proposed operation is safe for that specific board.
Source: §I · p. 1Method
BoardSafety structures manufacturer constraints into a traceable rule base and derives labeled board-operation scenarios, which it uses to evaluate rule access and structured-rationale prompting.
Source: §I · p. 1, A. Experimental Setting · p. 5Results
69.13% was the maximum accuracy across six open-weight LLMs, while rule access yielded larger and more consistent gains than structured-rationale prompting.
Source: §I · p. 2, the Reliability of Safety Judgments? · p. 5Takeaways & Limitations
Evaluated models still show persistent limitations in board-swap, near-boundary, and underspecified cases, so reliable board-specific safety judgments remain unresolved.
Source: §I · p. 2
Abstract
from arXiv · showhide
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 the BoardSafety 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 includes safe, unsafe, or insufficient-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.
I. INTRODUCTION
Board-specific manufacturer limits make it difficult to evaluate whether LLMs can judge proposed development-board operations safely. BoardSafety provides a traceable rule base and labeled scenarios to test those judgments, and experiments show persistent model limitations.
I. INTRODUCTION
- Gemma-3-12B labels both 9 V board-swap operations safe despite the Arduino Due’s 6–16 V range and the Arduino MKR WiFi 1010’s 5.5 V limit.The example illustrates why a verdict must account for the specified board and its documented constraint.Source: §I · p. 1, Figure 1 · p. 2
- Earlier hardware benchmarks assess design or implementation validity, but do not test whether LLMs apply the manufacturer constraint governing an operation on a specific board.BoardSafety evaluates judgments against the documented constraint for the specified board.Source: §I · p. 1
- BoardSafety combines a rule base of 490 constraints from 30 documents covering 53 boards with 298 scenarios labeled safe, unsafe, or insufficient-info.The constraints are traceable and recomputable, and the benchmark tests board-specific application and abstention when information is missing.Source: §I · pp. 1–2
- Scenarios include minimal pairs that vary only the board or decisive value, plus underspecified cases that omit that value.The benchmark is used to study rule access and structured-rationale prompting.Source: §I · p. 2
- 69.13% was the maximum accuracy across six open-weight LLMs, and only four of 24 model–condition combinations exceeded the always-unsafe baseline by their 95% Wilson lower bounds.Rule access yielded larger and more consistent accuracy gains than structured-rationale prompting, but only 13.4% of reviewed rationales correctly applied the applicable constraint.Source: §I · p. 2
II. RELATED WORK
Safe LLM advice in specialized settings requires applying relevant domain evidence to the specific decision context. BoardSafety examines this requirement for manufacturer constraints in development-board operations.
A. Context-Specific Safety of LLM Responses
- For a power-connection judgment, the model must compare supply voltage with the board’s input limits and should request safety information when it is missing.The cited work frames abstention as necessary when the available information is insufficient.Source: A. Context-Specific Safety of LLM… · p. 2
- Safe responses in specialized decisions require models to apply domain-specific evidence to the particular context, rather than rely on general knowledge alone.Prior work reports difficulties using relevant patient information and clinical guidelines, as well as harmful medical recommendations and limitations in laboratory risk assessment.Source: A. Context-Specific Safety of LLM… · p. 2
- A verdict alone does not show whether a model relied on parametric knowledge or contextual information, which it may fail to reconcile when the sources conflict.BoardSafety studies whether responses follow the relevant manufacturer constraint for development-board operations.Source: A. Context-Specific Safety of LLM… · p. 2
B. LLM Benchmarks for Hardware and Embedded Systems
Hardware and embedded-system benchmarks test circuit interpretation, design generation, implementation, and execution. They do not specifically evaluate constraint-grounded safety verdicts for proposed development-board operations.
B. LLM Benchmarks for Hardware and Embedded Systems
- Circuit and design benchmarks assess tasks such as analog-circuit reasoning, PCB connectivity and design-rule compliance, and board-level schematic generation.Examples include CIRCUIT [8], PCB-QA and PCB-Bench [9],, and HWE-Bench [11].Source: B. LLM Benchmarks for Hardware and… · p. 2
- Embedded-system evaluations test generated software or agents through hardware-in-the-loop tests, cross-platform programming tasks, real hardware execution, and multimodal assistance.Examples include Englhardt et al., EmbedBench, IoT-SkillsBench, and EmbedCopilot-Bench.Source: B. LLM Benchmarks for Hardware and… · pp. 2–3
- These benchmarks assess design correctness, working implementations, or development instructions, not safety verdicts grounded in a specific board’s documented constraints.BoardSafety addresses this gap, including abstention when essential information is missing.Source: B. LLM Benchmarks for Hardware and… · pp. 2–3
III. BOARDSAFETY BENCHMARK
BoardSafety evaluates whether an LLM judges a proposed operation against documented constraints for a specified development board. Its construction links source evidence and structured rules to labeled scenarios that undergo validation and review.
III. BOARDSAFETY BENCHMARK
- Each benchmark item specifies a board and operating setup, with a reference verdict of safe, unsafe, or insufficient-info based on the selected documented constraints.Insufficient-info applies when no violation is established but information needed to determine compliance is missing.Source: §III · p. 3
A. AI-Readiness
- AI-readiness is defined through five properties: traceable source passages, computable numeric limits, filterable rules, consistent binding constraints, and derivable labels.These properties connect source evidence, structured constraints, and reference labels.Source: A. AI-Readiness · p. 3
B. Source Corpus and Rule Base
- The rule base contains 490 records across 17 hazard categories from 30 vendor documents covering 53 boards from five vendors.Records store normalized constraints and source metadata; 487 include a verbatim supporting passage, and evidence tiers distinguish documented facts from inference.Source: B. Source Corpus and Rule Base · p. 3
C. Rule Selection and Label Derivation
The section defines how rules are selected and how operating scenarios receive labels by comparing fixed conditions with board-specific constraints. Sampling covers violations, safe cases, boundary and board-swap pairs, and missing-information cases.
C. Rule Selection and Label Derivation
- The standard seed pool excludes 17 cumulative-effect records from 304 Tier A/B design-limit records, while underspecified cases may also use Tier C1 records.The resulting pool contains 287 records; quotas, per-board caps, and a coverage sweep produce 300 candidate items from 213 seed rules.Source: C. Rule Selection and Label Derivation · p. 3
- Violation scenarios exceed a documented limit or specify a prohibited configuration, while safe scenarios use in-spec margins or vendor-documented permission.In-spec cases remain at least 15% below a single upper limit or at least 15% of a bounded interval from each endpoint.Source: C. Rule Selection and Label Derivation · p. 3
- Boundary pairs use 95% and 105% of one upper limit, while board-swap pairs hold the setup fixed and change the board to reverse the label.The two families contain 15 and 16 minimal pairs, respectively; underspecified items omit a needed quantity and receive insufficient-info labels when both compliant and violating values remain possible.Source: C. Rule Selection and Label Derivation · p. 3
- The pipeline derives labels from extracted board-specific constraints before LLMs render scenarios, then validates rules and scenarios through deterministic checks, blind model validation, and human review.The rule-based justification records the comparison supporting each label.Source: C. Rule Selection and Label Derivation · p. 3, Figure 2 · p. 4
D. Rule-Grounded Scenario Generation
After operating conditions and labels are fixed, an LLM renders each rule instance as a natural-language scenario while preserving those inputs and checking that stated facts remain consistent.
D. Rule-Grounded Scenario Generation
- Claude Opus 5 renders each fixed rule instance as a natural-language scenario after the operating condition and gold label are set.The generator receives the seed rule and complete rule set for the board, with the operating condition and label treated as immutable inputs.Source: D. Rule-Grounded Scenario Generation · p. 4
- An asserted-facts record links each stated quantity to its span in the scenario so a validator can check that the fixed condition is stated correctly.Quantities that determine the label, including combined quantities, must be stated explicitly rather than left for readers to calculate.Source: D. Rule-Grounded Scenario Generation · p. 4
- Distractors must comply with the board's rules, and minimal-pair scenarios share one narrative while differing only in board identity or decisive value.For insufficient-info items, the decisive quantity is intentionally omitted while all stated quantities remain consistent with the rule set.Source: D. Rule-Grounded Scenario Generation · p. 4
E. Escalating Quality Control
Quality control combines deterministic validation, independent checks, and expert review; the stages identify different kinds of errors and result in a retained set of 298 items.
E. Escalating Quality Control
- All 300 candidate items pass deterministic checks for stated values, structured facts, and label consistency, but these checks cannot detect misinterpretations in extracted source records.Two reviewers independently examine 59 sampled records, confirm 55, correct 4, and trace all 59 to supporting passages.Source: E. Escalating Quality Control · p. 4
- Blind validation by GPT-5.6 agrees with derived labels on 209 of 220 items and prompts repairs to 31 rule records; a 60-item rerun agrees on 56.The validator labels items without access to gold labels or metadata.Source: E. Escalating Quality Control · p. 4
- Two embedded-systems auditors review 100 items and reconcile disagreements, retaining 9 of 11 disputed labels and excluding 2 items whose seed records lack user-violable constraints.Blind validation covers pre-repair versions of 218 items, human audit covers 98, and the groups overlap on 91; all retained items pass deterministic validation.Source: E. Escalating Quality Control · p. 4
F. Released Benchmark
Across the tested conditions, rule access yields larger average accuracy gains than structured-rationale prompting, but reliability remains limited. The released benchmark includes 298 traceable scenarios, and the evaluation varies both rule access and rationale format.
F. Released Benchmark
- The released benchmark has 298 items across 46 boards, comprising 113 safe, 144 unsafe, and 41 insufficient-info cases, with 211 seed rules.Each item includes its seed rule, verbatim source passage, evidence tier, label derivation comparison, and validation and audit outcomes; board-level results are reported in aggregate and by family rather than as rankings.Source: F. Released Benchmark · p. 4
A. Experimental Setting
- The 2 × 2 evaluation varies board-rule access and direct versus four-step rationale prompting, and each model answers every scenario in all four conditions.Accuracy is the proportion of verdicts matching gold labels, reported with 95% Wilson intervals; the study also measures dangerous acceptance, safe rejection, family accuracy, abstention, and minimal-pair correctness.Source: A. Experimental Setting · p. 5
- Only 4 of 24 model-condition combinations have a 95% Wilson lower bound above the 48.3% always-unsafe baseline.Accuracy ranges from 36.91% to 69.13%, with Gemma-3-12B highest under R1T1.Source: the Reliability of Safety Judgments? · p. 5
- Rule access raises mean accuracy by 10.57 percentage points under T0 and 10.35 under T1, while structured rationale raises it by 4.53 points without rules and 4.31 with rules.Rationale-prompting effects vary across models and rule-access conditions; for Qwen3-4B the change is −2.68 points without rules and +13.09 with rules.Source: the Reliability of Safety Judgments? · p. 5
- Higher accuracy does not eliminate safety errors: dangerous acceptance averages 66.3% under R0T0 and 24.7% under R1T1, while safe rejection rises from 35.4% to 48.2%.This comparison combines changes in rule access and rationale prompting.Source: the Reliability of Safety Judgments? · p. 5
C. RQ2: What Does Aggregate Accuracy Obscure?
Aggregate accuracy obscures sharp differences across scenario families and failures on board-swap, boundary, and underspecified cases. These results show that models often struggle to recognize when information is missing.
C. RQ2: What Does Aggregate Accuracy Obscure?
- Despite 69.13% overall accuracy, Gemma-3-12B scored 86% on in-spec cases, 77% on violations, and 63% on boundary cases.It correctly labeled both items in 11 of 16 board-swap pairs and 4 of 15 boundary pairs.Source: C. RQ2: What Does Aggregate Accuracy… · p. 6
- 0–19.5% accuracy on underspecified cases contrasts with 66.4–84.1% on violation cases across all six models under R1T1.Table III reports per-item accuracy by scenario family and model.Source: C. RQ2: What Does Aggregate Accuracy… · pp. 5–6, Table III · p. 6
- Under R1T1, models predicted insufficient-info for only 0.3–4.0% of scenarios, although underspecified cases make up 13.8% of the benchmark.Gemma-3-12B correctly identified 8 of 41 underspecified cases, and 26 of 27 scenarios all six models missed were underspecified.Source: C. RQ2: What Does Aggregate Accuracy… · p. 6
D. RQ3: Do LLM Responses Follow the Safety Constraints?
Reviewed rationales often failed to demonstrate correct constraint application, including when verdicts were correct. Structured-rationale prompting produced longer responses but did not necessarily improve constraint application.
D. RQ3: Do LLM Responses Follow the Safety Constraints?
- Median visible-rationale length increased from 32 tokens under T0 to 79 under T1, but longer explanations did not necessarily indicate correct constraint application.The reported correctness rates describe a reviewed sample with rule access.Source: D. RQ3: Do LLM Responses Follow the… · pp. 6–7
- Only 13.4% of reviewed responses passed all four constraint-application criteria, while 62.8% of correct verdicts failed at least one criterion.The pass rates come from a stratified review sample of 216 responses, with equal weight for the three gold labels.Source: Table IV · p. 6, D. RQ3: Do LLM Responses Follow the… · p. 6
- 24.1% of reviewed responses with rule access met constraint-application correctness under R1T0, compared with 13.0% under R1T1.The prompting conditions also differ in required reasoning steps, so the difference cannot be attributed to rationale length alone.Source: Table IV · p. 6, D. RQ3: Do LLM Responses Follow the… · pp. 6–7
V. CONCLUSION AND FUTURE WORK
BoardSafety evaluates whether models judge proposed development-board operations against manufacturer-documented constraints. The experiments show that relevant rules improve performance but do not ensure correct application, and the authors identify further evaluation and validation work.
V. CONCLUSION AND FUTURE WORK
- 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.Source: §V · p. 7
- BoardSafety is built from vendor datasheets and hardware guides, using extracted structured constraints to derive reference labels for operating scenarios.The scenarios are fixed-labeled and validated through deterministic checks, blind model validation, and human review.Source: §V · p. 7
- Future work would extend evaluation to more models and practical hardware scenarios, strengthen expert validation, and test retrieval with deterministic constraint checks.Source: §V · p. 7