diff --git a/.github/workflows/release_notes_check.yaml b/.github/workflows/release_notes_check.yaml
index 792697140..38bb167e6 100644
--- a/.github/workflows/release_notes_check.yaml
+++ b/.github/workflows/release_notes_check.yaml
@@ -6,7 +6,7 @@ on:
 
 permissions:
   contents: read
-  pull-requests: read
+  pull-requests: write
 
 jobs:
   ci_check:
diff --git a/notebooks/how_to/add_context_to_llm_descriptions.ipynb b/notebooks/how_to/add_context_to_llm_descriptions.ipynb
index 45736d2c7..e8d06f0eb 100644
--- a/notebooks/how_to/add_context_to_llm_descriptions.ipynb
+++ b/notebooks/how_to/add_context_to_llm_descriptions.ipynb
@@ -41,7 +41,8 @@
     "    - [IQR Outliers Table](#toc6_3_7_)    \n",
     "    - [Descriptive Statistics](#toc6_3_8_)    \n",
     "    - [Pearson Correlation Matrix](#toc6_3_9_)    \n",
-    "\n",
+    "  - [Add test-specific context using the docstring](#toc6_4_)\n",
+    "- [Best practices for adding custom context](#toc7_)\n",
     ":::\n",
     "<!-- jn-toc-notebook-config\n",
     "\tnumbering=false\n",
@@ -123,10 +124,10 @@
     "import validmind as vm\n",
     "\n",
     "vm.init(\n",
-    "  # api_host = \"https://api.prod.validmind.ai/api/v1/tracking\",\n",
-    "  # api_key = \"...\",\n",
-    "  # api_secret = \"...\",\n",
-    "  # model = \"...\"\n",
+    "    # api_host=\"...\",\n",
+    "    # api_key=\"...\",\n",
+    "    # api_secret=\"...\",\n",
+    "    # model=\"...\",\n",
     ")"
    ]
   },
