diff --git a/CODEOWNERS b/CODEOWNERS
index 6edf8c78951b58d7cf3694e8fe95ce4c09e40b62..5e0404dca1a14c1e7884421f33da177448d758a0 100644
--- a/CODEOWNERS
+++ b/CODEOWNERS
@@ -7,7 +7,6 @@
 /base/                          @gabe @joshwolf @megamind @micah.nagel @michaelmcleroy @phillip.record @runyontr @ryan.j.garcia @brandencobb
 /chart/                         @gabe @joshwolf @megamind @micah.nagel @michaelmcleroy @phillip.record @runyontr @ryan.j.garcia @brandencobb
 /charter/                       @gabe @joshwolf @megamind @micah.nagel @michaelmcleroy @phillip.record @runyontr @ryan.j.garcia @brandencobb
-/hack/                          @gabe @joshwolf @megamind @micah.nagel @michaelmcleroy @phillip.record @runyontr @ryan.j.garcia @brandencobb
 /scripts/                       @gabe @joshwolf @megamind @micah.nagel @michaelmcleroy @phillip.record @runyontr @ryan.j.garcia @brandencobb
 /tests/                         @gabe @joshwolf @megamind @micah.nagel @michaelmcleroy @phillip.record @runyontr @ryan.j.garcia @brandencobb
 /docs/                          @gabe @joshwolf @megamind @micah.nagel @michaelmcleroy @phillip.record @runyontr @ryan.j.garcia @brandencobb
@@ -32,7 +31,6 @@ tests/                          @toladipupo @brandencobb @evan.rush
 
 ^[Hack Owners]
 scripts/                        @toladipupo @michaelmcleroy @egoode
-hack/                           @toladipupo @michaelmcleroy @egoode
 
 ^[Charter Owners]
 charter/                        @gabe @joshwolf @megamind @micah.nagel @michaelmcleroy @phillip.record @runyontr @ryan.j.garcia @brandencobb
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 37fa72fa76e2cdee17f69ac9a7db7339dbe724e7..f8c31f661d2e656672ceba7839e857cd5418a3a8 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -53,17 +53,17 @@ Configure `myvalues.yaml` to suit your needs.
 # Deploy the latest fluxv2 with Iron Bank images
 # For development, you can use flux from the internet using 'flux install`
 # Be aware, the internet version is likely newer than the Iron Bank version
-./hack/flux-install.sh
+./scripts/install_flux.sh
 
 # Apply a local version of the Big Bang chart
 # NOTE: This is the alternative to deploying a HelmRelease and having flux manage it, we use a local copy to avoid having to commit every change
 helm upgrade -i bigbang chart -n bigbang --create-namespace -f myvalues.yaml
 
