Skip to content

[Wave 3] Medium — Security-contract fixes: Provenance accuracy #647

Open

Description

@cemililik

Wave 3 · 25 finding(s) in 19 fix package(s). Medium-severity findings that touch the security contract (exit codes, secrets, paths, provenance): do these before the rest of wave 3.

Findings

  • CR-A01-038 (code, Medium) — Risk tier defaults to 'minimal-risk' and is emitted into Annex IV as a declared classification even when the operator never set one; docs also claim the tier drives auto-revert thresholds
    severity Medium · reachability default · intent intended-but-harmful · confidence confirmed · independently confirmed · reproduced end to end
    Failure scenario. A deployer who has not yet classified the system ships an Annex IV bundle asserting minimal risk.
    Where. forgelm/config.py:1232-1238, forgelm/config.py:1266-1269, forgelm/config.py:1318-1321, forgelm/compliance.py:1553-1561
    Recommended fix. Record whether the tier was explicitly set (model_fields_set) or default to 'unknown' at the next MAJOR; correct the 'drives auto-revert thresholds' claim.

  • CR-A01-043 (code, Medium) — Auto-chained pipeline stages re-load the Hub base model through the adapter's base_model_name_or_path without resolving or recording it; the stage manifest then asserts a different base commit
    severity Medium · reachability default · intent contract-violation · confidence confirmed · independently confirmed · reproduced end to end
    Failure scenario. Pipeline config: root model.name_or_path: org/base, with model.revision unset or 'v1.0'; stages sft then dpo, and the dpo stage has no model: block. Stage sft pins org/base to commit A. Before dpo starts, the default branch or tag moves to B, through an upstream push or a refreshed shared cache. Stage dpo fine-tunes on top of base commit B with no warning. Its compliance_report.json says model_lineage.base_model_revision={repo_id: .../final_model, resolution_source: local_path} and component_re…
    Where. forgelm/config.py:2156, forgelm/compliance.py:1296, forgelm/model.py:157, forgelm/model.py:589
    Recommended fix. When name_or_path is a directory holding adapter_config.json without config.json, resolve and pin base_model_name_or_path under ROLE_BASE_MODEL. Prefer the SHA the previous stage recorded, carried through pipeline state or written into the adapter dir, over the raw literal. Record that as the base entry. Clear the registry between stages, as known defect (2) also requires. Correct the local-path…

  • CR-A02-033 (code, Medium) — _measure_baseline_loss mutates config.evaluation.baseline_loss, so the manifest config_hash differs from the envelope and approval-event config_hash
    severity Medium · reachability default · intent contract-violation · confidence confirmed · independently confirmed · reproduced end to end
    Failure scenario. An auditor recomputes the config hash from the archived YAML and compares it to compliance_report.json: mismatch, i.e. the manifest appears bound to a different configuration than the one approved.
    Where. forgelm/trainer.py:358-365, forgelm/trainer.py:1282-1284, forgelm/trainer.py:1325 (confirmed), forgelm/trainer.py:1551
    Recommended fix. Keep the measured baseline in trainer state (e.g. self._measured_baseline) and pass it to execute_evaluation_checks instead of writing it into config; have generate_training_manifest take the precomputed _config_hash.

  • CR-A02-055 (code, Medium) — Training runtime, cost and train_loss cover only the last trainer.train() session
    severity Medium · reachability default · intent contract-violation · confidence confirmed · independently confirmed · reproduced end to end
    Failure scenario. A 10 h run with oom_recovery: true hits OOM at hour 6. It restarts from step 0 at half batch (documented residual semantics) and finishes 10 h later. resource_usage, the manifest and Annex IV record 10 GPU-hours, though about 16 were used. A run preempted at step 9000/10000 and resumed with --resume records about 10% of its compute, with no resume marker anywhere.
    Where. forgelm/trainer.py:1845-1851 (confirmed), forgelm/trainer.py:1270, forgelm/trainer.py:1579-1580 (confirmed), forgelm/trainer.py:1622-1644
    Recommended fix. Time the whole _run_with_oom_recovery loop and record per-attempt runtimes (attempts, failed_attempt_seconds). On resume, record resumed_from and either add the checkpoint's prior session runtime or mark the figures segment_only. Collect resource_usage on the gate-failure and revert paths too. Reword the docs if the figure stays session-scoped.

  • CR-A02-056 (code, Medium) — GPU info samples device 0 and counts node-visible GPUs, not the run's devices
    severity Medium · reachability default · intent contract-violation · confidence confirmed · independently confirmed · reproduced with stubs
    Failure scenario. Documented 2x4 multi-node run, 2 h, A100-SXM4-80GB: each node's compliance_report.json and Annex IV record gpu_count 4, gpu_hours 8.0 and $16, against 16 GPU-hours and $32. Rank 5 (local rank 1) writes peak_vram_gb 0.0. On an 8-GPU host using the documented docker command with nproc 4: gpu_count 8, gpu_hours 16 and $32 for 8 GPU-hours.
    Where. forgelm/trainer.py:1835-1843 (confirmed), forgelm/trainer.py:1880-1896, docs/reference/distributed_training.md:169-201, docs/usermanuals/en/operations/gpu-cost.md:93-104
    Recommended fix. Under distributed training use self.trainer.args.world_size (one GPU per rank). Use args.n_gpu for the DataParallel case and the distinct CUDA devices in hf_device_map for model parallelism. Sample the rank's own device (args.device / torch.cuda.current_device()), all-reduce the max peak, and write on rank 0 only.

  • CR-A03-030 (code, Medium) — Process-global revision registries are never reset, so later stages' manifests and component_revisions claim earlier loads
    severity Medium · reachability default · intent contract-violation · confidence confirmed · independently confirmed · reproduced end to end · already tracked: KNOWN-OPEN TRUST-08 — docs/roadmap/phase-16-trust-surface-hardening.md:519-522,542-543 (S8 open)
    Failure scenario. Two pipeline stages use the same Hub dataset. The upstream repo moves between them and stage 2's dataset_info call times out. Stage 2 trains on the new HEAD, but its manifest records stage 1's SHA as the loaded corpus.
    Where. forgelm/data.py:115 (confirmed), forgelm/data.py:333, forgelm/data.py:337, forgelm/compliance.py:978-985, forgelm/cli/_pipeline.py:1562-1564
    Recommended fix. _RESOLVED_DATASET_REVISIONS.pop(path, None) before every load of path, and write it only after a pinned load succeeds. Better still, return the revision with the dataset rather than through a global.

  • CR-A03-031 (code, Medium) — Training manifest, Annex IV, model card and deployer docs describe quantization and PEFT method from raw config flags, not the applied load: always '4-bit NF4', DoRA/rsLoRA/PiSSA dropped or misreport…
    severity Medium · reachability default · intent contract-violation · confidence confirmed · independently confirmed · reproduced end to end · already tracked: KNOWN-OPEN C31-RUN-OUTCOME — docs/roadmap/phase-16-trust-surface-hardening.md:519-530,540-544 (S8 open)
    Failure scenario. Training on a Mac/CPU CI runner with a QLoRA config produces a full-precision model whose manifest and model card assert 4-bit NF4; an auditor relies on the artefact.
    Where. forgelm/model.py:439-460 (CUDA-gated BitsAndBytesConfig; warning-only fallback at 450-460), forgelm/compliance.py:1536 (dora from use_dora), forgelm/compliance.py:2338-2354 (_describe_adapter_method), forgelm/model_card.py:227-233 (_build_extra_tags)
    Recommended fix. Record the effective quantization (set by the loader, as with the revision registry) and the actual bnb_4bit_quant_type; at minimum have the manifest state 'configured: 4-bit; effective: none (CUDA unavailable)'.

  • ↳ same root cause: DOC-D3B01-017 (docs, Medium) — docs/usermanuals/en/compliance/model-card.md: misleading — The card auto-populates the fine-tuning method, the DoRA flag and method-derived tags.
    severity Medium · already tracked: KNOWN-OPEN C31-RUN-OUTCOME docs/roadmap/phase-16-trust-surface-hardening.md:519-525
    Where. docs/usermanuals/en/compliance/model-card.md:14-15 (Turkish mirror: docs/usermanuals/tr/compliance/model-card.md:14-15) · type: misleading
    The document says. The card auto-populates the fine-tuning method, the DoRA flag and method-derived tags.
    What the code does. Method, tags and the DoRA row read only the deprecated lora.use_dora. A run configured with the current lora.method: dora renders 'DoRA | False', no dora tag and method 'QLoRA (4-bit)' / 'LoRA' (repro). pissa and rslora also render as 'LoRA'. compliance._describe_adapter_method handles method correctly.
    Code references. forgelm/model_card.py:217-238, forgelm/compliance.py:2338-2354, review-probe:repro_card.py
    Proposed correction. Fix the code: derive the method, tags and DoRA row from lora.method. Until then: "The DoRA row and tags reflect only the deprecated lora.use_dora; runs configured with lora.method: dora|pissa|rslora are shown as LoRA."
    Turkish mirror. the Turkish page has the same error; fix both in the same PR

  • CR-A04-025 (code, Medium) — synthetic.teacher_revision is honoured at load but never recorded in any artefact on the CLI path
    severity Medium · reachability default · intent contract-violation · confidence confirmed · independently confirmed · reproduced (plumbing only) · already tracked: KNOWN-OPEN TRUST-08 — docs/roadmap/phase-16-trust-surface-hardening.md:546-547 (S8 open)
    Where. forgelm/cli/_no_train_modes.py:180-246, forgelm/synthetic.py:292-314, forgelm/model.py:76, docs/reference/configuration.md:613
    Recommended fix. Persist the teacher's revision record next to the generated dataset and surface it in the training manifest, or correct the docs to say the teacher pin is applied but not recorded.

  • CR-A04-031 (code, Medium) — Single-stage --resume leaves no provenance: no audit event, manifest, Annex IV, model card or envelope field says the run resumed, from which checkpoint, or which run it continues
    severity Medium · reachability default · intent intended-but-harmful · confidence confirmed · independently confirmed · reproduced end to end
    Failure scenario. Reproduced in scenA. Run 1 (cfg1.yaml: sft, max_steps 4, save_steps 2) is preempted right after checkpoint-2 with EXIT=137. Its audit log holds only fg-c313de371f2f pipeline.initialized and training.started. Run 2 (same config, --resume --output-format json) exits 0 under the new run_id fg-fc13c8e77ccb. It emits pipeline.initialized, training.started, model.integrity_verified, compliance.governance_exported, compliance.governance_section_missing, compliance.artifacts_exported and pipeline.compl…
    Where. forgelm/cli/_training.py:144-149, forgelm/trainer.py:352-357, forgelm/trainer.py:1574, forgelm/trainer.py:1231
    Recommended fix. Emit a catalogued training.resumed event before trainer.train(). It should carry the checkpoint path, its global_step, the sha256 of the checkpoint's trainer_state.json and the prior run_id. The prior run_id needs to be persisted, for example by a TrainerCallback.on_save sidecar written into each checkpoint-N. Add a resumed_from block to the manifest, the Annex IV system_components or technic…

  • CR-A04-032 (code, Medium) — --resume does no checkpoint-vs-config compatibility check: changed dataset, base model, lora.alpha or learning_rate continue silently (exit 0) and every artefact credits the whole model to the new co…
    severity Medium · reachability default · intent contract-violation · confidence confirmed · independently confirmed · reproduced end to end
    Failure scenario. Every case below was reproduced with exit 0 and no warning beyond 'Auto-detected checkpoint for resume'. - scenB, dataset changed: the preempted run trained steps 1-2 on env/datasets/sft.jsonl (sha256 025064a3…); the resume trained steps 3-4 on data/sft_b.jsonl (sha256 c4d3b5eb…). checkpoint-4/trainer_state.json log_history holds steps 1-4. compliance_report data_provenance.fingerprint.sha256 is c4d3b5eb…, annex_iv_metadata.json data_governance names only sft_b.jsonl, and the model card Dataset…
    Where. forgelm/cli/_resume.py:13-66, forgelm/cli/_resume.py:58-66, forgelm/cli/_training.py:144-149, forgelm/trainer.py:1231
    Recommended fix. Write a sidecar into every checkpoint through a TrainerCallback.on_save, holding config_hash, base model plus revision, dataset fingerprint(s), LoRA r/alpha/targets/method, trainer_type and the optimizer/scheduler settings. On --resume, compare the sidecar with the current config. Also cross-check the checkpoint's adapter_config.json against config.lora and config.model. Refuse on any mismatch wi…

  • CR-A04-039 (code, Medium) — Bare --resume silently resumes the checkpoint-N of an auto-reverted run, and a follow-up run promotes the byte-identical rejected weights with exit 0 and no link to the revert (extends M-A02-005)
    severity Medium · reachability default · intent contract-violation · confidence confirmed · independently confirmed · reproduced end to end
    Failure scenario. A loss, safety or judge gate auto-reverts run A, and final_model is deleted. The operator or a CI retry (bare --resume, the documented preemption recovery) re-runs with a relaxed threshold, or relies on a stochastic gate. HF loads the rejected checkpoint-N. The new run passes and promotes the very weights that were rejected, exits 0, and its compliance bundle, model card, model_integrity.json and envelope show an ordinary successful run.
    Where. forgelm/cli/_resume.py:21-66, forgelm/cli/_training.py:144-149, forgelm/trainer.py:960-1007, forgelm/trainer.py:1571-1579
    Recommended fix. When resuming, read the output_dir audit log or the checkpoint's sibling manifest. Refuse, or require an explicit flag recorded in the audit log, when the checkpoint's source run ended in model.reverted. Record the source run_id (see finding 1). Alternatively delete or quarantine checkpoint-N on revert (M-A02-005 remedy).

  • CR-A07-031 (code, Medium) — Compliance dir keeps stale artefacts from earlier runs; a stale annex_iv_metadata.json verifies clean and the audit event lists stale files as exported
    severity Medium · reachability default · intent contract-violation · confidence confirmed · independently confirmed · reproduced end to end
    Failure scenario. An auditor receives a compliance/ dir whose Annex IV and Art. 9 risk assessment belong to an earlier run, together with an audit log entry claiming they were exported by the current run.
    Where. forgelm/compliance.py:2146-2153, forgelm/trainer.py:2094-2097, forgelm/trainer.py:2138-2147, forgelm/compliance.py:2205-2227
    Recommended fix. Remove (or move into the backup set) the bundle files this export does not produce, inside the same all-or-nothing promotion. Have the trainer log the list returned by export_compliance_artifacts rather than os.listdir.

  • CR-A07-044 (code, Medium) — Governance report inlines any data_audit_report.json in output_dir without binding it to the training dataset
    severity Medium · reachability default · intent intended-but-harmful · confidence confirmed · independently confirmed · reproduced end to end
    Where. forgelm/compliance.py:668-704, forgelm/compliance.py:730-733, forgelm/trainer.py:2111-2116
    Recommended fix. Compare report.source_input/source_path with the configured dataset (and extra_datasets). On a mismatch, refuse to inline it, or inline it with a mismatch flag and log a distinct audit event. Use a distinct event or reason for 'present but unreadable'.

  • CR-A07-051 (code, Medium) — benchmark.evaluation_completed and judge.evaluation_completed are emitted for evaluations that never ran, with an invented average of 0.0 and no failure reason or evaluation_completed discriminator
    severity Medium · reachability documented-opt-in · intent contract-violation · confidence confirmed · independently confirmed · reproduced end to end
    Failure scenario. A judge API outage or bad key (HTTP 401) during a regulated run produces a hash-chained record saying the judge scored the model 0.0 and failed it. A reviewer reading the chain cannot tell an outage from a catastrophically bad model. Under auto_revert the model is deleted on an outage, with only model.reverted.detail hinting at the cause.
    Where. docs/reference/audit_event_catalog.md:35, forgelm/benchmark.py:177-191, forgelm/benchmark.py:189, forgelm/benchmark.py:21-24
    Recommended fix. Add failure_reason, plus an evaluation_completed or measured flag, to both events. Emit average/average_score as null when nothing was scored. Update the catalog triggers to say the event also records an evaluation that could not run.

  • CR-A07-061 (code, Medium) — With training.max_steps set, the manifest, Annex IV §2, training_manifest.yaml and the model card state the configured num_train_epochs as 'epochs' and never record max_steps
    severity Medium · reachability default · intent contract-violation · confidence confirmed · independently confirmed · reproduced end to end
    Failure scenario. Config max_steps: 2 with the default num_train_epochs: 3. Annex IV §2 and compliance_report.json say epochs 3, training_manifest.yaml says epochs: 3 and the model card says '| Epochs | 3 |', but the run trained 2 optimiser steps (0.11 epoch). In the reverse case (small dataset, large max_steps) the artefacts understate training by many epochs.
    Where. forgelm/compliance.py:1528, forgelm/trainer.py:498-499, forgelm/config.py:465-472, forgelm/compliance.py:1839-1842
    Recommended fix. Record max_steps alongside epochs, plus the effective global_step/epoch from the trainer state. Label 'epochs' as the configured epoch count only when max_steps == -1.

  • CR-A08-010 (code, Medium) — The synthetic teacher's pinned revision is never written to any artefact, although the docs say it lands in model_lineage.component_revisions
    severity Medium · reachability documented-opt-in · intent contract-violation · confidence confirmed · independently confirmed · not reproduced (code trace) · already tracked: KNOWN-OPEN TRUST-08 — docs/roadmap/phase-16-trust-surface-hardening.md:546-547 (S8 open)
    Failure scenario. An auditor looks for the teacher's revision in the trained model's manifest. It is not there, although the docs promise it, and nothing else records which teacher produced the corpus.
    Where. forgelm/synthetic.py:281-315, forgelm/model.py:168-179, forgelm/compliance.py:1476-1489, forgelm/cli/_no_train_modes.py:180-245
    Recommended fix. Write a provenance sidecar or audit event from --generate-data (teacher_model, revision record, counts, output sha256), or correct the docs.

  • ↳ same root cause: DOC-D1B06-019 (docs, Medium) — docs/qms/statement_of_applicability.md: false claim — A.5.19: teacher loads are pinned and recorded under model_lineage.component_revisions
    severity Medium
    Where. docs/qms/statement_of_applicability.md:48 (Turkish mirror: docs/qms/statement_of_applicability-tr.md:49) · type: false claim
    The document says. A.5.19: teacher loads are pinned and recorded under model_lineage.component_revisions
    What the code does. The teacher revision is never written into any manifest (the --generate-data process writes none, and training never loads the teacher).
    Code references. forgelm/synthetic.py:280-300, forgelm/cli/_no_train_modes.py:180-240
    Proposed correction. Fix the code or move the teacher to 'not recorded'.
    Turkish mirror. the Turkish page has the same error; fix both in the same PR

  • ↳ same root cause: DOC-D1B06-026 (docs, Medium) — docs/reference/iso27001_control_mapping.md: false claim — The synthetic teacher is pinned by teacher_revision and its resolved commit is recorded under model_lineage.component_revisions
    severity Medium
    Where. docs/reference/iso27001_control_mapping.md:43,133 (Turkish mirror: docs/reference/iso27001_control_mapping-tr.md:42,132) · type: false claim
    The document says. The synthetic teacher is pinned by teacher_revision and its resolved commit is recorded under model_lineage.component_revisions
    What the code does. The teacher's revision goes only into an in-process registry. The teacher is loaded only by --generate-data. That mode writes no compliance manifest and is rejected on pipelines, and the training process never loads the teacher, so component_revisions in a training run's compliance_report.json never contains the teacher. The classifier, judge and reward model are loaded in the training proces…
    Code references. forgelm/synthetic.py:280-300, forgelm/model.py:168-196, forgelm/compliance.py:1434-1488, forgelm/cli/_no_train_modes.py:180-240
    Proposed correction. Fix the code: persist the teacher's resolved revision with the generated data and fold it into the training manifest. Until then, say the teacher pin is applied to the load but not recorded in any manifest.
    Turkish mirror. the Turkish page has the same error; fix both in the same PR

  • ↳ same root cause: DOC-D1B06-031 (docs, Medium) — docs/reference/soc2_trust_criteria_mapping.md: false claim — The synthetic teacher is pinned and recorded under model_lineage.component_revisions
    severity Medium
    Where. docs/reference/soc2_trust_criteria_mapping.md:39,60 (Turkish mirror: docs/reference/soc2_trust_criteria_mapping-tr.md:39,60) · type: false claim
    The document says. The synthetic teacher is pinned and recorded under model_lineage.component_revisions
    What the code does. The teacher revision exists only in the registry of the --generate-data process, which writes no manifest. Training runs never load the teacher, so it is never recorded.
    Code references. forgelm/synthetic.py:280-300, forgelm/cli/_no_train_modes.py:180-240, forgelm/compliance.py:1434-1488
    Proposed correction. Fix the code to persist the teacher revision. Until then, move 'synthetic teacher' to 'Not covered'.
    Turkish mirror. the Turkish page has the same error; fix both in the same PR

  • CR-A08-019 (code, Medium) — Model card is tagged 'safety-evaluated' and renders a Safety section with no gate verdict, for models that failed or were never scored
    severity Medium · reachability default · intent intended-but-harmful · confidence confirmed · independently confirmed · reproduced end to end
    Failure scenario. Under the default auto_revert: false, a fine-tune fails the safety gate (unsafe ratio 30% against a 5% ceiling) and is kept. Its README is pushed to the Hub with a 'safety-evaluated' tag and a safety score, and nothing says the model failed the threshold or what the threshold was. The same happens for a run where the classifier never loaded.
    Where. forgelm/model_card.py:194-213, forgelm/model_card.py:342-348, forgelm/trainer.py:1400-1490, forgelm/trainer.py:1652 (confirmed)
    Recommended fix. Only add the safety-evaluated tag when the safety result passed and evaluation_completed. Render the gate verdict and failure_reason in the safety and benchmark sections, or suppress the card when train_result.error is set.

  • CR-A13-032 (code, Medium) — Deploy configs carry no source run-id, timestamp or tensor-parallel recommendation
    severity Medium · reachability default · intent contract-violation · confidence confirmed · independently confirmed · reproduced end to end
    Failure scenario. An auditor tracing a deployed vLLM or TGI config back to its training run finds no run-id or timestamp, despite the manual's assurance. A multi-GPU operator expecting a tensor_parallel_size gets none and runs single-GPU defaults.
    Where. forgelm/deploy.py:88-215, forgelm/deploy.py:153-180, forgelm/cli/_parser.py:104-139, docs/usermanuals/en/deployment/deploy-targets.md:83
    Recommended fix. Either emit a provenance header (ForgeLM version, UTC timestamp, run_id read from the model directory's compliance or integrity manifest when present) and an optional --tensor-parallel-size / --gpus flag, or remove the claims at deploy-targets.md:83, :152 and :171 in EN and TR.

  • CR-A08-037 (code, Low) — Base-model licence and attribution are not propagated; base_model and language metadata can be wrong
    severity Low · reachability default · intent intended-but-harmful · confidence likely · single reviewer · reproduced end to end
    Failure scenario. A card for a Llama derivative is pushed to the Hub with no license metadata and no attribution. A stage-2 pipeline card names a local directory as its base_model.
    Where. forgelm/model_card.py:97-106, forgelm/model_card.py:311, forgelm/config.py:2225-2226
    Recommended fix. Optionally read the base repo's license from the HF cache metadata, or add an opt-in config field. Record the root base model for pipeline stages, and make language configurable or omit it.

  • ↳ same root cause: DOC-BLEGAL-128 (docs, Medium) — docs/usermanuals/en/data/synthetic-data.md: misleading — Some providers (notably OpenAI for some models) restrict using outputs to train competing models.
    severity Medium
    Where. docs/usermanuals/en/data/synthetic-data.md:112 (Turkish mirror: docs/usermanuals/tr/data/synthetic-data.md:112) · type: misleading
    The document says. Some providers (notably OpenAI for some models) restrict using outputs to train competing models.
    What the code does. OpenAI's Terms of Use and Services Agreement restrict Output generally, not only for some models, with narrow permitted exceptions. The Anthropic Commercial and Consumer terms and the Gemini API terms also prohibit training competing models. Mistral's commercial terms do not restrict text outputs. The Llama 3.3 licence s.1.b.i requires a distributed model trained on Llama outputs to have a name b…
    Proposed correction. 'Several providers (e.g. OpenAI, Anthropic, Google Gemini) prohibit using outputs to develop competing models across their services; Llama licences add naming duties for distributed derivatives. Check the current terms for your teacher.' TR: 'Birçok sağlayıcı (ör. OpenAI, Anthropic, Google Gemini) çıktıların rakip model geliştirmede kullanımını hi…
    Turkish mirror. the Turkish page has the same error; fix both in the same PR

  • ↳ same root cause: DOC-BLEGAL-160 (docs, Medium) — site/js/translations.js: misleading — [IS-T14-07] 'Llama-3.1-8B is a balanced default' / badge 'recommended' (also site/js/wizard.js:139-140,1549, config_template.yaml:4, forgelm/wizard/_state.py:133)
    severity Medium
    Where. site/js/translations.js:1538, :1540 · type: misleading
    The document says. [IS-T14-07] 'Llama-3.1-8B is a balanced default' / badge 'recommended' (also site/js/wizard.js:139-140,1549, config_template.yaml:4, forgelm/wizard/_state.py:133)
    What the code does. meta-llama/Llama-3.1-8B-Instruct is gated=manual (Meta approval plus HF_TOKEN; an unauthenticated fetch returns 'Access ... is restricted') under the Llama 3.1 Community License. On redistribution of the model or a derivative, the licence requires providing the Agreement, displaying 'Built with Llama' and starting the model name with 'Llama' (s.1.b.i), and it requires a separate Meta licence abov…
    Proposed correction. Llama-3.1-8B — gated: requires accepting the Llama 3.1 Community License on Hugging Face and an HF_TOKEN; derivatives you distribute must carry 'Built with Llama' and a 'Llama'-prefixed name. Alternatively, make an ungated Apache-2.0 model the default.

Done when

  • Every finding above is fixed or closed with a reason (tick it here).
  • Code fixes carry a test; doc fixes update the Turkish mirror in the same PR.

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: complianceCode area: compliancearea: configCode area: configarea: integrationsCode area: integrationsbacklog: knownAlready tracked in docs/roadmapbugSomething isn't workingdocumentationImprovements or additions to documentationseverity: mediumReal defect with limited reach or a workaroundsource: review-2026-10Found by the October 2026 code and documentation reviewwave: 3Roadmap wave 3: medium severity, module sweeps

    Type

    No type

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions