diff --git a/docs.kosli.com/content/implementation_guide/phase_2/plan_organizational_structure/naming_conventions.md b/docs.kosli.com/content/implementation_guide/phase_2/plan_organizational_structure/naming_conventions.md
deleted file mode 100644
index e7b256374..000000000
--- a/docs.kosli.com/content/implementation_guide/phase_2/plan_organizational_structure/naming_conventions.md
+++ /dev/null
@@ -1,199 +0,0 @@
----
-title: "Naming Conventions"
-bookCollapseSection: false
-weight: 200
----
-
-# Naming Conventions
-
-Clear and consistent naming makes it easy for everyone to understand what each item in Kosli represents. Good names help you route attestations correctly and quickly find what you need.
-
-Use these conventions for:
-- **Flows** and **Trails**
-- **Attestation Types**
-- **Environments**
-
-## General Guidelines
-
-The general guidelines should be considered best practices for all naming conventions in Kosli. You can adapt them to fit your organization’s needs, but consistency is key.
-
-All of our proposed conventions follow these general guidelines:
-
-**Structure**: `<element 1>` `<delimiter>` `<element 2>` `<delimiter>`...`<element N>`
-
-
-1. **Choose Delimiter**: Choose a delimiter that works for your and stick with it consistently.</br>
-For example hyphen `-`, underscore `_`, tilde `~` or dot `.`. </br>
-Avoid mixing delimiters within the same naming scheme.
-2. **Choose case style for elements**: Choose a meaningful case style across elements (e.g., PascalCase, camelCase, snake_case) and use it consistently. Avoid spaces and clashes with delimiters.
-3. **Keep it concise**: Shorter names are easier to read and remember. Aim for concise but descriptive names.
-4. **Avoid special characters**: Stick to alphanumeric characters and underscores/hyphens
-
-{{% hint warning %}}
-Be aware of using underscore `_` as the delimiter, as that conflicts with snake_case for elements.
-{{% /hint %}}
-
-{{% hint info %}}
-The rest of this document uses hyphen `-` as the delimiter in examples, but you can choose any delimiter that fits your needs.
-{{% /hint %}}
-
-### Regular Expression
-
-To help enforce these conventions programmatically, here are sample regular expressions you can use based on your chosen case style.
-
-Adjust the regex if you choose a different delimiter.
-
-{{< tabs "naming-regex" >}}
-{{< tab "snake_case" >}}
-
-**Example**: `element_one`-`element_two`-`element_three`
-
-```bash
-^[a-z][a-z0-9_]*(-[a-z][a-z0-9_]*)*$
-```
-
-{{< /tab >}}
-{{< tab "camelCase" >}}
-
-**Example**: `elementOne`-`elementTwo`-`elementThree`
-
-```bash
-^[a-z][a-zA-Z0-9]*(-[a-z][a-zA-Z0-9]*)*$
-```
-
-{{< /tab >}}
-{{< tab "PascalCase" >}}
-
-**Example**: `ElementOne`-`ElementTwo`-`ElementThree`
-
-```bash
-^[A-Z][a-zA-Z0-9]*(-[A-Z][a-zA-Z0-9]*)*$
-```
-{{< /tab >}}
-{{< /tabs >}}
-
-
-{{% hint info %}}
-If you want a specific length limit (e.g., max 50 characters), you can add a lookahead at the start of the regex:
-
-```bash
-^(?=.{1,50}$) # + rest of the regex
-```
-
-You can use online regex testers like [regex101](https://regex101.com/) to validate and test these expressions.
-
-{{% /hint %}}
-
-## Flows
-
-A clear naming convention transforms a simple ID into a meaningful identifier that everyone understands. This shared language ensures attestations go to the right place and you can track your releases from start to finish.
-
-### Build Flows
-
-Build Flows represent how code changes move from commit to artifact. Use the following convention to name Build Flows:
-
-**Name Convention:** `org-unit`-`repo`-`[service]`
-
-- **org-unit**: Your organizational unit, division or team name
-- **repo**: Your repository name
-- **service (Optional)**: The specific service or component that the artifact belongs to
-
-{{% hint info %}}
-You can skip `service` if your repository produces only one artifact, i.e. non-monorepo setups.
-{{% /hint %}}
-
-{{< tabs "build-flow-examples" >}}
-{{< tab "snake_case" >}}
-
-**Examples:**
-- `investment-web_app` (single artifact)
-- `investment-web_app-frontend` (with service: frontend)
-- `devops_team-mobile_app-backend` (with service: backend)
-
-```bash
-^[a-z][a-z0-9_]*-[a-z][a-z0-9_]*(-[a-z][a-z0-9_]*)?$
-```
-
-{{< /tab >}}
-{{< tab "camelCase" >}}
-
-**Examples:**
-- `investment-webApp` (single artifact)
-- `investment-webApp-frontend` (with service: frontend)
-- `devopsTeam-mobileApp-backend` (with service: backend)
-
-```bash
-^[a-z][a-zA-Z0-9]*-[a-z][a-zA-Z0-9]*(-[a-z][a-zA-Z0-9]*)?$
-```
-{{< /tab >}}
-{{< tab "PascalCase" >}}
-
-**Examples:**
-- `Investment-WebApp` (single artifact)
-- `Investment-WebApp-Frontend` (with service: frontend)
-- `DevOpsTeam-MobileApp-Backend` (with service: backend)
-
-```bash
-^[A-Z][a-zA-Z0-9]*-[A-Z][a-zA-Z0-9]*(-[A-Z][a-zA-Z0-9]*)?$
-```
-{{< /tab >}}
-{{< /tabs >}}
-
-### Release Flows
-
-Release Flows represent how artifacts move from build to deployment. Use the following convention to name Release Flows:
-
-**Name Convention:** `org-unit`-`repo`
-
-- **org-unit**: Your organizational unit, division or team name
-- **repo**: Your repository name
-
-{{< tabs "release-flow-examples" >}}
-{{< tab "snake_case" >}}
-**Examples:**
-- `investment-web_app`
-- `devops_team-mobile_app`
-```bash
-^[a-z][a-z0-9_]*-[a-z][a-z0-9_]*$
-```
-{{< /tab >}}
-{{< tab "camelCase" >}}
-**Examples:**
-- `investment-webApp`
-- `devopsTeam-mobileApp`
-```bash
-^[a-z][a-zA-Z0-9]*-[a-z][a-zA-Z0-9]*$
-```
-{{< /tab >}}
-{{< tab "PascalCase" >}}
-**Examples:**
-- `Investment-WebApp`
-- `DevOpsTeam-MobileApp`
-```bash
-^[A-Z][a-zA-Z0-9]*-[A-Z][a-zA-Z0-9]*$
-```
-{{< /tab >}}
-{{< /tabs >}}
-
-
-## Trails
-
-### Trails associated with [Build Flows]({{< ref "#build-flows" >}})
-
-**Name Convention:** `sha`
-
-- **sha**: The git commit HEAD SHA that triggered the build.
-
-### Trails associated with [Release Flows]({{< ref "#release-flows" >}})
-**Name Convention:** `env`-`pr-number`
-
-- **env**: The target deployment environment (e.g., staging, production)
-- **pr-number**: The pull request or change request number associated with the deployment.
-
-**Examples:**
-- `staging-42`
-- `production-108`
-
-```bash
-^[a-z][a-z0-9_]*-[0-9]+$
-```
diff --git a/docs.kosli.com/content/implementation_guide/phase_2/plan_organizational_structure/naming_conventions/_index.md b/docs.kosli.com/content/implementation_guide/phase_2/plan_organizational_structure/naming_conventions/_index.md
new file mode 100644
index 000000000..84d3d1772
--- /dev/null
+++ b/docs.kosli.com/content/implementation_guide/phase_2/plan_organizational_structure/naming_conventions/_index.md
@@ -0,0 +1,85 @@
+---
+title: "Naming Conventions"
+bookCollapseSection: true
+weight: 100
+---
+
+# Naming Conventions
+
+Clear and consistent naming makes it easy for everyone to understand what each item in Kosli represents. Good names help you route attestations correctly and quickly find what you need.
+
+Use these conventions for:
+- **Flows** and **Trails**
+- **Attestation Types**
+- **Environments**
+
+## General Guidelines
+
+The general guidelines should be considered best practices for all naming conventions in Kosli. You can adapt them to fit your organization’s needs, but consistency is key. All of our proposed conventions follow these general guidelines:
+
+**Structure**: `<element 1>` `<delimiter>` `<element 2>` `<delimiter>`...`<element N>`
+
+
+1. **Choose Delimiter**: Choose a delimiter that works for your and stick with it consistently.</br>
+For example hyphen `-`, underscore `_`, tilde `~` or dot `.`. </br>
+Avoid mixing delimiters within the same naming scheme.
+2. **Choose case style for elements**: Choose a meaningful case style across elements (e.g., PascalCase, camelCase, snake_case) and use it consistently. Avoid spaces and clashes with delimiters.
+3. **Keep it concise**: Shorter names are easier to read and remember. Aim for concise but descriptive names.
+4. **Avoid special characters**: Stick to alphanumeric characters and underscores/hyphens
+
+{{% hint warning %}}
+Be aware of using underscore `_` as the delimiter, as that conflicts with snake_case for elements.
+{{% /hint %}}
+
+{{% hint info %}}
+The rest of this document uses hyphen `-` as the delimiter in examples, but you can choose any delimiter that fits your needs.
+{{% /hint %}}
+
+### Regular Expression
+
+To help enforce these conventions programmatically, here are sample regular expressions you can use based on your chosen case style.
+
+Adjust the regex if you choose a different delimiter.
+
+{{< tabs "naming-regex" >}}
+{{< tab "snake_case" >}}
+
+**Example**: `element_one`-`element_two`-`element_three`
+
+```bash
+^[a-z][a-z0-9_]*(-[a-z][a-z0-9_]*)*$
+```
+
+{{< /tab >}}
+{{< tab "camelCase" >}}
+
+**Example**: `elementOne`-`elementTwo`-`elementThree`
+
+```bash
+^[a-z][a-zA-Z0-9]*(-[a-z][a-zA-Z0-9]*)*$
+```
+
+{{< /tab >}}
+{{< tab "PascalCase" >}}
+
+**Example**: `ElementOne`-`ElementTwo`-`ElementThree`
+
+```bash
+^[A-Z][a-zA-Z0-9]*(-[A-Z][a-zA-Z0-9]*)*$
+```
+{{< /tab >}}
+{{< /tabs >}}
+
+
+{{% hint info %}}
+If you want a specific length limit (e.g., max 50 characters), you can add a lookahead at the start of the regex:
+
+```bash
+^(?=.{1,50}$) # + rest of the regex
+```
+
+You can use online regex testers like [regex101](https://regex101.com/) to validate and test these expressions.
+
+{{% /hint %}}
+
+## Subpages
diff --git a/docs.kosli.com/content/implementation_guide/phase_2/plan_organizational_structure/naming_conventions/attestation_types.md b/docs.kosli.com/content/implementation_guide/phase_2/plan_organizational_structure/naming_conventions/attestation_types.md
new file mode 100644
index 000000000..ccdec0512
--- /dev/null
+++ b/docs.kosli.com/content/implementation_guide/phase_2/plan_organizational_structure/naming_conventions/attestation_types.md
@@ -0,0 +1,76 @@
+---
+title: "Attestation Types"
+bookCollapseSection: false
+weight: 300
+---
+
+# Attestation Types
+
+Use clear, descriptive names for custom attestation types to indicate what kind of evidence they represent.
+
+Naming convention relates to `TYPE-NAME` in Kosli CLI command:
+
+```bash
+kosli create attestation-type TYPE-NAME [flags]
+```
+
+See [CLI documentation]({{< ref "client_reference/kosli_create_attestation-type" >}}) for more details.
+
+**Name Convention:** `control objective`-`evidence type`-`[detail]`-`[version]`
+
+- **control objective**: The high-level control or requirement the attestation supports (e.g., control id, code review, security scan, unit test)
+- **evidence type**: The specific type of evidence being attested (e.g. tool-name, test-suite)
+- **detail (Optional)**: Additional context or detail about the attestation (e.g., type, severity-level, environment, etc.)
+- **version (Optional)**: The version of the attestation type or schema. Should follow semantic versioning (e.g., v1, v2)
+
+{{% hint info %}}
+
+- `detail` element may be repeated to add finer granularity if needed.
+- You can skip `detail` and `version` if not needed for your use case.
+- Kosli versions attestation types automatically, so `version` is often unnecessary. However, it can be useful for multiple version running at the same time, for example in shared pipelines.
+{{% /hint %}}
+
+{{< tabs "attestation-type-examples" >}}
+{{< tab "snake_case" >}}
+
+**Examples on `TYPE-NAME`:**
+- `bc1-version_control-v1` (BC1 version control attestation, version 1)
+- `code_review-github-pr` (basic code review attestation)
+- `security_scan-snyk-high` (Custom schema for Snyk scan with high severity detail)
+- `unit_test-junit-detail1-detail2-v2` (Multiple detail blocks with version)
+
+**Regex:**
+
+```bash
+^[a-z][a-z0-9_]*-[a-z][a-z0-9_]*(-[a-z][a-z0-9_]*)*(-v[1-9][0-9]*)?$
+```
+
+{{< /tab >}}
+{{< tab "camelCase" >}}
+**Examples on `TYPE-NAME`:**
+- `bc1-versionControl-v1` (BC1 version control attestation, version 1)
+- `codeReview-github-pr` (basic code review attestation)
+- `securityScan-snyk-high` (Custom schema for Snyk scan with high severity detail)
+- `unitTest-junit-detail1-detail2-v2` (Multiple detail blocks with version)
+
+**Regex:**
+
+```bash
+^[a-z][a-zA-Z0-9]*-[a-z][a-zA-Z0-9]*(-[a-z][a-zA-Z0-9]*)*(-v[1-9][0-9]*)?$
+```
+{{< /tab >}}
+{{< tab "PascalCase" >}}
+
+**Examples on `TYPE-NAME`:**
+- `Bc1-VersionControl-V1` (BC1 version control attestation, version 1)
+- `CodeReview-Github-Pr` (basic code review attestation)
+- `SecurityScan-Snyk-High` (Custom schema for Snyk scan with high severity detail)
+- `UnitTest-Junit-Detail1-Detail2-V2` (Multiple detail blocks with version)
+
+**Regex:**
+
+```bash
+^[A-Z][a-zA-Z0-9]*-[A-Z][a-zA-Z0-9]*(-[A-Z][a-zA-Z0-9]*)*(-V[1-9][0-9]*)?$
+```
+{{< /tab >}}
+{{< /tabs >}}
\ No newline at end of file
diff --git a/docs.kosli.com/content/implementation_guide/phase_2/plan_organizational_structure/naming_conventions/flows_and_trails.md b/docs.kosli.com/content/implementation_guide/phase_2/plan_organizational_structure/naming_conventions/flows_and_trails.md
new file mode 100644
index 000000000..00d7121cb
--- /dev/null
+++ b/docs.kosli.com/content/implementation_guide/phase_2/plan_organizational_structure/naming_conventions/flows_and_trails.md
@@ -0,0 +1,200 @@
+---
+title: "Flows and Trails"
+bookCollapseSection: false
+weight: 200
+---
+# Flows and Trails Naming Conventions
+
+This document outlines recommended naming conventions for Flows and Trails as they closely relate to each other in Kosli. Adopting these conventions will help maintain clarity and consistency across your organization.
+
+## Flows
+
+A clear naming convention transforms a simple ID into a meaningful identifier that everyone understands. This shared language ensures attestations go to the right place and you can track your releases from start to finish.
+
+The naming convention relates to `FLOW-NAME` in Kosli CLI command:
+
+```bash
+kosli create flow FLOW-NAME [flags]
+```
+
+See [CLI documentation]({{< ref "client_reference/kosli_create_flow" >}}) for more details.
+
+The following sections define conventions for the two main types of Flows in Kosli: Build Flows and Release Flows.
+
+- **Build Flows**: Represent how code changes move from commit to artifact.
+- **Release Flows**: Represent how artifacts move from binary repository to deployment.
+
+### Build Flows
+
+**Name Convention:** `org unit`-`repo`-`[service]`
+
+- **org unit**: Your organizational unit, division or team name
+- **repo**: Your repository name
+- **service (Optional)**: The specific service or component that the artifact belongs to
+
+{{% hint info %}}
+You can skip `service` if your repository produces only one artifact, i.e. non-monorepo setups.
+{{% /hint %}}
+
+{{< tabs "build-flow-examples" >}}
+{{< tab "snake_case" >}}
+
+**Examples on `FLOW-NAME`:**
+- `investment-web_app` (single artifact)
+- `investment-web_app-frontend` (with service: frontend)
+- `devops_team-mobile_app-backend` (with service: backend)
+
+**Regex:**
+
+```bash
+^[a-z][a-z0-9_]*-[a-z][a-z0-9_]*(-[a-z][a-z0-9_]*)?$
+```
+
+{{< /tab >}}
+{{< tab "camelCase" >}}
+
+**Examples on `FLOW-NAME`:**
+- `investment-webApp` (single artifact)
+- `investment-webApp-frontend` (with service: frontend)
+- `devopsTeam-mobileApp-backend` (with service: backend)
+
+**Regex:**
+
+```bash
+^[a-z][a-zA-Z0-9]*-[a-z][a-zA-Z0-9]*(-[a-z][a-zA-Z0-9]*)?$
+```
+{{< /tab >}}
+{{< tab "PascalCase" >}}
+
+**Examples on `FLOW-NAME`:**
+- `Investment-WebApp` (single artifact)
+- `Investment-WebApp-Frontend` (with service: frontend)
+- `DevOpsTeam-MobileApp-Backend` (with service: backend)
+
+**Regex:**
+
+```bash
+^[A-Z][a-zA-Z0-9]*-[A-Z][a-zA-Z0-9]*(-[A-Z][a-zA-Z0-9]*)?$
+```
+{{< /tab >}}
+{{< /tabs >}}
+
+### Release Flows
+
+**Name Convention:** `org unit`-`repo`
+
+- **org unit**: Your organizational unit, division or team name
+- **repo**: Your repository name
+
+{{< tabs "release-flow-examples" >}}
+{{< tab "snake_case" >}}
+
+**Examples on `FLOW-NAME`:**
+- `investment-web_app`
+- `devops_team-mobile_app`
+
+**Regex:**
+
+```bash
+^[a-z][a-z0-9_]*-[a-z][a-z0-9_]*$
+```
+{{< /tab >}}
+{{< tab "camelCase" >}}
+**Examples on `FLOW-NAME`:**
+- `investment-webApp`
+- `devopsTeam-mobileApp`
+
+**Regex:**
+
+```bash
+^[a-z][a-zA-Z0-9]*-[a-z][a-zA-Z0-9]*$
+```
+{{< /tab >}}
+{{< tab "PascalCase" >}}
+**Examples on `FLOW-NAME`:**
+- `Investment-WebApp`
+- `DevOpsTeam-MobileApp`
+
+**Regex:**
+
+```bash
+^[A-Z][a-zA-Z0-9]*-[A-Z][a-zA-Z0-9]*$
+```
+{{< /tab >}}
+{{< /tabs >}}
+
+
+## Trails
+
+The naming convention for Trails depends on the type of Flow they are associated with: Build Flows or Release Flows and relates to `TRAIL-NAME` in Kosli CLI command:
+
+```bash
+kosli begin trail TRAIL-NAME \
+  --flow FLOW-NAME \ # Build or Release Flow
+  [other flags]
+```
+
+See [CLI documentation]({{< ref "client_reference/kosli_begin_trail" >}}) for more details.
+
+
+### Trails associated with [Build Flows]({{< ref "#build-flows" >}})
+
+Casing does not matter for SHA values, so we do not provide multiple casing options here.
+
+**Name Convention:** `sha`
+
+- **sha**: The git commit HEAD SHA that triggered the build.
+
+**Examples on `TRAIL-NAME`:**
+- `abcdef1234567890abcdef1234567890abcdef12` (full 40-char SHA)
+- `abcdef123` (short SHA)
+
+**Regex:**
+
+```bash
+^[a-f0-9]+$
+```
+
+### Trails associated with [Release Flows]({{< ref "#release-flows" >}})
+**Name Convention:** `env`-`pr number`
+
+- **env**: The target deployment environment (e.g., staging, production)
+- **pr number**: The pull request or change request number associated with the deployment.
+
+{{< tabs "release-trail-examples" >}}
+{{< tab "snake_case" >}}
+**Examples on `TRAIL-NAME`:**
+- `staging-42`
+- `production-108`
+
+**Regex:**
+
+```bash
+^[a-z][a-z0-9_]*-[0-9]+$
+```
+
+{{< /tab >}}
+{{< tab "camelCase" >}}
+**Examples on `TRAIL-NAME`:**
+- `staging-42`
+- `production-108`
+
+**Regex:**
+
+```bash
+^[a-z][a-zA-Z0-9]*-[0-9]+$
+```
+
+{{< /tab >}}
+{{< tab "PascalCase" >}}
+**Examples on `TRAIL-NAME`:**
+- `Staging-42`
+- `Production-108`
+
+**Regex:**
+
+```bash
+^[A-Z][a-zA-Z0-9]*-[0-9]+$
+```
+{{< /tab >}}
+{{< /tabs >}}