-# It may take Big Bang up to 10 minutes to recognize your changes and start to deploy them.  This is based on the flux `interval` value set for polling.  You can force Big Bang to immediately check for changes by running the ./hack/sync.sh script.
-./hack/sync.sh
+# It may take Big Bang up to 10 minutes to recognize your changes and start to deploy them.  This is based on the flux `interval` value set for polling.  You can force Big Bang to immediately check for changes by running the ./scripts/sync.sh script.
+./scripts/sync.sh
 ```
 
-For more extensive development, use the [Development Guide](docs/c_development.md).
+For more extensive development, use the [Development Guide](./docs/developer).
 
 ## Testing Big Bang Development Changes
 
@@ -81,15 +81,11 @@ All routable endpoints BigBang deploys will use the TLD of `bigbang.dev` by defa
 
 ## Secrets & Certificates
 
-A __development only__ gpg key is provided at `bigbang-dev.asc` that is used to encrypt and decrypt the secrets in this Git repository (e.g. [hack/secrets](hack/secrets/).
-
-We cannot stress enough, __do not use this key to encrypt real secret data__.  It is a shared key meant to demonstrate the workflow of secrets management within Big Bang.
-
-Follow instructions in the [Big Bang encryption guide](docs/3_encryption.md) for how to encrypt and decrypt secrets.
+Follow instructions in the [Big Bang encryption guide](./docs/encryption.md) for how to encrypt and decrypt secrets.
 
 ## Merge requests process
 
 The merge request process is provided as an overview of the pipeline stages required to get a commit merged.
 
-Follow instruction in [CI-Workflow](docs/developer/ci-workflow.md) for specific details on the pipeline stages.
+Follow instruction in [CI-Workflow](./docs/developer/ci-workflow.md) for specific details on the pipeline stages.
 
diff --git a/README.md b/README.md
index 41bb0b542b2fa9f3d7ff840149e3fed68eb97ccc..45a0efd41054ffe1d7b38a6872561aac82d4efdd 100644
--- a/README.md
+++ b/README.md
@@ -14,11 +14,11 @@ Big Bang follows a [GitOps](#gitops) approach to configuration management, using
 
 Big Bang is intended to be used for deploying and maintaining a DoD hardened and approved set of packages into a Kubernetes cluster.  Deployment and configuration of ingress/egress, load balancing, policy auditing, logging, monitoring, etc. are handled via Big Bang.   Additional packages (e.g. ArgoCD, GitLab) can also be enabled and customized to extend Big Bang's baseline.  Once deployed, the customer can use the Kubernetes cluster to add mission specific applications.
 
-Additional information can be found in [Big Bang Overview](./docs/1_overview.md).
+Additional information can be found in [Big Bang Overview](./docs/overview.md).
 
 ## Getting Started
 
-To start using Big Bang, you will need to create your own Big Bang environment tailored to your needs.  The [Big Bang customer template](https://repo1.dso.mil/platform-one/big-bang/customers/template/) is provided for you to copy into your own Git repository and begin modifications.  Follow the instructions in [Big Bang Getting Started](./docs/2_getting_started.md) to customize and deploy Big Bang.
+To start using Big Bang, you will need to create your own Big Bang environment tailored to your needs.  The [Big Bang customer template](https://repo1.dso.mil/platform-one/big-bang/customers/template/) is provided for you to copy into your own Git repository and begin modifications.  Follow the instructions in [Big Bang Getting Started](./docs) to customize and deploy Big Bang.
 
 ## Maintainers
 
@@ -52,7 +52,7 @@ To start using Big Bang, you will need to create your own Big Bang environment t
 | sso | object | `{"auth_url":"https://{{ .Values.sso.oidc.host }}/auth/realms/{{ .Values.sso.oidc.realm }}/protocol/openid-connect/auth","certificate_authority":"","client_id":"","client_secret":"","jwks":"","oidc":{"host":"login.dso.mil","realm":"baby-yoda"},"secretName":"tls-ca-sso","token_url":"https://{{ .Values.sso.oidc.host }}/auth/realms/{{ .Values.sso.oidc.realm }}/protocol/openid-connect/token"}` | Global SSO values used for BigBang deployments when sso is enabled, can be overridden by individual packages. |
 | sso.oidc.host | string | `"login.dso.mil"` | Domain for keycloak used for configuring SSO |
 | sso.oidc.realm | string | `"baby-yoda"` | Keycloak realm containing clients |
-| sso.certificate_authority | string | `""` | Keycloak's certificate authority (PEM Format). Entered using chomp modifier (see chart/dev-sso-values.yaml for example). Used by authservice to support SSO for various packages |
+| sso.certificate_authority | string | `""` | Keycloak's certificate authority (PEM Format). Entered using chomp modifier (see ./docs/example_configs/dev-sso-values.yaml for example). Used by authservice to support SSO for various packages |
 | sso.jwks | string | `""` | Keycloak realm's json web key output, obtained at https://<keycloak-server>/auth/realms/<realm>/protocol/openid-connect/certs |
 | sso.client_id | string | `""` | OIDC client ID used for packages authenticated through authservice |
 | sso.client_secret | string | `""` | OIDC client secret used for packages authenticated through authservice |
diff --git a/chart/values.yaml b/chart/values.yaml
index 731b3000fb936389fb4f7f8e719a3689986d6bbb..f1fbe3fd5a558bb85a5ab7a396540b1ab4add14a 100644
--- a/chart/values.yaml
+++ b/chart/values.yaml
@@ -56,7 +56,7 @@ sso:
     # -- Keycloak realm containing clients
     realm: baby-yoda
 
-  # -- Keycloak's certificate authority (PEM Format). Entered using chomp modifier (see chart/dev-sso-values.yaml for example). Used by authservice to support SSO for various packages
+  # -- Keycloak's certificate authority (PEM Format). Entered using chomp modifier (see ./docs/example_configs/dev-sso-values.yaml for example). Used by authservice to support SSO for various packages
   certificate_authority: ""
 
   # -- Keycloak realm's json web key output, obtained at https://<keycloak-server>/auth/realms/<realm>/protocol/openid-connect/certs
diff --git a/charter/BigBangPackages.md b/charter/BigBangPackages.md
index ed9e502ef15e74f97683f36c7f3290c0833e8eae..1393def6b8993a446be7983d1abbeb4520ab72c1 100644
--- a/charter/BigBangPackages.md
+++ b/charter/BigBangPackages.md
@@ -2,7 +2,7 @@
 
 Each Big Bang Package is present in the [Big Bang Package](https://repo1.dso.mil/platform-one/big-bang/apps) repository and broken up into several sub-groupings.
 
-Each package has _at least_ two `CODEOWNERS`.  Responsibilities are outlined [here](ApplicationOwners.md).
+Each package has _at least_ two `CODEOWNERS`.  Responsibilities are outlined [here](PackageOwner.md).
 
 [[_TOC_]]
 
diff --git a/charter/Glossary.md b/charter/Glossary.md
index d1079009532d012b0435010ecd954780e38b9b3a..fd91280f0a036b5a50d4478980a5374e003943d7 100644
--- a/charter/Glossary.md
+++ b/charter/Glossary.md
@@ -1,5 +1,5 @@
 # Glossary
 
-**Big Bang Application**: Is an application deployable onto Kubernetes using manifests inside the Big Bang Application Repository that meets all the requirements of [Application Requirements](ApplicationRequirements.md).
+**Big Bang Application**: Is an application deployable onto Kubernetes using manifests inside the Big Bang Application Repository that meets all the requirements of [Package Requirements](PackageRequirements.md).
 
 **Release**: A release is any change to the manifests that would be installed when referencing this application.  It includes a change in Image tag, as well as modifications to the structure of any manifests that define the application deployment.
diff --git a/charter/Teams.md b/charter/Teams.md
index 71ea30a73cf8bdf17f1b3ad386adade1d0056d50..1659a24c47b382d9e390e5960a65a49d65e0c1bc 100644
--- a/charter/Teams.md
+++ b/charter/Teams.md
@@ -51,7 +51,7 @@ Execution in these two engineering efforts requires tight collaboration and feed
 #### Customers to Integration
 
 * Bugs
-* Environment specifics that can go back into Mock Environments as defined in [Testing](testing.md)
+* Environment specifics that can go back into Mock Environments as defined in [Testing](Testing.md)
 
 ### Product and Iron Bank
 
diff --git a/charter/Testing.md b/charter/Testing.md
index 063b6ff76ca34a6577ef848d4d1d5c478b09d0b5..c3461bd99bd17355d5c9bc20eabc72c2886e7ade 100644
--- a/charter/Testing.md
+++ b/charter/Testing.md
@@ -17,7 +17,7 @@ A detailed description of the pipelines and how to execute the testing process o
 
 ## Application Testing
 
-When a Big Bang application developer submits changes to a particular Big Bang application, the application needs to be tested to ensure functionality, as well as compliance with core [Application Requirements](ApplicationRequirements.md).  
+When a Big Bang application developer submits changes to a particular Big Bang application, the application needs to be tested to ensure functionality, as well as compliance with core [Package Requirements](PackageRequirements.md).  
 
 A core feature of all testing capabilities is its ability to be run locally by developers using their own environment, or by other teams looking to test proposed changes to the application (e.g. IronBank as part of container creation).  The GitLab pipelines will be simple wrappers around these common testing and deployment tools.
 
@@ -86,7 +86,7 @@ Also note that the "helm.sh/hook-weight" can be used to order the creation and e
 
 ## Umbrella Testing
 
-The end consumable is the [Umbrella Application](Umbrella.md).  As new versions of Big Bang Applications become available, those changes need to be integrated into the Umbrella and tested.  Each Merge Request into the Umbrella Repo requires passing of an [Upgrade Tests](#upgrade-tests) and the [End to End Tests](#end-to-end-tests) for all mock environments.
+The end consumable is the [Umbrella Application](BigBang.md).  As new versions of Big Bang Applications become available, those changes need to be integrated into the Umbrella and tested.  Each Merge Request into the Umbrella Repo requires passing of an [Upgrade Tests](#upgrade-tests) and the [End to End Tests](#end-to-end-tests) for all mock environments.
 
 ### Environments
 
diff --git a/charter/packages/anchore/Architecture.md b/charter/packages/anchore/Architecture.md
index 7b809fb3e64f809b43dba423f0530481fe0ea3c7..89fd63bc0b6575d3f9e3d2f68fa16abd7417a0b2 100644
--- a/charter/packages/anchore/Architecture.md
+++ b/charter/packages/anchore/Architecture.md
@@ -135,7 +135,7 @@ _Note:_ within Big Bang, logs are captured by fluentbit and shipped to elastic b
 
 ### Monitoring
 
-Anchore Engine and Enterprise expose prometheus metrics in the API of each service if the config.yaml used by that service has the metrics.enabled key set to true. Each service exports its own metrics and is typically scraped by a Prometheus installation to gather the metrics. Anchore does not aggregate or distribute metrics between services. You should configure your Prometheus deployment or integration to check each Anchore service’s api (using the same port it exports), for the /metrics route. For more information, see [Anchore Enterprise Monitoring](https://docs.anchore.com/current/docs/monitoring/#monitoring-in-kubernetes-andor-helm-chart) and [metrics.md](./metrics.md).
+Anchore Engine and Enterprise expose prometheus metrics in the API of each service if the config.yaml used by that service has the metrics.enabled key set to true. Each service exports its own metrics and is typically scraped by a Prometheus installation to gather the metrics. Anchore does not aggregate or distribute metrics between services. You should configure your Prometheus deployment or integration to check each Anchore service’s api (using the same port it exports), for the /metrics route. For more information, see [Anchore Enterprise Monitoring](https://docs.anchore.com/current/docs/monitoring/#monitoring-in-kubernetes-andor-helm-chart).
 
 The Big Bang Anchore Helm chart has been modified to use your `monitoring:` values in Big Bang to automatically toggle metrics on/off.
 
diff --git a/charter/packages/kiali/Architecture.md b/charter/packages/kiali/Architecture.md
index 57b9c2c73d240b24edb309c925b6cd546cc0d78d..e8e9c197089fd0e18943be6828732c2bbb21c1f5 100644
--- a/charter/packages/kiali/Architecture.md
+++ b/charter/packages/kiali/Architecture.md
@@ -119,7 +119,7 @@ kiali:
 
 ## Single Sign on (SSO)
 
-SSO for Kiali is done via [built in OIDC](https://kiali.io/documentation/latest/configuration/authentication/openid/). Big Bang abstracts and simplifies the settings required for SSO setup. The following values can be used to configure SSO for Kiali:
+SSO for Kiali is done via [built in OIDC](https://kiali.io/docs/configuration/authentication/openid/). Big Bang abstracts and simplifies the settings required for SSO setup. The following values can be used to configure SSO for Kiali:
 
 ```yaml
 kiali:
