diff --git a/.github/workflows/validate-pr-title.yml b/.github/workflows/validate-pr-title.yml
new file mode 100644
index 00000000..5d26d3fb
--- /dev/null
+++ b/.github/workflows/validate-pr-title.yml
@@ -0,0 +1,38 @@
+name: "Validate PR Title"
+
+on:
+  pull_request:
+    types: [ opened, edited, reopened, ready_for_review, synchronize ]
+
+jobs:
+  validate-pr-title:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      pull-requests: write
+
+    steps:
+      - name: Check PR title format
+        shell: bash
+        run: |
+          TITLE="${{ github.event.pull_request.title }}"
+          echo "PR title: $TITLE"
+          
+           # Skip validation for renovate
+          if [[ "$TITLE" == *"chore(deps)"* ]]; then
+            echo "⚠️ Skipping validation for renovate Prs."
+            exit 0
+          fi
+          
+          # Regex for:
+          # [category/subcategory] type(scope?): description (#123?)
+          PATTERN='^\[([a-z]+(/[a-z]+)*)\] (feat|fix|chore|docs|style|refactor|perf|test|build|ci|revert)(\([a-z]+\))?: [a-z].*( \(#[0-9]+\))$'
+          
+          if [[ ! "$TITLE" =~ $PATTERN ]]; then
+            echo "❌ Invalid PR title."
+            echo "Required format:"
+            echo "[category] type(scope?): description (#123)"
+            exit 1
+          fi
+          
+          echo "✅ PR title is valid."
\ No newline at end of file
diff --git a/docs/administration/policies.md b/docs/administration/policies.md
index 945b2c9e..7d5aaf32 100644
--- a/docs/administration/policies.md
+++ b/docs/administration/policies.md
@@ -10,9 +10,12 @@ This page currently includes the configuration of _login messages_, with plans t
 **Login Messages**   
 Administrators can create and manage messages that are displayed to users upon login. This feature is useful for providing important information or updates directly to users when they access the platform.
   There are three types of messages:
-  * **Platform Login Message**: Displayed above the login form to communicate vital information or announcements.
-  * **Platform Consent Message**: Displayed to users during the login process. It appears as a notification that blocks access to the login form until users actively give their consent by checking an approval box. This ensures that users acknowledge and agree to certain terms or conditions before proceeding with logging in.
-  * **Platform Consent Confirm Text**: A message accompanying the consent box, providing clarity on the consent confirmation process.
+
+**Platform Login Message**: Displayed above the login form to communicate vital information or announcements.
+  
+**Platform Consent Message**: Displayed to users during the login process. It appears as a notification that blocks access to the login form until users actively give their consent by checking an approval box. This ensures that users acknowledge and agree to certain terms or conditions before proceeding with logging in.
+  
+**Platform Consent Confirm Text**: A message accompanying the consent box, providing clarity on the consent confirmation process.
 
 These messages can be customized to fit the organization's specific needs and requirements, ensuring that critical information is communicated effectively to users.
 
diff --git a/docs/development/collectors.md b/docs/development/collectors.md
index dbb7deaa..2d1d9128 100644
--- a/docs/development/collectors.md
+++ b/docs/development/collectors.md
@@ -13,9 +13,9 @@ them against injected expectations in OpenAEV.
 
     Note that while this guide puts an emphasis on the Python language, a collector may be implemented in any language
     because it communicates with the OpenAEV server via its REST API. However, Filigran provides an official implementation
-    of a REST client for the OpenAEV API, in python: PyOBAS.
+    of a REST client for the OpenAEV API, in python: PyOAEV.
 
-In this guide, we will use [PyOBAS](https://pypi.org/project/pyobas/), the official OpenAEV API client for Python. The guide requires a basic understanding
+In this guide, we will use [PyOAEV](https://pypi.org/project/pyoaev/), the official OpenAEV API client for Python. The guide requires a basic understanding
 of the Python language, and a working Python install on the development machine.
 
 ### High level overview
@@ -25,10 +25,10 @@ expectations from within the OpenAEV system.
 
 ![High level process overview](assets/high-level-collector-overview.png)
 
-This would translate to this partially-pseudo code, using PyOBAS (some functions omitted for brevity):
+This would translate to this partially-pseudo code, using PyOAEV (some functions omitted for brevity):
 ```python
-from pyobas.daemons import CollectorDaemon
-from pyobas.configuration import Configuration
+from pyoaev.daemons import CollectorDaemon
+from pyoaev.configuration import Configuration
 
 # this is where the whole of the collector logic needs
 # to be implemented.
@@ -145,4 +145,4 @@ You may find reference implementations in the OpenAEV Collectors repository:
 * [Microsoft Sentinel](https://github.com/OpenAEV-Platform/collectors/tree/main/microsoft-sentinel)
 
 You might find them useful to find inspiration on how to implement a matching logic against your EDR or SIEM
-of choice, using PyOBAS.
+of choice, using PyOAEV.
diff --git a/docs/development/injectors.md b/docs/development/injectors.md
index 8a33ee45..08479793 100644
--- a/docs/development/injectors.md
+++ b/docs/development/injectors.md
@@ -26,7 +26,7 @@ internally to access the parameter values.
 
 !!! note "🐍 Python-based injectors"
 
-    For injectors created with the Python language, Filigran maintains the [`pyobas` library](https://pypi.org/project/pyobas/)
+    For injectors created with the Python language, Filigran maintains the [`pyoaev` library](https://pypi.org/project/pyoaev/)
     which provides a wealth of utility classes to compose a functional contract.
 
     Note however that injectors are typically independent processes communicating with OpenAEV via a network transport,