diff --git a/modules/ob-about-buildrun.adoc b/modules/ob-about-buildrun.adoc
index ce2b2602a029..3fdbb3908959 100644
--- a/modules/ob-about-buildrun.adoc
+++ b/modules/ob-about-buildrun.adoc
@@ -7,7 +7,7 @@
 = BuildRun resource
 
 [role="_abstract"]
-A `BuildRun` resource invokes a build on the cluster similar to a Tekton task run. It represents a workload that instantiates a build for execution with specific parameters. Each BuildRun defines a unique name for monitoring, references a Build instance, and specifies a service account within a namespace.
+A `BuildRun` resource invokes a build on the cluster similar to a Tekton task run. It represents a workload that instantiates a build for execution with specific parameters. Each `BuildRun` defines a unique name for monitoring, references a Build instance, and specifies a service account within a namespace.
 
 A `BuildRun` resource helps you to define the following elements:
 
diff --git a/modules/ob-basic-authentication.adoc b/modules/ob-basic-authentication.adoc
index 7e5ee37f45ac..e824e68e24d5 100644
--- a/modules/ob-basic-authentication.adoc
+++ b/modules/ob-basic-authentication.adoc
@@ -7,7 +7,7 @@
 = Basic authentication
 
 [role="_abstract"]
-Configure basic authentication credentials for a Git repository by creating a Kubernetes secret with a username and password. The following example shows a Git basic-auth secret referenced by a build:
+Configure Basic authentication credentials for a Git repository by creating a Kubernetes secret with a username and password. The following example shows a Git basic-auth secret referenced by a build:
 
 [source,yaml]
 ----
@@ -24,5 +24,5 @@ stringData:
 ----
 where:
 
-`type`:: Specifies the Kubernetes secret type. `kubernetes.io/basic-auth` indicates that the secret contains credentials for basic authentication.
-`stringData`:: Specifies the username and password used for basic authentication to the Git repository referenced by the build.
\ No newline at end of file
+`type`:: Specifies the Kubernetes secret type. `kubernetes.io/basic-auth` indicates that the secret contains credentials for Basic authentication.
+`stringData`:: Specifies the username and password used for Basic authentication to the Git repository referenced by the build.
\ No newline at end of file
diff --git a/modules/ob-build-run-status.adoc b/modules/ob-build-run-status.adoc
index 54409fb69823..9f7290e367f1 100644
--- a/modules/ob-build-run-status.adoc
+++ b/modules/ob-build-run-status.adoc
@@ -10,7 +10,7 @@
 Monitor the progress and completion of your image builds by checking the status of the `BuildRun` custom resource (CR).
 A `BuildRun` CR stores status information in the status.conditions field. This field includes the status, the reason for that status, and a descriptive message. For example, a `Succeeded` condition type means the build finished successfully.
 
-The following examples show how to view the status of a specific BuildRun CR.
+The following examples show how to view the status of a specific `BuildRun` CR.
 
 Unknown status::
 An `Unknown` status indicates the build is still starting or in progress. The following example shows a `BuildRun` with `Unknown` status:
diff --git a/modules/ob-configuring-pods-in-build-run.adoc b/modules/ob-configuring-pods-in-build-run.adoc
index ac8a15305476..d48a4d2e3106 100644
--- a/modules/ob-configuring-pods-in-build-run.adoc
+++ b/modules/ob-configuring-pods-in-build-run.adoc
@@ -11,7 +11,7 @@ Configure pod scheduling and placement for {builds-shortname} by using optional
 
 Use the following fields to configure {builds-shortname} pods:
 
-* `spec.tolerations`: Specifies pod tolerations. Note: Only the NoSchedule taint effect is supported.
+* `spec.tolerations`: Specifies pod tolerations. Note: Only the `NoSchedule` taint effect is supported.
 
 * `spec.nodeSelector`: Specifies the nodes where the pod must run.
 
diff --git a/modules/ob-configuring-pods-in-build.adoc b/modules/ob-configuring-pods-in-build.adoc
index 500a01b67896..4bbc17092a6b 100644
--- a/modules/ob-configuring-pods-in-build.adoc
+++ b/modules/ob-configuring-pods-in-build.adoc
@@ -20,6 +20,6 @@ Use the following optional `Build` CR fields to configure {builds-shortname} pod
 
 [NOTE]
 ====
-If you define these fields in the Build and BuildRun CRs, the BuildRun values take priority.
+If you define these fields in the Build and `BuildRun` CRs, the `BuildRun` values take priority.
 ====
 
