SeldonIO · paulb-seldon · Jul 16, 2025 · Jul 16, 2025
diff --git a/docs-gb/deployments/abtests.md b/docs-gb/deployments/abtests.md
@@ -24,7 +24,7 @@ In Seldon we provide two current examples on how to run Iter8 experiments.
 
 The first option is to create an AB Test for the candidate model with an updated Seldon Deployment and run an Iter8 experiment to progressively rollout the candidate based on a set of metrics. The architecture is show below:
 
-![seldonIter8Single](seldon-iter8-single.png)
+![seldonIter8Single](../images/seldon-iter8-single.png)
 
 
 We begin by updating our default model to start an AB test as shown below:
@@ -332,15 +332,15 @@ quickstart-exp   A/B    iris     Completed   15                     ExperimentCo
 
 In the above examples a final stage promotion action is defined for the successful candidate to be updated to the new default Seldon deployment.
 
-As a next step [run the notebook running through this example](../examples/iter8-single.html).
+As a next step [run the notebook running through this example](../notebooks/iter8-single.md).
 
 ## Seldon/Iter8 Experiment over separate Seldon Deployments
 
 We can also run experiments over separate Seldon Deployments. This though would require the creation in your service mesh of choice for a routing rule that Iter8 can modify to push traffic to each Seldon Deployment.
 
 The architecture for this type of experiment is shown below:
 
-![seldonIter8Separate](seldon-iter8-separate.png)
+![seldonIter8Separate](../images/seldon-iter8-separate.png)
 
 The difference here is we have two Seldon Deployments. A baseline:
 
@@ -498,4 +498,4 @@ spec:
 
 The progression of the experiment is very similar with in this case the best model be promoted onto of the existing default baseline.
 
-As a next step [run the notebook running through this example](../examples/iter8-separate.html).
+As a next step [run the notebook running through this example](../notebooks/iter8-separate.md).
diff --git a/docs-gb/deployments/metadata.md b/docs-gb/deployments/metadata.md
@@ -1,6 +1,6 @@
 # Model and Deployment Metadata
 
