Hardcoded thresholds, such as if score > 0.65 embedded directly in code, undermine version control and change tracking. When a threshold is embedded in application code, changing it requires a code change that may be reviewed as a software fix rather than as a compliance-relevant configuration change. The threshold’s history becomes entangled with the code’s history, making it difficult to isolate threshold changes for substantial modification assessment.

The Semgrep rule for hardcoded threshold detection flags magic numbers in decision logic, matching patterns where a score or prediction variable is compared against a literal float value. The rule directs the developer to define the threshold in a version-controlled configuration file, where threshold changes are tracked independently and subject to their own governance review.

This rule supports the broader principle that all compliance-relevant parameters should be externally configurable, version-controlled, and subject to explicit governance. A hardcoded threshold that is changed in a large code commit may escape the scrutiny it deserves; a threshold change in a dedicated configuration file is visible, reviewable, and assessable against the substantial modification framework.

Key outputs

• Semgrep rule for hardcoded threshold detection
• Developer guidance directing thresholds to configuration files
• Integration with pre-commit hooks and CI pipeline
• Module 10 and Module 3 documentation