[Wave 2] Next release — Technology: items confirmed current, with follow-ups #836

Wave 2 · 3 technology item(s) the review found current on 2026-10-01. They are not defects, but most carry a follow-up — a floor to raise, a sentence to correct, a pin to bump — and every one should be re-checked before each release.

Items

• TECH-T01-007 (technology, Next release) — TRL trainers and alignment methods: GRPO variants and defaults (DAPO, Dr.GRPO, GSPO, GFPO, async GRPO; loss_type, beta, scale_rewards) (current)
  severity Next release
  Item. GRPO variants and defaults (DAPO, Dr.GRPO, GSPO, GFPO, async GRPO; loss_type, beta, scale_rewards) · verdict: current · urgency: Next release
  State in ForgeLM. ForgeLM sets no loss_type, beta, scale_rewards or importance_sampling_level for GRPO, so it inherits TRL's defaults. docs/usermanuals/en/training/grpo.md:59 and :92 say KL beta is 'governed by TRL's defaults'. grpo.md:99 (TR :96) says GRPO 'Keeps a reference model in memory'.
  State of the ecosystem on 2026-10-01. GRPOTrainer remains a stable top-level trainer (v1.14.1 _toctree). The arbiter probe shows the same defaults on 1.0.0, 1.7.1 and 1.14.1: loss_type='dapo', beta=0.0, scale_rewards='group', importance_sampling_level='token', num_generations=8. The help text marks loss_type='grpo' as 'Not recommended due to length bias' (grpo_config.py 1.14.1:236-247). With beta=0.0 the trainer builds no reference m…
  Recommendation. Correct grpo.md:99 and TR :96. Name the effective TRL defaults (loss_type=dapo, beta=0.0, scale_rewards=group) in the docs and record the resolved values in the compliance manifest. Optionally expose grpo_loss_type and grpo_beta as config fields.
  Sources.

  • TRL v1.14.1 docs: GRPO Trainer (beta=0.0 default, dapo, dr_grpo, scale_rewards) (2026-09-29)
  • TRL v1.14.1 Paper Index (GSPO via importance_sampling_level='sequence') (2026-09-29)

• TECH-T11-005 (technology, Next release) — Regulation and standards: GDPR, ISO/IEC 27001, SOC 2, ISO/IEC 42001, EDPB, EU Cyber Resilience Act: ISO/IEC 27001:2022 (+Amd 1:2024) Annex A: 93 controls A.5-A.8 and ForgeLM's control mapping (curren…
  severity Next release
  Item. ISO/IEC 27001:2022 (+Amd 1:2024) Annex A: 93 controls A.5-A.8 and ForgeLM's control mapping · verdict: current · urgency: Next release
  State in ForgeLM. docs/reference/iso27001_control_mapping.md, docs/design/iso27001_soc2_alignment.md:47/:134-140 and docs/qms/statement_of_applicability.md:4 cite ISO/IEC 27001:2022 Annex A with 93 controls (37/8/14/34). Amd 1:2024 and ISO/IEC 27701 are never cited. iso27001_control_mapping.md:27 (TR :26) says 'human_approval.required/granted enforces trainer ≠ approver'. No such check exists in forgelm/, and stat…
  State of the ecosystem on 2026-10-01. The ISO open-data catalogue (Last-Modified 2026-09-30, retrieved today) lists ISO/IEC 27001:2022 (ed. 3, 2022-10-25, stage 60.60, replacedBy none) and ISO/IEC 27001:2022/Amd 1:2024 'Climate action changes' (2024-02-23, stage 60.60). No in-progress 27001 project appears, and the IEC webstore lifecycle shows underDevelopmentProduct: []. ISO/IEC 27002:2022 lists replacedBy [94703], which has no publ…
  Recommendation. Change mapping :27 (EN+TR) to 'records both identities; enforcement is deployer-side (IdP)', matching SoA :32. Use the official titles for A.5.31 and A.7.1 everywhere (EN+TR, SoA, design). Cite 'ISO/IEC 27001:2022 + Amd 1:2024' in the headers. Optionally map A.5.34 privacy evidence to ISO/IEC 27701:2025. Track 27002 project 94703 and re-validate the mapping when a DIS appears.
  Sources.

  • ISO Open Data: deliverables metadata (Last-Modified 2026-09-30) (2026-09-30)
  • ISO/IEC 27001:2022, IEC webstore (lifecycle incl. AMD1:2024; nothing under development) (2026-10-01T14:40:01Z)

• TECH-T12-007 (technology, Next release) — Supply-chain tooling, network dependencies and vulnerability scanning: pip-audit>=2.7.0,<3.0.0 and bandit[toml]>=1.7.0,<2.0.0 ([security]/[dev] extras; nightly and CI usage) (current)
  severity Next release
  Item. pip-audit>=2.7.0,<3.0.0 and bandit[toml]>=1.7.0,<2.0.0 ([security]/[dev] extras; nightly and CI usage) · verdict: current · urgency: Next release
  State in ForgeLM. pyproject.toml:224,233-234; ci.yml:517-524 runs bandit on push/PR to main; nightly.yml:309-334 runs pip-audit (no -s flag; || true followed by tools/check_pip_audit.py) and bandit, and is triggered only by schedule and workflow_dispatch; publish.yml runs neither. tools/pip_audit_ignores.yaml entries carry verified_at 2026-05-21 (133 days old; check_pip_audit.py warns after 90). Installed pip-au…
  State of the ecosystem on 2026-10-01. pip-audit 2.10.1 (2026-06-10) and bandit 1.9.4 (2026-02-25) are the latest releases and PyPI lists no advisories for them. pip-audit's --vulnerability-service defaults to pypi (choices osv, pypi, esms); --locked audits pyproject and pylock files.
  Recommendation. Fix the doc claims (or pass -s osv and add a pip-audit/bandit step to publish.yml), re-verify and re-date the ignore entries, and raise the floors to the versions the gates are written against.
  Sources.

  • PyPI pip-audit 2.10.1 (2026-06-10)
  • PyPI bandit 1.9.4 (2026-02-25)

Done when

• Each item's follow-up is done, or the item is re-checked and noted as still current (tick it here).

_{Found by the October 2026 ForgeLM code and documentation review against commit cab2947. Code links point at that commit; line numbers may have moved since. Finding IDs (CR-…, DOC-…, TECH-…) are stable references for this backlog.}