-![metadata](./metadata.svg)
+![metadata](../images//metadata.svg)
 
 
 ## Examples
@@ -122,7 +122,7 @@ Model metadata allow you to specify metadata for each of the components (nodes)
 New orchestrator engine will probe all nodes for their metadata and derive global `inputs` and `outputs` of your graph.
 It will then expose them together with all nodes' metadata at a single endpoint `/api/v1.0/metadata/` of your deployment.
 
-![graph-metadata](./graph-metadata.svg)
+![graph-metadata](../images/graph-metadata.svg)
 
 Example response:
 ```json

diff --git a/docs-gb/images/adversarial-attack.png b/docs-gb/images/adversarial-attack.png
diff --git a/docs-gb/images/anchors.jpg b/docs-gb/images/anchors.jpg
diff --git a/docs-gb/images/batch-processor.jpg b/docs-gb/images/batch-processor.jpg
diff --git a/docs-gb/images/batch-workflow-manager-integration.jpg b/docs-gb/images/batch-workflow-manager-integration.jpg
diff --git a/docs-gb/images/batch-workflow-managers.jpg b/docs-gb/images/batch-workflow-managers.jpg
diff --git a/docs-gb/images/cicd-seldon.jpg b/docs-gb/images/cicd-seldon.jpg
diff --git a/docs-gb/images/core-logo-large.png b/docs-gb/images/core-logo-large.png
diff --git a/docs-gb/images/core-logo-small.png b/docs-gb/images/core-logo-small.png
diff --git a/docs-gb/images/core-logo.png b/docs-gb/images/core-logo.png
diff --git a/docs-gb/images/core-play-logo.png b/docs-gb/images/core-play-logo.png
diff --git a/docs-gb/images/deploy-logo.png b/docs-gb/images/deploy-logo.png
diff --git a/docs-gb/images/e2e-model-serving.jpg b/docs-gb/images/e2e-model-serving.jpg
diff --git a/docs-gb/images/e2e-model-serving.svg b/docs-gb/images/e2e-model-serving.svg
diff --git a/docs-gb/images/inf-graph.png b/docs-gb/images/inf-graph.png
diff --git a/docs-gb/images/jaeger-ui-grpc-example.png b/docs-gb/images/jaeger-ui-grpc-example.png
diff --git a/docs-gb/images/jaeger-ui-rest-example.png b/docs-gb/images/jaeger-ui-rest-example.png
diff --git a/docs-gb/images/kibana-custom-search.png b/docs-gb/images/kibana-custom-search.png
diff --git a/docs-gb/images/language-wrappers-1.svg b/docs-gb/images/language-wrappers-1.svg
diff --git a/docs-gb/images/language-wrappers-2.svg b/docs-gb/images/language-wrappers-2.svg
diff --git a/docs-gb/images/metadata.svg b/docs-gb/images/metadata.svg
diff --git a/docs-gb/images/metrics.png b/docs-gb/images/metrics.png
diff --git a/docs-gb/images/model-servers.svg b/docs-gb/images/model-servers.svg
diff --git a/docs-gb/images/operator.svg b/docs-gb/images/operator.svg
diff --git a/docs-gb/images/orchestrator.svg b/docs-gb/images/orchestrator.svg
diff --git a/docs-gb/images/prometheus-graph.png b/docs-gb/images/prometheus-graph.png
diff --git a/docs-gb/images/prometheus-targets.png b/docs-gb/images/prometheus-targets.png
diff --git a/docs-gb/images/rest-openapi.jpg b/docs-gb/images/rest-openapi.jpg
diff --git a/docs-gb/images/seldon-core-high-level.jpg b/docs-gb/images/seldon-core-high-level.jpg
diff --git a/docs-gb/images/seldon-iter8-separate.png b/docs-gb/images/seldon-iter8-separate.png
diff --git a/docs-gb/images/seldon-iter8-single.png b/docs-gb/images/seldon-iter8-single.png
diff --git a/docs-gb/images/seldondeployment-crd.svg b/docs-gb/images/seldondeployment-crd.svg
diff --git a/docs-gb/images/stream-processing-knative.jpg b/docs-gb/images/stream-processing-knative.jpg
diff --git a/docs-gb/images/svcOrch1.png b/docs-gb/images/svcOrch1.png
diff --git a/docs-gb/images/tracing.svg b/docs-gb/images/tracing.svg
diff --git a/docs-gb/images/why_not_flask.svg b/docs-gb/images/why_not_flask.svg
diff --git a/docs-gb/install/advanced-helm-chart-configuration.md b/docs-gb/install/advanced-helm-chart-configuration.md
@@ -4,7 +4,8 @@
 
 This page provides a detailed overview of the installation parameters available for the Seldon Core installation when using Helm 3.x. The high level workflows to install Seldon Core can be found in the [Installation Page](../workflow/install.md).
 
-You can find the `values.yaml` file of the [seldon-core-operator Helm chart](https://github.com/SeldonIO/seldon-core/tree/master/helm-charts/seldon-core-operator), which contains basically all the values that you can configure in your installation by using the `set` flag in the format `--set value.path=YOUR_VALUE`.
+You can find the `values.yaml` file of the [seldon-core-operator Helm chart](https://github.com/SeldonIO/seldon-core/helm-charts/seldon-core-operator), which contains basically all the values that you can configure in your installation by using the `set` flag in the format `--set value.path=YOUR_VALUE`.
 
 The file has been written to be self documented, and has information on all the core parameters. Further information is referenced in the file to specific documentation pages.
-{% @github-files/github-code-block url="https://github.com/SeldonIO/seldon-core/tree/master/helm-charts/seldon-core-operator/values.yaml" %}
+
+{% @github-files/github-code-block url="https://github.com/SeldonIO/seldon-core/blob/master/helm-charts/seldon-core-operator/values.yaml" %}
diff --git a/docs-gb/overview.md b/docs-gb/overview.md
@@ -21,7 +21,7 @@ Keep reading to learn more!
 
 With `Seldon Core` you can take your model and put it directly into the production using our flexible `Model Servers`.
 
-![](../images/e2e-model-serving.svg)
+![](../docs-gb/images/e2e-model-serving.svg)
 
 Using the so-called `Reusable Model Servers` you can deploy your models into Kubernetes cluster in just a few steps:
 
@@ -48,7 +48,7 @@ Each of these are useful depending on the context and the actual use case.
   Does not require the central repository but requires a build of a new image for every model.
 
 
-![](../images/model-servers.svg)
+![](../docs-gb//images/model-servers.svg)
 
 Read more about our pre-packaged `Model Servers` on their dedicated documentation pages:
 - [MLflow Server](../servers/mlflow.html)
@@ -64,7 +64,7 @@ Language wrappers allows Seldon Core users to build `Reusable` and `Non-Reusable
 As you will see, the whole process is very simple and requires user to only define logic that
 loads models and perform inference prediction as well as the required runtime dependencies.
 
-![](../images/language-wrappers-1.svg)
+![](../docs-gb/images/language-wrappers-1.svg)
 
 
 Model loading and inference logic is defined in `Model.py` file:
@@ -103,7 +103,7 @@ $ curl http://localhost:9000/api/v1.0/predictions \
 }
 ```
 
-![](../images/language-wrappers-2.svg)
+![](../docs-gb/images/language-wrappers-2.svg)
 
 To complete containerisation process you need two more components:
 - `requirements.txt` file that describes your runtime dependencies
@@ -130,7 +130,7 @@ In Seldon Core we use CRDs to define the inference graph through the manifest ya
 The manifest file that you write is very powerful yet simple.
 You can easily define what models do you want in your deployment and how they are connected in the inference graph.
 
-![](../images/seldondeployment-crd.svg)
+![](../docs-gb//images/seldondeployment-crd.svg)
 
 You can think about the CRD as an abstraction around the actual deployment and services that are created in the cluster.
 Once the manifest is applied to the cluster, Seldon Core `Operator` creates all Kubernetes objects required to serve the inference requests.
@@ -149,7 +149,7 @@ It works according to the common Kubernetes operator pattern - in a continues lo
 - `diff` against desired state
 - if necessary `act` to apply desired state
 
-![](../images/operator.svg)
+![](../docs-gb/images/operator.svg)
 
 
 ## Service Orchestrator
@@ -159,7 +159,7 @@ It reads the inference graph structure from the `CRD` and when inference request
 
 It is because of the presence of `Service Orchestrator` that complex graph components like `routers`, `combiners` and output/input `transformers` are available in the `Seldon` world.
 
-![](../images/orchestrator.svg)
+![](../docs-gb/images/orchestrator.svg)
 
 `Service Orchestrator` is also responsible for providing many advance features out of the box:
 - `Jaeger` tracing
@@ -179,7 +179,7 @@ You can easily version your model and describe its expected inputs and outputs.
 These allow you to make connection to the platform you trained your model with (DVC, Pachyderm, ...)
 and know what inputs / outputs you can expect from your inference graph.
 
-![](../images/metadata.svg)
+![](../docs-gb/images/metadata.svg)
 
 Read more about [metadata provenance on its dedicated documentation page](../reference/apis/metadata.html).
 
@@ -189,7 +189,7 @@ Read more about [metadata provenance on its dedicated documentation page](../ref
 Metrics is important aspect of serving ML inference models in production.
 Out of the box Seldon Core deployments expose standard metrics to [Prometheus](https://prometheus.io/) on the `Service Orchestrator`.
 
-![](../images/metrics.png)
+![](../docs-gb/images/metrics.png)
 
 Read more about [metrics on its dedicated documentation page](../analytics/analytics.html).
 
@@ -198,7 +198,7 @@ Read more about [metrics on its dedicated documentation page](../analytics/analy
 
 By default, we support [Jaeger](https://www.jaegertracing.io/) for Distributed Tracing.
 
-![](../images/tracing.svg)
+![](../docs-gb/images/tracing.svg)
 
 Read more about [tracing on its dedicated documentation page](../graph/distributed-tracing.html).
 

diff --git a/docs-gb/routing/inference-graph.md b/docs-gb/routing/inference-graph.md
@@ -4,7 +4,7 @@ Seldon Core extends Kubernetes with its own custom resource SeldonDeployment whe
 
 A SeldonDeployment is a JSON or YAML file that allows you to define your graph of component images and the resources each of those images will need to run (using a Kubernetes PodTemplateSpec). The parts of a SeldonDeployment are shown below:
 
-![inference-graph](./inf-graph.png)
+![inference-graph](../images/inf-graph.png)
 
 A minimal example for a single model, this time in YAML, is shown below:
 ```yaml

diff --git a/docs-gb/servers/huggingface.md b/docs-gb/servers/huggingface.md
@@ -94,5 +94,6 @@ spec:
     replicas: 1
 ```
 
-.. note::
-  As a next step, why not try running a larger-scale model? You can find one in gs://seldon-models/v1.18.0/huggingface/text-gen-custom-gpt2. However, you may need to request more memory!
+{% hint style="note" %}
+As a next step, why not try running a larger-scale model? You can find one in gs://seldon-models/v1.18.0/huggingface/text-gen-custom-gpt2. However, you may need to request more memory!
+{% endhint %}