{ "schema_version": 1, "builder_plan": { "scenario": "An agent looks good in demos, but you cannot tell which product tasks it fails.", "change": "Use the study's evaluation idea to inspect a small set of tasks with human-checked answers.", "baseline": "Your current evaluator and a manually reviewed reference set.", "steps": [ "Locate the paper's implementation and check its license, model support, data needs, and hardware requirements. Stop here if you cannot obtain the required artifacts.", "Save a small set of representative product tasks and expected outcomes. Keep evaluation tasks out of any training or tuning, and choose quality and cost limits before running.", "Run the baseline and the proposed change on identical inputs. Keep other settings fixed and repeat paired runs to expose variation.", "Save per-task outputs, failures, timings, and all usage costs. Review regressions before expanding the test." ], "measure": "Agreement with human review, missed failures, false alarms, and evaluation cost per task.", "decision": "Keep the change only if it meets your preselected quality and latency limits and improves the metric you care about after setup and operating costs. Otherwise retain the baseline. This is an exploration plan, not a validated recommendation." }, "builder_review": null, "arxiv_id": "2610.21570", "title": "Independent Data-Integrity Verification for LLM-Driven Functional Coverage Closure in Hardware Design", "summary": "The method replaces trusting the LLM agent's own account of coverage and correctness with coverage read directly from simulator-exported reports (cocotb-coverage YAML) and data-integrity scoreboards independent of the model. It costs the engineering effort of writing design-specific scoreboards and monitors, plus the simulation and LLM-API runtime of an iterative closure loop; it adds no GPU training burden. It can fail because the independent scoreboard is not yet attached to the LLM-generated tests themselves, so data integrity of those tests is unverified, and the evidence rests on three designs, no baseline, no ablation, and runs aggregated across agent checkpoints.", "rationale": "The trust-but-verify pattern is sound and cheap to replicate, but the evidence base is preliminary and the domain (RTL functional verification) is outside most ML production work, so it warrants monitoring rather than adoption.", "technique": "Independent coverage and scoreboard verification of LLM-generated hardware tests", "family": "avaliacao_de_agente", "recommendation": "observar", "published": "2026-10-15", "as_of": "2026-10-18", "editorial_status": "indexed", "source_url": "https://arxiv.org/abs/2610.21570", "independent_implementations": 0, "total_implementations": 0, "stars": 0, "citations": 0, "claims": [ { "claim_id": "claim-01", "statement": "The method replaces trusting the LLM agent's own account of coverage and correctness with coverage read directly from simulator-exported reports (cocotb-coverage YAML) and data-integrity scoreboards independent of the model. It costs the engineering effort of writing design-specific scoreboards and monitors, plus the simulation and LLM-API runtime of an iterative closure loop; it adds no GPU training burden. It can fail because the independent scoreboard is not yet attached to the LLM-generated tests themselves, so data integrity of those tests is unverified, and the evidence rests on three designs, no baseline, no ablation, and runs aggregated across agent checkpoints.", "basis": "inferred", "result": "", "baseline": "", "conditions": "", "source_url": "https://arxiv.org/abs/2610.21570", "source_page": null, "source_excerpt": "" }, { "claim_id": "claim-02", "statement": "On three RTL designs, the agent raised functional coverage from 91.7%, 88.9% and 67.4% to 100% within an 8-iteration budget in every logged run; the evidence is limited to three designs with no baseline or ablation.", "basis": "inferred", "result": "", "baseline": "", "conditions": "", "source_url": "https://arxiv.org/abs/2610.21570", "source_page": null, "source_excerpt": "" } ], "exposure_map": [ { "dimension": "quality", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "compute", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "latency", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "operations", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "compatibility", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "security", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "data_and_training", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" }, { "dimension": "reproducibility", "basis": "not_evaluated", "finding": "", "interpretation": "", "limitation": "", "next_check": "", "source_url": "", "source_page": null, "source_excerpt": "" } ], "risks": [], "minimum_test": [], "open_questions": [], "independent_tests": [], "lab_reproductions": [], "report_available": false, "validation_tier": "unknown", "evidence_tier": "unknown", "infrastructure_basis": "unknown", "equations": [], "equations_status": "not_fetched", "core_kind": "", "equations_fetched_at": "", "equations_source_url": "", "equations_source_sha256": "", "exposures_reviewed_at": "", "exposures_source_sha256": "" }