@@ -134,16 +134,16 @@ sso:
     realm: baby-yoda
 ```
 
-If you require a more advanced SSO configuration there are additional ways to customize that are detailed in the [upstream OIDC docs](https://kiali.io/documentation/latest/configuration/authentication/openid/). This doc includes details on how to configure username, scope, timeout, proxies, and more. It also lists some [SSO provider specifics](https://kiali.io/documentation/latest/configuration/authentication/openid/#_provider_specific_instructions) which may be needed for configuring with different providers. If you want to provide any further configuration than what is included in the `kiali.sso` block, you can override the BB pre-configured SSO and pass values via `kiali.values.cr.spec.auth`.
+If you require a more advanced SSO configuration there are additional ways to customize that are detailed in the [upstream OIDC docs](https://kiali.io/docs/configuration/authentication/openid/). This doc includes details on how to configure username, scope, timeout, proxies, and more. It also lists some [SSO provider specifics](https://kiali.io/docs/configuration/authentication/openid/#_provider_specific_instructions) which may be needed for configuring with different providers. If you want to provide any further configuration than what is included in the `kiali.sso` block, you can override the BB pre-configured SSO and pass values via `kiali.values.cr.spec.auth`.
 
 ## Non-SSO Login
 
-If you do not configure Kiali with SSO you will have [4 options](https://kiali.io/documentation/latest/configuration/authentication/) for authentication. Big Bang will default to using the token method.
+If you do not configure Kiali with SSO you will have [4 options](https://kiali.io/docs/configuration/authentication/) for authentication. Big Bang will default to using the token method.
 
-- Token: Uses the Kubernetes service account token for authentication. This method makes use of your cluster's RBAC and you can create additional service accounts/tokens to restrict access. In general Kiali gives the same access as whatever is granted to the token used for login (additional [details provided upstream](https://kiali.io/documentation/latest/configuration/rbac/)).
+- Token: Uses the Kubernetes service account token for authentication. This method makes use of your cluster's RBAC and you can create additional service accounts/tokens to restrict access. In general Kiali gives the same access as whatever is granted to the token used for login (additional [details provided upstream](https://kiali.io/docs/configuration/rbac/)).
   - To get the default Kiali SA token for login: `kubectl get secret -n kiali | grep kiali-service-account-token | awk '{print $1}' | xargs kubectl get secret -n kiali -o go-template='{{.data.token | base64decode}}'`
-- OpenShift: This method will redirect users to the OpenShift console login page for authentication (and is only available for use on OpenShift). Details and setup can be seen in the [upstream docs](https://kiali.io/documentation/latest/configuration/authentication/openshift/).
-- Header: Requires use of reverse proxy to inject token into the header of the request. More details and considerations are noted [upstream](https://kiali.io/documentation/latest/configuration/authentication/header/).
+- OpenShift: This method will redirect users to the OpenShift console login page for authentication (and is only available for use on OpenShift). Details and setup can be seen in the [upstream docs](https://kiali.io/docs/configuration/authentication/openshift/).
+- Header: Requires use of reverse proxy to inject token into the header of the request. More details and considerations are noted [upstream](https://kiali.io/docs/configuration/authentication/header/).
 - Anonymous: No authentication, Kiali is open to whoever can access the URL.
 
 Example of how to override the authentication method:
diff --git a/charter/packages/twistlock/Architecture.md b/charter/packages/twistlock/Architecture.md
index a243a07f1140f56ffe16963aab3d942b22c06e82..9710a104036ef1b8200c7055cad05c6daf4ab1c5 100644
--- a/charter/packages/twistlock/Architecture.md
+++ b/charter/packages/twistlock/Architecture.md
@@ -4,10 +4,6 @@
 
 [Twistlock Administration Guide](https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-04/prisma-cloud-compute-edition-admin/welcome/getting_started.html)
 
-## Contents
-
-[Developer Guide](docs/developer-guide.md)
-
 ## Big Bang Touch Points
 
 ```mermaid
