diff --git a/docs/developer/package-integration/network-policies.md b/docs/developer/package-integration/network-policies.md
index da0bf61996c3f93e003d6f2b4d13dad02ba43320..9570d26eb21bdbf7599f942e167d1ba8f335aa03 100644
--- a/docs/developer/package-integration/network-policies.md
+++ b/docs/developer/package-integration/network-policies.md
@@ -8,7 +8,7 @@ To increase the overall security posture of Big Bang, network policies are put i
 
 ## Prerequisites
 
-- Understanding of ports and communications of applications and other components within BigBang
+- Understanding of ports and communications of applications and other components within Big Bang.
 - `chart/templates/bigbang` and `chart/templates/bigbang/networkpolicies` folders within package for committing bigbang specific templates.
 
 ## Integration
@@ -71,23 +71,23 @@ There are a few ways to determine if a network policy is blocking egress or ingr
 
 ### Allowing Exceptions
 
-- Egress exceptions to consider:
-  - pod to pod
-  - SSO
-    - When available, use a value from the helm values for the port
-    - Otherwise, use the SSO default and allow egress to all IPs, except the cloud metadata IP. The default port should be 443.
-  - storage database
-    - When available, use a value from the helm values for the port
-    - Otherwise, use the database default and allow egress to all IPs, except the cloud metadata IP.
-  - Istiod for istio-proxy sidecars
-- Ingress exceptions to consider:
-  - Kube-api
-  - Prometheus
-  - Istio for virtual service
-  - web endpoints
-- Once you have determined an exception needs to be made, create a template in `chart/templates/bigbang/networkpolicies`.
-- NetworkPolicy templates follow the naming convention of `direction-destination.yaml` (eg: egress-dns.yaml).
-- Each networkPolicy template in the package will have an if statement checking for `networkPolicies.enabled` and will only be present when `enabled: true`
+* Egress exceptions to consider:
+  * Pod to pod
+  * SSO:
+      * When available, use a value from the helm values for the port.
+      * Otherwise, use the SSO default and allow egress to all IPs, except the cloud metadata IP. The default port should be 443.
+  * Storage database:
+      * When available, use a value from the helm values for the port.
+      * Otherwise, use the database default and allow egress to all IPs, except the cloud metadata IP.
+  * Istiod for istio-proxy sidecars
+* Ingress exceptions to consider:
+  * Kube-api
+  * Prometheus
+  * Istio for virtual service
+  * Web endpoints
+* Once you have determined an exception needs to be made, create a template in `chart/templates/bigbang/networkpolicies`.
+* NetworkPolicy templates follow the naming convention of `direction-destination.yaml` (eg: egress-dns.yaml).
+* Each networkPolicy template in the package will have an if statement checking for `networkPolicies.enabled` and will only be present when `enabled: true`
 
 For example, if the podinfo package needs to send information to istiod, add the following content to a file named `egress-istio-d.yaml`:
 
@@ -161,10 +161,10 @@ networkPolicies:
     istio: ingressgateway
 ```
 
-- Use the `enabled: false` code above in order to disable networkPolicy templates for the package. The networkPolicy templates will be enabled by default when deployed from BigBang because it will inherit the `networkPolicies.enabled` [value](https://repo1.dso.mil/big-bang/bigbang/-/blob/master/chart/values.yaml#L102).
-- The ingressLabels portion supports packages that have an externally accessible UIs. Values from BigBang will also be inherited in this portion to ensure traffic from the correct istio ingressgateway is whitelisted.
+* Use the `enabled: false` code above in order to disable networkPolicy templates for the package. The networkPolicy templates will be enabled by default when deployed from BigBang because it will inherit the `networkPolicies.enabled` [value](https://repo1.dso.mil/big-bang/bigbang/-/blob/master/chart/values.yaml#L102).
+* The ingressLabels portion supports packages that have an externally accessible UIs. Values from Big Bang will also be inherited in this portion to ensure traffic from the correct istio ingressgateway is whitelisted.
 
-Example of a BigBang value configuration, `bigbang/templates/podinfo/values.yaml`, when adding a package into BigBang with networkPolicies:
+Example of a Big Bang value configuration, `bigbang/templates/podinfo/values.yaml`, when adding a package into Big Bang with networkPolicies:
 
 ```yaml
 networkPolicies:
