The fourth governance gate verifies that the AISDP remains current with respect to the change being deployed. A modification that passes every technical and fairness gate may still create a non-conformity if affected documentation modules have not been updated. This page covers the module-to-change mapping, evaluation criteria, and alternatives for manual currency verification.
The documentation currency gate prevents non-conformities caused by outdated AISDP modules after system changes. The gate queries the AISDP synchronisation layer to determine which of twelve modules are affected by the current change using a module-to-change-type mapping. The gate passes only when all affected modules reference current evidence from the latest pipeline execution or have been flagged as reviewed by the AI System Assessor. Modules 10 and 12 are affected by every change since they record version control and change history. The Documentation Currency Record lists each affected module, its evidence version, currency status, and reviewer confirmation. Without an automated synchronisation layer, the AI System Assessor maintains the mapping manually and conducts currency checks before each deployment. Manual checks are reliable when diligent but risk being rushed under deployment pressure, mitigated by making the signed check a prerequisite for the deployment authorisation gate.
The fourth governance gate verifies that the AISDP remains current with respect to the change being deployed.
The fourth governance gate verifies that the aisdp remains current with respect to the change being deployed. A system modification that passes every technical and fairness gate may still create a non-conformity if the AISDP modules affected by the change have not been updated to reflect the new state.
Each AISDP module has defined trigger conditions that determine when a currency check is required.
Each AISDP module has defined trigger conditions that determine when a currency check is required. Module 1 (System Description) is triggered by changes to intended purpose, target population, or deployment context. Module 2 (Model Selection) is triggered by changes to model component, model version, or model provider. Module 3 (Architecture) is triggered by changes to system architecture, infrastructure, or component interfaces. Module 4 (Data Governance) is triggered by changes to training data, validation data, feature set, or data sources.
Module 5 (Testing) is triggered by any change that triggers model re-evaluation. Module 6 (Risk Management) is triggered by any change that activates the risk gate. Module 7 (Human Oversight) is triggered by changes to the oversight interface, operator workflow, or override mechanism. Module 8 (Transparency) is triggered by changes to user-facing explanations, instructions for use, or disclosure text. Module 9 (Cybersecurity) is triggered by changes to security architecture, dependencies, or threat model.
Without an AISDP synchronisation layer, the documentation currency check is a manual step performed before each deployment.
Without an AISDP synchronisation layer, the documentation currency check is a manual step performed before each deployment. The AI System Assessor maintains the module-to-change-type mapping as a reference checklist. Before each deployment, the Assessor reviews the change log, identifies the affected modules using the mapping, and verifies that each affected module has been updated to reflect the current change. The Assessor records the check in a structured form and signs it.
Manual currency checks are reliable when conducted diligently. The risk is that the check is rushed or omitted under deployment pressure. The AI Governance Lead mitigates this risk by making the signed currency check a mandatory prerequisite for the deployment authorisation at , ensuring that no deployment can proceed without documented confirmation that the AISDP is current.
Yes. The AISDP synchronisation layer compares each module's evidence references against the current pipeline execution. Modules with outdated references are flagged automatically. Human review is still needed for modules requiring narrative judgement.
The gate fails and deployment is blocked until the module is either auto-populated with current evidence or the AI System Assessor confirms it has been manually reviewed and updated.
No. Only the modules affected by the specific change type need updating. However, Modules 10 and 12 are affected by every change since they record version control and change history.
A system change that passes technical and fairness gates may still create a non-conformity if the AISDP modules it affects have not been updated to reflect the change.
A module-to-change-type mapping defines trigger conditions. The synchronisation layer checks whether each affected module references current evidence from the latest pipeline execution.
Twelve modules map to specific change types. Modules 10 and 12 are affected by every change. Other modules are triggered by specific categories such as model, data, architecture, or oversight changes.
The AI System Assessor manually reviews the change log, identifies affected modules, verifies updates, and signs a structured form as a prerequisite for deployment authorisation.
The gate queries the AISDP synchronisation layer to determine which modules are affected by the current change. It then checks, for each affected module, whether the module has been updated to reflect the change. The gate passes only when all affected modules are either auto-populated with the current pipeline execution's evidence or flagged as reviewed by the AI System Assessor. The gate fails if any affected module references evidence from a previous pipeline execution while a newer execution has produced superseding evidence.
The gate produces a Documentation Currency Record listing each affected module, the evidence version it references, whether the reference is current, and the reviewer's confirmation. This record is deposited in the governance artefact registry and feeds AISDP Module 10 covering version control and change management.
Modules 10 (Version Control) and 12 (PMM and Change History) are triggered by every change because they record the change itself and the full change history respectively. Module 11 (FRIA) is triggered only when the risk gate flags a change as having fundamental rights implications.
The AISDP synchronisation layer performs the automated check, the AI System Assessor reviews and confirms currency of modules requiring human judgement, and the Conformity Assessment Coordinator verifies the check as part of the continuous assessment process.
CTO of Standard Intelligence. Leads platform engineering and contributes to the PIG series technical content.
