Fix broken links

docs/features/istio/tutorials/k8s-istio-authorization-policies.mdx

@@ -258,7 +258,7 @@ Try to create an intents file yourself for **client-other**, and apply it to all
 
 ### What's next
 
-- Get started with the [Otterize network mapper for Istio](/quickstart/visualization/k8s-istio-watcher) to help you bootstrap intents files with HTTP resources
+- Get started with the [Otterize network mapper for Istio](/features/istio/tutorials/k8s-istio-watcher) to help you bootstrap intents files with HTTP resources
   for use in [intent-based access control (IBAC)](/overview/intent-based-access-control).
 
 ## Teardown

docs/features/network-mapping-network-policies/reference/README.mdx

@@ -120,7 +120,7 @@ Here's the image generated by running `otterize network-mapper visualize -n otte
 `otterize network-mapper export [--format] [-n <namespace1>,<namespace2>,...] [-o <path>] [--output-type <output-type>]`
 
 Return the network map built by the network mapper since it started, or since it was reset,
-as YAML [client intents file(s)](/reference/intents-and-intents-files/#intents-file-formats) or as JSON file(s).
+as YAML [client intents file(s)](/overview/intent-based-access-control) or as JSON file(s).
 
 #### Options
 

docs/features/network-mapping-network-policies/tutorials/aws-eks-cni-mini.mdx

@@ -156,7 +156,7 @@ And you should see your access graph showing the service as protected:
 
 ### What's next
 
-Have a look at the [guide on how to deploy protection to a larger, more complex application one step at a time](/guides/protect-1-service-network-policies).
+Have a look at the [guide on how to deploy protection to a larger, more complex application one step at a time](/features/network-mapping-network-policies/tutorials/protect-1-service-network-policies).
 
 ## Teardown
 

docs/features/network-mapping-network-policies/tutorials/k8s-network-policies.mdx

@@ -265,7 +265,7 @@ Otterize saved us from doing all this work by simply declaring the client's inte
 while the appropriate network policies were managed automatically behind the scenes.
 
 Further information about network policies and Otterize can be found
-[here](/reference/access-controls/network-policies).
+[here](/features/network-mapping-network-policies/reference/Network-Policies-Deep-Dive).
 
 </details>
 

docs/overview/intent-based-access-control.mdx

@@ -19,7 +19,6 @@ In other words, developers declare what their service intends to access, and tha
 
 Here’s an example of a client intents file (as a Kubernetes custom resource YAML) for a service named **client** that has network access to another service named **auth-server** and has access to **production-db’s** **metrics** database:
 ```yaml
-
 apiVersion: k8s.otterize.com/v1alpha2
 kind: ClientIntents
 metadata:

docs/overview/otterize-cloud/README.mdx

@@ -10,7 +10,7 @@ This page is focused on the current capabilities of Otterize Cloud.
 
 ## What it does
 
-Otterize Cloud attaches to [Otterize OSS](/otterize-oss) operators (the intents operator, network mapper, and credentials operator) running in your Kubernetes clusters.
+Otterize Cloud attaches to [Otterize OSS](/overview/otterize-oss) operators (the intents operator, network mapper, and credentials operator) running in your Kubernetes clusters.
 While Otterize OSS does the heavy lifting — mapping pod-to-pod traffic, responding to intents files applied with `kubectl` and
 configuring network policies, Kafka ACLs, and Istio authorization policies — Otterize Cloud adds:
 - **Visibility**: visualize the network map of any connected cluster.

docs/overview/otterize-oss/README.mdx

@@ -28,5 +28,5 @@ To get started with Otterize OSS, see the tutorials for [network policies](/feat
 
 ## Usage metrics
 
-Components in Otterize OSS collect usage information — counts of events like `INTENTS_APPLIED`, `NETWORK_POLICY_CREATED`, `KAFKA_ACL_DELETED`, etc. — and can report those back to the Otterize team. This is entirely optional and does not affect the functionality of Otterize OSS, but it does help the team at Otterize understand what the community finds useful and hence how to improve it. (Of course, direct feedback through the [Otterize Community Slack](https://joinslack.otterize.com/) is very much appreciated too.) For more information, including what is sent and how to turn it off or on, see [the usage telemetry documentation](/otterize-oss/usage-telemetry).
+Components in Otterize OSS collect usage information — counts of events like `INTENTS_APPLIED`, `NETWORK_POLICY_CREATED`, `KAFKA_ACL_DELETED`, etc. — and can report those back to the Otterize team. This is entirely optional and does not affect the functionality of Otterize OSS, but it does help the team at Otterize understand what the community finds useful and hence how to improve it. (Of course, direct feedback through the [Otterize Community Slack](https://joinslack.otterize.com/) is very much appreciated too.) For more information, including what is sent and how to turn it off or on, see [the usage telemetry documentation](/overview/otterize-oss/usage-telemetry).
 

docs/reference/cli/README.mdx

@@ -5,7 +5,7 @@ title: CLI
 
 The Otterize command line interface (CLI) offers the following capabilities:
 - [Interact with](#network-mapper) the [Otterize network mapper](/features/network-mapping-network-policies/tutorials/k8s-network-mapper) running in a Kubernetes cluster.
-- [Transform](#otterize-intents-convert--f-path) [intents files](/reference/intents-and-intents-files/#intents-file-formats) from plain YAML format to Kubernetes custom resource YAML format.
+- [Transform](#otterize-intents-convert--f-path) [intents files](/overview/intent-based-access-control) from plain YAML format to Kubernetes custom resource YAML format.
 - Interact with the Otterize Cloud, through its REST API.
 
 This CLI is open-source software. To see its source or build it yourself,
@@ -141,7 +141,7 @@ Here's the image generated by running `otterize network-mapper visualize -n otte
 ### `otterize network-mapper export [--format] [-n <namespace1>,<namespace2>,...] [-o <path>] [--output-type <output-type>]`
 
 Return the network map built by the network mapper since it started, or since it was reset,
-as YAML [client intents file(s)](/reference/intents-and-intents-files/#intents-file-formats) or as JSON file(s).
+as YAML [client intents file(s)](/overview/intent-based-access-control) or as JSON file(s).
 
 #### Options
 

docs/reference/configuration/intents-operator/README.mdx

@@ -38,7 +38,7 @@ You can override the service name the intents operator uses when it computes net
 ### Network policies
 The intents operator automatically creates, updates and deletes network policies, and automatically labels client and server pods, to reflect precisely the client-to-server calls declared in client intents files.
 
-The intents operator can also be configured to process client intents *without* creating and managing network policies, to provide visibility on what would happen once enforcement via network policies is activated. More information can be found in the [shadow vs active enforcement documentation](/shadow-vs-active-enforcement).
+The intents operator can also be configured to process client intents *without* creating and managing network policies, to provide visibility on what would happen once enforcement via network policies is activated. More information can be found in the [shadow vs active enforcement documentation](/reference/shadow-vs-active-enforcement).
 
 In the example above, the `checkoutservice` intends to call the `shippingservice`. When the CRD is applied through `kubectl apply`, the intents operator labels the `checkoutservice` and `shippingservice` pods, and creates a network policy for the ingress of the `shippingservice` that references these labels and allows calls to the `shippingservice` from the `checkoutservice`.
 
@@ -50,7 +50,7 @@ label, `intents.otterize.com/access-server-<servicename>-<servicehash>`, is appl
 to access the server. This label is used as the selector to determine which client pods are allowed to access the server
 pod.
 
-Learn more: [Network policies deep dive](/reference/access-controls/network-policies)
+Learn more: [Network policies deep dive](/features/network-mapping-network-policies/reference/Network-Policies-Deep-Dive)
 #### Handling external traffic
 The intents operator has automatic behavior for allowing external traffic for pods which have indicated that they are supposed to accept external traffic, such as by creating a `Service` of type `NodePort` or `LoadBalancer`, or an `Ingress` resource.
 
@@ -65,7 +65,7 @@ This behavior can be disabled using the Helm chart's values.
 ### Kafka mTLS & ACLs
 The intents operator automatically creates, updates, and deletes ACLs in Kafka clusters running within your Kubernetes cluster according to the declared intents. It does not modify other ACLs. It works together with the [Otterize credentials operator](/reference/configuration/credentials-operator) to easily enable secure access to Kafka from client pods, all in your Kubernetes cluster.
 
-The intents operator can also be configured to process client intents *without* creating and managing Kafka ACLs, to provide visibility on what would happen once enforcement via Kafka ACLs is activated. More information can be found in the [shadow vs active enforcement documentation](/shadow-vs-active-enforcement).
+The intents operator can also be configured to process client intents *without* creating and managing Kafka ACLs, to provide visibility on what would happen once enforcement via Kafka ACLs is activated. More information can be found in the [shadow vs active enforcement documentation](/reference/shadow-vs-active-enforcement).
 
 The Otterize credentials operator automatically registers client pods with the credentials service &mdash; either a SPIRE server, or the Otterize Cloud-managed credentials service &mdash; and writes the trusted credentials generated by that service into Kubernetes secrets for use by those pods. The intents operator takes `ClientIntents` with `type: kafka` and creates Kafka ACLs that grant the requested access to the cryptographic identities (SVIDs) created by the credentials operator.
 
@@ -83,7 +83,7 @@ Try the [Just-in-time PostgreSQL users & access](/features/postgresql/tutorials/
 ### Istio AuthorizationPolicy
 The intents operator automatically creates, updates and deletes Istio authorization policies, automatically looks up service accounts for client pods and labels server pods, to reflect precisely the client-to-server calls declared in client intents files.
 
-The intents operator can also be configured to process client intents *without* creating and managing Istio authorization policies, to provide visibility on what would happen once enforcement via Istio authorization policy is activated. More information can be found in the [shadow vs active enforcement documentation](/shadow-vs-active-enforcement).
+The intents operator can also be configured to process client intents *without* creating and managing Istio authorization policies, to provide visibility on what would happen once enforcement via Istio authorization policy is activated. More information can be found in the [shadow vs active enforcement documentation](/reference/shadow-vs-active-enforcement).
 
 In the example above, the `checkoutservice` intends to call the `shippingservice`. When the CRD is applied through `kubectl apply`, the intents operator labels the `shippingservice` pod, looks up `checkoutservice`'s service account, and creates an authorization policy for the ingress of the `shippingservice` that references the service account and allows calls to the `shippingservice` from the `checkoutservice`.
 

docs/reference/shadow-vs-active-enforcement/README.mdx

@@ -113,6 +113,6 @@ This will place a default-deny network policy on the server, and at the same tim
 
 ![Otterize Cloud - access graph - checkout service protected](/img/shadow-vs-active-enforcement/access-graph-protected-checkoutservice.png)
 
-You can read more about the access graph in the [Otterize Cloud](/otterize-cloud) documentation.
+You can read more about the access graph in the [Otterize Cloud](/overview/otterize-cloud) documentation.
 
-And for a quick guide that shows how to use shadow enforcement to roll out IBAC gradually and controllably, see [Protecting one service with network policies](/guides/protect-1-service-network-policies).
+And for a quick guide that shows how to use shadow enforcement to roll out IBAC gradually and controllably, see [Protecting one service with network policies](/features/network-mapping-network-policies/tutorials/protect-1-service-network-policies).

docs/reference/terminology/README.mdx

@@ -15,7 +15,7 @@ An Otterize service is the logical "atom" of service-to-service authentication a
 The [Otterize CLI](/reference/cli) is a command-line utility used to control and interact with the Otterize network mapper, manipulate local Intents files, and (coming soon!) interact with Otterize Cloud.
 
 ### Intent (or client intent)
-Otterize intents are a way to declare that one service intends to call another service. Otterize uses them to apply authorization rules to enable the calls to go through, and block any unintended calls. An *intent* refers to a client declaring a particular call to a server; *all* a given client's intents to the servers it intends to call are collected in a single *client intents file*. [Learn more about intents](/reference/intents-and-intents-files).
+Otterize intents are a way to declare that one service intends to call another service. Otterize uses them to apply authorization rules to enable the calls to go through, and block any unintended calls. An *intent* refers to a client declaring a particular call to a server; *all* a given client's intents to the servers it intends to call are collected in a single *client intents file*. [Learn more about intents](/overview/intent-based-access-control).
 
 ### Integrations
 Otterize Cloud supports two types of integrations: Kubernetes integrations and generic integrations. Kubernetes integrations connect a Kubernetes cluster to Otterize Cloud, allowing communication with the Otterize operators. Generic integrations connect external systems to Otterize Cloud, providing API/CLI access credentials. These integrations are named based on their usage and must have unique names within an organization.
@@ -55,7 +55,7 @@ to Kafka resources such as topics.
 
 ## Kubernetes
 ### Custom resource
-A Kubernetes custom resource refers to a resource that is not present in the base distribution of Kubernetes (such as Deployment or Pod), but comes with an installed operator. The [Otterize ClientIntents](/reference/intents-and-intents-files/) are one such resource. [Read more about Kubernetes custom resources here](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
+A Kubernetes custom resource refers to a resource that is not present in the base distribution of Kubernetes (such as Deployment or Pod), but comes with an installed operator. The [Otterize ClientIntents](/overview/intent-based-access-control) are one such resource. [Read more about Kubernetes custom resources here](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
 
 ### CNI (Container Network Interface)
 CNI is a CNCF project that provides libraries for implementing plugins for configuring network interfaces in Linux containers, and is used by Kubernetes to provide pods running in a cluster with network connectivity.