Skip to content

Add component-selection reasoning and audit protocols#177

Merged
Alan-Jowett merged 8 commits intomicrosoft:mainfrom
Alan-Jowett:add-component-selection-protocols
Apr 6, 2026
Merged

Add component-selection reasoning and audit protocols#177
Alan-Jowett merged 8 commits intomicrosoft:mainfrom
Alan-Jowett:add-component-selection-protocols

Conversation

@Alan-Jowett
Copy link
Copy Markdown
Member

@Alan-Jowett Alan-Jowett commented Apr 6, 2026

Summary

Add two new protocols for electronic component selection in hardware design workflows. This is Step 1 of 9 in building an end-to-end hardware design workflow (idea → requirements → components → schematic → PCB → manufacturing artifacts).

New Components

Type Name Path Description
Protocol (reasoning) component-selection protocols/reasoning/component-selection.md Systematic component selection from requirements with real-time sourcing verification
Protocol (analysis) component-selection-audit protocols/analysis/component-selection-audit.md Adversarial audit of component selection decisions

Design Decisions

  • Reasoning protocol (not analysis): \component-selection\ is a generative/constructive methodology — it produces a selection. The corresponding \component-selection-audit\ is the adversarial verifier.
  • Scoped to core functional components: Supporting circuitry (decoupling, ESD, regulation, pull-ups) is explicitly out of scope — those are derived during schematic design from selected components' datasheets. This prevents scope overlap with the planned \schematic-design\ protocol.
  • Real-time search required: The protocol mandates web search for availability and pricing verification. Component lifecycle and stock status change frequently — LLM training data alone is insufficient.
  • Weighted decision matrix: Output uses a structured comparison matrix with adjustable weights, enabling reproducible and auditable selection decisions.
  • Adversarial audit catches hallucinations: The audit protocol independently verifies every part number, spec claim, sourcing assertion, and compatibility claim. It explicitly catalogs common LLM hallucination patterns for electronic parts (plausible suffixes, evaluation board vs IC part numbers, etc.).
  • No new persona needed: The existing \�lectrical-engineer\ persona provides the necessary domain expertise.
  • No new format needed: The protocol's output structure fits within existing format types.
  • **\�pplicable_to: []**: No template exists yet that references these protocols. Will be updated when the \design-schematic\ template and \hardware-design-workflow\ template are created in later steps.

Checklist

  • All files have SPDX license headers
  • YAML frontmatter is valid and complete
  • Component names match file names (kebab-case)
  • manifest.yaml updated with all new components
  • No vague instructions in protocols or templates
  • Protocols have numbered, ordered phases
  • New components do not conflict with existing ones
  • CI validation passes (\python tests/validate-manifest.py)

Add component-selection reasoning and audit protocols
beab768 
Add two new protocols for electronic component selection in hardware
design workflows:

- component-selection (reasoning): Systematic methodology for selecting
  core functional components from requirements. Covers requirements
  extraction, candidate search with real-time verification, technical
  evaluation with weighted decision matrices, sourcing verification,
  and cross-component compatibility checking. Scoped to core functional
  components; supporting circuitry belongs in schematic design.

- component-selection-audit (analysis): Adversarial audit that
  independently verifies part numbers exist, datasheet specs match
  claims, sourcing data is current, compatibility assertions hold, and
  all requirements are satisfied. Designed to catch hallucinated parts
  and stale specifications.

These are Step 1 of 9 in building an end-to-end hardware design
workflow (idea -> requirements -> components -> schematic -> PCB ->
manufacturing artifacts).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot AI review requested due to automatic review settings April 6, 2026 15:28
Copilot AI reviewed Apr 6, 2026
View reviewed changes
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR adds two new PromptKit protocol components to support a future hardware design workflow step focused on selecting electronic components from requirements and then adversarially auditing that selection.

Changes:

  • Added a new reasoning protocol for systematic component selection, including candidate search, technical/sourcing evaluation, compatibility checks, and a weighted decision matrix.
  • Added a new analysis protocol to independently audit part numbers, datasheet claims, sourcing data, requirements traceability, and compatibility assertions.
  • Registered both new protocols in manifest.yaml so they’re discoverable by the bootstrap/assembly tooling.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File Description
protocols/reasoning/component-selection.md Introduces the step-by-step component selection methodology and output artifacts (tables/matrices).
protocols/analysis/component-selection-audit.md Adds an adversarial verification protocol to catch hallucinated parts/specs and stale sourcing/compatibility claims.
manifest.yaml Adds both protocols to the manifest under the appropriate protocol categories.

Alan Jowett and others added 2 commits April 6, 2026 08:33
Address adversarial audit findings for component-selection protocols
db9426a 
Fix 6 findings identified during self-audit:

1. Voltage regulator identification gap (Medium): Phase 6 now
   explicitly flags when a voltage domain has no direct power source,
   documenting the need for a regulator as a schematic design handoff.
   Previously this was only implicitly captured in Phase 8.3.

2. Undefined input artifact (Medium): Added an Input section to the
   protocol preamble specifying valid inputs (natural language
   description, existing requirements doc, or user conversation) and
   instructing the LLM to probe for missing information.

3. Undefined priority levels (Low): Phase 1 now defines Must/Should/May
   priority values and their effect on downstream evaluation (Must
   failures trigger elimination in Phase 4).

