Fix broken links in docs

docs/examples/extracting_entities.ipynb

@@ -77,7 +77,7 @@
    "source": [
     "## Step 1: Create the RAIL Spec\n",
     "\n",
-    "Ordinarily, we would create an RAIL spec in a separate file. For the purposes of this example, we will create the spec in this notebook as a string following the RAIL syntax. For more information on RAIL, see the [RAIL documentation](/concepts/output.md).  We will also show the same RAIL spec in a code-first format using a Pydantic model.\n",
+    "Ordinarily, we would create an RAIL spec in a separate file. For the purposes of this example, we will create the spec in this notebook as a string following the RAIL syntax. For more information on RAIL, see the [RAIL documentation](/docs/how_to_guides/rail).  We will also show the same RAIL spec in a code-first format using a Pydantic model.\n",
     "\n",
     "Here, we request:\n",
     "\n",

docs/examples/guardrails_with_chat_models.ipynb

@@ -14,7 +14,7 @@
     "\n",
     "## Objective\n",
     "\n",
-    "We retry the [entity extraction example](./extracting_entities/pydantic) using a chat model.\n",
+    "We retry the [entity extraction example](./extracting_entities.ipynb) using a chat model.\n",
     "\n",
     "## Step 0: Download PDF and load it as string\n",
     "\n",

docs/examples/no_secrets_in_generated_text.ipynb

@@ -26,11 +26,11 @@
    "source": [
     "## Step 1: Create the RAIL Spec\n",
     "\n",
-    "Ordinarily, we would create an RAIL spec in a separate file. For the purposes of this example, we will create the spec in this notebook as a string following the RAIL syntax. For more information on RAIL, see the [RAIL documentation](/concepts/output.md).  We will also show the same RAIL spec in a code-first format using a Pydantic model.\n",
+    "Ordinarily, we would create an RAIL spec in a separate file. For the purposes of this example, we will create the spec in this notebook as a string following the RAIL syntax. For more information on RAIL, see the [RAIL documentation](/docs/how_to_guides/rail).  We will also show the same RAIL spec in a code-first format using a Pydantic model.\n",
     "\n",
     "In this RAIL spec, we:\n",
     "\n",
-    "1. Create a custom Validator that checks if a string has any secrets. This is a simple example, but you can use this to create more complex Validators. For more information on creating custom Validators, see the [Validators documentation](/concepts/validators.md).\n",
+    "1. Create a custom Validator that checks if a string has any secrets. This is a simple example, but you can use this to create more complex Validators. For more information on creating custom Validators, see the [Validators documentation](/docs/hub/how_to_guides/custom_validator).\n",
     "2. Create a `output` schema that returns an object with a `api_help` key."
    ]
   },

docs/examples/recipe_generation.ipynb

