fix relative paths

Author: lbeurerkellner

docs/explorer/api/annotations.md

@@ -8,7 +8,7 @@ Annotations provide additional context, facilitating collaboration and agent err
 
 <figure class='wide'>
 
-<img src="{{ base_url }}/assets/annotated-trace.png" alt="An annotated trace" style="width: 100%;">
+<img src="site:assets/annotated-trace.png" alt="An annotated trace" style="width: 100%;">
 
 <figcaption>An annotated trace in Explorer</figcaption>
 

docs/explorer/api/client-setup.md

@@ -3,7 +3,7 @@
 The SDK exposes a `Client` class. To create an object of this type, you need two variables: the Invariant API endpoint URL and the API key.
 
 ## Getting the API Key
-Navigate to the <img class='inline-invariant' src="{{ base_url }}/assets/logo.svg"/> [Invariant Explorer](https://explorer.invariantlabs.ai) and create an account via GitHub Sign-In.
+Navigate to the <img class='inline-invariant' src="site:assets/logo.svg"/> [Invariant Explorer](https://explorer.invariantlabs.ai) and create an account via GitHub Sign-In.
 
 Once you have created an account, go to your [User Settings](https://explorer.invariantlabs.ai/settings) and generate an API key.
 

docs/explorer/api/uploading-traces/file-uploads.md

@@ -8,7 +8,7 @@ Apart from API-based uploads, you can also upload datasets to Explorer using the
 
 To upload a dataset to Explorer, navigate to the [home page](https://explorer.invariantlabs.ai) and click on the `New Dataset` button. This will open the file upload dialog.
 
-![File Upload Dialog]({{ base_url }}/assets/explorer-create-dataset.png)
+![File Upload Dialog](site:assets/explorer-create-dataset.png)
 
 Click on the `Choose a File` button and select the dataset file from your local machine. Once the file is selected, click on the `Create` button to start the upload process.
 

docs/gateway/agent-integrations/openhands.md

@@ -31,7 +31,7 @@ Enable the `Advanced Options` toggle under settings and update the `Base URL` to
 https://explorer.invariantlabs.ai/api/v1/gateway/{add-your-dataset-name-here}/openai
 ```
 
-<img src="{{ base_url }}/assets/openhands-integration.png" style="height: 400px !important; display: block; margin: 0 auto;"/>
+<img src="site:assets/openhands-integration.png" style="height: 400px !important; display: block; margin: 0 auto;"/>
 
 > **Note:** Do not include the curly braces `{}`.
 

docs/guardrails/dataflow-rules.md

@@ -7,7 +7,7 @@ Secure the dataflow of your agentic system, to ensure that sensitive data never
 Due to their dynamic nature, agentic systems often mix and combine data from different sources, and can easily leak sensitive information. Guardrails provides a simple way to define dataflow rules, to ensure that sensitive data never leaves the system through unintended channels.
 
 <br/><br/>
-<img src="{{ base_url }}/assets/guardrails/dataflow.svg" alt="Invariant Architecture" class="invariant-architecture" style="display: block; margin: 0 auto; width: 100%; max-width: 400pt;"/>
+<img src="site:assets/guardrails/dataflow.svg" alt="Invariant Architecture" class="invariant-architecture" style="display: block; margin: 0 auto; width: 100%; max-width: 400pt;"/>
 <br/><br/>
 
 <div class='risks'/>

docs/guardrails/index.md

@@ -20,7 +20,7 @@ Before securing an agent, it is important to understand its capabilities. This i
 This is important to understand, as it forms the basis for threat modeling and risk assessment. In contrast to traditional software, agentic systems are highly dynamic, meaning tools and APIs can be called in arbitrary ways, and the agent's behavior can change based on the context and the task at hand.
 
 <br/><br/>
-<img src="{{ base_url }}/assets/guardrails/tool-calls.svg" alt="Invariant Architecture" class="invariant-architecture" style="display: block; margin: 0 auto; width: 100%; max-width: 400pt;"/>
+<img src="site:/assets/guardrails/tool-calls.svg" alt="Invariant Architecture" class="invariant-architecture" style="display: block; margin: 0 auto; width: 100%; max-width: 400pt;"/>
 <br/><br/>
 
 ## Constraining Your Agent's Capability space with Rules
@@ -30,7 +30,7 @@ Once you have a good understanding of your agent's capabilities, you can start w
 Invariant’s guardrailing runtime allows you to express these constraints declaratively, ensuring the agent only operates within predefined security boundaries—even in dynamic and open-ended environments. This makes it easier to detect policy violations, reduce risk exposure, and maintain trust in agentic systems.
 
 <br/><br/>
-<img src="{{ base_url }}/assets/guardrails/space-overlap.svg" alt="Invariant Architecture" class="invariant-architecture" style="display: block; margin: 0 auto; width: 100%; max-width: 290pt;"/>
+<img src="site:assets/guardrails/space-overlap.svg" alt="Invariant Architecture" class="invariant-architecture" style="display: block; margin: 0 auto; width: 100%; max-width: 290pt;"/>
 <br/><br/>
 
 ## Writing Your First Rule
@@ -41,7 +41,7 @@ Let's assume a simple example agent that is capable of managing a user's email i
 * `send_email(recipient: str, subject: str, body: str)` to send an email to a user.
 
 <br/><br/>
-<img src="{{ base_url }}/assets/guardrails/email-agent-example.svg" alt="Invariant Architecture" class="invariant-architecture" style="display: block; margin: 0 auto; width: 100%; max-width: 290pt;"/>
+<img src="site:assets/guardrails/email-agent-example.svg" alt="Invariant Architecture" class="invariant-architecture" style="display: block; margin: 0 auto; width: 100%; max-width: 290pt;"/>
 <br/><br/>
 
 Unconstrained, this agent can easily fail, allowing a bad actor or sheer malfunction to induce failure states such as data leaks, spamming, or even phishing attacks. 
@@ -99,7 +99,7 @@ Next, let's also consider different workflows our agent may carry out. For examp
 This behavior has the risk that the agent may be prompt injected by an untrusted email, leading to malicious behavior. A possible such scenario is illustratd in the figure below, where an attacker sends a malicious email to the agent, which then leaks sensitive information to the attacker.
 
 <figure>
-<img src="{{ base_url }}/assets/guardrails/email-agent-flow.png" alt="Malicious email agent flow" class="invariant-architecture" style="display: block; margin: 0 auto; width: 100%; max-width: 450pt;"/>
+<img src="site:assets/guardrails/email-agent-flow.png" alt="Malicious email agent flow" class="invariant-architecture" style="display: block; margin: 0 auto; width: 100%; max-width: 450pt;"/>
 <figcaption>An email agent is prompt injected in a malicious email and then leaks information to an attacker.</figcaption>
 </figure>
 

docs/guardrails/tool-calls.md

@@ -11,7 +11,7 @@ For security reasons, it is important to ensure that all tool calls an agent exe
 Guardrails provide you a powerful way to enforce such security policies, and to limit the agent's tool interface to only the tools and functions that are necessary for the task at hand.
 
 <br/><br/>
-<img src="{{ base_url }}/assets/guardrails/tool-calls.svg" alt="Invariant Architecture" class="invariant-architecture" style="display: block; margin: 0 auto; width: 100%; max-width: 400pt;"/>
+<img src="site:assets/guardrails/tool-calls.svg" alt="Invariant Architecture" class="invariant-architecture" style="display: block; margin: 0 auto; width: 100%; max-width: 400pt;"/>
 <br/><br/>
 
 <div class='risks'/>

docs/testing/writing/parameterized-tests.md

@@ -44,4 +44,4 @@ def test_check_weather_in(city: str):
 
 When pushing the parameterized test results to Explorer (`invariant test --push`), the resulting test instances will be listed separately:
 
-<img src="{{ base_url }}/assets/parameterized_tests.png"/>
+<img src="site:assets/parameterized_tests.png"/>

mkdocs.yml

@@ -32,6 +32,8 @@ use_directory_urls: true
 
 plugins:
   - mkdocs-jupyter
+  - site-urls
+  - search
   # TODO(Hemang): Remove these once we change the URLs in the other places.
   - redirects:
       redirect_maps:

requirements.txt

@@ -1,4 +1,5 @@
 mkdocs
 mkdocs-jupyter
 mkdocs-material
-mkdocs-redirects
+mkdocs-redirects
+mkdocs-site-urls