formatting, capitalization, etc

docs/airgapped-docs/prereqs.md

@@ -13,4 +13,4 @@ This means you have:
 - the carbide helm charts available for use
 - configured k3s/rke2 to use your registry
 - configured Rancher Manager to use your registry
-- setup policy enforcement to only allow images from the CSR to run
+- setup policy enforcement to only allow images from the CSR

docs/registry-docs/copying-images.md

@@ -1,6 +1,6 @@
 # Copying Images to a Registry
 
-This page will walk you through copying our secured images into your own registry for later use.
+This page will walk you through hauling our secured images into your own registry for later use.
 
 If you're hauling images into an airgapped registry, check the documentation [here](downloading-images.md).
 

docs/registry-docs/introduction.md

@@ -7,7 +7,7 @@ As our product is still in the IOC phase, there are some expectations to level-s
 
 * IOC users can expect tooling and processes to be changed, improved and streamlined continuously as we strive to improve the Carbide offering.
 
-**DISCLAIMER**:  The Secured Registry (rgcrprod.azurecr.us) is _not_ intended to be used as the primary registry for running Kubernetes clusters. It is only intended as the acquisition point to obtain the Carbide secured images. Customers should seed their own private OCI registries, and use that registry for their Kubernetes clusters.
+> **DISCLAIMER**:  The Secured Registry (rgcrprod.azurecr.us) is _not_ intended to be used as the primary registry for running Kubernetes clusters. It is only intended as the acquisition point to obtain the Carbide secured images. Customers should seed their own private OCI registries, and use that registry for their Kubernetes clusters.
 
 If you see issues and areas for improvement, please submit Github issues [here](https://github.com/rancherfederal/carbide-docs/issues).
 
@@ -31,4 +31,4 @@ The Carbide Secured Registry (CSR)  was designed from the ground up to build the
 
 If we follow the SLSA level requirements using the enhancements introduced with Carbide Secured Registry (CSR), it currently puts us firmly at a SLSA level 2 (up from SLSA 0).  However, the astute readers will recognize that with the current verbatim implementation of SLSA levels, level 3 and 4 are currently unobtainable due to requirements such as "accredited build platforms".
 
-As stated earlier, the foundation for ultimately achieving SLSA 4 have been put in place to allow us to mature alongside software supply chain best practices, and standards. On that note, it's important to recognize that Carbide Secured Registry (CSR) is an ever evolving set of capabilities. Just as the standards and best practices around software supply chain security evolve, so will Carbide Secured Registry (CSR).
+As stated earlier, the foundation for ultimately achieving SLSA 4 have been put in place to allow us to mature alongside software supply chain best practices, and standards. On that note, it's important to recognize that Carbide Secured Registry (CSR) is an ever evolving set of capabilities. Just as the standards and best practices around software supply chain security evolve, so will Carbide Secured Registry (CSR).

docs/registry-docs/prereqs.md

@@ -6,15 +6,15 @@ Below are all the things you need to get started with the Hardened Container Reg
 
 ## Required Tooling
 
-**Packaging/Airgapping: [hauler](https://hauler.dev)**
+**Packaging/Airgapping: [Hauler](https://hauler.dev)**
 ```bash
 # example installation steps
 # please see the docs: https://rancherfederal.github.io/hauler-docs/docs/introduction/install
 
 curl -sfL https://get.hauler.dev | bash
 ```
 
-**Supply Chain Verification: [cosign](https://docs.sigstore.dev)**
+**Supply Chain Verification: [Cosign](https://docs.sigstore.dev)**
 ```bash
 # example installation steps
 # please see the docs: https://docs.sigstore.dev/system_config/installation
@@ -24,7 +24,7 @@ sudo mv cosign-linux-amd64 /usr/local/bin/cosign
 sudo chmod 755 /usr/local/bin/cosign
 ```
 
-**K8s Package Management: [helm](https://helm.sh/docs)**
+**K8s Package Management: [Helm](https://helm.sh/docs)**
 ```bash
 # example installation steps
 # please see the docs: https://helm.sh/docs/intro/install
@@ -52,6 +52,6 @@ tCAZva7CLlk/6gxvCM0QkIKznfaGTRMMYTaHMdQSau6yulDLlpokA++i8Q==
 ## Setup
 
 ```bash
-# authenticate into carbide secured registry
+# log in to carbide secured registry
 hauler login -u <redacted> -p <redacted> rgcrprod.azurecr.us
 ```

docs/registry-docs/validating-images.md

@@ -6,7 +6,7 @@ This will guide you through validating the signatures and attestations of each i
 
 Before pulling images or even after images have been pushed to a registry, you should always verify those images against the carbide public key. Below are the instructions for using `cosign` directly from a registry.
 
-**NOTE:** You'll need to substitute `rgcrprod.azurecr.us` with your own registry domain, if verifying images in your own registry.
+> **NOTE:** You'll need to substitute `rgcrprod.azurecr.us` with your own registry domain, if verifying images in your own registry.
 
 In Carbide Images v2 (or Cosign v2), the attachment of supply chain artifacts to the top layer of an image has been deprecated. In order for us to maintain interoperability, we have migrated our images and supply chain artifacts to be attached at the individual layer for a specific platform or architecture of an image.
 

docs/stigatron-docs/prereqs.md

@@ -14,4 +14,4 @@ This means you have:
 - the carbide helm charts available for use
 - configured k3s/rke2 to use your registry
 - configured Rancher Manager to use your registry
-- setup policy enforcement to only allow images from the CSR to run
+- setup policy enforcement to only allow images from the CSR