diff --git a/docs/airgap/README.md b/docs/airgap/README.md
index 2f9bf5dbdc59d7808ec316a2186aff256ed0d0d4..737eeb93fe217870bf038dc76831b4472815f176 100644
--- a/docs/airgap/README.md
+++ b/docs/airgap/README.md
@@ -338,7 +338,7 @@ kubectl create ns bigbang
 
 Installing Big Bang in an air gap environment currently uses the Helm charts from the **[Big Bang Repo](https://repo1.dso.mil/platform-one/big-bang/bigbang)**.
 
-All changes are modified in the custom [values.yaml](./examples/values.yaml) file. Modify as needed and replace IP.
+All changes are modified in the custom [values.yaml](./scripts/values.yaml) file. Modify as needed and replace IP.
 
 Change the hostname for the installation. It is currently set to the development domain:
 
diff --git a/docs/configuration.md b/docs/configuration.md
index 70635cf468ab37ccde9f8f57bdd0d0f53f6c62b9..bdd0df1428a9abb6ef57e1225f12a712ca1774b9 100644
--- a/docs/configuration.md
+++ b/docs/configuration.md
@@ -38,7 +38,7 @@ In all four cases, Big Bang reads a single key named `values.yaml` that contains
 Before configuring Big Bang, it is expected that you have already setup:
 
 - A Kubernetes cluster
-- A [SOPS key pair](3_encryption.md)
+- A [SOPS key pair](encryption.md)
 - A Git repository to hold your configuration
   - Pull credentials for the Git repository (if not public)
 - An Iron Bank robot account for production, or a non-robot account for testing. Reference [Iron Bank authentication](https://repo1.dso.mil/platform-one/big-bang/bigbang/-/blob/master/docs/b_troubleshooting.md#iron-bank-authentication) for additional details.
@@ -51,7 +51,7 @@ At a minimum, the following items must be configured for a default Big Bang depl
 - [Big Bang version](#big-bang-version)
 - [Environment Git repository](#environment-location)
 - [Hostname](#hostname)
-- [SOPS private key reference](3_encryption.md).
+- [SOPS private key reference](encryption.md).
 - [Registry pull credentials](#registry-pull-credentials)
 
 The Big Bang [Environment Template](https://repo1.dso.mil/platform-one/big-bang/customers/template) has placeholders for all of the above.
diff --git a/docs/deployment.md b/docs/deployment.md
index 416f553ed9f0bf9ad6e26bcf665ea08ca30746e5..06ffd229f5369fd88824a4b71a66f66f5af122d5 100644
--- a/docs/deployment.md
+++ b/docs/deployment.md
@@ -46,13 +46,13 @@ Big Bang follows a [GitOps](https://www.weave.works/blog/what-is-gitops-really)
 
 All changes to the Big Bang cluster should be made through Git.  After changes are pushed, Big Bang will automatically reconcile the difference with the cluster.
 
-> It may take Big Bang up to 10 minutes to recognize your changes and start to deploy them.  This is based on the `interval` value set for polling.  You can force Big Bang to immediately check for changes by running the [sync.sh](../hack/sync.sh) script.
+> It may take Big Bang up to 10 minutes to recognize your changes and start to deploy them.  This is based on the `interval` value set for polling.  You can force Big Bang to immediately check for changes by running the [sync.sh](../scripts/sync.sh) script.
 
 Changes to values can be tested in each environment using the named folders to override values and/or point to specific repo branches or tags.  After testing, the changes can be placed into the `./base` folder if the change is shared between all environments.
 
 ## Monitor
 
-The following commands will help you monitor the progress of the Big Bang deployment.  Review the [flowchart](./1_overview.md#Diagram), if needed, to understand the progression.  Use the [Troubleshooting Guide](./b_troubleshooting.md) if you have failures.
+The following commands will help you monitor the progress of the Big Bang deployment.  Review the [flowchart](./overview.md#Diagram), if needed, to understand the progression.  Use the [Troubleshooting Guide](./troubleshooting.md) if you have failures.
 
 1. Verify Flux is running
 
diff --git a/docs/developer/package-integration/package-integration-database.md b/docs/developer/package-integration/package-integration-database.md
index 41cd6100df8787e74a2c84c4d0dfa74433150dd5..c9174c21004fccd1902c9b654afcdc409d47809a 100644
--- a/docs/developer/package-integration/package-integration-database.md
+++ b/docs/developer/package-integration/package-integration-database.md
@@ -115,7 +115,7 @@ Example: [Mattermost](https://repo1.dso.mil/platform-one/big-bang/bigbang/-/blob
 
 ## Validation
 
-For validating connection to the external database in your environment or testing in CI pipeline you will need to add the database specific values to your overrides file or `tests/ci/k3d/values.yaml` respectively.
+For validating connection to the external database in your environment or testing in CI pipeline you will need to add the database specific values to your overrides file or `./tests/test-values.yaml` respectively.
 
 Mattermost Example:
 
diff --git a/docs/developer/package-integration/package-integration-documentation.md b/docs/developer/package-integration/package-integration-documentation.md
index 75241dba646f413572837d8d9fe6bb946d55672a..6a4217a39716d495389180008ba6d8126b11c0c6 100644
--- a/docs/developer/package-integration/package-integration-documentation.md
+++ b/docs/developer/package-integration/package-integration-documentation.md
@@ -2,8 +2,8 @@
 
 Big Bang requires some additional documentation for supported packages to help user's understand how it interacts with other components.  The following are documents that should be created or updated for integration into Big Bang:
 
-- Package Architecture: See [Big Bang's Architecture instructions](../../charter/packages/ref-package/Architecture.md).  Examples are included in [charter/packages](../../charter/packages)
-- [Big Bang Packages](../../charter/BigBangPackages.md)
-- [Default Credentials](../guides/using_bigbang/default_credentials.md)
-- [Licensing](../understanding_bigbang/licensing_expectations.md)
-- [Minimum Hardware Requirements](../guides/prerequisites/minimum_hardware_requirements.md)
+- Package Architecture: See [Big Bang's Architecture instructions](../../../charter/packages/ref-package/Architecture.md).  Examples are included in [charter/packages](../../../charter/packages)
+- [Big Bang Packages](../../../charter/BigBangPackages.md)
+- [Default Credentials](../../guides/using_bigbang/default_credentials.md)
+- [Licensing](../../understanding_bigbang/licensing_expectations.md)
+- [Minimum Hardware Requirements](../../guides/prerequisites/minimum_hardware_requirements.md)
diff --git a/docs/developer/package-integration/package-integration-supported.md b/docs/developer/package-integration/package-integration-supported.md
index d5b127af64ee7b06a193488f1816a2899729e0fe..d7fc30a8f2e10c4628408496e6bfeb55f1684df9 100644
--- a/docs/developer/package-integration/package-integration-supported.md
+++ b/docs/developer/package-integration/package-integration-supported.md
@@ -84,11 +84,11 @@
        values: {}
    ```
 
-1. Edit tests/ci/k3d/values.yaml. These are the settings that the CI pipeline uses to run a deployment test.  Set your Package to be enabled and add any other necessary values. Where possible reduce the number of replicas to a minimum to reduce strain on the CI infrastructure. When you commit your code the pipeline will run. You can view the pipeline in the Repo1 Gitlab console. Fix any errors in the pipeline output. The pipeline automatically runs a "smoke" test. It deploys bigbang on a k3d cluster using the test values file.
+1. Edit `./tests/test-values.yaml`. These are the settings that the CI pipeline uses to run a deployment test.  Set your Package to be enabled and add any other necessary values. Where possible reduce the number of replicas to a minimum to reduce strain on the CI infrastructure. When you commit your code the pipeline will run. You can view the pipeline in the Repo1 Gitlab console. Fix any errors in the pipeline output. The pipeline automatically runs a "smoke" test. It deploys bigbang on a k3d cluster using the test values file.
 
 1. Add your packages name to the ORDERED_HELMRELEASES list in scripts/deploy/02_wait_for_helmreleases.sh.
 
-1. Create an overrrides directory as a sibling directory next to the bigbang code directory. Put your override yaml files in this directory. The reason we do this is to avoid modifying the bigbang values.yaml that is under source control. You could accidentally commit it with your secrets. Avoid that mistake and create a local overrides directory. One option is to copy the tests/ci/k3d/values.yaml to make the override-values.yaml and make modifications. The file structure is like this:
+1. Create an overrrides directory as a sibling directory next to the bigbang code directory. Put your override yaml files in this directory. The reason we do this is to avoid modifying the bigbang values.yaml that is under source control. You could accidentally commit it with your secrets. Avoid that mistake and create a local overrides directory. One option is to copy the `./tests/test-values.yaml` to make the override-values.yaml and make modifications. The file structure is like this:
     ```text
     ├── bigbang/
     └── overrides/
@@ -151,7 +151,7 @@ helm delete bigbang -n bigbang
 # Helm delete will not delete the bigbang namespace
 kubectl delete ns bigbang
 # Istio namespace will be stuck in "finalizing". So run the script to delete it.
-hack/remove-ns-finalizer.sh istio-system
+./script/remove-ns-finalizer.sh istio-system
 ```
 
 ### GitOps with Flux
@@ -171,15 +171,15 @@ watch kubectl get pod,helmrelease -A
 # Tear down
 kubectl delete -f dev/bigbang.yaml
 # Istio namespace will be stuck in "finalizing". So run the script to delete it. You will need 'jq' installed
-hack/remove-ns-finalizer.sh istio-system
+./scripts/remove-ns-finalizer.sh istio-system
 
 # If you have pushed code changes before the tear down, occasionally the bigbang deployments are not terminated because Flux has not had enough time to reconcile the helmreleases
 
 # Re-deploy bigbang
 kubectl apply -f dev/bigbang.yaml
 # Run the sync script.
-hack/sync.sh
+./scripts/sync.sh
 # Tear down
 kubectl delete -f dev/bigbang.yaml
-hack/remove-ns-finalizer.sh istio-system
+./scripts/remove-ns-finalizer.sh istio-system
 ```
diff --git a/docs/encryption.md b/docs/encryption.md
index c3f8857d4b4d2a74a49e38b46550c9f72efda82d..4f9e6fb75d178912800d2934c38c649d504c93b3 100644
--- a/docs/encryption.md
+++ b/docs/encryption.md
@@ -5,7 +5,6 @@ Table of Contents
 - [Big Bang Encryption](#big-bang-encryption)
   - [SOPS](#sops)
   - [Create Encryption Keys](#create-encryption-keys)
-    - [Samples](#samples)
   - [Configure SOPS](#configure-sops)
   - [Deploy Private Key](#deploy-private-key)
     - [GPG](#gpg)
@@ -39,23 +38,6 @@ To setup Big Bang with SOPS, a key pair must be created.  The private key is use
 
 > *GPG is not recommended for production use because the private key can be misplaced or compromised too easily
 
-### Samples
-
-If you plan to utilize Big Bang provided samples, either in the template or in this repository, setup the following:
-
-1. Install [gpg](https://gnupg.org/download/)
-1. Import the [Big Bang development key](../hack/bigbang-dev.asc)
-   > Do **NOT** use this key for any deployment.  It is only for demonstration purposes.
-
-   ```bash
-   gpg --import <private key>
-   ```
-
-1. Validate by decrypting and opening a sample file for editing
-
-   ```bash
-   sops <filename.enc.yaml>
-   ```
 
 ## Configure SOPS
 
@@ -88,7 +70,7 @@ SOPS uses `.sops.yaml` as a configuration file for which keys to use for newly c
 1. Deploy your SOPS private key to a secret named `sops-gpg` in the cluster
 
    ```bash
-   gpg --export-secret-keys --armor <new key fingerprint> | kubectl create secret generic sops-gpg -n bigbang --from-file=bigbangkey.asc=/dev/stdin
+   gpg --export-secret-keys --armor <new key fingerprint> | kubectl create secret generic sops-gpg -n bigbang --from-file=yourkey.asc=/dev/stdin
    ```
 
 ### AWS KMS
diff --git a/docs/example_configs/dev-sso-values.yaml b/docs/example_configs/dev-sso-values.yaml
index 1edc1a1927d532ad0d4b755756680cbd1399ba39..e382676cd07a42b0020ee17dc63c2159df29581b 100644
--- a/docs/example_configs/dev-sso-values.yaml
+++ b/docs/example_configs/dev-sso-values.yaml
@@ -106,7 +106,7 @@ sso:
     -----END CERTIFICATE-----
 
   # # LetsEncrypt certificate authority for keycloak.bigbang.dev
-  # # Use this CA if you deployed Keycloak with *.bigbang.dev certificate using chart/keycloak-dev-values.yaml
+  # # Use this CA if you deployed Keycloak with *.bigbang.dev certificate using ./docs/example_configs/keycloak-dev-values.yaml
   # certificate_authority: |
   #   -----BEGIN CERTIFICATE-----
   #   MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw
diff --git a/docs/guides/deployment_scenarios/sso_quickstart.md b/docs/guides/deployment_scenarios/sso_quickstart.md
index 5a89b15053dc7fd0a5cb74d0076371fad8adcf1a..a2ef8051ab7b48e6ee6fe281357b9c897beeb9ac 100644
--- a/docs/guides/deployment_scenarios/sso_quickstart.md
+++ b/docs/guides/deployment_scenarios/sso_quickstart.md
@@ -418,7 +418,7 @@ EOF
 
 helm upgrade --install bigbang \$HOME/bigbang/chart \
   --values https://repo1.dso.mil/platform-one/big-bang/bigbang/-/raw/master/chart/ingress-certs.yaml \
-  --values \$HOME/bigbang/chart/dev-k3d-values.yaml \
+  --values \$HOME/bigbang/docs/example_configs/opa-overrides-k3d.yaml \
   --values \$HOME/ib_creds.yaml \
   --values \$HOME/demo_values.yaml \
   --namespace=bigbang --create-namespace
@@ -485,7 +485,7 @@ twistlock:
 EOF
 
 helm upgrade --install bigbang \$HOME/bigbang/chart \
-  --values \$HOME/bigbang/chart/keycloak-dev-values.yaml \
+  --values \$HOME/bigbang/docs/example_configs/keycloak-dev-values.yaml \
   --values \$HOME/ib_creds.yaml \
   --values \$HOME/keycloak_qs_demo_values.yaml \
   --namespace=bigbang --create-namespace
@@ -699,7 +699,7 @@ EOF
 
 helm upgrade --install bigbang \$HOME/bigbang/chart \
   --values https://repo1.dso.mil/platform-one/big-bang/bigbang/-/raw/master/chart/ingress-certs.yaml \
-  --values \$HOME/bigbang/chart/dev-k3d-values.yaml \
+  --values \$HOME/bigbang/docs/example_configs/opa-overrides-k3d.yaml \
   --values \$HOME/ib_creds.yaml \
   --values \$HOME/demo_values.yaml \
   --values \$HOME/auth_service_demo_values.yaml \
diff --git a/docs/overview.md b/docs/overview.md
index 9ba4bc8d142eac2f566de278b4a71fd2f394d2c0..8a650f1e6892409987f68704fdcbe36985698eb6 100644
--- a/docs/overview.md
+++ b/docs/overview.md
@@ -79,14 +79,14 @@ The diagram below shows a typical deployment of Big Bang into a Kubernetes clust
 
 ### Configuration
 
-1. The user must [setup an encryption key pair](./3_encryption.md) for SOPS and store the private key securely (e.g. KMS).  This should **NOT** be stored in Git.
-1. The user should then [configure Big Bang](./4_configuration.md) values and secrets for the targeted Kubernetes cluster.
+1. The user must [setup an encryption key pair](./encryption.md) for SOPS and store the private key securely (e.g. KMS).  This should **NOT** be stored in Git.
+1. The user should then [configure Big Bang](./configuration.md) values and secrets for the targeted Kubernetes cluster.
 1. All secrets should be encrypted with SOPS to protect them.
 1. Once all of the configuration has been completed, it must be pushed to a Git repository.
 
 ### Deployment
 
-1. With everything in Git, the user can [deploy BigBang](./5_deployment.md) using a Kubernetes manifest.
+1. With everything in Git, the user can [deploy BigBang](./deployment.md) using a Kubernetes manifest.
 1. The manifest holds two Flux resources, one pointing to the Git repository holding the custom environment, and one telling Flux to run Kustomize on a targeted folder within the repo.
    1. The repository is reconciled first, pulling the files from Git.
    1. Next, Kustomize is run on the environment configuration
diff --git a/docs/troubleshooting.md b/docs/troubleshooting.md
index d1cf04fda7dc7243fece0ea5bb513dede7d25bdc..7d222cd41e772a5459c023447889de818068a52b 100644
--- a/docs/troubleshooting.md
+++ b/docs/troubleshooting.md
@@ -9,7 +9,7 @@
   - [Kustomization](#kustomization)
   - [Packages](#packages)
 
-Big Bang can take a long time to run.  After making changes, it could take 10-15 minutes to take effect.  Use the [sync.sh](../hack/sync.sh) script to speed this up.
+Big Bang can take a long time to run.  After making changes, it could take 10-15 minutes to take effect.  Use the [sync.sh](../scripts/sync.sh) script to speed this up.
 
 Big Bang is configured to retry failed package installations and upgrades.  Before concluding you have a failure, make sure you allow Big Bang to attempt to resolve dependencies and retry.
 
@@ -34,7 +34,7 @@ kubectl get events -n flux-system
 | Symptom | Cause | Resolution |
 |--|--|--|
 | Install script timed and pods are still pulling the image | Slow connection to docker registry | Adjust `--timeout` value in `flux install` to wait longer |
-| Pod status is `ImagePullBackOff` or `ErrImagePull` | Bad registry, version, or credentials | Fix the `--registry`, `--version`, or `--image-pull secret` options or use the `hack/flux-install.sh` script for pulling from Iron Bank |
+| Pod status is `ImagePullBackOff` or `ErrImagePull` | Bad registry, version, or credentials | Fix the `--registry`, `--version`, or `--image-pull secret` options or use the `./scripts/install_flux.sh` script for pulling from Iron Bank |
 
 ## Git Repository