Reconcile validation posture for components ahead of last fully evaluated version

[ProfessorPolymorphic]

Summary

python3 .github/scripts/lint_components.py on 2026-04-21 reported two components whose current version is ahead of the last fully evaluated version:

• nsf-award-notice-extraction-udm is at 1.1.0, but the last fully evaluated version is 1.0.0 (oldest case: 2427549)
• rfp-extraction is at 1.1.0, but the last fully evaluated version is 1.0.0 (oldest case: NSF_26-508)

That does not break the repo, but it does mean the current docs and catalog should continue to be careful not to imply that the newest checked-in version has full release-grade validation coverage.

Why this matters

The repo now documents evaluation posture more clearly, but these warnings are still real contract-maintenance debt. If we leave them unresolved for long, downstream consumers may have to guess whether the newer component versions are intentionally unevaluated, implicitly still valid, or simply behind on metadata.

Desired outcome

For each affected component, do one of the following:

1. Re-run the relevant eval cases against the current component version and update validated_against_version in the case metadata.
2. If the current version is intentionally still covered by existing evidence, make that explicit by bumping the recorded validated_against_version and documenting why that is safe.
3. If the current version should not yet be treated as fully covered, keep the warning state but add an explicit maintainer note so the posture is unambiguous.

Acceptance criteria

• python3 .github/scripts/lint_components.py no longer warns for these components, or the remaining warning state is explicitly documented as intentional.
• The component-local eval metadata and any related human-facing wording stay aligned.
• No README or docs text overstates validation readiness for these component versions.

Related

• Related to the broader reproducibility/evaluation pairing work tracked in Pair components with evaluation-data-sets for reproducibility + accuracy metrics #12.

[ProfessorPolymorphic]

Related follow-on work from the same triad-alignment pass:

• AI4RA/evaluation-harness#1 tracks the need for a reproducible local validation baseline from a fresh checkout.
• AI4RA/evaluation-harness#2 tracks harness-side consumption of triad.workspace.yaml for sibling discovery and ref sanity checks.

These are downstream coordination items rather than blockers for the prompt-library metadata fix, but they came out of the same cross-repo cleanup pass.