Decision Thresholds & Feature Flags

Decision thresholds and feature flags are configuration artefacts that materially affect the system’s behaviour. A change to a decision threshold (for example, raising the shortlisting score from 65 to 70) alters which individuals are affected by the system’s outputs. A feature flag that enables or disables a processing pathway changes the system’s functional behaviour. Both types of change must be version-controlled with the same rigour as code and model changes.

Configuration artefacts should be stored as configuration-as-code in version-controlled repositories, separate from application code. Each configuration change produces a new version with a timestamp, the identity of the author, and a description of the change. The configuration version forms one of the five components of the composite version identifier described above.

Threshold changes are assessed against the substantial modification framework. A threshold change that shifts the system’s fairness profile or significantly alters its selection rates may constitute a substantial modification, even though no code or model has changed. The AI Governance Lead reviews threshold changes before deployment, and the review record is retained as Module 10 evidence.

Key outputs

• Version-controlled configuration files for thresholds and feature flags
• Change tracking with author identity, timestamp, and rationale
• Integration into the composite version identifier
• AI Governance Lead review records for threshold changes

Business Rules

Business rules applied in the post-processing layer are configuration artefacts that shape the system’s outputs. Each rule modifies the model’s raw output and changes the outcome that affected persons experience. Business rules must therefore be version-controlled, with each change tracked, reviewed, and assessable against the substantial modification thresholds.

Like decision thresholds, business rules should be stored as configuration-as-code, separate from the application code that executes them. This separation ensures that rule changes are visible as discrete, reviewable events rather than buried within broader code changes. The configuration file records each rule’s definition, its rationale, and its fairness impact assessment.

Changes to business rules follow the same governance pathway as threshold changes. The Technical SME assesses the fairness impact of the proposed change, the AI Governance Lead reviews and approves, and the change is deployed through the CI/CD pipeline with the updated configuration version reflected in the composite version identifier. The complete history of business rule changes is retained as Module 10 and Module 12 evidence.

Key outputs

• Version-controlled business rule configuration files
• Per-rule definition, rationale, and fairness impact assessment
• Governance review and approval records
• Module 10 and Module 12 AISDP documentation

LLM Prompts & System Instructions

For AI systems incorporating large language models, the system prompt is one of the most consequential design artefacts. It defines the model’s behaviour: its constraints, persona, output format, safety boundaries, and domain-specific instructions. A change to the system prompt can alter the system’s outputs as materially as a change to the model’s weights.

Despite this significance, system prompts are frequently managed outside formal version control. They may be edited by product managers without engineering review or stored in configuration files not subject to change control. This governance gap creates compliance risk: a prompt change that materially alters the system’s behaviour may constitute a substantial modification under Article 3(23) without being assessed as such.

System prompts for high-risk AI systems should be treated as version-controlled, governed artefacts. They are stored in Git or a dedicated prompt registry with equivalent versioning and audit logging. Every prompt change produces a new version with a timestamp, the author’s identity, and a change description. Changes that could alter the system’s intended purpose or compliance-relevant behaviour are assessed against the substantial modification thresholds. Changes should trigger re-execution of the sentinel dataset test to verify outputs remain within declared thresholds. Module 3 records the current prompt version and content; Module 10 records the prompt governance process and change history.

Key outputs

• Version-controlled prompt artefacts in Git or a dedicated prompt registry
• Prompt change approval process (Technical SME and AI Governance Lead review)
• Sentinel test re-execution on prompt changes
• Module 3 and Module 10 AISDP documentation