Interpretations¶
Where the Guidelines text can be read more than one way, this file records the reading the toolkit implements by default (the stricter one), the lenient alternative, and the config option that switches between them. Paragraph numbers refer to the final Guidelines (7 Oct 2026).
| # | Clause | Ambiguity | Default (strict) | Lenient option | Config key |
|---|---|---|---|---|---|
| I-1 | §1.8 | "FIs may meet the expectations set out in Sections 3 to 4 from 7 October 2027, and Section 5 and 6 by 7 October 2028." The word from could be read as "no earlier than". The Response to Feedback §13.5 clarifies Sections 3–4 are due by 12 months (7 Oct 2027) and Sections 5–6 by 24 months (7 Oct 2028). | Sections 1–4 due 2027-10-07; Sections 5–6 due 2028-10-07. Gap reports flag Section 5–6 controls for high-materiality use cases as "apply as soon as possible" per Response §13.5. | none | — |
| I-2 | §2.3 / §2.5 | Which use cases qualify for basic governance only. §2.3 is an FI-level test ("the AI services or tools used by the FI"), not a per-use-case test. | The toolkit treats the basic-policy regime as FI-level: it applies only when every use case in the register passes the §2.3 test (no material adverse impact). A single material use case puts the whole FI under Sections 3–6. | regime: per_use_case lets an FI apply §2.5 to individual assistive use cases. |
materiality.basic_regime |
| I-3 | §4.11 / Response §7.21 | Whether "high risk materiality" triggers (§5.3, §5.19, §5.24, §5.23(b)) are keyed on inherent or residual rating. | Inherent rating, per Response §7.21. | none | — |
| I-4 | §4.12 | How Impact / Complexity / Reliance combine. MAS explicitly does not prescribe (Response §7.19). | Default rubric: tier = max of dimension levels, with Impact as primary and a gate: Complexity/Reliance can raise the tier at most one level above Impact. | Alternative rubrics via YAML. | materiality.rubric |
| I-5 | §4.7 | Inventory attributes are "may include". Completeness scoring treats all listed attributes as expected. | Completeness score counts every §4.7 attribute; missing attributes are reported as gaps, not failures (consistent with fn 24 which allows documented omissions). | inventory.required_attributes list override. |
inventory.required_attributes |
| I-6 | fn 25 | Agent attributes are an example ("may include"). | For any use case tagged agent, the toolkit expects the fn 25 attributes (identifiers, tools/systems accessible, components, guardrails) and reports them as gaps when missing. |
inventory.agent_attributes_required: false |
inventory.agent_attributes_required |
| I-7 | §5.8 | "Where fairness considerations are relevant". Relevance is an FI judgement. | Fairness controls are applicable whenever the use case affects customers or individuals (affects_individuals: true) or is tagged credit, insurance, advisory, hr. Otherwise not-applicable with reason. |
Explicit fairness_relevant override on the use case. |
use_case.fairness_relevant |
| I-8 | §5.19 | "formal independent validation" — independence of the validator. Response §10.55 allows external parties; Response §10.58 says vendor-commissioned reviews only qualify if independent of the vendor's dev team. | Validator must be a different party from owner, developer and deployer and must not be the vendor. |
controls.allow_vendor_validation: true |
controls.allow_vendor_validation |
| I-9 | §5.23(d) | Prompt/response logging for GenAI/agents "could also be considered". | Logging of prompts, responses, model version and reasoning/tool traces is expected (needs-attestation if absent) for GenAI/agent use cases rated Medium or above. | monitor.genai_logging: optional |
monitor.genai_logging |
| I-10 | §5.25(a) | What counts as a "significant" change. MAS leaves to the FI's framework (Response §10.73). | Default framework: changes to training data, architecture, key assumptions, scope of use, model version/provider, prompts/system instructions, tools granted to an agent → significant. | YAML override of change classes. | change.significant_classes |
| I-11 | §4.2 | "material third-party service providers" is not defined in the Guidelines; Outsourcing/TPRM materiality is a separate test (Response §9.19–9.21). | The toolkit takes a material_provider: true/false flag from the FI's third-party register and does not infer it. |
— | thirdparty.material |