@@ -176,8 +176,8 @@ networkPolicies:
   controlPlaneCidr: {{ .Values.networkPolicies.controlPlaneCidr }}
 ```
 
-- If the package needs to talk to the kube-api service (eg: operators) then the `controlPlaneCidr` value will be required.
-  - The `controlPlaneCidr` will control egress to the kube-api and be wide open by default, but will inherit the `networkPolicies.controlPlaneCidr` value from BigBang so the range can be locked down.
+* If the package needs to talk to the kube-api service (eg: operators) then the `controlPlaneCidr` value will be required.
+    * The `controlPlaneCidr` will control egress to the kube-api and be wide open by default, but will inherit the `networkPolicies.controlPlaneCidr` value from Big Bang so the range can be locked down.
 
 Sample `chart/templates/bigbang/networkpolicies/egress-kube-api.yaml`:
 
@@ -206,14 +206,14 @@ spec:
 
 - The networkPolicy template for kube-api egress will look like the above, so that communication to the [AWS Instance Metadata](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) and [Azure Instance Metadata](https://docs.microsoft.com/en-us/azure/virtual-machines/windows/instance-metadata-service) can be limited unless required by the package.
 
-### Supporting additional network policies through values.yaml
+### Supporting Additional Network Policies through values.yaml
 
-All bigbang core and supported addon packages are expected to provide support for the deployment of additional network policies through the values yaml [as per the user guide](../../guides/using-bigbang/network-policies.md). There is a standard mechanism for the implementation of this pattern, with two use cases: 
+All Big Bang core and supported addon packages are expected to provide support for the deployment of additional network policies through the values yaml [as per the user guide](../../guides/using-bigbang/network-policies.md). There is a standard mechanism for the implementation of this pattern, with two use cases: 
 
-- where a package will only be deployed into its own namespace (the majority of bigbang packages)
-- where a package may be used in inside another package's namespace or deployed into its own namespace (such as the gitlab-runner)
+* Where a package will only be deployed into its own namespace (i.e., the majority of bigbang packages).
+* Where a package may be used in inside another package's namespace or deployed into its own namespace (e.g., the gitlab-runner).
 
-#### Single namespace
+#### Single Namespace
 
 For this use case, a simple iteration over the values is sufficient to create the needed functionality. The standard pattern is to place this into `<package>/chart/templates/bigbang/networkpolicies/additional-networkpolicies.yaml`:
 
@@ -231,7 +231,7 @@ spec:
 {{- end }}
 ```
 
