diff --git a/RELEASE.md b/RELEASE.md
index f18f02a6bd..49e0659cd1 100644
--- a/RELEASE.md
+++ b/RELEASE.md
@@ -39,9 +39,28 @@ This step also usually lasts about a week.
 After QA and bugfixing are complete for both OSS and Desktop:
 
 * Final releases are cut from their respective RC branches.
-* Release timing is coordinated with Langflow’s DevRel team.
+* Release timing is coordinated with Langflow's DevRel team.
 * For at least 24 hours after release, Discord, GitHub, and other support channels should be monitored for critical bug reports.
 
+### 4. Release Artifacts
+
+The release workflow automatically publishes the following artifacts:
+
+* **PyPI Packages:**
+  * `langflow` - Main package with all integrations
+  * `langflow-base` - Core framework without integrations
+  * `lfx` - Lightweight executor CLI
+  * `langflow-sdk` - SDK for programmatic access (when updated)
+
+* **Docker Images:**
+  * `langflowai/langflow` - Full Langflow image
+  * `langflowai/langflow-backend` - Backend-only image (published independently)
+  * `langflowai/langflow-frontend` - Frontend-only image (published independently)
+  * `langflowai/langflow-ep` - Enterprise edition image (published independently)
+  * `langflowai/langflow-base` - Base image without integrations
+
+**Note:** Backend, frontend, and enterprise images are published separately from the main image and will be built even if the main version already exists on Docker Hub.
+
 ## Branch Model
 
 | Branch                                        | Purpose                                                                                                         | Merge Policy                                                                         |
@@ -101,6 +120,10 @@ git merge --ff-only release-X.Y.Z      # Fast-forward main to include RC changes
 
 * Follows [Semantic Versioning](https://semver.org): `MAJOR.MINOR.PATCH`.
 * RC tags use `-rc.N`, e.g. `v1.8.0-rc.1`.
+* **All tags MUST start with `v` prefix** (e.g., `v1.9.1`, not `1.9.1`).
+  * The release workflow validates this format and rejects tags without the `v` prefix.
+  * Duplicate tags (e.g., both `1.8.3` and `v1.8.3`) cause GitHub's release notes generation to use the wrong base comparison, resulting in incomplete changelogs.
+  * The workflow automatically checks for and prevents duplicate tags.
 
 ## Roles