Update AI Policy

source/Development/Diagnostics/lfric_diagnostics.rst

@@ -69,7 +69,7 @@ Field requests can be grouped to be output to different file streams.
    included in the ``iodef.xml`` file for a given application configuration.
 
 XIOS is a highly complex and flexible parallel IO system with post-processing
-capabilites, including the ability to apply time and spatial processing as
+capabilities, including the ability to apply time and spatial processing as
 well as combine multiple fields. It is developed at IPSL.
 
 .. caution::

source/Development/TestSuites/multi-repo_testing.rst

@@ -35,15 +35,15 @@ local git clone, in which case it should take the form,
 ``source: <HOSTNAME>:/path/to/clone``.
 
 The ``ref`` setting takes a git tree-ish value. Common settings will be a commit
-hash, a tag or a branch name as demostrated by the examples below. At
+hash, a tag or a branch name as demonstrated by the examples below. At
 release, the refs will be tags and will be changed to the long form of the relevant
 commit hash as part of linked pull requests.
 
 If left blank the behaviour depends on the source:
 
 * **a GitHub source:** the Head of the repositories default branch will be used.
 * **a local clone:** the state of the repository at source extraction time will be used.
-  It is recommened to set a ref when setting the source to a local clone.  That way
+  It is recommended to set a ref when setting the source to a local clone.  That way
   if you switch branches in the clone, the correct branch for testing will be used.
 
 Various different configurations of an lfric_core source are shown below with an
@@ -66,7 +66,7 @@ explanation of each,
         source: git@github.com:MetOffice/lfric_core.git
         ref:
 
-    # A Users fork of the lfric_core repoistory, on branch my_branch
+    # A Users fork of the lfric_core repository, on branch my_branch
     lfric_core:
         source: git@github.com:UserName/lfric_core.git
         ref: my_branch

source/Development/TestSuites/um.rst

@@ -60,7 +60,7 @@ groups, and that you can specify more than one at once, e.g.
 |                    | team.                                                    |
 +--------------------+----------------------------------------------------------+
 | all                | The complete test suite, including all longer runs and   |
-|                    | less commonly used utilites. This is run automatically   |
+|                    | less commonly used utilities. This is run automatically  |
 |                    | every week and monitored by the SSD team. All            |
 |                    | :ref:`KGO <kgo>` changing PRs need to run this group.    |
 +--------------------+----------------------------------------------------------+

source/Development/kgo.rst

@@ -61,10 +61,10 @@ such changes onto ``main``. When preparing your change for review:
 
     4. If you are adding new checksums, ``git add`` the files.
 
-    5. You can check the new kgo updated properly by retiggering tasks in
+    5. You can check the new kgo updated properly by retriggering tasks in
        the test suite. First retrigger ``export-source``, and then when
        complete ``export-source_ex1a`` if new checksums are present there
-       (there is no need to retigger spice). You may need to change the
+       (there is no need to retrigger spice). You may need to change the
        maximum window extent of the gui in order to see the succeeded
        tasks. Now you can retrigger the failed checksums - these should now
        pass if the kgo was updated in the clone correctly.
@@ -98,7 +98,7 @@ such changes onto ``main``. When preparing your change for review:
 
 .. tip::
 
-    More details on the KGO update proceedures for all repositories can be
+    More details on the KGO update procedures for all repositories can be
     found on the :ref:`How to Commit page<kgo_instructions>`.
 
 .. toctree::

source/FurtherDetails/ai.rst

@@ -9,25 +9,217 @@
 AI Policy
 =========
 