-#### Multiple namespaces
+#### Multiple Namespaces
 
 For this use case, refer to [the gitlab runner implementation](https://repo1.dso.mil/big-bang/product/packages/gitlab-runner/-/blob/main/chart/templates/bigbang/networkpolicies/egress-runner-jobs.yaml?ref_type=heads). In this pattern, a given chart may be deployed into one or more namespaces. However, you may only want to enable to control of additional network policies in a certain subset of those namespaces. In these cases, it is sufficient to extend the conditional at the top that checks for the flag in the values:
 
@@ -241,4 +241,4 @@ For this use case, refer to [the gitlab runner implementation](https://repo1.dso
 
 ## Validation
 
-- Package functions as expected and is able to communicate with all BigBang touchpoints.
+* Package functions as expected and is able to communicate with all Big Bang touchpoints.
diff --git a/docs/developer/package-integration/ownership.md b/docs/developer/package-integration/ownership.md
index 095a1ed3b94b8b26b34ff40c7837abd0ca217838..e036701ab6ed39d8908a42700db58439e2cb126e 100644
--- a/docs/developer/package-integration/ownership.md
+++ b/docs/developer/package-integration/ownership.md
@@ -2,30 +2,30 @@
 
 Package owners will be responsible for the following:
 
-* Cutting Releases for the packages and getting into BigBang
-* Implementing Package requirements outlined by the [package integration guide](../README.md)
-* Reviewing Merge Requests into the Package Repository
-* Reviewing Merge Request CI/CD pipeline execution results to ensure that there are no regressions in conformance tests nor package cypress tests.  
+* Cutting releases for the packages and getting into Big Bang.
+* Implementing package requirements outlined by the [package integration guide](../README.md).
+* Reviewing Merge Requests (MRs) into the package repository.
+* Reviewing MR CI/CD pipeline execution results to ensure that there are no regressions in conformance tests nor package cypress tests.  
 * Tracking upstream changes to packages including new features, architectures, dependencies.
-* Upgrading package with new upstream versions
-* Implementing features based on customer requests/requirements
-* Adding and improving interactions with current new new Big Bang Packages
-* IronBank interactions
-  * Identifying new Images to harden
-  * Notify IronBank of new versions available
-  * Testing new IronBank images
-  * [Long term] Providing CI processes for hardening images
+* Upgrading package with new upstream versions.
+* Implementing features based on customer requests/requirements.
+* Adding and improving interactions with current new new Big Bang packages.
+* IronBank interactions:
+  * Identifying new images to harden.
+  * Notify IronBank of new versions available.
+  * Testing new IronBank images.
+  * [Long term] Providing CI processes for hardening images.
 
 Package Owners will be identified by the use of [CODEOWNERS](https://docs.gitlab.com/ee/user/project/code_owners.html) files in the repository.
 
-There must be at least 3 (three) Package owners for each application and they shall be from different companies. Inactive Package owners from different Value Streams or external vendors shall be removed.
+There must be at least three package owners for each application and they shall be from different companies. Inactive package owners from different value streams or external vendors shall be removed.
 
 ## Package Shadows
 
-There can also be defined, for each package, shadows that are tracking ownership for each package.  These shadows are responsible for filling in for the primary package
-owners as needed.  This could be the result of a package owner being on leave, or transitioning off of the team.  The shadows will maintain situational awareness on all
-Merge Requests and be ready and able to participate in resolving production issues.  Shadows will be listed in the CODEOWNERS file like Package Owners.
+There can also be defined, for each package, shadows that are tracking ownership for each package. These shadows are responsible for filling in for the primary package
+owners as needed. This could be the result of a package owner being on leave, or transitioning off of the team. The shadows will maintain situational awareness on all
+Merge Requests and be ready and able to participate in resolving production issues. Shadows will be listed in the CODEOWNERS file like package owners.
 
 ## New Package Owners
 
-A majority of Package Owners can approve the addition of a new member to the CODEOWNERs file, as long as one company does not control more than half the owners.
+A majority of package owners can approve the addition of a new member to the CODEOWNERs file, as long as one company does not control more than half the owners.
diff --git a/docs/developer/package-integration/pipeline.md b/docs/developer/package-integration/pipeline.md
index 6b1e4682befa01c52eb3a819b3a24e7195107782..16a446483a010559ba233f6a370481dbaf7cc3ee 100644
--- a/docs/developer/package-integration/pipeline.md
+++ b/docs/developer/package-integration/pipeline.md
@@ -1,33 +1,32 @@
 # Pipeline Integration
 
-Big Bang contains and uses a continuous deployment tool to deploy packages using Helm charts sourced from Git.  This document will cover how to integrate a Helm chart from a mission application or other package into the pattern Big Bang requires.  Once complete, you will be able to deploy your package with Big Bang.
+Big Bang contains and uses a continuous deployment tool to deploy packages using Helm charts sourced from Git. This document will cover how to integrate a Helm chart from a mission application or other package into the pattern Big Bang requires. Once complete, you will be able to deploy your package with Big Bang.
 
 ## Prerequisites
 
-- [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
-- [Docker CLI](https://docs.docker.com/get-docker/)
-- [Big Bang package project containing your Helm chart](./upstream.md)
-   > You will need to have the Container Registry enabled.This can be requested from the Big Bang team.
+* [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
+* [Docker CLI](https://docs.docker.com/get-docker/)
+* [Big Bang package project containing your Helm chart](./upstream.md)
+   > You will need to have the Container Registry enabled. This can be requested from the Big Bang team.
 
 > Throughout this document, we will be setting up an application called `podinfo` as a demonstration.
 
-
 ## Branching
 
-Each package will have a default branch of `main`.  Immutable tags will be used to identify releases and will follow a semver versioning scheme. 
+Each package will have a default branch of `main.` Immutable tags will be used to identify releases and will follow a semver versioning scheme. 
 
 ## Package Pipeline
 
-Pipelines provide rapid feedback to changes in our Helm chart as we develop and should be put in place as early as possible.  Big Bang has a few different pipelines that can be used for packages.
+Pipelines provide rapid feedback to changes in our Helm chart as we develop and should be put in place as early as possible. Big Bang has a few different pipelines that can be used for packages.
 
-- [bigbang-package](https://repo1.dso.mil/big-bang/pipeline-templates/pipeline-templates/-/blob/master/pipelines/bigbang-package.yaml)
-- [sandbox](https://repo1.dso.mil/big-bang/pipeline-templates/pipeline-templates/-/blob/master/pipelines/sandbox.yaml)
-- [third-party](https://repo1.dso.mil/big-bang/pipeline-templates/pipeline-templates/-/blob/master/pipelines/third-party.yaml)
+* [bigbang-package](https://repo1.dso.mil/big-bang/pipeline-templates/pipeline-templates/-/blob/master/pipelines/bigbang-package.yaml)
+* [sandbox](https://repo1.dso.mil/big-bang/pipeline-templates/pipeline-templates/-/blob/master/pipelines/sandbox.yaml)
+* [third-party](https://repo1.dso.mil/big-bang/pipeline-templates/pipeline-templates/-/blob/master/pipelines/third-party.yaml)
 
 
-The pipeline **requires** that all images are stored in either Iron Bank (`registry1.dso.mil`) or Repo1 (`registry.dso.mil`).  In some cases, you may be able to substitute images already in Iron Bank for the ones in the Helm chart.  For example, images for `curl`, `kubectl` or `jq` can use `registry1.dso.mil/ironbank/big-bang/base`.  If you have not already submitted your containers to Iron Bank, [start the process](https://repo1.dso.mil/dsop/dccscr/-/blob/master/README.md).  While you are working your way to Iron Bank approval, you can temporarily put the images in `registry.dso.mil` for development by doing the following:
+The pipeline **requires** that all images are stored in either Iron Bank (`registry1.dso.mil`) or Repo1 (`registry.dso.mil`). In some cases, you may be able to substitute images already in Iron Bank for the ones in the Helm chart. For example, images for `curl`, `kubectl` or `jq` can use `registry1.dso.mil/ironbank/big-bang/base.`  If you have not already submitted your containers to Iron Bank, [start the process](https://repo1.dso.mil/dsop/dccscr/-/blob/master/README.md). While you are working your way to Iron Bank approval, you can temporarily put the images in `registry.dso.mil` for development by doing the following:
 
-> Check if the Container Registry is on by navigating to `https://repo1.dso.mil/big-bang/apps/sandbox/<your project>/container_registry`.  If you get a 404 error, you need to request a Maintainer turn this feature on in your project via Settings > General > Visibility > Container Registry.
+> Check if the Container Registry is on by navigating to `https://repo1.dso.mil/big-bang/apps/sandbox/<your project>/container_registry`. If you get a 404 error, you need to request a Maintainer turn this feature on in your project via Settings > General > Visibility > Container Registry.
 
 ```shell
 # Image Info
@@ -59,27 +58,27 @@ docker push $IMGDST_REPO/$IMGDST_PROJ/$IMGNAME:$IMGTAG
     ```
 
 1. Update the repo's CI/CD settings to call the pipeline (`Settings > CI/CD > General pipelines > Expand > CI/CD configuration file`).
-    For Bigbang
+    For Big Bang:
 
     ```plaintext
     pipelines/bigbang-package.yaml@platform-one/big-bang/pipeline-templates/pipeline-templates:master
     ```
 
-    For Third party
+    For Third party:
 
     ```plaintext
     pipelines/third-party.yaml@platform-one/big-bang/pipeline-templates/pipeline-templates:master
     ```
 
-    For Sandbox
+    For Sandbox:
 
     ```plaintext
     pipelines/sandbox.yaml@platform-one/big-bang/pipeline-templates/pipeline-templates:master
     ```
 
-1. Add overlay values for testing into `tests/test-values.yaml`.  This will be where you add values needed for running in the pipeline.  For now it can be a blank, placeholder.
+1. Add overlay values for testing into `tests/test-values.yaml.` This will be where you add values needed for running in the pipeline. For now it can be a blank, placeholder.
 
-1. Commit the changes
+1. Commit the changes.
 
     ```shell
     git add -A
@@ -87,9 +86,9 @@ docker push $IMGDST_REPO/$IMGDST_PROJ/$IMGNAME:$IMGTAG
     git push
     ```
 
-1. Big Bang requires a Merge Request to run the pipeline.  Open a MR to merge your branch into the main branch.
+1. Big Bang requires a Merge Request (MR) to run the pipeline. Open a MR to merge your branch into the main branch.
 
-    > You will need to add `SKIP UPDATE CHECK` and `SKIP UPGRADE` into the title of the first MR or it will fail.  Until you have a baseline Helm chart and CHANGELOG in place, these stages need to be skipped.
+    > You will need to add `SKIP UPDATE CHECK` and `SKIP UPGRADE` into the title of the first MR or it will fail. Until you have a baseline Helm chart and CHANGELOG in place, these stages need to be skipped.
 
 1. The pipeline will install the package, run any Helm tests (`chart/tests`), and run any custom tests (`tests`).
 
@@ -103,10 +102,10 @@ Third-party and sandbox pipelines both have an `integration` stage that will dep
 
 Examples of components that contribute to a package being "Big Bang compatible":
 
-- Configuring a package to be deployed via Flux custom resource definitions ([GitRepositories](https://fluxcd.io/docs/components/source/gitrepositories/) and [HelmReleases](https://fluxcd.io/docs/components/helm/helmreleases/))
+* Configuring a package to be deployed via Flux custom resource definitions ([GitRepositories](https://fluxcd.io/docs/components/source/gitrepositories/) and [HelmReleases](https://fluxcd.io/docs/components/helm/helmreleases/)).
 
-- Service mesh components ([Automatic Istio sidecar injection](https://istio.io/latest/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection) and [Istio VirtualService](https://istio.io/latest/docs/reference/config/networking/virtual-service/))
+* Service mesh components ([Automatic Istio sidecar injection](https://istio.io/latest/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection) and [Istio VirtualService](https://istio.io/latest/docs/reference/config/networking/virtual-service/)).
  
-This stage also allows any Big Bang Core or Addon packages to be deployed alongside a third-party or sandbox package for testing compatibility/functionality.
+This stage also allows any Big Bang core or add-on packages to be deployed alongside a third-party or sandbox package for testing compatibility/functionality.
 
 To set this up in a package repo, see the guide [here](./flux.md).
diff --git a/docs/developer/package-integration/policy-enforcement.md b/docs/developer/package-integration/policy-enforcement.md
index ca6ff4b9f51b31f57f8621fc658bce03a1fa05b2..a66561166285cadbe8cace95c1b5c8f35afdb843 100644
--- a/docs/developer/package-integration/policy-enforcement.md
+++ b/docs/developer/package-integration/policy-enforcement.md
@@ -6,14 +6,14 @@ When integrating your package, you must adhere to the policies enforced by Kyver
 
 ## Prerequisites
 
-- A K8s cluster with Big Bang installed.
-- cluster admin access to the cluster with [kubectl](https://kubernetes.io/docs/tasks/tools/).
+* A K8s cluster with Big Bang installed.
+* Cluster admin access to the cluster with [kubectl](https://kubernetes.io/docs/tasks/tools/).
 
 ## Integration
 
 ### 1. Deploying a Policy Enforcement Tool (Kyverno)
 
-Kyverno is deployed as the first package in the default Big Bang configuration. This setup allows Kyverno to protect the cluster from the start by enforcing policies on all resources. Your package will interact with the cluster under the governance of Kyverno's policy engine.
+Kyverno is deployed as the first package in the default Big Bang configuration. This set up allows Kyverno to protect the cluster from the start by enforcing policies on all resources. Your package will interact with the cluster under the governance of Kyverno's policy engine.
 
 ### 2. Identifying Violations Found on Your Application