@@ -34,7 +34,7 @@
    "source": [
     "## Step 1: Create the RAIL Spec\n",
     "\n",
-    "Ordinarily, we would create an RAIL spec in a separate file. For the purposes of this example, we will create the spec in this notebook as a string following the RAIL syntax. For more information on RAIL, see the [RAIL documentation](/concepts/output.md).  We will also show the same RAIL spec in a code-first format using a Pydantic model."
+    "Ordinarily, we would create an RAIL spec in a separate file. For the purposes of this example, we will create the spec in this notebook as a string following the RAIL syntax. For more information on RAIL, see the [RAIL documentation](/docs/how_to_guides/rail).  We will also show the same RAIL spec in a code-first format using a Pydantic model."
    ]
   },
   {

docs/examples/syntax_error_free_sql.ipynb

@@ -48,7 +48,7 @@
    "source": [
     "## Step 1: Create the RAIL Spec\n",
     "\n",
-    "Ordinarily, we would create an RAIL spec in a separate file. For the purposes of this example, we will create the spec in this notebook as a string following the RAIL syntax. For more information on RAIL, see the [RAIL documentation](/concepts/output.md).  We will also show the same RAIL spec in a code-first format using a Pydantic model.\n",
+    "Ordinarily, we would create an RAIL spec in a separate file. For the purposes of this example, we will create the spec in this notebook as a string following the RAIL syntax. For more information on RAIL, see the [RAIL documentation](/docs/how_to_guides/rail).  We will also show the same RAIL spec in a code-first format using a Pydantic model.\n",
     "\n",
     "In this RAIL spec, we:\n",
     "\n",

docs/examples/text_summarization_quality.ipynb

@@ -45,7 +45,7 @@
    "source": [
     "## Step 1: Create the RAIL Spec\n",
     "\n",
-    "Ordinarily, we would create an RAIL spec in a separate file. For the purposes of this example, we will create the spec in this notebook as a string following the RAIL syntax. For more information on RAIL, see the [RAIL documentation](/concepts/output.md).  We will also show the same RAIL spec in a code-first format using a Pydantic model.\n",
+    "Ordinarily, we would create an RAIL spec in a separate file. For the purposes of this example, we will create the spec in this notebook as a string following the RAIL syntax. For more information on RAIL, see the [RAIL documentation](/docs/how_to_guides/rail).  We will also show the same RAIL spec in a code-first format using a Pydantic model.\n",
     "\n",
     "In this RAIL spec, we:\n",
     "\n",

docs/examples/translation_to_specific_language.ipynb

@@ -54,7 +54,7 @@
    "source": [
     "## Step 1: Create the RAIL Spec\n",
     "\n",
-    "Ordinarily, we would create an RAIL spec in a separate file. For the purposes of this example, we will create the spec in this notebook as a string following the RAIL syntax. For more information on RAIL, see the [RAIL documentation](/concepts/output.md).  We will also show the same RAIL spec in a code-first format using a Pydantic model.\n",
+    "Ordinarily, we would create an RAIL spec in a separate file. For the purposes of this example, we will create the spec in this notebook as a string following the RAIL syntax. For more information on RAIL, see the [RAIL documentation](/docs/how_to_guides/rail).  We will also show the same RAIL spec in a code-first format using a Pydantic model.\n",
     "\n",
     "In this RAIL spec, we:\n",
     "\n",

docs/examples/translation_with_quality_check.ipynb

@@ -45,7 +45,7 @@
    "source": [
     "## Step 1: Create the RAIL Spec / Pydantic model\n",
     "\n",
-    "Ordinarily, we would create an RAIL spec in a separate file. For the purposes of this example, we will create the spec in this notebook as a string following the RAIL syntax. For more information on RAIL, see the [RAIL documentation](../concepts/output.md). We will also show the same RAIL spec in a code-first format using a Pydantic model.\n",
+    "Ordinarily, we would create an RAIL spec in a separate file. For the purposes of this example, we will create the spec in this notebook as a string following the RAIL syntax. For more information on RAIL, see the [RAIL documentation](/docs/how_to_guides/rail). We will also show the same RAIL spec in a code-first format using a Pydantic model.\n",
     "\n",
     "In this RAIL spec, we:\n",
     "\n",

docs/examples/valid_chess_moves.ipynb

@@ -54,7 +54,7 @@
    "source": [
     "## Step 1: Create the RAIL Spec\n",
     "\n",
-    "Ordinarily, we would create an RAIL spec in a separate file. For the purposes of this example, we will create the spec in this notebook as a string following the RAIL syntax. For more information on RAIL, see the [RAIL documentation](/concepts/output.md).  We will also show the same RAIL spec in a code-first format using a Pydantic model."
+    "Ordinarily, we would create an RAIL spec in a separate file. For the purposes of this example, we will create the spec in this notebook as a string following the RAIL syntax. For more information on RAIL, see the [RAIL documentation](/docs/how_to_guides/rail).  We will also show the same RAIL spec in a code-first format using a Pydantic model."
    ]
   },
   {

docs/guardrails_ai/getting_started.ipynb

@@ -154,9 +154,9 @@
    "source": [
     "#### Specifying quality criteria\n",
     "\n",
-    "Next, we want to specify the quality criteria for the output to be valid and corrective actions to be taken if the output is invalid. We can do this by adding a `format` tag to each field in the output schema. Format tags can either be enforced by Guardrails, or they can only be suggetions to the LLM. You can see the list of validators enforced by Guardrails [here](../hub/api_reference_markdown/validators.md). Additionally, you can create your own custom validators, see examples here [1](../examples/no_secrets_in_generated_text), [2](../examples/recipe_generation), [3](../examples/valid_chess_moves).\n",
+    "Next, we want to specify the quality criteria for the output to be valid and corrective actions to be taken if the output is invalid. We can do this by adding a `format` tag to each field in the output schema. Format tags can either be enforced by Guardrails, or they can only be suggetions to the LLM. You can see the list of validators enforced by Guardrails [here](https://hub.guardrailsai.com/validator/guardrails/valid_choices). Additionally, you can create your own custom validators, see examples here [1](../examples/no_secrets_in_generated_text.ipynb), [2](../examples/recipe_generation.ipynb), [3](../examples/valid_chess_moves.ipynb).\n",
     "\n",
-    "As an example, for our use case we specify that the `affected_area` of `symptoms` should be one of the following: `['head', 'neck', 'chest']`. For this, we use the [`valid-choices` validator](https://www.guardrailsai.com/docs/hub/api_reference_markdown/validators#validchoices).\n",
+    "As an example, for our use case we specify that the `affected_area` of `symptoms` should be one of the following: `['head', 'neck', 'chest']`. For this, we use the [`valid-choices` validator](https://hub.guardrailsai.com/validator/guardrails/valid_choice).\n",
     "\n",
     "\n",
     "#### Specifying corrective actions\n",
@@ -165,7 +165,7 @@
     "\n",
     "For example, we can specify that if the `affected_area` of a symptom is not one of the valid choices, we should re-prompt the LLM to correct its output.\n",
     "\n",
-    "We do this by adding the `on-fail-valid-choices='reask'` attribute to the `affected_area` field. To see the full list of corrective actions, see [here](https://www.guardrailsai.com/docs/hub/concepts/on_fail_policies).\n",
+    "We do this by adding the `on-fail-valid-choices='reask'` attribute to the `affected_area` field. To see the full list of corrective actions, see [here](/docs/hub/concepts/on_fail_policies).\n",
     "\n",
     "\n",
     "Finally, our updated output schema looks like:"

docs/how_to_guides/logs.md

@@ -4,8 +4,6 @@ All `Guard` calls are logged internally, and can be accessed via the guard histo
 
 ## Accessing logs via `Guard.history`
 
-`history` is an attribute of the `Guard` class. It implements a standard `Stack` interface with a few extra helper methods and properties.  For more information on our `Stack` implementation see the [Helper Classes](/docs/api_reference_markdown/helper_classes) page.
-
 Each entry in the history stack is a `Call` log which will contain information specific to a particular `Guard.__call__` or `Guard.parse` call in the order that they were executed within the current session.
 
 For example, if you have a guard:
@@ -119,7 +117,7 @@ llm responses
 }
 ```
 
-For more information on `Call`, see the [History & Logs](/api_reference/history_and_logs/#guardrails.classes.history.Call) page.
+For more information on `Call`, see the [History & Logs](/docs/api_reference_markdown/history_and_logs) page.
 
 ## 🇻🇦 Accessing logs from individual steps
 In addition to the cumulative values available directly on the `Call` log, it also contains a `Stack` of `Iteration`'s.  Each `Iteration` represent the logs from within a step in the guardrails process.  This includes the call to the LLM, as well as parsing and validating the LLM's response.

docs/index.md

@@ -16,7 +16,7 @@ Guardrails AI is the leading open-source framework to define and enforce assuran
 
 Guardrails provides an object definition called a `Rail` for enforcing a specification on an LLM output, and a lightweight wrapper called a `Guard` around LLM API calls to implement this spec.
 
-1. `rail` (**R**eliable **AI** markup **L**anguage) files for specifying structure and type information, validators and corrective actions over LLM outputs. The concept of a Rail has evolved from markup - Rails can be defined in either <a href='/docs/defining_guards/pydantic'>Pydantic</a> or <a href='/docs/defining_guards/rail'>RAIL</a> for structured outputs, or directly in <a href='/docs/defining_guards/strings'>Python</a> for string outputs.
+1. `rail` (**R**eliable **AI** markup **L**anguage) files for specifying structure and type information, validators and corrective actions over LLM outputs. The concept of a Rail has evolved from markup - Rails can be defined in either <a href='/docs-graveyard/defining_guards/pydantic.ipynb'>Pydantic</a> or <a href='/docs/how_to_guides/rail'>RAIL</a> for structured outputs, or directly in <a href='/docs-graveyard/defining_guards/strings.ipynb'>Python</a> for string outputs.
 2. `Guard` wraps around LLM API calls to structure, validate and correct the outputs.
 
 ```mermaid