diff --git a/modules/ob-creating-a-buildah-build-network-restricted.adoc b/modules/ob-creating-a-buildah-build-network-restricted.adoc
new file mode 100644
index 000000000000..651fd607b8a8
--- /dev/null
+++ b/modules/ob-creating-a-buildah-build-network-restricted.adoc
@@ -0,0 +1,227 @@
+// Module included in the following assemblies:
+//
+// * work_with_builds/creating-container-images-in-a-network-restricted-environment.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id='ob-creating-a-buildah-build-in-a-network-restricted-environment_{context}']
+= Creating a buildah build in a network-restricted environment
+
+[role="_abstract"]
+Create a `buildah` build in a network-restricted environment by mirroring the images that `buildah` build strategy requires. Mirroring the images eliminates the need for public registry access. This ensures clusters use only images that comply with external content controls.
+
+.Prerequisites
+
+* You have installed the {builds-operator} on the {ocp-product-title} cluster.
+* You have installed the `oc` CLI.
+* Optional: You have installed the link:https://console.redhat.com/openshift/downloads[`shp` CLI].
+* Your cluster can connect and interact with the Git source that you can use to create the buildah build.
+* You have the builder-image required to create the `buildah` build in your local registry. If the builder-image is not present in the local registry, mirror the source image.
+
+.Procedure
+
+. Run the following command to mirror the images that `buildah` build strategy requires:
++
+[source,terminal]
+----
+$ oc image mirror --insecure -a <registry_authentication> registry.redhat.io/ubi8/buildah@sha256:1c89cc3cab0ac0fc7387c1fe5e63443468219aab6fd531c8dad6d22fd999819e <mirror_registry>/<repo>/ubi8_buildah
+----
++
+where:
+
+`<registry_authentication>`:: Specifies the authentication credentials used to access a container registry. This is required when pushing to or pulling from a private registry.
+`<mirror_registry>`:: Specifies the registry where the image you want to mirror is stored.
+
+. Create a `Build` resource and apply it to the {ocp-product-title} cluster. You can
+do so by using the `oc` command or the `shp` command:
++
+[source,terminal]
+----
+$ oc apply -f - <<EOF
+apiVersion: shipwright.io/v1beta1
+kind: Build
+metadata:
+  name: buildah-golang-build
+spec:
+  source:
+    type: Git
+    git:
+      url: https://github.com/shipwright-io/sample-go
+    contextDir: docker-build
+  strategy:
+    name: buildah
+    kind: ClusterBuildStrategy
+  paramValues:
+  - name: dockerfile
+    value: Dockerfile
+  output:
+    image: image-registry.openshift-image-registry.svc:5000/buildah-example/sample-go-app
+EOF
+----
++
+--
+where:
+
+`source`:: Defines the location where the source code is placed.
+`strategy`:: Defines the build strategy that you use to build the container.
+`paramValues`:: Defines the parameter defined in the build strategy. To set the value of the `dockerfile` strategy parameter, specify the Dockerfile location required to build the output image.
+`output`:: Defines the location where the built image is pushed. In this procedural example, the built image is pushed to the {ocp-product-title} cluster internal registry. `buildah-example` is the name of the current project. Ensure that the specified project exists to allow the image push.
+--
+
++
+[source,terminal]
+----
+$ shp build create buildah-golang-build \
+--source-url="https://github.com/redhat-openshift-builds/samples"
+--source-context-dir="buildah-build" \
+--strategy-name="buildah" \
+--dockerfile="Dockerfile" \
+--output-image="image-registry.openshift-image-registry.svc:5000/buildah-example/go-app"
+----
++
+where:
+
+`source-context-dir`:: Defines the location where the source code is placed.
+`strategy-name`:: Defines the build strategy that you use to build the container.
+`dockerfile`:: Defines the parameter defined in the build strategy. To set the value of the `dockerfile` strategy parameter, specifies the Dockerfile location required to build the output image.
+`output-image`:: Defines the location where the built image is pushed. In this procedural example, the built image is pushed to the {ocp-product-title} cluster internal registry. `buildah-example` is the name of the current project. Ensure that the specified project exists to allow the image push.
+
+. Check if the `Build` resource is created. You can do so by using the `oc` command or
+the `shp` command:
++
+[source,terminal]
+----
+$ oc get builds.shipwright.io buildah-golang-build
+----
+
++
+[source,terminal]
+----
+$ shp build list
+----
+
+. Create a `BuildRun` resource and apply it to the {ocp-product-title} cluster. You can do so by using the `oc` command or the `shp` command:
++
+[source,terminal]
+----
+$ oc apply -f - <<EOF
+apiVersion: shipwright.io/v1beta1
+kind: BuildRun
+metadata:
+  name: buildah-golang-buildrun
+spec:
+  build:
+    name: buildah-golang-build
+EOF
+----
++
+where:
+
+`spec.build.name`:: Defines the build to run, which is expected to be available in the same namespace.
+
++
+[source,terminal]
+----
+$ shp build run buildah-golang-build --follow
+----
+* `--follow`:: (Optional) Use the `--follow` flag to view the build logs in the output result.
+
+. Check if the `BuildRun` resource is created. You can do so by using the `oc` command or
+the `shp` command:
++
+[source,terminal]
+----
+$ oc get buildrun buildah-golang-buildrun
+----
+
++
+[source,terminal]
+----
+$ shp buildrun list
+----
++
+The `BuildRun` resource creates a `TaskRun` resource, which then creates the pods to execute build strategy steps.
+
+.Verification
+
+After all the containers complete their tasks, verify the following resources:
+
+. Check whether the pod shows the `STATUS` field as `Completed`:
++
+[source,terminal]
+----
+$ oc get pods -w
+----
++
+Example output:
++
+[source,terminal]
+----
+NAME                                READY   STATUS    RESTARTS   AGE
+buildah-golang-buildrun-dtrg2-pod   2/2     Running   0          4s
+buildah-golang-buildrun-dtrg2-pod   1/2     NotReady  0          7s
+buildah-golang-buildrun-dtrg2-pod   0/2     Completed 0          55s
+----
+
+. Check whether the required `TaskRun` resource shows the `SUCCEEDED` field as `True`:
++
+[source,terminal]
+----
+$ oc get tr
+----
++
+Example output:
++
+[source,terminal]
+----
+NAME                           SUCCEEDED  REASON     STARTTIME   COMPLETIONTIME
+buildah-golang-buildrun-dtrg2  True       Succeeded  11m         8m51s
+----
+
+. Check whether the required `BuildRun` resource shows the `SUCCEEDED` field as `True`:
++
+[source,terminal]
+----
+$ oc get br
+----
++
+Example output:
++
+[source,terminal]
+----
+NAME                     SUCCEEDED   REASON       STARTTIME     COMPLETIONTIME
+buildah-golang-buildrun  True        Succeeded    13m           11m
+----
+
+. During verification, if a build run fails, you can check the `status.failureDetails` field in your `BuildRun` resource to identify the exact point where the failure happened in the pod or container.
++
+[NOTE]
+====
+The pod might switch to a `NotReady` state because one of the containers has completed its task. This is an expected behavior.
+====
+
+. Validate whether the image has been pushed to the registry that is specified in the `build.spec.output.image` field. Run the following command to pull the image from a node that can access the internal registry:
++
+[source,terminal]
+----
+$ podman manifest inspect image-registry.openshift-image-registry.svc:5000/buildah-example/taxi-app
+----
++
+In the previous example, the project name is `buildah-example`, and the image name is `taxi-app`.
++
+Example output:
++
+[source,terminal]
+----
+   "schemaVersion": 2,
+    "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
+    "manifests": [
+        {
+            "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
+            "size": 594,
+            "digest": "sha256:6a05100e302c86c03fec6277f4b3107f1fdde6c69d3ca9a4207e4735a5213e32",
+            "platform": {
+                "architecture": "amd64",
+                "os": "linux"
+            }
+     ]
+----
diff --git a/modules/ob-creating-a-buildah-build-standard.adoc b/modules/ob-creating-a-buildah-build-standard.adoc
new file mode 100644
index 000000000000..ce698dabfe24
--- /dev/null
+++ b/modules/ob-creating-a-buildah-build-standard.adoc
@@ -0,0 +1,213 @@
+// Module included in the following assemblies:
+//
+// * work-with-builds/creating-container-images.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ob-creating-a-buildah-build_{context}"]
+= Creating a buildah build
+
+[role="_abstract"]
+Use a `buildah` build strategy to build and push a container image using a Dockerfile.
+
+.Prerequisites
+
+* You have installed the {builds-operator} on the {ocp-product-title} cluster.
+* You have installed the `oc` CLI.
+* Optional: You have installed the link:https://console.redhat.com/openshift/downloads[`shp` CLI].
+
+.Procedure
+
+. Create a `Build` resource and apply it to the {ocp-product-title} cluster. You can
+do so by using the `oc` command or the `shp` command:
++
+[source,terminal]
+----
+$ oc apply -f - <<EOF
+apiVersion: shipwright.io/v1beta1
+kind: Build
+metadata:
+  name: buildah-golang-build
+spec:
+  source:
+    type: Git
+    git:
+      url: https://github.com/shipwright-io/sample-go
+    contextDir: docker-build
+  strategy:
+    name: buildah
+    kind: ClusterBuildStrategy
+  paramValues:
+  - name: dockerfile
+    value: Dockerfile
+  output:
+    image: image-registry.openshift-image-registry.svc:5000/buildah-example/sample-go-app
+EOF
+----
++
+--
+where:
+
+`source`:: Defines the location where the source code is placed.
+`strategy`:: Defines the build strategy that you use to build the container.
+`paramValues`:: Defines the parameter defined in the build strategy. To set the value of the `dockerfile` strategy parameter, specify the Dockerfile location required to build the output image.
+`output`:: Defines the location where the built image is pushed. In this procedural example, the built image is pushed to the {ocp-product-title} cluster internal registry. `buildah-example` is the name of the current project. Ensure that the specified project exists to allow the image push.
+--
+
++
+[source,terminal]
+----
+$ shp build create buildah-golang-build \
+--source-url="https://github.com/redhat-openshift-builds/samples"
+--source-context-dir="buildah-build" \
+--strategy-name="buildah" \
+--dockerfile="Dockerfile" \
+--output-image="image-registry.openshift-image-registry.svc:5000/buildah-example/go-app"
+----
++
+where:
+
+`source-context-dir`:: Defines the location where the source code is placed.
+`strategy-name`:: Defines the build strategy that you use to build the container.
+`dockerfile`:: Defines the parameter defined in the build strategy. To set the value of the `dockerfile` strategy parameter, specifies the Dockerfile location required to build the output image.
+`output-image`:: Defines the location where the built image is pushed. In this procedural example, the built image is pushed to the {ocp-product-title} cluster internal registry. `buildah-example` is the name of the current project. Ensure that the specified project exists to allow the image push.
+
+. Check if the `Build` resource is created. You can do so by using the `oc` command or
+the `shp` command:
++
+[source,terminal]
+----
+$ oc get builds.shipwright.io buildah-golang-build
+----
+
++
+[source,terminal]
+----
+$ shp build list
+----
+
+. Create a `BuildRun` resource and apply it to the {ocp-product-title} cluster. You can do so by using the `oc` command or the `shp` command:
++
+[source,terminal]
+----
+$ oc apply -f - <<EOF
+apiVersion: shipwright.io/v1beta1
+kind: BuildRun
+metadata:
+  name: buildah-golang-buildrun
+spec:
+  build:
+    name: buildah-golang-build
+EOF
+----
++
+where:
+
+`spec.build.name`:: Defines the build to run, which is expected to be available in the same namespace.
+
++
+[source,terminal]
+----
+$ shp build run buildah-golang-build --follow
+----
+* `--follow`:: (Optional) Use the `--follow` flag to view the build logs in the output result.
+
+. Check if the `BuildRun` resource is created. You can do so by using the `oc` command or
+the `shp` command:
++
+[source,terminal]
+----
+$ oc get buildrun buildah-golang-buildrun
+----
+
++
+[source,terminal]
+----
+$ shp buildrun list
+----
++
+The `BuildRun` resource creates a `TaskRun` resource, which then creates the pods to execute build strategy steps.
+
+.Verification
+
+After all the containers complete their tasks, verify the following resources:
+
+. Check whether the pod shows the `STATUS` field as `Completed`:
++
+[source,terminal]
+----
+$ oc get pods -w
+----
++
+Example output:
++
+[source,terminal]
+----
+NAME                                READY   STATUS    RESTARTS   AGE
+buildah-golang-buildrun-dtrg2-pod   2/2     Running   0          4s
+buildah-golang-buildrun-dtrg2-pod   1/2     NotReady  0          7s
+buildah-golang-buildrun-dtrg2-pod   0/2     Completed 0          55s
+----
+
+. Check whether the required `TaskRun` resource shows the `SUCCEEDED` field as `True`:
++
+[source,terminal]
+----
+$ oc get tr
+----
++
+Example output:
++
+[source,terminal]
+----
+NAME                           SUCCEEDED  REASON     STARTTIME   COMPLETIONTIME
+buildah-golang-buildrun-dtrg2  True       Succeeded  11m         8m51s
+----
+
+. Check whether the required `BuildRun` resource shows the `SUCCEEDED` field as `True`:
++
+[source,terminal]
+----
+$ oc get br
+----
++
+Example output:
++
+[source,terminal]
+----
+NAME                     SUCCEEDED   REASON       STARTTIME     COMPLETIONTIME
+buildah-golang-buildrun  True        Succeeded    13m           11m
+----
+
+. During verification, if a build run fails, you can check the `status.failureDetails` field in your `BuildRun` resource to identify the exact point where the failure happened in the pod or container.
++
+[NOTE]
+====
+The pod might switch to a `NotReady` state because one of the containers has completed its task. This is an expected behavior.
+====
+
+. Validate whether the image has been pushed to the registry that is specified in the `build.spec.output.image` field. Run the following command to pull the image from a node that can access the internal registry:
++
+[source,terminal]
+----
+$ podman manifest inspect image-registry.openshift-image-registry.svc:5000/buildah-example/taxi-app
+----
++
+In the previous example, the project name is `buildah-example`, and the image name is `taxi-app`.
++
+Example output:
++
+[source,terminal]
+----
+   "schemaVersion": 2,
+    "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
+    "manifests": [
+        {
+            "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
+            "size": 594,
+            "digest": "sha256:6a05100e302c86c03fec6277f4b3107f1fdde6c69d3ca9a4207e4735a5213e32",
+            "platform": {
+                "architecture": "amd64",
+                "os": "linux"
+            }
+     ]
+----
diff --git a/modules/ob-creating-a-buildah-build.adoc b/modules/ob-creating-a-buildah-build.adoc
index 1d9e507c3921..7bda55c90f80 100644
--- a/modules/ob-creating-a-buildah-build.adoc
+++ b/modules/ob-creating-a-buildah-build.adoc
@@ -182,7 +182,7 @@ buildah-golang-buildrun-dtrg2-pod   1/2     NotReady  0          7s
 buildah-golang-buildrun-dtrg2-pod   0/2     Completed 0          55s
 ----
 
-. Check whether the respective `TaskRun` resource shows the `SUCCEEDED` field as `True`:
+. Check whether the required `TaskRun` resource shows the `SUCCEEDED` field as `True`:
 +
 [source,terminal]
 ----
@@ -197,7 +197,7 @@ NAME                           SUCCEEDED  REASON     STARTTIME   COMPLETIONTIME
 buildah-golang-buildrun-dtrg2  True       Succeeded  11m         8m51s
 ----
 
-. Check whether the respective `BuildRun` resource shows the `SUCCEEDED` field as `True`:
+. Check whether the required `BuildRun` resource shows the `SUCCEEDED` field as `True`:
 +
 [source,terminal]
 ----
diff --git a/modules/ob-creating-a-buildpacks-build.adoc b/modules/ob-creating-a-buildpacks-build.adoc
index c2050f7d3313..8fcf2c0ffd65 100644
--- a/modules/ob-creating-a-buildpacks-build.adoc
+++ b/modules/ob-creating-a-buildpacks-build.adoc
@@ -23,8 +23,7 @@ Use a `buildpacks` build to create and push container images to the target regis
 
 [IMPORTANT]
 ====
-Using `shp` CLI with buildpacks requires additional permissions setup that
-you must complete before you start creating a buildpacks build.
+Using `shp` CLI with buildpacks requires additional permissions setup that you must complete before you start creating a buildpacks build.
 ====
 
 .Procedure
@@ -127,7 +126,7 @@ $ oc get builds.shipwright.io buildpack-nodejs-build
 $ shp build list
 ----
 
-. Create a `BuildRun` resource and apply it to the {ocp-product-title} cluster.  You can do so by using the `oc` command or the `shp` command:
+. Create a `BuildRun` resource and apply it to the {ocp-product-title} cluster. You can do so by using the `oc` command or the `shp` command:
 +
 [source,terminal]
 ----
@@ -198,7 +197,7 @@ $ shp buildrun list
 +
 [NOTE]
 ====
-The `BuildRun` resource creates a `TaskRun` resource, which then creates the pods to execute build strategy steps.
+The `BuildRun` resource creates a `TaskRun` resource, which then creates the pods to run build strategy steps.
 ====
 
 .Verification
diff --git a/modules/ob-creating-a-s2i-build-network-restricted.adoc b/modules/ob-creating-a-s2i-build-network-restricted.adoc
new file mode 100644
index 000000000000..8d2f05f7717c
--- /dev/null
+++ b/modules/ob-creating-a-s2i-build-network-restricted.adoc
@@ -0,0 +1,229 @@
+// Module included in the following assemblies:
+//
+// * work_with_builds/creating-container-images-in-a-network-restricted-environment.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id='ob-creating-a-source-to-image-build-in-a-network-restricted-environment_{context}']
+= Creating a source-to-image build in a network-restricted environment
+
+[role="_abstract"]
+Use the `source-to-image` build strategy in disconnected environments by first mirroring required builder images to a local registry. This approach allows your cluster to operate without public registry access while maintaining compliance with organizational content policies.
+
+.Prerequisites
+
+* You have installed the {builds-operator} on the {ocp-product-title} cluster.
+* You have installed the `oc` CLI.
+* Optional: You have installed the link:https://console.redhat.com/openshift/downloads[`shp` CLI].
+* Your cluster can connect and interact with the Git source that you can use to create the source-to-image build.
+* You have the builder-image required to create the `source-to-image` build in your local registry. If the builder-image is not present in the local registry, mirror the source image.
+
+.Procedure
+
+. Run the following command to mirror the images that `source-to-image` build strategy requires:
++
+[source,terminal]
+----
+$ oc image mirror --insecure -a <registry_authentication> registry.redhat.io/source-to-image/source-to-image-rhel8@sha256:d041c1bbe503d152d0759598f79802e257816d674b342670ef61c6f9e6d401c5 <mirror_registry>/<repo>/source-to-image-source-to-image-rhel8
+----
++
+where:
+
+`<registry_authentication>`:: Specifies the authentication credentials used to access a container registry. This is required when pushing to or pulling from a private registry.
+`<mirror_registry>`:: Specifies the registry where the image you want to mirror is stored.
+
+. Create a `Build` resource and apply it to the {ocp-product-title} cluster. You can do so by using the `oc` command or the `shp` command:
++
+[source,terminal]
+----
+$ oc apply -f - <<EOF
+apiVersion: shipwright.io/v1beta1
+kind: Build
+metadata:
+  name: s2i-nodejs-build
+spec:
+  source:
+    type: Git
+    git:
+      url: https://github.com/redhat-openshift-builds/samples
+    contextDir: s2i-build/nodejs
+  strategy:
+    name: source-to-image
+    kind: ClusterBuildStrategy
+  paramValues:
+  - name: builder-image
+    value: quay.io/centos7/nodejs-12-centos7:master
+  output:
+    image: quay.io/<repo>/s2i-nodejs-example
+    pushSecret: registry-credential
+EOF
+----
++
+--
+where:
+
+`source`:: Defines the location where the source code is placed.
+`strategy`:: Defines the build strategy that you use to build the container.
+`paramValues`:: Defines the parameters for the build strategy. For `source-to-image` builds, this includes the `builder-image` parameter that specifies the base image used to build your application.
+`output`:: Defines the location where the built image is pushed. In this procedural example, the built image is pushed to the {ocp-product-title} cluster internal registry. `buildah-example` is the name of the current project. Ensure that the specified project exists to allow the image push.
+`pushSecret`:: Defines the secret name that stores the credentials for pushing container images. To generate a secret of the type `docker-registry` for authentication, see "Authentication to container registries".
+--
+
++
+[source,terminal]
+----
+$ shp build create s2i-nodejs-build \
+--source-url="https://github.com/redhat-openshift-builds/samples" --source-context-dir="s2i-build/nodejs" \
+--strategy-name="source-to-image" \
+--builder-image="quay.io/centos7/nodejs-12-centos7" \
+--output-image="quay.io/<repo>/s2i-nodejs-example" \
+--output-credentials-secret="registry-credential"
+----
++
+where:
+
+`source-context-dir`:: Defines the location where the source code is placed.
+`strategy-name`:: The build strategy that you use to build the container.
+`builder-image`:: The parameter defined in the build strategy. For `source-to-image` builds, this specifies the base image used to build your application.
+`output-image`:: The location where the built image is pushed. In this procedural example, the built image is pushed to the {ocp-product-title} cluster internal registry. `buildah-example` is the name of the current project. Ensure that the specified project exists to allow the image push.
+`output-credentials-secret`:: The secret name that stores the credentials for pushing container images. To generate a secret of the type `docker-registry` for authentication, see "Authentication to container registries".
+
+. Check if the `Build` resource is created. You can do so by using the `oc` command or the `shp` command:
++
+[source,terminal]
+----
+$ oc get builds.shipwright.io s2i-nodejs-build
+----
+
++
+[source,terminal]
+----
+$ shp build list
+----
+
+. Create a `BuildRun` resource and apply it to the {ocp-product-title} cluster. You can do so by using the `oc` command or the `shp` command:
++
+[source,terminal]
+----
+$ oc apply -f - <<EOF
+apiVersion: shipwright.io/v1beta1
+kind: BuildRun
+metadata:
+  name: s2i-nodejs-buildrun
+spec:
+  build:
+    name: s2i-nodejs-build
+EOF
+----
++
+where:
+
+`spec.build.name`:: Specifies the respective build to run, which is expected to be available in the same namespace.
+
++
+[source,terminal]
+----
+$ shp build run s2i-nodejs-build --follow
+----
++
+where:
+
+`--follow`:: (Optional) Use the `--follow` flag to view the build logs in the output result.
+
+. Check if the `BuildRun` resource is created. You can do so by using the `oc` command or the `shp` command:
++
+[source,terminal]
+----
+$ oc get buildrun s2i-nodejs-buildrun
+----
+
++
+[source,terminal]
+----
+$ shp buildrun list
+----
++
+The `BuildRun` resource creates a `TaskRun` resource, which then creates the pods to execute build strategy steps.
+
+.Verification
+
+After all the containers complete their tasks, verify the statuses of the following resources:
+
+. Check whether the pod shows the `STATUS` field as `Completed`:
++
+[source,terminal]
+----
+$ oc get pods -w
+----
++
+Example output:
++
+[source,terminal]
+----
+NAME                                READY   STATUS     RESTARTS   AGE
+s2i-nodejs-buildrun-phxxm-pod       2/2     Running    0          10s
+s2i-nodejs-buildrun-phxxm-pod       1/2     NotReady   0          14s
+s2i-nodejs-buildrun-phxxm-pod       0/2     Completed  0          2m
+----
+
+. Check whether the respective `TaskRun` resource shows the `SUCCEEDED` field as `True`:
++
+[source,terminal]
+----
+$ oc get tr
+----
++
+Example output:
++
+[source,terminal]
+----
+NAME                           SUCCEEDED  REASON     STARTTIME   COMPLETIONTIME
+s2i-nodejs-buildrun-phxxm      True       Succeeded  2m39s        13s
+----
+
+. Check whether the respective `BuildRun` resource shows the `SUCCEEDED` field as `True`:
++
+[source,terminal]
+----
+$ oc get br
+----
++
+Example output:
++
+[source,terminal]
+----
+NAME                     SUCCEEDED   REASON       STARTTIME     COMPLETIONTIME
+s2i-nodejs-buildrun      True        Succeeded    2m41s           15s
+----
+
+. During verification, if a build run fails, you can check the `status.failureDetails` field in your `BuildRun` resource to identify the exact point where the failure happened in the pod or container.
++
+[NOTE]
+====
+The pod might switch to a `NotReady` state because one of the containers has completed its task. This is an expected behavior.
+====
+
+. Validate whether the image has been pushed to the registry that is specified in the `build.spec.output.image` field. Log in to the registry and run the following command to pull the image:
++
+[source,terminal]
+----
+$ podman manifest inspect image-registry.openshift-image-registry.svc:5000/s2i-example/taxi-app
+----
+In the previous example, the project name is `s2i-example`, and the image name is `taxi-app`.
++
+Example output:
++
+[source,terminal]
+----
+   "schemaVersion": 2,
+    "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
+    "manifests": [
+        {
+            "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
+            "size": 594,
+            "digest": "sha256:6a05100e302c86c03fec6277f4b3107f1fdde6c69d3ca9a4207e4735a5213e32",
+            "platform": {
+                "architecture": "amd64",
+                "os": "linux"
+            }
+     ]
+----
diff --git a/modules/ob-creating-a-s2i-build-standard.adoc b/modules/ob-creating-a-s2i-build-standard.adoc
new file mode 100644
index 000000000000..b2efeefabdaf
--- /dev/null
+++ b/modules/ob-creating-a-s2i-build-standard.adoc
@@ -0,0 +1,215 @@
+// Module included in the following assemblies:
+//
+// * work_with_builds/creating-container-images.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ob-creating-a-s2i-build_{context}"]
+= Creating a source-to-image build
+
+[role="_abstract"]
+Use a `source-to-image` (S2I) build strategy to turn application source code into a container image using a base image.
+
+.Prerequisites
+
+* You have installed the {builds-operator} on the {ocp-product-title} cluster.
+* You have installed the `oc` CLI.
+* Optional: You have installed the link:https://console.redhat.com/openshift/downloads[`shp` CLI].
+
+.Procedure
+
+. Create a `Build` resource and apply it to the {ocp-product-title} cluster. You can do so by using the `oc` command or the `shp` command:
++
+[source,terminal]
+----
+$ oc apply -f - <<EOF
+apiVersion: shipwright.io/v1beta1
+kind: Build
+metadata:
+  name: s2i-nodejs-build
+spec:
+  source:
+    type: Git
+    git:
+      url: https://github.com/redhat-openshift-builds/samples
+    contextDir: s2i-build/nodejs
+  strategy:
+    name: source-to-image
+    kind: ClusterBuildStrategy
+  paramValues:
+  - name: builder-image
+    value: quay.io/centos7/nodejs-12-centos7:master
+  output:
+    image: quay.io/<repo>/s2i-nodejs-example
+    pushSecret: registry-credential
+EOF
+----
++
+--
+where:
+
+`source`:: Defines the location where the source code is placed.
+`strategy`:: Defines the build strategy that you use to build the container.
+`paramValues`:: Defines the parameters for the build strategy. For `source-to-image` builds, this includes the `builder-image` parameter that specifies the base image used to build your application.
+`output`:: Defines the location where the built image is pushed. In this procedural example, the built image is pushed to the {ocp-product-title} cluster internal registry. `buildah-example` is the name of the current project. Ensure that the specified project exists to allow the image push.
+`pushSecret`:: Defines the secret name that stores the credentials for pushing container images. To generate a secret of the type `docker-registry` for authentication, see "Authentication to container registries".
+--
+
++
+[source,terminal]
+----
+$ shp build create s2i-nodejs-build \
+--source-url="https://github.com/redhat-openshift-builds/samples" --source-context-dir="s2i-build/nodejs" \
+--strategy-name="source-to-image" \
+--builder-image="quay.io/centos7/nodejs-12-centos7" \
+--output-image="quay.io/<repo>/s2i-nodejs-example" \
+--output-credentials-secret="registry-credential"
+----
++
+where:
+
+`source-context-dir`:: Defines the location where the source code is placed.
+`strategy-name`:: The build strategy that you use to build the container.
+`builder-image`:: The parameter defined in the build strategy. For `source-to-image` builds, this specifies the base image used to build your application.
+`output-image`:: The location where the built image is pushed. In this procedural example, the built image is pushed to the {ocp-product-title} cluster internal registry. `buildah-example` is the name of the current project. Ensure that the specified project exists to allow the image push.
+`output-credentials-secret`:: The secret name that stores the credentials for pushing container images. To generate a secret of the type `docker-registry` for authentication, see "Authentication to container registries".
+
+. Check if the `Build` resource is created. You can do so by using the `oc` command or the `shp` command:
++
+[source,terminal]
+----
+$ oc get builds.shipwright.io s2i-nodejs-build
+----
+
++
+[source,terminal]
+----
+$ shp build list
+----
+
+. Create a `BuildRun` resource and apply it to the {ocp-product-title} cluster. You can do so by using the `oc` command or the `shp` command:
++
+[source,terminal]
+----
+$ oc apply -f - <<EOF
+apiVersion: shipwright.io/v1beta1
+kind: BuildRun
+metadata:
+  name: s2i-nodejs-buildrun
+spec:
+  build:
+    name: s2i-nodejs-build
+EOF
+----
++
+where:
+
+`spec.build.name`:: Specifies the respective build to run, which is expected to be available in the same namespace.
+
++
+[source,terminal]
+----
+$ shp build run s2i-nodejs-build --follow
+----
++
+where:
+
+`--follow`:: (Optional) Use the `--follow` flag to view the build logs in the output result.
+
+. Check if the `BuildRun` resource is created. You can do so by using the `oc` command or the `shp` command:
++
+[source,terminal]
+----
+$ oc get buildrun s2i-nodejs-buildrun
+----
+
++
+[source,terminal]
+----
+$ shp buildrun list
+----
++
+The `BuildRun` resource creates a `TaskRun` resource, which then creates the pods to execute build strategy steps.
+
+.Verification
+
+After all the containers complete their tasks, verify the statuses of the following resources:
+
+. Check whether the pod shows the `STATUS` field as `Completed`:
++
+[source,terminal]
+----
+$ oc get pods -w
+----
++
+Example output:
++
+[source,terminal]
+----
+NAME                                READY   STATUS     RESTARTS   AGE
+s2i-nodejs-buildrun-phxxm-pod       2/2     Running    0          10s
+s2i-nodejs-buildrun-phxxm-pod       1/2     NotReady   0          14s
+s2i-nodejs-buildrun-phxxm-pod       0/2     Completed  0          2m
+----
+
+. Check whether the respective `TaskRun` resource shows the `SUCCEEDED` field as `True`:
++
+[source,terminal]
+----
+$ oc get tr
+----
++
+Example output:
++
+[source,terminal]
+----
+NAME                           SUCCEEDED  REASON     STARTTIME   COMPLETIONTIME
+s2i-nodejs-buildrun-phxxm      True       Succeeded  2m39s        13s
+----
+
+. Check whether the respective `BuildRun` resource shows the `SUCCEEDED` field as `True`:
++
+[source,terminal]
+----
+$ oc get br
+----
++
+Example output:
++
+[source,terminal]
+----
+NAME                     SUCCEEDED   REASON       STARTTIME     COMPLETIONTIME
+s2i-nodejs-buildrun      True        Succeeded    2m41s           15s
+----
+
+. During verification, if a build run fails, you can check the `status.failureDetails` field in your `BuildRun` resource to identify the exact point where the failure happened in the pod or container.
++
+[NOTE]
+====
+The pod might switch to a `NotReady` state because one of the containers has completed its task. This is an expected behavior.
+====
+
+. Validate whether the image has been pushed to the registry that is specified in the `build.spec.output.image` field. Log in to the registry and run the following command to pull the image:
++
+[source,terminal]
+----
+$ podman manifest inspect image-registry.openshift-image-registry.svc:5000/s2i-example/taxi-app
+----
+In the previous example, the project name is `s2i-example`, and the image name is `taxi-app`.
++
+Example output:
++
+[source,terminal]
+----
+   "schemaVersion": 2,
+    "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
+    "manifests": [
+        {
+            "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
+            "size": 594,
+            "digest": "sha256:6a05100e302c86c03fec6277f4b3107f1fdde6c69d3ca9a4207e4735a5213e32",
+            "platform": {
+                "architecture": "amd64",
+                "os": "linux"
+            }
+     ]
+----
diff --git a/modules/ob-defining-param-values-in-build-run.adoc b/modules/ob-defining-param-values-in-build-run.adoc
index b56d1358e8d7..61c96d43d319 100644
--- a/modules/ob-defining-param-values-in-build-run.adoc
+++ b/modules/ob-defining-param-values-in-build-run.adoc
@@ -7,7 +7,7 @@
 = Parameter values definition for a build run
 
 [role="_abstract"]
-You can define values for build strategy parameters in your BuildRun custom resource (CR). Values set in the BuildRun resource override any values with the same name in the Build resource.
+You can define values for build strategy parameters in your `BuildRun` custom resource (CR). Values set in the `BuildRun` resource override any values with the same name in the Build resource.
 
 In the following example, the `cache` value in the `BuildRun` overrides the `cache` value in the `Build` resource:
 
diff --git a/modules/ob-example-configuration-for-defining-parameter-values.adoc b/modules/ob-example-configuration-for-defining-parameter-values.adoc
index 39027ff8a4e3..04ba22928140 100644
--- a/modules/ob-example-configuration-for-defining-parameter-values.adoc
+++ b/modules/ob-example-configuration-for-defining-parameter-values.adoc
@@ -9,7 +9,7 @@
 [role="_abstract"]
 The following examples show how to set parameters in a build strategy. You can use a `Build` custom resource (CR) to give these parameters specific values. You can also assign values to array parameters.
 
-Define parameters in a ClusterBuildStrategy CR::
+Define parameters in a `ClusterBuildStrategy` CR::
 The following example shows a `ClusterBuildStrategy` CR with several parameters:
 +
 [source,yaml]
diff --git a/modules/ob-isolate-all-project-builds-using-a-specific-runtimeclass.adoc b/modules/ob-isolate-all-project-builds-using-a-specific-runtimeclass.adoc
index d71b3e899b3e..110373b2eca9 100644
--- a/modules/ob-isolate-all-project-builds-using-a-specific-runtimeclass.adoc
+++ b/modules/ob-isolate-all-project-builds-using-a-specific-runtimeclass.adoc
@@ -47,7 +47,7 @@ spec:
 where:
 
 `spec.source`:: Defines the Git repository and context directory containing the source code to build.
-`spec.strategy`:: Specifies the build strategy to use. In this example, the `buildah` ClusterBuildStrategy is used.
+`spec.strategy`:: Specifies the build strategy to use. In this example, the `buildah` `ClusterBuildStrategy` is used.
 `spec.output.image`:: Specifies the destination for the built container image.
 `spec.runtimeClassName`:: Specifies the RuntimeClass to use for build isolation. For example, `kata` for OpenShift Sandboxed Containers.
 +
@@ -81,7 +81,8 @@ A `Succeeded` status reason confirms that the `Build` passed validation. If the
 $ oc get build buildah-build-kata -o jsonpath='{.spec.runtimeClassName}'
 ----
 +
-.Example output
+Example output:
++
 [source,terminal]
 ----
 kata
diff --git a/modules/ob-runtimeclass-prerequisites-and-precedence.adoc b/modules/ob-runtimeclass-prerequisites-and-precedence.adoc
index f603c733fe1e..9d1fc0d817c0 100644
--- a/modules/ob-runtimeclass-prerequisites-and-precedence.adoc
+++ b/modules/ob-runtimeclass-prerequisites-and-precedence.adoc
@@ -8,7 +8,7 @@
 = Runtime selection requirements and precedence
 
 [role="_abstract"]
-Meet cluster configuration requirements and understand how the system resolves `runtimeClassName` conflicts across Build and BuildRun resources before using alternative runtimes.
+Meet cluster configuration requirements and understand how the system resolves `runtimeClassName` conflicts across Build and `BuildRun` resources before using alternative runtimes.
 
 * On {product-title}, OpenShift Sandboxed Containers Operator supports `runtimeClass` for Kata Containers. This operator manages the full lifecycle of the Kata Containers runtime on your cluster. As a cluster administrator, you must install the operator from OperatorHub and then create a `KataConfig` custom resource. The operator then:
 ** Installs the required RHCOS extensions (QEMU, kata-containers) on worker nodes.
@@ -63,7 +63,7 @@ The following table summarizes how the system resolves which runtime to use when
 [options="header"]
 |===
 
-| Build runtimeClassName | BuildRun runtimeClassName | Effective RuntimeClass
+| Build runtimeClassName | `BuildRun` runtimeClassName | Effective RuntimeClass
 
 | Not set | Not set | Cluster default |
 | kata    | Not set | kata |
diff --git a/modules/ob-specifying-environment-variables.adoc b/modules/ob-specifying-environment-variables.adoc
index 035fae806e49..bfa2c8284982 100644
--- a/modules/ob-specifying-environment-variables.adoc
+++ b/modules/ob-specifying-environment-variables.adoc
@@ -7,7 +7,7 @@
 = Environment variables definition
 
 [role="_abstract"]
-You can set environment variables in your BuildRun custom resource (CR). These variables pass information to the build container. You can use literal values or the Kubernetes downward API.
+You can set environment variables in your `BuildRun` custom resource (CR). These variables pass information to the build container. You can use literal values or the Kubernetes downward API.
  
 The following example shows how to define environment variables:
 [source,yaml]
diff --git a/modules/ob-step-results-in-build-run-status.adoc b/modules/ob-step-results-in-build-run-status.adoc
index c6ba131278fa..dee9aef15fb4 100644
--- a/modules/ob-step-results-in-build-run-status.adoc
+++ b/modules/ob-step-results-in-build-run-status.adoc
@@ -7,7 +7,7 @@
 = Step results in build run status
 
 [role="_abstract"]
-After a `BuildRun` custom resource (CR) finishes execution, `.status.taskResults` shows step results like the image digest or commit SHA. `.status.sources` holds results from source steps, and `.status.output` holds results from output steps, reflecting the source and built image.
+After a `BuildRun` custom resource (CR) finishes execution, `.status.taskResults` shows step results such as the image digest or commit SHA. `.status.sources` holds results from source steps, and `.status.output` holds results from output steps, reflecting the source and built image.
 
 The following example shows a `BuildRun` CR with step results for a Git source:
 
diff --git a/modules/ob-strategies-with-different-resources.adoc b/modules/ob-strategies-with-different-resources.adoc
index 51c6208f6493..ed74f9b7630a 100644
--- a/modules/ob-strategies-with-different-resources.adoc
+++ b/modules/ob-strategies-with-different-resources.adoc
@@ -9,7 +9,7 @@
 [role="_abstract"]
 Define multiple variants of the same strategy to apply different resource limits for different build requirements.
 
-The following examples use the same `buildah` strategy with small and medium limits defined for the resources.These examples provide a strategy administrator more control over the step resources definition.
+The following examples use the same `buildah` strategy with small and medium limits defined for the resources. These examples provide a strategy administrator more control over the step resources definition.
 
 You can define the `spec.steps[].resources` field with a small resource limit for the `buildah` strategy, as shown in the following example:
 
diff --git a/modules/ob-usage-of-git-secret.adoc b/modules/ob-usage-of-git-secret.adoc
index 6b589e6321df..1261adeb0b6e 100644
--- a/modules/ob-usage-of-git-secret.adoc
+++ b/modules/ob-usage-of-git-secret.adoc
@@ -8,7 +8,7 @@
 = Usage of Git secret
 
 [role="_abstract"]
-After creating a secret in the relevant namespace, you can reference it in your `Build` custom resource (CR). You can configure the Git secret to use either basic authentication or Secure Shell (SSH) authentication.
+After creating a secret in the relevant namespace, you can reference it in your `Build` custom resource (CR). You can configure the Git secret to use either Basic authentication or Secure Shell (SSH) authentication.
 
 The following example shows the usage of a Git secret with SSH authentication type:
 
@@ -25,7 +25,7 @@ spec:
       cloneSecret: secret-git-ssh-auth
 ----
 
-The following example shows the usage of a Git secret with basic authentication type:
+The following example shows the usage of a Git secret with Basic authentication type:
 
 [source,yaml]
 ----
diff --git a/work_with_builds/creating-container-images-in-a-network-restricted-environment.adoc b/work_with_builds/creating-container-images-in-a-network-restricted-environment.adoc
index 0bafe93718b1..f732f3c9023f 100644
--- a/work_with_builds/creating-container-images-in-a-network-restricted-environment.adoc
+++ b/work_with_builds/creating-container-images-in-a-network-restricted-environment.adoc
@@ -4,16 +4,15 @@
 
 include::_attributes/common-attributes.adoc[]
 :context: managing-builds-in-network-restricted-environment
-:network-restricted: true
 
 toc::[]
 
 [role="_abstract"]
 As an application developer, configure {ocp-product-title} with an HTTP or HTTPS proxy to enforce security and prevent direct internet access for your build processes. This setup enforces security by routing build pulls of dependencies, images, and code through a monitored outgoing proxy gateway.
 
-include::modules/ob-creating-a-buildah-build.adoc[leveloffset=+1]
+include::modules/ob-creating-a-buildah-build-network-restricted.adoc[leveloffset=+1]
 
-include::modules/ob-creating-a-s2i-build.adoc[leveloffset=+1]
+include::modules/ob-creating-a-s2i-build-network-restricted.adoc[leveloffset=+1]
 
 include::modules/ob-verifying-proxy-details.adoc[leveloffset=+1]
 
@@ -21,8 +20,8 @@ include::modules/ob-verifying-proxy-details.adoc[leveloffset=+1]
 [id="additional-resources_{context}"]
 == Additional resources
 
-* xref:../about/build-strategies.adoc[Build strategies]
-* xref:../installing/installing-openshift-builds.adoc[Installing builds]
+* xref:../about/build-strategies.adoc#build-strategies[Build strategies]
+* xref:../installing/installing-openshift-builds.adoc#installing-openshift-builds[Installing builds]
 * xref:../authenticating/understanding-authentication-at-runtime.adoc#ob-authentication-to-container-registries_understanding-authentication-at-runtime[Authentication to container registries]
 * link:https://docs.openshift.com/pipelines/1.16/install_config/installing-pipelines.html#op-pipelines-operator-in-restricted-environment_installing-pipelines[Red Hat OpenShift Pipelines Operator in a restricted environment]
 * link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/configuring_network_settings/enable-cluster-wide-proxy[Configuring cluster-wide proxy]
diff --git a/work_with_builds/creating-container-images.adoc b/work_with_builds/creating-container-images.adoc
index 7b1f68dabdf5..34e7e3b63c16 100644
--- a/work_with_builds/creating-container-images.adoc
+++ b/work_with_builds/creating-container-images.adoc
@@ -10,9 +10,9 @@ toc::[]
 [role="_abstract"]
 As an application developer, create container images using `buildah`, `source-to-image`, or the `buildpacks` strategy, depending on your source code, framework, and automation requirements. You can also use Open Container Initiative (OCI) artifacts to build container images.
 
-include::modules/ob-creating-a-buildah-build.adoc[leveloffset=+1]
+include::modules/ob-creating-a-buildah-build-standard.adoc[leveloffset=+1]
 
-include::modules/ob-creating-a-s2i-build.adoc[leveloffset=+1]
+include::modules/ob-creating-a-s2i-build-standard.adoc[leveloffset=+1]
 
 include::modules/ob-creating-a-buildpacks-build.adoc[leveloffset=+1]
 
@@ -23,5 +23,5 @@ include::modules/ob-creating-a-build-with-oci-artifacts.adoc[leveloffset=+1]
 == Additional resources
 
 * xref:../authenticating/understanding-authentication-at-runtime.adoc#ob-authentication-to-container-registries_understanding-authentication-at-runtime[Authentication to container registries]
-* xref:../about/build-strategies.adoc[Build strategies]
-* xref:../installing/installing-openshift-builds.adoc[Installing builds]
\ No newline at end of file
+* xref:../about/build-strategies.adoc#about-build-strategies[Build strategies]
+* xref:../installing/installing-openshift-builds.adoc#installing-openshift-builds[Installing builds]
\ No newline at end of file
diff --git a/work_with_builds/managing-builds.adoc b/work_with_builds/managing-builds.adoc
index ed2e50513694..2091a1c1d7ad 100644
--- a/work_with_builds/managing-builds.adoc
+++ b/work_with_builds/managing-builds.adoc
@@ -1,6 +1,6 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="managing-builds"]
-= Managing Builds
+= Managing builds
 
 include::_attributes/common-attributes.adoc[]
 :context: managing-builds
@@ -22,5 +22,5 @@ include::modules/ob-deleting-a-buildstrategy-resource.adoc[leveloffset=+1]
 [id="additional-resources_{context}"]
 == Additional resources
 
-* xref:../about/build-strategies.adoc[Build strategies]
-* xref:../installing/installing-openshift-builds.adoc[Installing builds]
+* xref:../about/build-strategies.adoc#build-strategies[Build strategies]
+* xref:../installing/installing-openshift-builds.adoc#installing-openshift-builds[Installing builds]
diff --git a/work_with_builds/optimize-build-performance.adoc b/work_with_builds/optimize-build-performance.adoc
index cfa2f32ea46c..8ace519e01ac 100644
--- a/work_with_builds/optimize-build-performance.adoc
+++ b/work_with_builds/optimize-build-performance.adoc
@@ -13,11 +13,11 @@ By default, build strategies give standard resource allocations. However, heavy
 You can override the step resources to tune your builds at two levels:
 
 * Build configuration level: For permanent resource adjustments to a specific application.
-* BuildRun level: For one-time large builds (e.g., a major release).
+* `BuildRun` level: For one-time large builds (e.g., a major release).
 
 When multiple overrides exist, the system applies them in the following order of priority:
 
-* BuildRun overrides
+* `BuildRun` overrides
 * Build configuration overrides
 * Strategy defaults