-Please ensure that when using Generative AI tools, appropriate guardrails are
-in place and contributions have correct attribution. For Met Office
-contributors, this includes adhering to the Use of Generative AI policy.
-Contributors from other institutions should check if their institution has
-similar policies, and follow the local policy.
-
-Code where Generative AI tools have been used needs to have clear attribution to
-meet the Met Office Generative AI policy. This includes attribution in the
-commit message and in each modified file. Any file where a modification has been
-made with Generative AI assistance must have a comment immediately before the
-module level docstring, containing:
-
-.. code-block::
-
-    # Some of the content of this file has been produced with the assistance of
-    <Generative AI tool name>."
-
-where ``<Generative AI tool name>`` should be replaced with the specific name of
-the tool such as ``<Institution Name> Github Copilot Enterprise`` (e.g. Met
-Office Github Copilot Enterprise), ``Github Copilot Personal``,
-``ChatGPT GPT-4``, etc. For Met Office contributors, Met Office Github Copilot
-Enterprise is the only approved Generative AI tool.
+The primary objective of this policy is to prevent the introduction of
+third-party intellectual property rights (IPR)-protected code into the
+simulation systems.
+
+This policy is written so it can be reused across open source repositories
+using the BSD-3-Clause licence, which does not define requirements for
+AI-assisted contributions.
+
+Scope
+-----
+
+This policy applies to AI-assisted contributions in:
+
+* source code
+* tests
+* scripts and configuration
+* documentation, including prose/narrative content and code examples
+
+For this policy, AI-assisted means content generated, completed, or
+substantially refactored by a Generative AI tool.
+
+Core Principles and Tool Restrictions
+-------------------------------------
+
+* **Acknowledge Public-Domain AI Risks**: AI tools trained on public
+  repositories can generate code that violates open-source licences or
+  copyrights.
+* **Do Not Use Free or Personal-Tier Tools**: Use of free or personal-tier
+  AI coding tools is *strictly prohibited* for project contributions.
+* **Use Approved Enterprise-Tier Tools Only**: Contributors may only use
+  enterprise-tier AI tools approved by their employing organisation or the
+  repository maintainers.
+* **Prohibit AI Agents From Committing Code**: AI tools and agents are not
+  permitted to directly commit code, open pull requests, or perform repository
+  operations. All AI-generated or AI-assisted content must be reviewed,
+  validated, and committed by a human contributor with explicit intent and
+  accountability.
+* **Assume Full Contributor Responsibility**: The human contributor is
+  responsible for all submitted content, including correctness, licensing
+  checks, and project standards compliance.
+
+.. dropdown:: Internal Met Office Contributors
+
+    For guidance specific to the Met Office, consult the
+    `central Met Office AI Policy <https://metoffice.sharepoint.com/sites/AICommsSite/SitePages/Met-Office-AI-Policy.aspx>`__.
+
+    Where applicable Met Office information-governance or data-handling
+    requirements call for approval from an Information Asset Owner (IAO) or
+    Information Asset Manager (IAM) for information or data used with an AI
+    tool, obtain that approval before merging and record it in the pull request
+    description. This is not a blanket IAO/IAM approval requirement for every
+    AI-assisted change.
+
+Approved enterprise-tier tools
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+An approved tool must satisfy all of the following:
+
+* enterprise-tier licence with auditable terms of use
+* terms that allow open source contribution workflows
+* explicit organisational approval by employer or project maintainers
+* controls appropriate to institutional IPR and data handling requirements
+
+If a contributor cannot use an approved enterprise-tier tool, code must be
+written manually without the use of any AI or machine learning (ML) code
+generation assistants.
+
+Legal framing and BSD-3-Clause compatibility
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This policy adds process controls for AI use. It does not alter the
+BSD-3-Clause licence terms, warranties, or disclaimers.
+
+Attribution and review requirements in this policy are **mandatory**
+contribution conditions for the simulation systems repositories.
+
+Attribution Requirements
+------------------------
+
+If an approved Generative AI tool is used, you **must** provide attribution in
+two places:
+
+**1. the pull request description**
+
+The pull request description **must** identify the tool and what it assisted
+with, for example:
+
+.. code-block:: text
+
+  Assisted-by: [Institution Name] [Tool / Agent Context] ([Model Version])
+  for spatial interpolation optimisation.
+
+Commit messages are easy to forget, especially across multiple commits, and are
+not reliably enforceable before merge. Repeating the same note in individual
+commit messages is encouraged for traceability, but is not a substitute for the
+pull request description, which is what reviewers check before merge.
+
+Attribution must be specific enough for later audit. Include tool name,
+model/version where available, and PR number in the source file header.
+
+**2. the source file header**
+
+Add a comment near the top of the file, including documentation-only files
+(for example ``.rst`` files with no code examples). Use the native comment
+style for the language or markup, for example:
+
+.. tab-set::
+
+   .. tab-item:: Fortran
+
+      .. code-block:: f90
+
+         ! Some content in this file was generated or refactored with assistance from
+         ! - [Institution Name] [Tool / Agent Context] ([Model Version]); PR #123.
+
+   .. tab-item:: Python
+
+      .. code-block:: python
+
+         # Some content in this file was generated or refactored with assistance from
+         # - [Institution Name] [Tool / Agent Context] ([Model Version]); PR #123.
+
+   .. tab-item:: C++
+
+      .. code-block:: cpp
+
+         // Some content in this file was generated or refactored with assistance from
+         // - [Institution Name] [Tool / Agent Context] ([Model Version]); PR #123.
+
+   .. tab-item:: reStructuredText
+
+      .. code-block:: rst
+
+         ..
+            Some content in this file was generated or refactored with assistance from
+            - [Institution Name] [Tool / Agent Context] ([Model Version]); PR #123.
+
+.. dropdown:: Internal example (non-normative)
+
+    For Met Office contributors, these examples show how to identify the tool
+    and model-selection mode used:
+
+    * ``Met Office GitHub Copilot Business (Claude Sonnet 5)`` identifies
+      Copilot Business and the specific model used.
+    * ``Met Office Claude Code via AI Foundry (Agent-selected model)`` identifies
+      Claude Code via AI Foundry when it automatically selects a model for each
+      task. This selection mode may be used in a local or cloud environment.
+      When the specific model or models used are known, name them instead.
+
+    This example is provided for convenience. It does not change the
+    requirement that only approved enterprise-tier tools may be used.
+
+List each distinct tool and model/version once in the file header, followed by
+the PR number or numbers for the contributions it assisted. Add PR numbers to
+the existing entry when the same tool and model/version are used again. Use a
+separate entry for a different tool or model/version. For example:
+
+.. code-block:: text
+
+  Some content in this file was generated or refactored with assistance from
+  - [Institution Name] [Tool / Agent Context] ([Model Version]); PRs #123, #456
+  - [Institution Name] [Tool / Agent Context] ([Other Model Version]); PR #789
+  - [Other Institution Name] [Other Tool / Agent Context] ([Model Version]); PR #987
+
+Code Review Guidelines
+----------------------
+
+Reviewers must remember that AI-generated code is not self-authenticating.
+The human contributor remains fully responsible for its contents.
+
+Reviewer Checklist Matrix
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
++------+--------------------+------------------------------+------------------------+
+| Step | Action             | Pass Criteria                | Fail Action            |
++======+====================+==============================+========================+
+| 1    | Check file header  | Explicitly names approved    | Block merge if         |
+|      | and PR description | enterprise-tier tool and     | free/personal tier     |
+|      |                    | includes required attribution| is used                |
++------+--------------------+------------------------------+------------------------+
+| 2    | Check licence      | No obvious proprietary or    | Pause merge and        |
+|      | compatibility      | or restrictively licensed    | request proof of       |
+|      |                    | copy-pasted snippets         | origin/provenance      |
++------+--------------------+------------------------------+------------------------+
+| 3    | Assess Logic and   | Reviewer understands every   | Request revisions for  |
+|      | Edge Cases         | line; edge cases are handled | "black box" code       |
++------+--------------------+------------------------------+------------------------+
+| 4    | Run Test Suite     | Code passes all unit,        | Block merge until      |
+|      |                    | integration, and             | tests pass natively    |
+|      |                    | regression tests             |                        |
++------+--------------------+------------------------------+------------------------+
+| 5    | Check IAO/IAM      | If applicable rules require  | Hold merge until       |
+|      | approval needs     | approval for information or  | required approval is   |
+|      |                    | data used with AI, confirm   | obtained and recorded  |
+|      |                    | approval is recorded in PR   | in the PR              |
++------+--------------------+------------------------------+------------------------+
+
+Enforcement and Remediation
+---------------------------
+
+The enforcement model is corrective-first, except where banned tools or
+unresolved IPR risk is involved.
+
+* Missing attribution: request correction before merge.
+* Free/personal-tier AI use: block merge until replaced with compliant
+  contribution.
+* Suspected licence/IPR conflict: pause review, request provenance, and escalate
+  to maintainers.
+
+If an IPR issue is discovered after merge, maintainers should choose one of:
+
+* revert the change
+* rewrite affected code
+* retain with verified, compatible attribution where legally valid

source/FurtherDetails/dos_donts.rst

@@ -49,7 +49,7 @@ and resolving any conflicts.
 **Licensing** - Don't add code to any project (or to any branch thereof) that
 has been developed under a different license without agreement from the
 Simulation Systems and Deployment Team. This includes lifting Fortran code or
-text from books. Our repositiories must not infringe copyright.
+text from books. Our repositories must not infringe copyright.
 
 **Request support by raising an issue**. Newly raised issues are not
 monitored. Use the appropriate :ref:`support` channels.

source/FurtherDetails/glossary.rst

@@ -49,7 +49,7 @@ Linked Pull Request (Linked PR):
 Overarching Issue:
     Where a piece of work has been split into multiple sections an overarching
     issue can be used to track this work. It should be closed when the whole arc
-    has been completed. GitHub also allows subissues which can be created from
+    has been completed. GitHub also allows sub-issues which can be created from
     the overarching issue.
 
 Regression:

source/FurtherDetails/who.rst

@@ -143,7 +143,7 @@ Core Capability Development Team:
 
 Tools and Collaborative Development Team:
     The TCD Team is responsible for the development and integration of third
-    party tools with LFRic including Psyclone, XIOS and LFRic Inputs.
+    party tools with LFRic including PSyclone, XIOS and LFRic Inputs.
 
     The team can be contacted at ToolsCollabDevTeam@metoffice.gov.uk
 
@@ -154,7 +154,7 @@ Tools and Collaborative Development Team:
 HPC Optimisation Team
 ---------------------
 
-The HPC optimistation team take a general lead in matters relating to compute
+The HPC optimisation team take a general lead in matters relating to compute
 performance of the UM, LFRic and other systems.
 
 * Examine and improve the performance and scalability of the UM and coupled

source/Reviewers/nightlytesting.rst

@@ -17,7 +17,7 @@ Nightly Testing
 Modifying and Installing Testing
 --------------------------------
 
-Nightly testing is controlled by 2 cronfiles, ``auto-gen_testing.cron`` and
+Nightly testing is controlled by 2 cron files, ``auto-gen_testing.cron`` and
 ``manual.cron`` both located in ``~/Crontabs/``. The first is automatically
 generated the script ``generate_test_suite_cron.py`` which is stored in the
 SimSys_Scripts GitHub repo and controls the launching and clean up of the
@@ -151,6 +151,6 @@ items can be added/edited. When done click ``submit`` and then ``Trigger``
 .. important::
 
     When finished Keyboard terminate the cylc url command and choose y when
-    prompted. This shutsdown the cylc server and prevents multiple connections
+    prompted. This shuts down the cylc server and prevents multiple connections
     opening.
 

source/Reviewers/releases/release_notes.rst

@@ -85,7 +85,7 @@ Create a new wiki page:
     * [LFRic Apps vnX.Y](https://github.com/MetOffice/lfric_apps/releases/tag/vnX.Y)
     * [LFRic Core vnX.Y](https://github.com/MetOffice/lfric_core/releases/tag/vnX.Y)
     * [UM vnX.Y](https://github.com/MetOffice/um/releases/tag/vnX.Y) (private within the MetOffice organisation)
-    * [JULES vnX.Y](https://github.com/MetOffice/jules/releases/tag/vnX.Y) (currently private, will hopefully soon be publically available)
+    * [JULES vnX.Y](https://github.com/MetOffice/jules/releases/tag/vnX.Y)
 
     ## Key Highlights
     * A few highlights the affect multiple repositories

source/Reviewers/releases/shared_accounts.rst

@@ -9,7 +9,7 @@
 Repo and Shared Accounts Permissions
 ====================================
 
-Modify SSD Team Github Permissions:
+Modify SSD Team GitHub Permissions:
 
 * https://github.com/orgs/MetOffice/teams/ssdteam
 

source/Reviewers/releases/shumlib_release.rst

@@ -62,7 +62,7 @@ First install on azspice,
 
 .. code-block:: shell
 
-    export SPACKDIR= # Set this as the Spackadmin Data Directory (no trailing slash)
+    export SPACKDIR= # Set this as the spackadmin Data Directory (no trailing slash)
     BUILD_DESTINATION=$UMDIR/shumlib/shumlib-YYYY.MM.V scripts/meto_install_shumlib.sh azspice
 
 Then ssh to each of EXAB, EXCD and EXZ and install there,

source/Reviewers/releases/um_main_release.rst

@@ -316,7 +316,7 @@ appear in the correct place. Do this by running,
 
 and check that ``~umadmin/cylc_run/umx.y_install/runN/share/vnX.Y``
 exists and is the new version number. If that has worked, change the
-CENTRALL_INSTALL flag to true and rerun,
+``CENTRAL_INSTALL`` flag to ``true`` and rerun,
 
 .. code-block:: shell