name: bspdn-pdn-sufficiency-evaluator
description: Evaluate whether the current BSPDN PDN contract is strong enough under BPR reserved for PDN, separating PDN sufficiency from signal-mixing questions.
BSPDN PDN Sufficiency Evaluator
Use this skill when the question is "is the current PDN contract strong enough?" rather than "did backside signal routing help?"
When to use
Use this skill when:
- the project needs to decide whether
BPR + current backside PDNis sufficient, - PDN weakness may be confounding backside-signal conclusions,
Strict-BPR,PDN-boost, orStress-checkcomparisons need a dedicated evaluator,- PDN stability must be judged without letting signal use
BPR.
Scope boundary
This skill owns:
- PDN sufficiency judgments under the current BSPDN contract,
- separating PDN strength questions from signal-routing benefit questions,
- deciding whether the issue is likely
PDN under-strengthvstopology invalidityvscase unsuitability.
It does not own:
- redefining the physical contract itself without
bspdn-physical-contract-auditor, - benefit attribution across
front-only / CTS-backside-only / partial-signal-backside, - general execution orchestration.
Core experiment family
Use this family by default:
Strict-BPRPDN-boostStress-check
Expected outputs
*.results.tsv*.conclusion.md- optional
*.experience_delta.md
Hard rules
- Never answer "PDN is weak" by letting signal use
BPR; that changes the question. - Keep
BPR-reserved-for-PDNintact unless the physical contract is separately overturned. - Distinguish:
- PDN connectivity/stability evidence
- timing side effects
- congestion side effects
- A better
PDN-boostresult implies "strengthen PDN", not "relax the signal contract".
Operational references
- Load
references/background-knowledge-links.mdfor the current summarized PDN-sufficiency knowledge contract. - Load
references/update-mechanism.mdwhen deciding whether the evaluator's assumptions or pass/fail criteria need refresh.