Fixed typing errors and doc enhancement (#521)

* Update README.md

* Update get-started.md

* Update next-steps.md

* Update use-cases.md

* Update versus.md

README.md

@@ -18,7 +18,7 @@
 
 KitOps is a packaging and versioning system for AI/ML projects that uses open standards so it works with the AI/ML, development, and DevOps tools you are already using, and can be stored in your enterprise registry.
 
-KitOps makes it easy for organizations to track, control, and audit access and changes to their AI project artifacts. It simplifies the handoffs between data scientists, application developers, and SREs working with LLMs and other AI/ML models. KitOps' ModelKits are an OCI-compliant package for models, their dependencies, configurations, codebases, features, hyperparmeters, and any other documentation. ModelKits are portable, reproducible, and work with the tools you already use.
+KitOps makes it easy for organizations to track, control, and audit access and changes to their AI project artifacts. It simplifies the handoffs between data scientists, application developers, and SREs working with LLMs and other AI/ML models. KitOps' ModelKits are an OCI-compliant package for models, their dependencies, configurations, codebases, features, hyperparameters, and any other documentation. ModelKits are portable, reproducible, and work with the tools you already use.
 
 Teams and enterprises use KitOps as a gate between development and production deployment. This ensures that projects are complete, versioned, and compatible with existing pipelines and tools. This makes deployments, rollbacks, and other production operations simpler and safer.
 
@@ -40,7 +40,7 @@ Get the most out of KitOps' ModelKits by using them with the **[Jozu Hub](https:
 * 🤖 **[Automation](https://github.com/marketplace/actions/setup-kit-cli):** Pack or unpack a ModelKit locally or as part of your CI/CD workflow for testing, integration, or deployment.
 * 🪛 **[LLM fine-tuning](https://dev.to/kitops/fine-tune-your-first-large-language-model-llm-with-lora-llamacpp-and-kitops-in-5-easy-steps-1g7f):** Use KitOps to fine-tune a large language model using LoRA.
 * 🎯 **[RAG pipelines](https://www.codeproject.com/Articles/5384392/A-Step-by-Step-Guide-to-Building-and-Distributing):** Create a RAG pipeline for tailoring an LLM with KitOps.
-* 🔒 **[Tamper-proofing](https://kitops.ml/docs/modelkit/spec.html):** Each ModelKit package includes a SHA digest for itself, and every artifact it holds.
+* 🔒 **[Tamper-proofing](https://kitops.ml/docs/modelkit/spec.html):** Each ModelKit package includes an SHA digest for itself, and every artifact it holds.
 * 📝 **[Artifact signing](https://kitops.ml/docs/next-steps.html):** ModelKits and their assets can be signed so you can be confident of their provenance.
 * 🌈 **[Standards-based](https://kitops.ml/docs/modelkit/compatibility.html):** Store ModelKits in any OCI 1.1-compliant container or artifact registry.
 * 🥧 **[Simple syntax](https://kitops.ml/docs/kitfile/kf-overview.html):** Kitfiles are easy to write and read, using a familiar YAML syntax.
@@ -66,7 +66,7 @@ There's a video of KitOps in action on the [KitOps site](https://kitops.ml/).
 
 1. [Install the CLI](https://kitops.ml/docs/cli/installation.html) for your platform.
 2. Follow the [Getting Started](https://kitops.ml/docs/get-started.html) docs to learn to pack, unpack, and share a ModelKit.
-3. Test drive one of our [ModelKit Quick Starts](https://jozu.ml/organization/jozu-quickstarts) that include everything thing you need to run your model including a codebase, dataset, documentation, and of course the model.
+3. Test drive one of our [ModelKit Quick Starts](https://jozu.ml/organization/jozu-quickstarts) that includes everything thing you need to run your model including a codebase, dataset, documentation, and of course the model.
 
 - [Meta LLama 3.1](https://jozu.ml/repository/jozu/llama3.1-8b)
 - [Google Gemma](https://jozu.ml/repository/jozu/gemma-7b)

docs/src/docs/get-started.md

@@ -28,7 +28,7 @@ You'll see information about the version of Kit you're running. If you get an er
 
 ### 2/ Login to Your Registry
 
-You can use the [login command](./cli/cli-reference.md#kit-login) to authenticate with any OCI v1.1-compatible container registry - local or remote (you can see our [list of compliant registries](./modelkit/compatibility.md)). In this guide we'll use the [Jozu Hub](https://jozu.ml/) because it's free to sign-up and provides more detail on what's inside each ModelKit like whether it's signed or has provenance. You can substitute your own repository if preferred.
+You can use the [login command](./cli/cli-reference.md#kit-login) to authenticate with any OCI v1.1-compatible container registry - local or remote (you can see our [list of compliant registries](./modelkit/compatibility.md)). In this guide, we'll use the [Jozu Hub](https://jozu.ml/) because it's free to sign-up and provides more detail on what's inside each ModelKit like whether it's signed or has provenance. You can substitute your own repository if preferred.
 
 ```sh
 kit login jozu.ml
@@ -38,7 +38,7 @@ After entering your username and password, you'll see `Log in successful`. If yo
 
 ### 3/ Get a Sample ModelKit
 
-Let's use the [unpack command](./cli/cli-reference.md#kit-unpack) to pull a [sample ModelKit from Jozu Hub](https://jozu.ml/browse) to our machine that we can play with. In this case we'll unpack the whole thing, but one of the great things about Kit is that you can also selectively unpack only the artifacts you need: just the model, the model and dataset, the code, the configuration...whatever you want. Check out the `unpack` [command reference](./cli/cli-reference.md#kit-unpack) for details.
+Let's use the [unpack command](./cli/cli-reference.md#kit-unpack) to pull a [sample ModelKit from Jozu Hub](https://jozu.ml/browse) to our machine that we can play with. In this case, we'll unpack the whole thing, but one of the great things about Kit is that you can also selectively unpack only the artifacts you need: just the model, the model and dataset, the code, the configuration...whatever you want. Check out the `unpack` [command reference](./cli/cli-reference.md#kit-unpack) for details.
 
 You can grab <a href="https://jozu.ml/discover"
   v-ga-track="{
@@ -80,9 +80,9 @@ You'll see the column headings for an empty table with things like `REPOSITORY`,
 
 ### 5/ Pack the ModelKit
 
-Since our repository is empty we'll need use the [pack command](./cli/cli-reference.md#kit-pack) to create our ModelKit. The ModelKit in your local registry will need to be named the same as your remote registry. The command will look like: `kit pack . -t [your registry address]/[your registry user or organization name]/[your repository name]:[your tag name]`
+Since our repository is empty we'll need to use the [pack command](./cli/cli-reference.md#kit-pack) to create our ModelKit. The ModelKit in your local registry will need to be named the same as your remote registry. The command will look like: `kit pack . -t [your registry address]/[your registry user or organization name]/[your repository name]:[your tag name]`
 
-In our case we are pushing a ModelKit tagged `latest` to:
+In our case, we are pushing a ModelKit tagged `latest` to:
 * The [Jozu Hub](https://jozu.ml/) registry
 * The `brad` user organization
 * The `quick-start` repository

docs/src/docs/next-steps.md

@@ -131,7 +131,7 @@ kit pack . -f /path/to/your/Kitfile -t film-slm:champion
 
 ### Pushing to a Remote Registry
 
-In each case this will pack a ModelKit and store it in your local registry. To push it to a remote registry for sharing with others, there are two steps:
+In each case, this will pack a ModelKit and store it in your local registry. To push it to a remote registry for sharing with others, there are two steps:
 
 1. Tagging the local copy with the remote registry's name
 1. Pushing the remote-named copy from your local to the remote registry

docs/src/docs/use-cases.md

@@ -35,7 +35,7 @@ This guarantees that models used by internal teams are safe and tamper-proof. By
 
 ### Protecting Production 🚦
 
-After model development has completed, the resulting ModelKit and its artifacts can again by scanned by something like ModelScan and only allowed to move forward if it passes. Using ModelKits here again ensures that a model that passes the scan is packaged and signed so that it cannot be tampered with on its way to production.
+After model development has been completed, the resulting ModelKit and its artifacts can again by scanned by something like ModelScan and only allowed to move forward if it passes. Using ModelKits here again ensures that a model that passes the scan is packaged and signed so that it cannot be tampered with on its way to production.
 
 Even with this level of scrutiny, however, there remain some risks since the varying repositories and versioning of artifacts during development can invite accidental or malicious tampering. This leads us to Level 3 adoption...
 
@@ -118,7 +118,7 @@ kit push registry.gitlab.com/chatbot/legalchat:challenger
 
 Adding the `challenger` tag to a ModelKit was a trigger in our team for the DevOps group to know that it was ready to deploy to production. They would take the serialized model from the ModelKit and ready it for deployment via our pipelines. This may mean putting the model into a container, but it may mean using an init container, a sidecar, entrypoint, or post-start hooks.
 
-Once the model was deployed and validated in production the ModelKit for the model that was previously tagged `champion` would be retagged to `rollback`, and the ModelKit for the `challenger` would be retagged to `champion`. These changes were part of our deployment automation and ensured that we were always ready to quickly redeploy the `rollback` model in case something catastrophic happened in production withe current `champion`.
+Once the model was deployed and validated in production the ModelKit for the model that was previously tagged `champion` would be retagged to `rollback`, and the ModelKit for the `challenger` would be retagged to `champion`. These changes were part of our deployment automation and ensured that we were always ready to quickly redeploy the `rollback` model in case something catastrophic happened in production with the current `champion`.
 
 ```shell
 kit tag registry.gitlab.com/chatbot/legalchat:champion registry.gitlab.com/chatbot/legalchat:rollback
@@ -130,4 +130,4 @@ kit tag registry.gitlab.com/chatbot/legalchat:challenger registry.gitlab.com/cha
 kit push registry.gitlab.com/chatbot/legalchat:champion
 ```
 
-If you use KitOps differently and want to share it go ahead - we'd love to hear about it!
+If you use KitOps differently and want to share it go ahead - we'd love to hear about it!

docs/src/docs/versus.md

@@ -75,7 +75,7 @@ Git is excellent at managing software projects that consist of a large number of
 
 #### ModelKits & Git
 
-Code related to model development is often easier to store in ModelKits where it is always in-sync with the Jupyter Notebook, serialized model, and datasets used during development. Larger codebases and code related to application integrations is best kept in git, but is often helpful to also package into the ModelKit ([a codebase can be stored in a ModelKit](./kitfile/format.html#code) so that anyone can see the state of the code at the point that the project's ModelKit was versioned).
+Code related to model development is often easier to store in ModelKits where it is always in-sync with the Jupyter Notebook, serialized model, and datasets used during development. Larger codebases and code related to application integrations are best kept in git, but is often helpful to also package into the ModelKit ([a codebase can be stored in a ModelKit](./kitfile/format.html#code) so that anyone can see the state of the code at the point that the project's ModelKit was versioned).
 
 ### Dataset Storage
 
@@ -85,4 +85,4 @@ It's easy to end up with near-duplicate datasets in different locations, making
 
 #### ModelKits & Dataset Storage
 
-Keeping datasets in versioned ModelKits ensures that it's always clear which data and state, was used with a specific version of the model. It avoids the risk of accidental data contamination and ensures you can always trace the [model/data lineage](./modelkit/spec.md#terminology-and-structure). A library of ModelKits for an AI project acts as a kind of audit record, allowing you to diff package contents to see when something changed and who made the change.
+Keeping datasets in versioned ModelKits ensures that it's always clear which data and state, was used with a specific version of the model. It avoids the risk of accidental data contamination and ensures you can always trace the [model/data lineage](./modelkit/spec.md#terminology-and-structure). A library of ModelKits for an AI project acts as a kind of audit record, allowing you to diff package contents to see when something changed and who made the change.