Skip to content

Five more SOC2 rows cite evidence ForgeLM does not produce: SoD enforcement (CC1.2), an 'Annex IV public summary' (CC2.2), config_hash 'in model_lineage' (PI1.4), a co-located Ann… (CR-A10-009) #456

Open

Description

@cemililik

Wave 1 · theme D1-9: Compliance mappings and marketing language · highest severity High · 1 finding(s) · effort small

Summary

An auditor following the SOC2 mapping looks for config_hash under model_lineage, a public Annex IV summary, a co-located evidence bundle with the audit log and integrity manifest, integrity hashes in the keyed audit chain, and an enforced approver/trainer separation. None is there; the mapping overstates operating controls.

Primary finding

CR-A10-009 — Five more SOC2 rows cite evidence ForgeLM does not produce: SoD enforcement (CC1.2), an 'Annex IV public summary' (CC2.2), config_hash 'in model_lineage' (PI1.4), a co-located Annex IV bundle (PI1.5)…

severity High · reachability default · intent contract-violation · confidence confirmed · independently confirmed · reproduced end to end

What happens. These rows each overstate or misplace evidence; the TR mirror makes the same claims. (1) CC1.2 (:29) presents 'Approval gate operator ≠ trainer' as ForgeLM evidence. Nothing compares the approver with the trainer's operator (_approve.py:121-175, 597-603), and when FORGELM_OPERATOR is set the two 'collapse to the same value' by design (_approve.py:597-602). human_approval_gate.md:25 itself says ForgeLM does not enforce segregation of duties. This is distinct from the already-reported post-hoc-detection item. (2) CC2.2 (:34) cites an 'Annex IV public summary'. No such artefact exists (no match for 'public summary' in forgelm/). The only Annex IV output is annex_iv_metadata.json, a technical document that can carry monitoring.endpoint verbatim (already reported), so treating it as a public summary is unsafe. (3) PI1.4 (EN :82 / TR :81) places config_hash 'in model_lineage'. It is a top-level manifest key (compliance.py:1516-1517); model_lineage has no config_hash (confirmed on a real run). (4) PI1.5 (EN :83 / TR :82) says the 'Annex IV bundle co-locates manifest + report + audit + integrity'. The trainer writes the compliance files to <output_dir>/compliance/ (trainer.py:2087-2088), the audit log to <output_dir>/audit_log.jsonl (compliance.py:175) and model_integrity.json to <output_dir>/final_model/ (trainer.py:2161-2165). The Annex IV artefact names the log only by bare basename, with no path, run_id or digest (compliance.py:1857), and references model_integrity.json not at all. No bundle is produced on any CLI path. Related: M5r1-A07-057 and the already-reported export_evidence_bundle / enterprise-guide items. (5) CC3.4 (:39) cites 'model.integrity_verified SHA-256 artifact hashes for diff'. The event carries only an artifact count (trainer.py:2167) and is emitted at…

Where.

Evidence.

  • The run1 artefact layout is out/audit_log.jsonl(+.manifest.json); out/compliance/{annex_iv_metadata.json, compliance_report.json, data_governance_report.json, data_provenance.json, training_manifest.yaml}; out/final_model/{model_integrity.json, deployer_instructions.md, README.md, adapter files}. The model_lineage keys are adapter_method, backend, base_model, base_model_revision, component_revisions, quantization and trust_remote_code. The integrity_verified line is {..., "event": "model.integr…

Recommended fix. CC1.2: mark as deployer-side (ForgeLM records both identities only). CC2.2: drop 'Annex IV public summary' or name model card README.md. PI1.4: say 'config_hash (top-level)'. PI1.5: describe the real three locations and that no bundle is produced (or wire export_evidence_bundle). CC3.4: say the event records an artifact count; hashes live only in the unkeyed model_integrity.json. Optionally put the integrity-manifest digest into model.integrity_verified so the keyed chain anchors it.

Acceptance criteria

  • A regression test reproduces the failure scenario and asserts the corrected behaviour.
  • Documentation listed above is corrected in English and in its Turkish mirror in the same PR.
  • Every finding in this issue is resolved or explicitly closed with a reason.

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: gdpr-approvalCode area: gdpr-approvalbugSomething isn't workingseverity: highWrong behaviour or a false claim users rely onsource: review-2026-10Found by the October 2026 code and documentation reviewwave: 1Roadmap wave 1: high severity, small effort

    Type

    No type

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions