alan-turing-institute · JimMadge · Apr 2, 2026 · Mar 27, 2026 · Mar 27, 2026 · Mar 27, 2026
diff --git a/docs/abbreviations.yml b/docs/abbreviations.yml
@@ -2,3 +2,4 @@ version: 1
 project:
   abbreviations:
     TRE: Trusted Research Environment
+    IG: Information Governance
diff --git a/docs/architecture/architecture.md b/docs/architecture/architecture.md
@@ -8,7 +8,7 @@ These are mapped to our [roles](#arch-roles),
 
 - {span .role .tre-operator}``(blue) owned by {term}`TRE Operator Organisation` ``
 - {span .role .hosting-provider}``(green) owned by {term}`FRIDGE Hosting Organisation` ``
-- {span .role .job-submitter}``(orange) used by {term}`Job Submitters`, owned by {term}`TRE Operator Organisation` ``
+- {span .role .job-submitter}``(orange) used by {term}`Job Submitters <Job Submitter>`, owned by {term}`TRE Operator Organisation` ``
 
 {span .role .external}`pink` items indicate externally controlled resources, outside of the scope of our [roles](#arch-roles).
 
@@ -104,9 +104,9 @@ All must point to the {term}`Access Cluster` where a [K8s Ingress Controller](ht
 
 #### Proxies
 
-For {term}`Job Submitters`, the local API interface and FRIDGE proxy provide transparent access to the FRIDGE API.
+For {term}`Job Submitter`s, the local API interface and FRIDGE proxy provide transparent access to the FRIDGE API.
 It will appear to them as a service in the network of their TRE workspace with endpoints for submitting and managing jobs dispatched to the FRIDGE instance.
-Similarly, {term}`TRE Administrators` are able to manage the K8s components of their FRIDGE instance through their own API interface.
+Similarly, {term}`TRE Administrator`s are able to manage the K8s components of their FRIDGE instance through their own API interface.
 
 The proxies and {term}`Access Cluster's <Access Cluster>` Kube API are distinct pods.
 Proxy pods run an SSH daemon and are used to pass requests through to the {term}`Isolated Cluster's <Isolated Cluster>` Kube API or FRIDGE API via an SSH tunnel.
@@ -146,7 +146,7 @@ For example, the [container repository](#arch-arch-internal-harbor).
 ### FRIDGE API
 
 The FRIDGE API provides users with endpoints to manage data, and submit and monitor jobs.
-Writing a custom API separates {term}`Job Submitters` from the underlying implementation, so that they may use a single FRIDGE interface irrespective.
+Writing a custom API separates {term}`Job Submitter`s from the underlying implementation, so that they may use a single FRIDGE interface irrespective.
 This API will then be resilient to changes to the FRIDGE [](#arch-arch-internal-workflow) and storage.
 It will also enable the creation of user-focused FRIDGE tools such as CLIs or web interfaces for job submission and management.
 
@@ -159,15 +159,15 @@ The workflow manager is an instance of [Argo Workflows](https://argoproj.github.
 (arch-arch-internal-jobns)=
 #### Job Namespace
 
-To isolate {term}`Job Submitters' <Job Submitters>` processes from the rest of the {term}`Isolated Cluster`, including components which enforce security, jobs may only be run in a dedicated namespace.
+To isolate {term}`Job Submitter`s' processes from the rest of the {term}`Isolated Cluster`, including components which enforce security, jobs may only be run in a dedicated namespace.
 This namespace has no access to external resources, other than research data and container images, and jobs are restricted to run without privileges.
 
 (arch-arch-internal-harbor)=
 ### Container Repository
 
 An instance of the [Harbor](https://goharbor.io/) container registry provides access to container images for the isolated cluster.
-It acts both as a read-through cache for allowed public registries (such as Docker Hub, Quay and GitHub Container Registry) and as a repository for {term}`Job Submitters' <Job Submitters>` own container images.
-This allows {term}`Job Submitters` to easily use custom software, by building a container image and pushing to the repository.
+It acts both as a read-through cache for allowed public registries (such as Docker Hub, Quay and GitHub Container Registry) and as a repository for {term}`Job Submitter`s' own container images.
+This allows {term}`Job Submitter`s to easily use custom software, by building a container image and pushing to the repository.
 
 ### Storage
 

diff --git a/docs/architecture/defence_in_depth.md b/docs/architecture/defence_in_depth.md
@@ -32,12 +32,12 @@ FRIDGE uses Kubernetes [Role Based Access Control](https://kubernetes.io/docs/co
 This then allows certain pods to interact with the Kubernetes API in a limited way.
 
 For example, the [](#arch-arch-internal-workflow) inherits a role which allows it to create jobs in the job namespace only.
-This allows it to dispatch job requests from {term}`Job Submitters`, but not create resources in other namespaces or modify other FRIDGE components.
+This allows it to dispatch job requests from {term}`Job Submitters <Job Submitter>`, but not create resources in other namespaces or modify other FRIDGE components.
 
 ### On Cluster Nodes
 
 The built in Kubernetes [Restricted](https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted) [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/) are applied to all namespaces, except those which need additional privileges.
-Specifically, all pods launched by {term}`Job Submitters` must comply with the Restricted standard.
+Specifically, all pods launched by {term}`Job Submitters <Job Submitter>` must comply with the Restricted standard.
 This prevents running as root, accessing host storage, and accessing the host network amongst other restrictions.
 
 Compromising the host of a pod is therefore unlikely.

diff --git a/docs/architecture/lifecycle.md b/docs/architecture/lifecycle.md
@@ -29,8 +29,8 @@ sequenceDiagram
 ## FRIDGE provisioning
 
 After the [](#arch-lifecycle-init) a FRIDGE instance may be deployed.
-The {term}`TRE Operator Organisation` triggers the {term}`TRE Administrators` and {term}`Hosting Provider Administrators` to deploy the TRE (if it isn't already), FRIDGE instance, and connect them.
-Once this is complete, the {term}`Principal Investigators` will be informed the FRIDGE instance is ready to be used.
+The {term}`TRE Operator Organisation` triggers the {term}`TRE Administrator`s and {term}`Hosting Administrator`s to deploy the TRE (if it isn't already), FRIDGE instance, and connect them.
+Once this is complete, the {term}`Principal Investigator`s will be informed the FRIDGE instance is ready to be used.
 
 :::{mermaid}
 sequenceDiagram
@@ -66,9 +66,9 @@ sequenceDiagram
 
 With the TRE connected, the research team can now dispatch jobs to the FRIDGE instance.
 
-The {term}`Principal Investigators` are able to upload the sensitive input data to immutable storage.
+The {term}`Principal Investigator`s are able to upload the sensitive input data to immutable storage.
 
-The {term}`Safe Researchers` can now work using FRIDGE in the loop,
+The {term}`Safe Researcher`s can now work using FRIDGE in the loop,
 
 1. Identify question
 2. Design and submit job specification
@@ -107,8 +107,8 @@ sequenceDiagram
 
 ## FRIDGE teardown
 
-When there is no longer the need for a FRIDGE, the {term}`Principal Investigators` request the instance teardown.
-The {term}`TRE Operator Organisation` instructs the  {term}`TRE Administrators` and {term}`Hosting Provider Administrators` to conduct the teardown.
+When there is no longer the need for a FRIDGE, the {term}`Principal Investigator`s request the instance teardown.
+The {term}`TRE Operator Organisation` instructs the  {term}`TRE Administrator`s and {term}`Hosting Administrator`s to conduct the teardown.
 
 :::{mermaid}
 sequenceDiagram

diff --git a/docs/architecture/responsibility_and_5_safes.md b/docs/architecture/responsibility_and_5_safes.md