@@ -143,7 +144,7 @@
   },
   {
    "cell_type": "code",
-   "execution_count": null,
+   "execution_count": 3,
    "metadata": {},
    "outputs": [],
    "source": [
@@ -255,7 +256,7 @@
   },
   {
    "cell_type": "code",
-   "execution_count": null,
+   "execution_count": 6,
    "metadata": {},
    "outputs": [],
    "source": [
@@ -292,7 +293,7 @@
   },
   {
    "cell_type": "code",
-   "execution_count": null,
+   "execution_count": 7,
    "metadata": {},
    "outputs": [],
    "source": [
@@ -463,7 +464,7 @@
   },
   {
    "cell_type": "code",
-   "execution_count": 83,
+   "execution_count": 13,
    "metadata": {},
    "outputs": [],
    "source": [
@@ -506,7 +507,7 @@
   },
   {
    "cell_type": "code",
-   "execution_count": null,
+   "execution_count": 15,
    "metadata": {},
    "outputs": [],
    "source": [
@@ -526,7 +527,7 @@
   },
   {
    "cell_type": "code",
-   "execution_count": 23,
+   "execution_count": 16,
    "metadata": {},
    "outputs": [],
    "source": [
@@ -585,7 +586,7 @@
   },
   {
    "cell_type": "code",
-   "execution_count": 69,
+   "execution_count": 18,
    "metadata": {},
    "outputs": [],
    "source": [
@@ -650,7 +651,7 @@
   },
   {
    "cell_type": "code",
-   "execution_count": 77,
+   "execution_count": 20,
    "metadata": {},
    "outputs": [],
    "source": [
@@ -717,7 +718,7 @@
   },
   {
    "cell_type": "code",
-   "execution_count": 84,
+   "execution_count": 22,
    "metadata": {},
    "outputs": [],
    "source": [
@@ -793,7 +794,7 @@
   },
   {
    "cell_type": "code",
-   "execution_count": 90,
+   "execution_count": 24,
    "metadata": {},
    "outputs": [],
    "source": [
@@ -868,7 +869,7 @@
   },
   {
    "cell_type": "code",
-   "execution_count": 45,
+   "execution_count": 26,
    "metadata": {},
    "outputs": [],
    "source": [
@@ -937,7 +938,7 @@
   },
   {
    "cell_type": "code",
-   "execution_count": 50,
+   "execution_count": 28,
    "metadata": {},
    "outputs": [],
    "source": [
@@ -1001,7 +1002,7 @@
   },
   {
    "cell_type": "code",
-   "execution_count": 57,
+   "execution_count": 30,
    "metadata": {},
    "outputs": [],
    "source": [
@@ -1086,7 +1087,7 @@
   },
   {
    "cell_type": "code",
-   "execution_count": 62,
+   "execution_count": 32,
    "metadata": {},
    "outputs": [],
    "source": [
@@ -1142,13 +1143,249 @@
     "    },\n",
     ")"
    ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "<a id='toc6_4_'></a>\n",
+    "\n",
+    "### Add test-specific context using the docstring\n",
+    "\n",
+    "Another way to customize test result descriptions is to include explicit instructions in the test docstring:\n",
+    "\n",
+    "- Unlike the environment variable methods above which require runtime configuration and is best for dynamic customization across multiple levels (global, test suite, test-specific), modifying the docstring permanently embeds instructions within the test definition itself.\n",
+    "- This docstring approach is ideal for tests with consistent reporting requirements that should persist across environments, ensuring standardized outputs regardless of external configuration settings.\n",
+    "\n",
+    "In the following example, we demonstrate using post-processing functions to dynamically modify the docstring at runtime, which is useful for experimentation in notebooks. However, users can alternatively hardcode these same instructions directly in the test's docstring if they want these customizations to be permanently part of the test definition without requiring additional runtime code. **Use this method when you want instructions to remain an intrinsic part of the test's definition,** eliminating the need to repeatedly set environment variables in different execution contexts.\n",
+    "\n",
+    "We'll implement a custom test with a default docstring that follows the ValidMind docstring structure. First, we will run this custom test with the default description:"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": null,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "os.environ[\"VALIDMIND_LLM_DESCRIPTIONS_CONTEXT_ENABLED\"] = \"0\"\n",
+    "\n",
+    "@vm.test(\"my_custom_tests.MissingValues\")\n",
+    "def MissingValues(dataset, min_threshold = 1):\n",
+    "    \"\"\"\n",
+    "    Evaluates dataset quality by ensuring missing value ratio across all features does not exceed a set threshold.\n",
+    "\n",
+    "    ### Purpose\n",
+    "\n",
+    "    The Missing Values test is designed to evaluate the quality of a dataset by measuring the number of missing values\n",
+    "    across all features. The objective is to ensure that the ratio of missing data to total data is less than a\n",
+    "    predefined threshold, defaulting to 1, in order to maintain the data quality necessary for reliable predictive\n",
+    "    strength in a machine learning model.\n",
+    "\n",
+    "    ### Test Mechanism\n",
+    "\n",
+    "    The mechanism for this test involves iterating through each column of the dataset, counting missing values\n",
+    "    (represented as NaNs), and calculating the percentage they represent against the total number of rows. The test\n",
+    "    then checks if these missing value counts are less than the predefined `min_threshold`. The results are shown in a\n",
+    "    table summarizing each column, the number of missing values, the percentage of missing values in each column, and a\n",
+    "    Pass/Fail status based on the threshold comparison.\n",
+    "\n",
+    "    ### Signs of High Risk\n",
+    "\n",
+    "    - When the number of missing values in any column exceeds the `min_threshold` value.\n",
+    "    - Presence of missing values across many columns, leading to multiple instances of failing the threshold.\n",
+    "\n",
+    "    ### Strengths\n",
+    "\n",
+    "    - Quick and granular identification of missing data across each feature in the dataset.\n",
+    "    - Provides an effective and straightforward means of maintaining data quality, essential for constructing efficient\n",
+    "    machine learning models.\n",
+    "\n",
+    "    ### Limitations\n",
+    "\n",
+    "    - Does not suggest the root causes of the missing values or recommend ways to impute or handle them.\n",
+    "    - May overlook features with significant missing data but still less than the `min_threshold`, potentially\n",
+    "    impacting the model.\n",
+    "    - Does not account for data encoded as values like \"-999\" or \"None,\" which might not technically classify as\n",
+    "    missing but could bear similar implications.\n",
+    "    \"\"\"\n",
+    "    df = dataset.df\n",
+    "    missing = df.isna().sum()\n",
+    "\n",
+    "    return (\n",
+    "        [\n",
+    "            {\n",
+    "                \"Column\": col,\n",
+    "                \"Number of Missing Values\": missing[col],\n",
+    "                \"Percentage of Missing Values (%)\": missing[col] / df.shape[0] * 100,\n",
+    "                \"Pass/Fail\": \"Pass\" if missing[col] < min_threshold else \"Fail\",\n",
+    "            }\n",
+    "            for col in missing.index\n",
+    "        ],\n",
+    "        all(missing[col] < min_threshold for col in missing.index),\n",
+    "    )\n",
+    "\n",
+    "vm.tests.run_test(\n",
+    "    \"my_custom_tests.MissingValues\",\n",
+    "    inputs={\"dataset\": vm_raw_dataset},\n",
+    ")"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "Now, let's append custom instructions to the test docstring by using a post-processing function that modifies the default docstring before rerunning the test:"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": 35,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "from validmind.vm_models.result import TestResult\n",
+    "\n",
+    "# This function will append the instructions to the end of the docstring\n",
+    "def add_instructions(result: TestResult): \n",
+    "    result.doc += \"\"\"\\n\\nINSTRUCTIONS: \n",
+    "    - Generate 5 Key insights.\n",
+    "    - Add the following note at the end of the generated output: '*NOTE: This is a sample of the data, for the full data results please look in the appendix*'\n",
+    "    \"\"\"\n",
+    "    return result"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "You’ll notice that the description generated by the LLM is now updated to reflect the appended instructions:"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": null,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "vm.tests.run_test(\n",
+    "    \"my_custom_tests.MissingValues\",\n",
+    "    inputs={\"dataset\": vm_raw_dataset},\n",
+    "    post_process_fn=add_instructions,\n",
+    ")"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "If we are happy with the customization, we can now hardcode the instructions into our docstring, so they become a permanent part of the test definition and persist across any environment where the test is executed:"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": null,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "os.environ[\"VALIDMIND_LLM_DESCRIPTIONS_CONTEXT_ENABLED\"] = \"0\"\n",
+    "\n",
+    "@vm.test(\"my_custom_tests.MissingValues\")\n",
+    "def MissingValues(dataset, min_threshold = 1):\n",
+    "    \"\"\"\n",
+    "    Evaluates dataset quality by ensuring missing value ratio across all features does not exceed a set threshold.\n",
+    "\n",
+    "    ### Purpose\n",
+    "\n",
+    "    The Missing Values test is designed to evaluate the quality of a dataset by measuring the number of missing values\n",
+    "    across all features. The objective is to ensure that the ratio of missing data to total data is less than a\n",
+    "    predefined threshold, defaulting to 1, in order to maintain the data quality necessary for reliable predictive\n",
+    "    strength in a machine learning model.\n",
+    "\n",
+    "    ### Test Mechanism\n",
+    "\n",
+    "    The mechanism for this test involves iterating through each column of the dataset, counting missing values\n",
+    "    (represented as NaNs), and calculating the percentage they represent against the total number of rows. The test\n",
+    "    then checks if these missing value counts are less than the predefined `min_threshold`. The results are shown in a\n",
+    "    table summarizing each column, the number of missing values, the percentage of missing values in each column, and a\n",
+    "    Pass/Fail status based on the threshold comparison.\n",
+    "\n",
+    "    ### Signs of High Risk\n",
+    "\n",
+    "    - When the number of missing values in any column exceeds the `min_threshold` value.\n",
+    "    - Presence of missing values across many columns, leading to multiple instances of failing the threshold.\n",
+    "\n",
+    "    ### Strengths\n",
+    "\n",
+    "    - Quick and granular identification of missing data across each feature in the dataset.\n",
+    "    - Provides an effective and straightforward means of maintaining data quality, essential for constructing efficient\n",
+    "    machine learning models.\n",
+    "\n",
+    "    ### Limitations\n",
+    "\n",
+    "    - Does not suggest the root causes of the missing values or recommend ways to impute or handle them.\n",
+    "    - May overlook features with significant missing data but still less than the `min_threshold`, potentially\n",
+    "    impacting the model.\n",
+    "    - Does not account for data encoded as values like \"-999\" or \"None,\" which might not technically classify as\n",
+    "    missing but could bear similar implications.\n",
+    "\n",
+    "    INSTRUCTIONS: \n",
+    "    - Generate 5 Key insights.\n",
+    "    - Add the following note at the end of the generated output: '*NOTE: This is a sample of the data, for the full data results please look in the appendix*'\n",
+    "    \"\"\"\n",
+    "    df = dataset.df\n",
+    "    missing = df.isna().sum()\n",
+    "\n",
+    "    return (\n",
+    "        [\n",
+    "            {\n",
+    "                \"Column\": col,\n",
+    "                \"Number of Missing Values\": missing[col],\n",
+    "                \"Percentage of Missing Values (%)\": missing[col] / df.shape[0] * 100,\n",
+    "                \"Pass/Fail\": \"Pass\" if missing[col] < min_threshold else \"Fail\",\n",
+    "            }\n",
+    "            for col in missing.index\n",
+    "        ],\n",
+    "        all(missing[col] < min_threshold for col in missing.index),\n",
+    "    )\n",
+    "\n",
+    "vm.tests.run_test(\n",
+    "    \"my_custom_tests.MissingValues\",\n",
+    "    inputs={\"dataset\": vm_raw_dataset},\n",
+    ")"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "<a id='toc7_'></a>\n",
+    "\n",
+    "## Best practices for adding custom context\n",
+    "\n",
+    "When working with test result descriptions, it's often useful to provide custom instructions that guide how a test should be interpreted. There are two main ways to add this context: through environment variables or by modifying the test's docstring. Each method has different use cases, levels of persistence, and scopes of influence. Understanding when to use each can help ensure clarity, maintainability, and consistency in your testing workflows. \n",
+    "\n",
+    "The **test’s docstring** is a natural place to embed instructions that are closely tied to the purpose and interpretation of that specific test. There are two ways to leverage docstrings:\n",
+    "\n",
+    "- Hardcoded instructions can be written directly into the test function’s docstring in the source code. These instructions become a permanent part of the test definition and will persist across all environments where the test is run. This approach is ideal when you want clear, consistent guidance that always travels with the test.\n",
+    "- Dynamic modification of the docstring at runtime allows you to append instructions using a post-processing function. This is useful in interactive or experimental settings—such as notebooks—where you may want to fine-tune the test’s description temporarily. These instructions are local to the current test and do not affect others\n",
+    "\n",
+    "While docstrings are localized to individual tests, **environment variables** offer a broader mechanism for injecting context at runtime. This method is best used when you want to apply the same guidance across multiple tests in a session. For example, you might define a high-level context once and have it apply globally throughout a suite of tests. However, because environment variables persist beyond a single test, they can unintentionally influence the behavior of subsequent tests unless explicitly overridden or cleared. This global scope is powerful, but it requires careful handling to avoid unexpected side effects.\n",
+    "\n",
+    "**Choosing the right approach**\n",
+    "- Use hardcoded docstring instructions when you want test guidance to be a permanent part of the test definition, ensuring consistency across environments.\n",
+    "- Use docstring post-processing when you need flexibility for local or temporary customization, particularly in experimental or development settings.\n",
+    "- Use environment variables to apply a shared context across multiple tests, but be mindful that the configuration will persist unless you reset it.\n",
+    "\n",
+    "This tiered approach provides both precision and flexibility—letting you decide whether context should live inside the test, be generated dynamically at runtime, or apply more broadly across test runs."
+   ]
   }
  ],
  "metadata": {
   "kernelspec": {
-   "display_name": "validmind-py3.10",
+   "display_name": "ValidMind Library",
    "language": "python",
-   "name": "validmind-py3.10"
+   "name": "validmind"
   },
   "language_info": {
    "codemirror_mode": {
@@ -1160,7 +1397,7 @@
    "name": "python",
    "nbconvert_exporter": "python",
    "pygments_lexer": "ipython3",
-   "version": "3.10.13"
+   "version": "3.10.15"
   }
  },
  "nbformat": 4,
diff --git a/notebooks/tutorials/model_development/2-start_development_process.ipynb b/notebooks/tutorials/model_development/2-start_development_process.ipynb
index 74bec6960..ead67c31b 100644
--- a/notebooks/tutorials/model_development/2-start_development_process.ipynb
+++ b/notebooks/tutorials/model_development/2-start_development_process.ipynb
@@ -688,8 +688,9 @@
     "    <img src= \"add-content-block.gif\" alt=\"Screenshot showing insert block button in model documentation\" style=\"border: 2px solid #083E44; border-radius: 8px; border-right-width: 2px; border-bottom-width: 3px;\">\n",
     "    <br><br>\n",
     "\n",
-    "5. Click **+** and then select **Test-Driven Block**:\n",
+    "5. Click **+** and then select **Test-Driven Block** under FROM LIBRARY:\n",
     "\n",
+    "    - Click on **VM Library** under TEST-DRIVEN in the left sidebar.\n",
     "    - In the search bar, type in `HighPearsonCorrelation`.\n",
     "    - Select `HighPearsonCorrelation:balanced_raw_dataset` as the test.\n",
     "\n",
diff --git a/notebooks/tutorials/model_development/3-integrate_custom_tests.ipynb b/notebooks/tutorials/model_development/3-integrate_custom_tests.ipynb
index 038f45c38..1b4bf8112 100644
--- a/notebooks/tutorials/model_development/3-integrate_custom_tests.ipynb
+++ b/notebooks/tutorials/model_development/3-integrate_custom_tests.ipynb
@@ -913,10 +913,10 @@
     "    <img src= \"add-content-block.gif\" alt=\"Screenshot showing insert block button in model documentation\" style=\"border: 2px solid #083E44; border-radius: 8px; border-right-width: 2px; border-bottom-width: 3px;\">\n",
     "    <br><br>\n",
     "\n",
-    "5. Click **+** and then select **Test-Driven Block**:\n",
+    "5. Click **+** and then select **Test-Driven Block** under FROM LIBRARY:\n",
     "\n",
-    "    - In the search bar, type in `ConfusionMatrix`.\n",
-    "    - Select the custom `ConfusionMatrix` tests you logged above:\n",
+    "    - Click on **Custom** under TEST-DRIVEN in the left sidebar.\n",
+    "    - Select the two custom `ConfusionMatrix` tests you logged above:\n",
     "\n",
     "    <img src= \"selecting-confusion-matrix-test.png\" alt=\"Screenshot showing the ConfusionMatrix tests selected\" style=\"border: 2px solid #083E44; border-radius: 8px; border-right-width: 2px; border-bottom-width: 3px;\">\n",
     "    <br><br>\n",
diff --git a/notebooks/tutorials/model_development/add-content-block.gif b/notebooks/tutorials/model_development/add-content-block.gif
index daab9d44d..60d9e5825 100644
Binary files a/notebooks/tutorials/model_development/add-content-block.gif and b/notebooks/tutorials/model_development/add-content-block.gif differ
diff --git a/notebooks/tutorials/model_development/selecting-confusion-matrix-test.png b/notebooks/tutorials/model_development/selecting-confusion-matrix-test.png
index de27323a7..ce32255cc 100644
Binary files a/notebooks/tutorials/model_development/selecting-confusion-matrix-test.png and b/notebooks/tutorials/model_development/selecting-confusion-matrix-test.png differ
diff --git a/notebooks/tutorials/model_development/selecting-high-pearson-correlation-test.png b/notebooks/tutorials/model_development/selecting-high-pearson-correlation-test.png
index 2c4b87c6b..7f9868d1e 100644
Binary files a/notebooks/tutorials/model_development/selecting-high-pearson-correlation-test.png and b/notebooks/tutorials/model_development/selecting-high-pearson-correlation-test.png differ
diff --git a/notebooks/tutorials/model_validation/3-developing_challenger_model.ipynb b/notebooks/tutorials/model_validation/3-developing_challenger_model.ipynb
index b0d226012..9daf05da3 100644
--- a/notebooks/tutorials/model_validation/3-developing_challenger_model.ipynb
+++ b/notebooks/tutorials/model_validation/3-developing_challenger_model.ipynb
@@ -8,7 +8,7 @@
     "\n",
     "Learn how to use ValidMind for your end-to-end model validation process with our series of four introductory notebooks. In this third notebook, develop a potential challenger model and then pass your model and its predictions to ValidMind.\n",
     "\n",
-    "A *challenger model* is an alternate model that attempt to outperform the champion model, ensuring that the best performing fit-for-purpose model is always considered for deployment. Challenger models also help avoid over-reliance on a single model, and allow testing of new features, algorithms, or data sources without disrupting the production lifecycle."
+    "A *challenger model* is an alternate model that attempts to outperform the champion model, ensuring that the best performing fit-for-purpose model is always considered for deployment. Challenger models also help avoid over-reliance on a single model, and allow testing of new features, algorithms, or data sources without disrupting the production lifecycle."
    ]
   },
   {