4. Module vs. bare IC for wireless (Medium): Phase 3 now explicitly
   requires evaluating both pre-certified modules and bare ICs for
   wireless components, with guidance on certification implications
   (FCC Part 15, CE RED) and a preference for modules in prototype/
   low-volume designs.

5. Ambiguous audit halt behavior (Low): Audit Phase 1.4 now says
   'continue auditing remaining components' instead of 'do not proceed',
   clarifying that unverified part numbers are blocking findings in the
   final verdict but do not halt the audit mid-execution.

6. Rigid candidate count (Low): Phase 3 now says 'at least 2' with
   guidance to consider 4-5 for broad categories (MCU, wireless) and
   to document rationale when fewer candidates exist.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Fix power budget dimensional ambiguity in component-selection
579cbd2 
Address reviewer feedback on Phase 6 power budget roll-up: the original
text compared worst-case current (mA) against 'power source capacity'
which is ambiguous — battery capacity is measured in mAh (charge), not
mA (current). This is a dimensional mismatch that would produce
nonsensical results.

Split into two distinct checks:
(a) Instantaneous current check: worst-case current draw per rail vs.
    regulator/source maximum current rating (with 80% flag threshold)
(b) Battery life estimate: average current in the mode profile vs.
    battery capacity (mAh/Wh) and required runtime

Also require explicit unit labeling in all tables and bullets.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot AI review requested due to automatic review settings April 6, 2026 15:36
Copilot AI reviewed Apr 6, 2026
View reviewed changes
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

Add composition notes for standalone protocols
9c0acde 
Both component-selection and component-selection-audit use
applicable_to: [] but did not document this in the body text.
CONTRIBUTING.md requires protocols with empty applicable_to to
state they are intended for standalone/manual composition.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@Alan-Jowett Alan-Jowett requested a review from Copilot April 6, 2026 15:43
Copilot AI reviewed Apr 6, 2026
View reviewed changes
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

Add web search fallback and fix formatting
807ddfe 
Address three reviewer findings:

1. Missing space after bold label (formatting): 'Scope boundary:This'
   was missing a space after the colon. Trivial formatting fix.

2. No fallback when web search is unavailable (component-selection):
   Phase 3 mandates real-time verification via web search but had no
   guidance for environments without browsing tools. Without a
   fallback, the LLM could fabricate verification data, violating
   anti-hallucination guardrails. Added explicit instructions to
   mark unverified fields as [UNVERIFIED]/[UNKNOWN], request user-
   provided URLs, and label recommendations as pending verification.

3. Same gap in audit protocol (component-selection-audit): Phase 1
   requires searching manufacturer/distributor sites but had no
   fallback. Added a preamble requiring the auditor to request
   user-provided sources when search is unavailable, mark assertions
   as [UNVERIFIED], and cap the verdict at PASS WITH CONDITIONS
   when source verification is incomplete.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@Alan-Jowett Alan-Jowett requested a review from Copilot April 6, 2026 15:51
Copilot AI reviewed Apr 6, 2026
View reviewed changes
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

Fix internal consistency in search fallback and audit verdicts
3d73486 
Address two reviewer findings:

1. Phase 5 (Sourcing Evaluation) requires distributor searches but
   lacked the same web-search fallback added to Phase 3. Added a
   cross-reference to Phase 3's constraints to avoid duplication
   while maintaining internal consistency.

2. Audit protocol contradiction: the no-browsing preamble said
   'PASS WITH CONDITIONS at best' for unverified assertions, but
   Phase 1.4 says unverified part numbers force FAIL. These
   contradicted when web search was unavailable. Fixed by
   distinguishing blocking items (part number existence, manufacturer,
   orderable status — always force FAIL if unverified) from
   non-blocking items (pricing, stock levels, lead times — allowed
   under PASS WITH CONDITIONS).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@Alan-Jowett Alan-Jowett requested a review from Copilot April 6, 2026 16:00
Copilot AI reviewed Apr 6, 2026
View reviewed changes
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

Fix example traceability and label derating threshold
9ea3054 
1. CR-001 mapping inconsistency: Phase 2 example mapped Wireless MCU
   to CR-001 (temperature requirement) + CR-002. CR-001 is the
   temperature sensor requirement, not wireless. Fixed to CR-002 only.

2. 80% derating threshold: Labeled as a default conservative heuristic
   rather than a hard rule, with guidance to adjust based on
   application context (battery sag, ambient temperature, tolerances,
   transient loads).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@Alan-Jowett Alan-Jowett requested a review from Copilot April 6, 2026 16:14
Copilot AI reviewed Apr 6, 2026
View reviewed changes
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

Fix NRND definition and add Informational severity
1804cd6 
1. NRND lifecycle definition: 'will be discontinued' overstates the
   implication. NRND means higher lifecycle risk and discouraged for
   new designs, not certain discontinuation. Reworded to reflect
   actual industry semantics.

2. Missing Informational severity: Phase 2 severity classification
   listed Critical/High/Medium/Low but Phases 3.3 and 6 reference
   Informational findings. Added Informational level to keep the
   protocol internally consistent, matching the severity scale used
   in other PromptKit protocols (e.g., layout-design-review).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@Alan-Jowett Alan-Jowett merged commit a44e55a into microsoft:main Apr 6, 2026
3 checks passed
@Alan-Jowett Alan-Jowett deleted the add-component-selection-protocols branch April 7, 2026 18:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

Copilot code review Copilot Copilot left review comments

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@Alan-Jowett