diff --git a/readme.md b/readme.md
index 441375e..2e24cce 100644
--- a/readme.md
+++ b/readme.md
@@ -6,60 +6,28 @@ This guide outlines the naming conventions, branching strategy, and merging proc
 
 ## Branch Naming Conventions
 
-### Feature Branches
+- **Feature Branch**: `feature/<name>`
+  - Example: `feature/add_build_stage`
+- **Bugfix Branch**: `bugfix/<name>`
+  - Example: `bugfix/pages_duplication`
+- **Hotfix Branch**: `hotfix/<name>`
+  - Example: `hotfix/deployment_failure`
 
-- **Naming Convention**: `feature/<workstream>_<version>`
-  - Example: `feature/streamlit_UI0_1.0`, `feature/textract_1.5`
+## ....
 
 ## Branching Strategy
 
-### Creating Feature Branches
+### Creating Branches
 
-1. **From Release Branch**: Create a feature branch from `release/uat_<version>`
-   - Example: To develop Streamlit UI1 v1.5, create `feature/streamlit_UI1_1.5` from `release/uat_1.0`
-
-### Merging Process
-
-#### Merging to DEV
-
-1. **Initial Merge**: Once the feature is ready, merge the feature branch into DEV.
-2. **Verification**: Ensure the functionality is verified in DEV.
-
-#### Merging to UAT
-
-1. **Approval Requirement**: Merge to UAT requires approval from default reviewers (Anup / Priya / Umang).
-2. **Post-Approval Merge**: After approval, merge the same feature branch that was verified in DEV into UAT.
-
-#### Merging to PROD
-
-1. **Final Merge**: Once the feature is tested and approved in UAT, merge it into PROD.
-2. **Complete Versions**: Deployment to PROD should only be done with complete versions (e.g., v1.0, v2.0) with an appropriate release branch in place.
-
-## State of Branches
-
-### After Initial Release (v1.0)
-| Workstream | DEV | UAT | PROD |
-|------------|-----|-----|------|
-| Streamlit  | 1.0 | 1.0 | 1.0  |
-| Textract   | 1.0 | 1.0 | 1.0  |
-| DevOps     | 1.0 | 1.0 | 1.0  |
-| Data       | 1.0 | 1.0 | 1.0  |
-
-### After Streamlit 1.5 and Textract 1.5
-| Workstream | DEV | UAT | PROD |
-|------------|-----|-----|------|
-| Streamlit  | 1.5 | 1.5 | 1.0  |
-| Textract   | 1.5 | 1.5 | 1.0  |
-| DevOps     | 1.0 | 1.0 | 1.0  |
-| Data       | 1.0 | 1.0 | 1.0  |
-
-## Merge Restrictions
-
-- **Workstream Specific Changes**: For feature branches, only changes in the respective folder are allowed. Other changes require a separate feature branch. This ensures that workstream changes are deployed to the respective infra. 
-- **Merge Approval**: Merging into DEV, UAT or PROD requires approval from default reviewers.
+1. Create a feature branch from `main` using the appropriate naming convention.
+2. Create a small and complete change. `main` must always have deployable code.
+3. Create a Pull Request back to `main`.
+4. Ensure all checks have passed.
+5. Merge new code.
+6. Ensure the functionality is verified in the dev environment.
 
 ## Refer to the branching guide in Confluence for more info on this 
 
 ---
 
-This guide ensures that all team members follow the best practices for branch management and releases.
+This guide ensures that all team members follow the best practices for branch management and releases.
\ No newline at end of file