Doc Update (#129)

* init update

* Update terminology.rst

* fix the branch to create an index.html, and fix pre-commit issues

* Doc update

* made several changes to the docs after Shuguang's revision

* fixing pre-commit issues

* fixed the reference file to the final prompt config file

* added google analytics

---------

Co-authored-by: Salman Paracha <salmanparacha@MacBook-Pro-261.local>

docs/source/guides/function_calling.rst

@@ -0,0 +1,226 @@
+.. _function_calling:
+
+Function Calling
+================
+
+**Function Calling** is a powerful feature in Arch that allows your application to dynamically execute backend functions or services based on user prompts.
+This enables seamless integration between natural language interactions and backend operations, turning user inputs into actionable results.
+
+
+What is Function Calling?
+-------------------------
+
+Function Calling refers to the mechanism where the user's prompt is parsed, relevant parameters are extracted, and a designated backend function (or API) is triggered to execute a particular task.
+This feature bridges the gap between generative AI systems and functional business logic, allowing users to interact with the system through natural language while the backend performs the necessary operations.
+
+Function Calling Workflow
+-------------------------
+
+#. **Prompt Parsing**
+
+    When a user submits a prompt, Arch analyzes it to determine the intent. Based on this intent, the system identifies whether a function needs to be invoked and which parameters should be extracted.
+
+#. **Parameter Extraction**
+
+    Arch’s advanced natural language processing capabilities automatically extract parameters from the prompt that are necessary for executing the function. These parameters can include text, numbers, dates, locations, or other relevant data points.
+
+#. **Function Invocation**
+
+    Once the necessary parameters have been extracted, Arch invokes the relevant backend function. This function could be an API, a database query, or any other form of backend logic. The function is executed with the extracted parameters to produce the desired output.
+
+#. **Response Handling**
+
+    After the function has been called and executed, the result is processed and a response is generated. This response is typically delivered in a user-friendly format, which can include text explanations, data summaries, or even a confirmation message for critical actions.
+
+
+Arch-Function
+-------------------------
+The `Arch-Function <https://huggingface.co/collections/katanemolabs/arch-function-66f209a693ea8df14317ad68>`_ collection of large language models (LLMs) is a collection state-of-the-art (SOTA) LLMs specifically designed for **function calling** tasks.
+The models are designed to understand complex function signatures, identify required parameters, and produce accurate function call outputs based on natural language prompts.
+Achieving performance on par with GPT-4, these models set a new benchmark in the domain of function-oriented tasks, making them suitable for scenarios where automated API interaction and function execution is crucial.
+
+In summary, the Arch-Function collection demonstrates:
+
+- **State-of-the-art performance** in function calling
+- **Accurate parameter identification and suggestion**, even in ambiguous or incomplete inputs
+- **High generalization** across multiple function calling use cases, from API interactions to automated backend tasks.
+- Optimized **low-latency, high-throughput performance**, making it suitable for real-time, production environments.
+
+
+Key Features
+~~~~~~~~~~~~
+.. table::
+    :width: 100%
+
+    =========================   ===============================================================
+    **Functionality**	        **Definition**
+    =========================   ===============================================================
+    Single Function Calling	    Call only one function per user prompt
+    Parallel Function Calling	Call the same function multiple times but with parameter values
+    Multiple Function Calling	Call different functions per user prompt
+    Parallel & Multiple	        Perform both parallel and multiple function calling
+    =========================   ===============================================================
+
+
+Supported Languages
+~~~~~~~~~~~~~~~~~~~
+.. table::
+    :width: 100%
+
+    =========================   ===========================================================================================================================================
+    **Language**	            **Data Type**
+    =========================   ===========================================================================================================================================
+    Python	                    ``int``, ``str``, ``float``, ``bool``, ``list``, ``set``, ``dict``, ``tuple``
+    Java	                    ``byte``, ``short``, ``int``, ``long``, ``float``, ``double``, ``boolean``, ``char``, ``Array``, ``ArrayList``, ``Set``, ``HashMap``, ``Hashtable``, ``Queue``, ``Stack``
+    Javascript	                ``Number``, ``Bigint``, ``String``, ``Boolean``, ``Object``, ``Array``, ``Date``
+    =========================   ===========================================================================================================================================
+
+
+Implementing Function Calling
+-----------------------------
+
+Here’s a step-by-step guide to configuring function calling within your Arch setup:
+
+Step 1: Define the Function
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Create or identify the backend function you want Arch to call. This could be an API endpoint, a script, or any other executable backend logic.
+
+.. code-block:: python
+    :caption: Example Function
+
+    import requests
+
+    def get_weather(location: str, unit: str = "fahrenheit"):
+        if unit not in ["celsius", "fahrenheit"]:
+            raise ValueError("Invalid unit. Choose either 'celsius' or 'fahrenheit'.")
+
+        api_server = "https://api.yourweatherapp.com"
+        endpoint = f"{api_server}/weather"
+
+        params = {
+            "location": location,
+            "unit": unit
+        }
+
+        response = requests.get(endpoint, params=params)
+        return response.json()
+
+    # Example usage
+    weather_info = get_weather("Seattle, WA", "celsius")
+    print(weather_info)
+
+
+Step 2: Configure Prompt Targets
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Map the function to a prompt target, defining the intent and parameters that Arch will extract from the user’s prompt.
+
+.. code-block:: yaml
+    :caption: Example Config
+
+    prompt_targets:
+      - name: get_weather
+        description: Get the current weather for a location
+        parameters:
+          - name: location
+            description: The city and state, e.g. San Francisco, New York
+            type: str
+            required: true
+          - name: unit
+            description: The unit of temperature to return
+            type: str
+            enum: ["celsius", "fahrenheit"]
+        endpoint:
+          name: api_server
+          path: /weather
+
+Step 3: Validate Parameters
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Arch will validate parameters and ensure that the required parameters (e.g., location) are present in the prompt, and add validation rules if necessary.
+Here is ane example validation schema using the `jsonschema <https://json-schema.org/docs>`_ library
+
+.. code-block:: python
+    :caption: Example Validation Schema
+
+    import requests
+    from jsonschema import validate, ValidationError
+
+    # Define the JSON Schema for parameter validation
+    weather_validation_schema = {
+        "type": "object",
+        "properties": {
+            "location": {
+                "type": "string",
+                "minLength": 1,
+                "description": "The city and state, e.g. 'San Francisco, New York'"
+            },
+            "unit": {
+                "type": "string",
+                "enum": ["celsius", "fahrenheit"],
+                "description": "The unit of temperature to return"
+            }
+        },
+        "required": ["location"],
+        "additionalProperties": False
+    }
+
+    def get_weather(location: str, unit: str = "fahrenheit"):
+        # Create the data object for validation
+        params = {
+            "location": location,
+            "unit": unit
+        }
+
+        # Validate parameters using JSON Schema
+        try:
+            validate(instance=params, schema=weather_validation_schema)
+        except ValidationError as e:
+            raise ValueError(f"Invalid input: {e.message}")
+
+        # Prepare the API request
+        api_server = "https://api.yourweatherapp.com"
+        endpoint = f"{api_server}/weather"
+
+        # Make the API request
+        response = requests.get(endpoint, params=params)
+        return response.json()
+
+    # Example usage
+    weather_info = get_weather("Seattle, WA", "celsius")
+    print(weather_info)
+
+
+Step 4: Execute and Return the Response
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Once the function is called, format the response and send it back to Arch-Function.
+Next, Arch-Function provides users with coherent and user-friendly responses.
+
+
+Example Use Cases
+-----------------
+
+Here are some common use cases where Function Calling can be highly beneficial:
+
+- **Data Retrieval**: Extracting information from databases or APIs based on user inputs (e.g., checking account balances, retrieving order status).
+- **Transactional Operations**: Executing business logic such as placing an order, processing payments, or updating user profiles.
+- **Information Aggregation**: Fetching and combining data from multiple sources (e.g., displaying travel itineraries or combining analytics from various dashboards).
+- **Task Automation**: Automating routine tasks like setting reminders, scheduling meetings, or sending emails.
+- **User Personalization**: Tailoring responses based on user history, preferences, or ongoing interactions.
+
+Best Practices and Tips
+-----------------------
+When integrating function calling into your generative AI applications, keep these tips in mind to get the most out of our Arch-Function models:
+
+- **Keep it clear and simple**: Your function names and parameters should be straightforward and easy to understand. Think of it like explaining a task to a smart colleague - the clearer you are, the better the results.
+
+- **Context is king**: Don't skimp on the descriptions for your functions and parameters. The more context you provide, the better the LLM can understand when and how to use each function.
+
+- **Be specific with your parameters**: Instead of using generic types, get specific. If you're asking for a date, say it's a date. If you need a number between 1 and 10, spell that out. The more precise you are, the more accurate the LLM's responses will be.
+
+- **Expect the unexpected**: Test your functions thoroughly, including edge cases. LLMs can be creative in their interpretations, so it's crucial to ensure your setup is robust and can handle unexpected inputs.
+
+- **Watch and learn**: Pay attention to how the LLM uses your functions. Which ones does it call often? In what contexts? This information can help you optimize your setup over time.
+
+Remember, working with LLMs is part science, part art. Don't be afraid to experiment and iterate to find what works best for your specific use case.

docs/source/guides/observability/access_logging.rst

@@ -0,0 +1,23 @@
+.. _arch_access_logging:
+
+Access Logging
+==============
+
+Access logging in Arch refers to the logging of detailed information about each request and response that flows through Arch.
+It provides visibility into the traffic passing through Arch, which is crucial for monitoring, debugging, and analyzing the
+behavior of AI applications and their interactions.
+
+Key Features
+^^^^^^^^^^^^
+* **Per-Request Logging**:
+  Each request that passes through Arch is logged. This includes important metadata such as HTTP method,
+  path, response status code, request duration, upstream host, and more.
+* **Integration with Monitoring Tools**:
+  Access logs can be exported to centralized logging systems (e.g., ELK stack or Fluentd) or used to feed monitoring and alerting systems.
+* **Structured Logging**: where each request is logged as a object, making it easier to parse and analyze using tools like Elasticsearch and Kibana.
+
+.. code-block:: console
+
+    $ [2024-09-27T14:52:01.123Z] "ARCH REQUEST" GET /path/to/resource HTTP/1.1 200 512 1024 56 upstream_service.com D
+    X-Arch-Upstream-Service-Time: 25
+    X-Arch-Attempt-Count: 1

docs/source/guides/observability/monitoring.rst

@@ -0,0 +1,9 @@
+.. _monitoring:
+
+Monitoring
+==========
+
+Arch offers several monitoring metrics that help you understand three critical aspects of your application:
+latency, token usage, and error rates by an upstream LLM provider. Latency measures the speed at which your
+application is responding to users, which includes metrics like time to first token (TFT), time per output
+token (TOT) metrics, and the total latency as perceived by users.

docs/source/guides/observability/observability.rst

@@ -0,0 +1,11 @@
+.. _observability:
+
+Observability
+=============
+
+.. toctree::
+  :maxdepth: 2
+
+  tracing
+  monitoring
+  access_logging

docs/source/guides/observability/tracing.rst

@@ -0,0 +1,313 @@
+.. _arch_overview_tracing:
+
+Tracing
+=======
+
+Overview
+--------
+
+`OpenTelemetry <https://opentelemetry.io/>`_ is an open-source observability framework providing APIs
+and instrumentation for generating, collecting, processing, and exporting telemetry data, such as traces,
+metrics, and logs. Its flexible design supports a wide range of backends and seamlessly integrates with
+modern application tools. A key feature of OpenTelemetry is its commitment to standards like the
+`W3C Trace Context <https://www.w3.org/TR/trace-context/>`_
+
+**Tracing** is a critical tool that allows developers to visualize and understand the flow of
+requests in an AI application. With tracing, you can capture a detailed view of how requests propagate
+through various services and components, which is crucial for **debugging**, **performance optimization**,
+and understanding complex AI agent architectures like Co-pilots.
+
+**Arch** propagates trace context using the W3C Trace Context standard, specifically through the
+``traceparent`` header. This allows each component in the system to record its part of the request
+flow, enabling **end-to-end tracing** across the entire application. By using OpenTelemetry, Arch ensures
+that developers can capture this trace data consistently and in a format compatible with various observability
+tools.
+
+
+Benefits of Using ``Traceparent`` Headers
+-----------------------------------------
+
+- **Standardization**: The W3C Trace Context standard ensures compatibility across ecosystem tools, allowing
+  traces to be propagated uniformly through different layers of the system.
+- **Ease of Integration**: OpenTelemetry's design allows developers to easily integrate tracing with minimal
+  changes to their codebase, enabling quick adoption of end-to-end observability.
+- **Interoperability**: Works seamlessly with popular tracing tools like AWS X-Ray, Datadog, Jaeger, and many others,
+  making it easy to visualize traces in the tools you're already usi
+
+How to Initiate A Trace
+-----------------------
+
+1. **Enable Tracing Configuration**: Simply add the ``tracing: 100`` flag to in the :ref:`listener <arch_overview_listeners>` config
+
+2. **Trace Context Propagation**: Arch automatically propagates the ``traceparent`` header. When a request is received, Arch will:
+
+   - Generate a new ``traceparent`` header if one is not present.
+   - Extract the trace context from the ``traceparent`` header if it exists.
+   - Start a new span representing its processing of the request.
+   - Forward the ``traceparent`` header to downstream services.
+
+3. **Sampling Policy**: The 100 in ``tracing: 100`` means that all the requests as sampled for tracing.
+   You can adjust this value from 0-100.
+
+
+Trace Propagation
+-----------------
+
+Arch uses the W3C Trace Context standard for trace propagation, which relies on the ``traceparent`` header.
+This header carries tracing information in a standardized format, enabling interoperability between different
+tracing systems.
+
+Header Format
+~~~~~~~~~~~~~
+
+The ``traceparent`` header has the following format::
+
+   traceparent: {version}-{trace-id}-{parent-id}-{trace-flags}
+
+- ``{version}``: The version of the Trace Context specification (e.g., ``00``).
+- ``{trace-id}``: A 16-byte (32-character hexadecimal) unique identifier for the trace.
+- ``{parent-id}``: An 8-byte (16-character hexadecimal) identifier for the parent span.
+- ``{trace-flags}``: Flags indicating trace options (e.g., sampling).
+
+Instrumentation
+~~~~~~~~~~~~~~~
+
+To integrate AI tracing, your application needs to follow a few simple steps. The steps
+below are very common practice, and not unique to Arch, when you reading tracing headers and export
+`spans <https://docs.lightstep.com/docs/understand-distributed-tracing>`_ for distributed tracing.
+
+- Read the ``traceparent`` header from incoming requests.
+- Start new spans as children of the extracted context.
+- Include the ``traceparent`` header in outbound requests to propagate trace context.
+- Send tracing data to a collector or tracing backend to export spans
+
+Example with OpenTelemetry in Python
+************************************
+
+Install OpenTelemetry packages:
+
+.. code-block:: console
+
+    $ pip install opentelemetry-api opentelemetry-sdk opentelemetry-exporter-otlp
+    $ pip install opentelemetry-instrumentation-requests
+
+Set up the tracer and exporter:
+
+.. code-block:: python
+
+   from opentelemetry import trace
+   from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
+   from opentelemetry.instrumentation.requests import RequestsInstrumentor
+   from opentelemetry.sdk.resources import Resource
+   from opentelemetry.sdk.trace import TracerProvider
+   from opentelemetry.sdk.trace.export import BatchSpanProcessor
+
+   # Define the service name
+   resource = Resource(attributes={
+       "service.name": "customer-support-agent"
+   })
+
+   # Set up the tracer provider and exporter
+   tracer_provider = TracerProvider(resource=resource)
+   otlp_exporter = OTLPSpanExporter(endpoint="otel-collector:4317", insecure=True)
+   span_processor = BatchSpanProcessor(otlp_exporter)
+   tracer_provider.add_span_processor(span_processor)
+   trace.set_tracer_provider(tracer_provider)
+
+   # Instrument HTTP requests
+   RequestsInstrumentor().instrument()
+
+Handle incoming requests:
+
+.. code-block:: python
+
+   from opentelemetry import trace
+   from opentelemetry.propagate import extract, inject
+   import requests
+
+   def handle_request(request):
+       # Extract the trace context
+       context = extract(request.headers)
+       tracer = trace.get_tracer(__name__)
+
+       with tracer.start_as_current_span("process_customer_request", context=context):
+           # Example of processing a customer request
+           print("Processing customer request...")
+
+           # Prepare headers for outgoing request to payment service
+           headers = {}
+           inject(headers)
+
+           # Make outgoing request to external service (e.g., payment gateway)
+           response = requests.get("http://payment-service/api", headers=headers)
+
+           print(f"Payment service response: {response.content}")
+
+
+AI Agent Tracing Visualization Example
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following is an example of tracing for an AI-powered customer support system.
+A customer interacts with AI agents, which forward their requests through different
+specialized services and external systems.
+
+::
+
+    +--------------------------+
+    |   Customer Interaction   |
+    +--------------------------+
+               |
+               v
+    +--------------------------+        +--------------------------+
+    |  Agent 1 (Main - Arch)   | ---->  | External Payment Service |
+    +--------------------------+        +--------------------------+
+               |                                  |
+               v                                  v
+    +--------------------------+        +--------------------------+
+    |  Agent 2 (Support - Arch)| ---->  |   Internal Tech Support  |
+    +--------------------------+        +--------------------------+
+               |                                  |
+               v                                  v
+    +--------------------------+        +--------------------------+
+    | Agent 3 (Orders- Arch)   | ---->  |   Inventory Management   |
+    +--------------------------+        +--------------------------+
+
+Trace Breakdown:
+****************
+
+- Customer Interaction:
+    - Span 1: Customer initiates a request via the AI-powered chatbot for billing support (e.g., asking for payment details).
+
+- AI Agent 1 (Main - Arch):
+    - Span 2: AI Agent 1 (Main) processes the request and identifies it as related to billing, forwarding the request
+      to an external payment service.
+    - Span 3: AI Agent 1 determines that additional technical support is needed for processing and forwards the request
+      to AI Agent 2.
+
+- External Payment Service:
+    - Span 4: The external payment service processes the payment-related request (e.g., verifying payment status) and sends
+      the response back to AI Agent 1.
+
+- AI Agent 2 (Tech - Arch):
+    - Span 5: AI Agent 2, responsible for technical queries, processes a request forwarded from AI Agent 1 (e.g., checking for
+      any account issues).
+    - Span 6: AI Agent 2 forwards the query to Internal Tech Support for further investigation.
+
+- Internal Tech Support:
+    - Span 7: Internal Tech Support processes the request (e.g., resolving account access issues) and responds to AI Agent 2.
+
+- AI Agent 3 (Orders - Arch):
+    - Span 8: AI Agent 3 handles order-related queries. AI Agent 1 forwards the request to AI Agent 3 after payment verification
+      is completed.
+    - Span 9: AI Agent 3 forwards a request to the Inventory Management system to confirm product availability for a pending order.
+
+- Inventory Management:
+    - Span 10: The Inventory Management system checks stock and availability and returns the information to AI Agent 3.
+
+Integrating with Tracing Tools
+------------------------------
+
+AWS X-Ray
+~~~~~~~~~
+
+To send tracing data to `AWS X-Ray <https://aws.amazon.com/xray/>`_ :
+
+1. **Configure OpenTelemetry Collector**: Set up the collector to export traces to AWS X-Ray.
+
+   Collector configuration (``otel-collector-config.yaml``):
+
+   .. code-block:: yaml
+
+      receivers:
+        otlp:
+          protocols:
+            grpc:
+
+      processors:
+        batch:
+
+      exporters:
+        awsxray:
+          region: <Your-Aws-Region>
+
+      service:
+        pipelines:
+          traces:
+            receivers: [otlp]
+            processors: [batch]
+            exporters: [awsxray]
+
+2. **Deploy the Collector**: Run the collector as a Docker container, Kubernetes pod, or standalone service.
+3. **Ensure AWS Credentials**: Provide AWS credentials to the collector, preferably via IAM roles.
+4. **Verify Traces**: Access the AWS X-Ray console to view your traces.
+
+Datadog
+~~~~~~~
+
+Datadog
+
+To send tracing data to `Datadog <https://docs.datadoghq.com/getting_started/tracing/>`_:
+
+1. **Configure OpenTelemetry Collector**: Set up the collector to export traces to Datadog.
+
+   Collector configuration (``otel-collector-config.yaml``):
+
+   .. code-block:: yaml
+
+      receivers:
+        otlp:
+          protocols:
+            grpc:
+
+      processors:
+        batch:
+
+      exporters:
+        datadog:
+          api:
+            key: "${<Your-Datadog-Api-Key>}"
+          site: "${DD_SITE}"
+
+      service:
+        pipelines:
+          traces:
+            receivers: [otlp]
+            processors: [batch]
+            exporters: [datadog]
+
+2. **Set Environment Variables**: Provide your Datadog API key and site.
+
+   .. code-block:: console
+
+        $ export <Your-Datadog-Api-Key>=<Your-Datadog-Api-Key>
+        $ export DD_SITE=datadoghq.com  # Or datadoghq.eu
+
+3. **Deploy the Collector**: Run the collector in your environment.
+4. **Verify Traces**: Access the Datadog APM dashboard to view your traces.
+
+
+Best Practices
+--------------
+
+- **Consistent Instrumentation**: Ensure all services propagate the ``traceparent`` header.
+- **Secure Configuration**: Protect sensitive data and secure communication between services.
+- **Performance Monitoring**: Be mindful of the performance impact and adjust sampling rates accordingly.
+- **Error Handling**: Implement proper error handling to prevent tracing issues from affecting your application.
+
+Summary
+----------
+
+By leveraging the ``traceparent`` header for trace context propagation, Arch enables developers to implement
+tracing efficiently. This approach simplifies the process of collecting and analyzing tracing data in common
+tools like AWS X-Ray and Datadog, enhancing observability and facilitating faster debugging and optimization.
+
+Additional Resources
+--------------------
+
+- `OpenTelemetry Documentation <https://opentelemetry.io/docs/>`_
+- `W3C Trace Context Specification <https://www.w3.org/TR/trace-context/>`_
+- `AWS X-Ray Exporter <https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/awsxrayexporter>`_
+- `Datadog Exporter <https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/datadogexporter>`_
+
+.. Note::
+   Replace placeholders such as ``<Your-Aws-Region>`` and ``<Your-Datadog-Api-Key>`` with your actual configurations.

docs/source/guides/prompt_guard.rst

@@ -0,0 +1,90 @@
+.. _prompt_guard:
+
+Prompt Guard
+================
+
+**Prompt guard** is a security and validation layer designed to protect prompt-based systems by filtering and analyzing inputs before they reach the core processing stages.
+In applications where prompts generate responses or execute specific actions based on user inputs, prompt guard minimizes risks like malicious inputs, unexpected errors, or misaligned outputs.
+By adding a layer of input scrutiny, prompt guard ensures safer, more reliable, and accurate interactions in prompt-driven environments.
+
+Why Prompt Guard
+----------------
+
+.. vale Vale.Spelling = NO
+
+- **Input Validation**
+    - **Type Enforcement**: Ensures that inputs are of the expected data types, such as integers, strings, lists, or specific formats, reducing errors from unexpected data.
+    - **Value Constraints**: Restricts inputs to valid ranges, lengths, or patterns to avoid unusual or incorrect responses.
+
+- **Prompt Sanitization**
+    - **Injection Prevention**: Detects and filters inputs that might attempt injection attacks, like adding code or SQL queries in a prompt-based application.
+    - **Content Filtering**: Identifies and removes potentially harmful, sensitive, or inappropriate content from inputs to maintain safe interactions.
+
+- **Intent Detection**
+    - **Behavioral Analysis**: Analyzes prompt intent to detect if the input aligns with the function’s intended use. This can help prevent unwanted behavior, such as attempts to bypass limitations or misuse system functions.
+    - **Sentiment and Tone Checking**: Examines the tone of prompts to ensure they align with application guidelines, useful in conversational systems and customer support interactions.
+
+- **Dynamic Error Handling**
+    - **Automatic Correction**: Applies error-handling techniques to suggest corrections for minor input errors, such as typos or misformatted data.
+    - **Feedback Mechanism**: Provides informative error messages to users, helping them understand how to correct input mistakes or adhere to guidelines.
+
+- **Policy Enforcement**
+    - **Role-Based Filtering**: Customizes input validation based on user roles or permissions, allowing more flexibility or stricter enforcement depending on user access.
+    - **Compliance Checks**: Ensures inputs meet compliance or regulatory standards, especially in fields like finance or healthcare, where prompt outputs must align with strict guidelines.
+
+
+Arch-Guard
+----------
+In the evolving landscape of LLM-powered applications, safeguarding against prompt attacks is crucial.
+These attacks involve malicious prompts crafted to manipulate the intended behavior of the model, potentially leading to undesirable outcomes.
+Arch-Guard is designed to address this challenge.
+
+What Is Arch-Guard
+~~~~~~~~~~~~~~~~~~
+`Arch-Guard <https://huggingface.co/collections/katanemolabs/arch-guard-6702bdc08b889e4bce8f446d>`_ is a robust classifier model specifically trained on a diverse corpus of prompt attacks.
+It excels at detecting explicitly malicious prompts and assessing toxic content, providing an essential layer of security for LLM applications.
+
+By embedding Arch-Guard within the Arch architecture, we empower developers to build robust, LLM-powered applications while prioritizing security and safety. With Arch-Guard, you can navigate the complexities of prompt management with confidence, knowing you have a reliable defense against malicious input.
+
+
+How Arch-Guard Works
+----------------------
+
+#. **Pre-Processing Stage**
+
+    As a request or prompt is received, Prompt Guard first performs validation, applying any type, format, or constraint checks. If any violations are detected, the input is flagged, and a tailored error message may be returned.
+
+#. **Sanitization Stage**
+
+    The prompt is analyzed for potentially harmful or inappropriate content, and necessary filters are applied to clean the input.
+
+#. **Behavior Analysis**
+
+    Next, the system assesses the intent and context of the prompt, verifying that it aligns with predefined function requirements. If the prompt raises any red flags, it can be modified or flagged for review.
+
+#. **Error Handling and Feedback**
+
+    If the prompt contains errors or does not meet certain criteria, the user receives immediate feedback or correction suggestions, enhancing usability and reducing the chance of repeated input mistakes.
+
+#. **Output Control**
+
+    After input validation and filtering, the prompt is allowed to proceed to the main processing phase. The output can also undergo a final check to ensure compliance with content guidelines or role-based policies.
+
+
+Benefits of Using Prompt Guard
+------------------------------
+
+- **Enhanced Security**: Protects against injection attacks, harmful content, and misuse, securing both system and user data.
+
+- **Increased Accuracy**: Filters out inappropriate or misaligned inputs, leading to more accurate and intended outputs.
+
+- **Better User Experience**: Clear feedback and error correction improve user interactions by guiding them to correct input formats and constraints.
+
+- **Regulatory Compliance**: Ensures that prompts adhere to necessary guidelines, especially for sensitive fields, minimizing the risk of regulatory breaches.
+
+
+Summary
+-------
+
+Prompt guard is an essential tool for any prompt-based system that values security, accuracy, and compliance.
+By implementing Prompt Guard, developers can provide a robust layer of input validation and security, leading to better-performing, reliable, and safer applications.