diff --git a/docs/content/en/docs/advanced-config/_index.md b/docs/content/en/docs/advanced-config/_index.md
deleted file mode 100644
index 08e17764300..00000000000
--- a/docs/content/en/docs/advanced-config/_index.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-title: "Advanced Configuration"
-weight: 4
-icon: "observability"
-description: "Tetragon deployment configuration options"
----
diff --git a/docs/content/en/docs/concepts/enforcement/_index.md b/docs/content/en/docs/concepts/enforcement/_index.md
index a9ff913857c..2a739e9149d 100644
--- a/docs/content/en/docs/concepts/enforcement/_index.md
+++ b/docs/content/en/docs/concepts/enforcement/_index.md
@@ -1,7 +1,7 @@
 ---
 title: "Enforcement"
 icon: "overview"
-weight: 5
+weight: 4
 description: "Documentation for Tetragon enforcement system"
 ---
 
diff --git a/docs/content/en/docs/concepts/tetragon-events/_index.md b/docs/content/en/docs/concepts/events/_index.md
similarity index 83%
rename from docs/content/en/docs/concepts/tetragon-events/_index.md
rename to docs/content/en/docs/concepts/events/_index.md
index 434d8c4b601..6ce8ef5fdd8 100644
--- a/docs/content/en/docs/concepts/tetragon-events/_index.md
+++ b/docs/content/en/docs/concepts/events/_index.md
@@ -1,7 +1,7 @@
 ---
-title: "Tetragon Events"
+title: "Events"
 icon: "overview"
-weight: 3
+weight: 1
 description: "Documentation for Tetragon event system"
 ---
 
diff --git a/docs/content/en/docs/concepts/events/grpc-events.md b/docs/content/en/docs/concepts/events/grpc-events.md
new file mode 100644
index 00000000000..836e0c67aea
--- /dev/null
+++ b/docs/content/en/docs/concepts/events/grpc-events.md
@@ -0,0 +1,8 @@
+---
+title: "gRPC Events"
+weight: 3
+icon: "reference"
+description: "Tetragon gRPC events"
+---
+
+A gRPC endpoint is exposed by the agent and is configurable.
diff --git a/docs/content/en/docs/concepts/tetragon-events/json-events.md b/docs/content/en/docs/concepts/events/json-events.md
similarity index 100%
rename from docs/content/en/docs/concepts/tetragon-events/json-events.md
rename to docs/content/en/docs/concepts/events/json-events.md
diff --git a/docs/content/en/docs/tutorials/tetragon-metrics.md b/docs/content/en/docs/concepts/metrics.md
similarity index 83%
rename from docs/content/en/docs/tutorials/tetragon-metrics.md
rename to docs/content/en/docs/concepts/metrics.md
index 4dd3ef636d0..34838765b88 100644
--- a/docs/content/en/docs/tutorials/tetragon-metrics.md
+++ b/docs/content/en/docs/concepts/metrics.md
@@ -1,14 +1,18 @@
 ---
-title: "Tetragon Metrics"
-weight: 1
+title: "Metrics"
 icon: "overview"
-description: "Fetching and understanding Tetragon metrics"
+weight: 2
+description: "Documentation for Tetragon metrics"
 ---
 
+Tetragon's metrics are exposed to the system through an HTTP endpoint. These
+are used to expose event summaries and information about the state of the
+Tetragon agent.
+
 ## Kubernetes
 
-Tetragon pods expose a  metrics endpoint by default. The chart also creates a service named `tetragon`
-that exposes metrics on the specified port. 
+Tetragon pods exposes a metrics endpoint by default. The chart also creates a
+service named `tetragon` that exposes metrics on the specified port.
 
 ### Getting metrics port
 
@@ -25,8 +29,8 @@ tetragon   ClusterIP   10.96.54.218   <none>        2112/TCP    3m
 ```
 
 {{< note >}}
-In the previous output it shows, 2112 is the port on which the service is 
-listening. It is also the port on which the Tetragon metrics server listens 
+In the previous output it shows, 2112 is the port on which the service is
+listening. It is also the port on which the Tetragon metrics server listens
 with the default Helm values.
 {{< /note >}}
 
@@ -40,11 +44,11 @@ kubectl -n kube-system port-forward service/tetragon 2112:2112
 
 ## Package
 
-By default, metrics are disabled, which can be enabled using `--metrics-server` 
+By default, metrics are disabled, which can be enabled using `--metrics-server`
 flag, by specifying the address.
 
 Alternatively, the [examples/configuration/tetragon.yaml](https://github.com/cilium/tetragon/blob/main/examples/configuration/tetragon.yaml)
-file contains example entries showing the defaults for the address of 
+file contains example entries showing the defaults for the address of
 metrics-server. Local overrides can be created by editing and copying this file
 into `/etc/tetragon/tetragon.yaml`, or by editing and copying "drop-ins" from
 the [examples/configuration/tetragon.conf.d](https://github.com/cilium/tetragon/tree/main/examples/configuration/tetragon.conf.d)
@@ -62,25 +66,25 @@ sudo tetragon --metrics-server localhost:2112
 The output should be similar to this:
 
 ```
-time="2023-09-21T13:17:08+05:30" level=info msg="Starting tetragon" 
+time="2023-09-21T13:17:08+05:30" level=info msg="Starting tetragon"
 version=v0.11.0
-time="2023-09-21T13:17:08+05:30" level=info msg="config settings" 
+time="2023-09-21T13:17:08+05:30" level=info msg="config settings"
 config="mapeased
-time="2023-09-22T23:16:24+05:30" level=info msg="Starting metrics server" 
-addr="localhost:2112" 
+time="2023-09-22T23:16:24+05:30" level=info msg="Starting metrics server"
+addr="localhost:2112"
 [...]
 time="2023-09-21T13:17:08+05:30" level=info msg="Listening for events..."
 ```
 
-Alternatively, a file named `server-address` can be created in `etc/tetragon/tetragon.conf.d/metrics-server` with content specifying 
-a port like this `localhost:2112`, or any port of your choice as mentioned 
+Alternatively, a file named `server-address` can be created in `etc/tetragon/tetragon.conf.d/metrics-server` with content specifying
+a port like this `localhost:2112`, or any port of your choice as mentioned
 above.
 
 ## Fetch the Metrics
 
-After the metrics are exposed, either by port forwarding in case of 
-Kubernetes installation or by setting metrics address in case of Package 
-installation, the metrics can be fetched using 
+After the metrics are exposed, either by port forwarding in case of
+Kubernetes installation or by setting metrics address in case of Package
+installation, the metrics can be fetched using
 `curl` on `localhost:2112/metrics`:
 
 ```shell-session
diff --git a/docs/content/en/docs/concepts/metrics/_index.md b/docs/content/en/docs/concepts/metrics/_index.md
deleted file mode 100644
index c36851262e8..00000000000
--- a/docs/content/en/docs/concepts/metrics/_index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: "Tetragon Metrics"
-icon: "overview"
-weight: 3
-description: "Documentation for Tetragon metrics"
----
-
-Tetragon's metrics are exposed to the system through an HTTP endpoint these are
-used to expose event summaries and information about the state of the
-Tetragon agent.
diff --git a/docs/content/en/docs/concepts/tetragon-events/grpc-events.md b/docs/content/en/docs/concepts/tetragon-events/grpc-events.md
deleted file mode 100644
index 8656363ddc8..00000000000
--- a/docs/content/en/docs/concepts/tetragon-events/grpc-events.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-title: "GRPC Events"
-weight: 3
-icon: "reference"
-description: "Tetragon GRPC events"
----
-
-A GRPC endpoint is exposed by the agent and is configurable.
diff --git a/docs/content/en/docs/getting-started/enforcement.md b/docs/content/en/docs/getting-started/enforcement.md
index eec35ff50fc..bfc23664888 100644
--- a/docs/content/en/docs/getting-started/enforcement.md
+++ b/docs/content/en/docs/getting-started/enforcement.md
@@ -1,19 +1,19 @@
 ---
 title: "Policy Enforcement"
-weight: 2
+weight: 6
 description: "Policy Enforcement"
 ---
 
 This adds a network and file policy enforcement on top of execution, file tracing
 and networking policy already deployed in the quick start.  In this use case we use
-a namespace filter to limit the scope of the enforcement policy to just the 'darkstar'
+a namespace filter to limit the scope of the enforcement policy to just the `darkstar`
 cluster we installed the demo application in from the
 [Quick Kubernetes Install]({{< ref "docs/getting-started/install-k8s" >}}).
 
 This highlights two important concepts of Tetragon. First in kernel filtering
 provides a key performance improvement by limiting events from kernel to user
 space. But, also allows for enforcing policies in the kernel. By issueing a
-SIGKILL to the binary at this point the application will be stopped from
+`SIGKILL` to the process at this point the application will be stopped from
 continuing to run. If the operation is triggered through a syscall this means
 the application will not return from the syscall and will be terminated.
 
@@ -22,20 +22,21 @@ segment a policy to apply to targeted namespaces and pods. This is critical
 for effective policy segmentation.
 
 For implementation details see the [Enforcement]({{< ref "/docs/concepts/enforcement" >}})
-section.
+concept section.
 
 ## Kubernetes Enforcement
 
-The following section is layed out with the following: A guide to promote the
-network observation policy that observer all network traffic egressing the
-cluster to enforce this policy. A guide to promote the file access monitoring
-policy to block write and read operations to sensitive files.
+The following section is layed out with the following:
+- A guide to promote the network observation policy that observer all network
+  traffic egressing the cluster to enforce this policy.
+- A guide to promote the file access monitoring policy to block write and read
+  operations to sensitive files.
 
-### Kubernetes Block TCP Connect outside Cluster
+### Block TCP Connect outside Cluster
 
 First we will deploy the [Network Monitoring]({{< ref "docs/getting-started/network" >}})
 policy with enforcement on. For this case the policy is written to only apply
-against the 'empire' namespace. This limits the scope of the policy for the
+against the `empire` namespace. This limits the scope of the policy for the
 getting started guide.
 
 Ensure we have the proper Pod CIDRs
@@ -46,86 +47,81 @@ export PODCIDR=`kubectl get nodes -o jsonpath='{.items[*].spec.podCIDR}'`
 
  and Service CIDRs configured.
 
-{{< tabpane text=true >}}
-{{% tab GKE %}}
-
-```shell-session
+{{< tabpane lang=shell-session >}}
+{{< tab GKE >}}
 export SERVICECIDR=$(gcloud container clusters describe ${NAME} --zone ${ZONE} --project ${PROJECT} | awk '/servicesIpv4CidrBlock/ { print $2; }')
-```
-{{% /tab %}}
+{{< /tab >}}
 
-{{% tab Kind %}}
-```shell-session
+{{< tab Kind >}}
 export SERVICECIDR=$(kubectl describe pod -n kube-system kube-apiserver-kind-control-plane | awk -F= '/--service-cluster-ip-range/ {print $2; }')
-```
 {{< /tab >}}
 {{< /tabpane >}}
 
 Then we can apply the egress cluster enforcement policy
 
 ```shell-session
-wget http://github.com/cilium/tetragon/quickstart/network_egress_cluster_enforce.yaml
+wget http://github.com/cilium/tetragon/examples/quickstart/network_egress_cluster_enforce.yaml
 envsubst < network_egress_cluster_enforce.yaml | kubectl apply -n default -f -
 ```
 
-With the enforcement policy applied we can attach tetra to observe events again,
+With the enforcement policy applied we can attach tetra to observe events again:
 
 ```shell-session
- kubectl exec -ti -n kube-system ds/tetragon -c tetragon -- tetra getevents -o compact --pods xwing
+kubectl exec -ti -n kube-system ds/tetragon -c tetragon -- tetra getevents -o compact --pods xwing
 ```
 
-And once again execute a curl command in the xwing,
+And once again execute a curl command in the xwing:
 
 ```shell-session
 kubectl exec -ti xwing -- bash -c 'curl https://ebpf.io/applications/#tetragon'
 ```
 
-The command returns an error code because the egress TCP connects are blocked shown here
-```shell-session
-$ kubectl exec -ti xwing -- bash -c 'curl https://ebpf.io/applications/#tetragon'
+The command returns an error code because the egress TCP connects are blocked shown here.
+```
 command terminated with exit code 137
 ```
 
-connect inside the cluster will work as expected,
+Connect inside the cluster will work as expected,
 
 ```shell-session
 kubectl exec -ti xwing -- bash -c 'curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing'
 ```
 
-The Tetra CLI will print the curl and annotate that the process that was issued a Sigkill. The successful internal connect is filtered and will not be shown.
+The Tetra CLI will print the curl and annotate that the process that was issued
+a Sigkill. The successful internal connect is filtered and will not be shown.
 
-``` shell
-🚀 process default/xwing /bin/bash -c "curl https://ebpf.io/applications/#tetragon" 
-🚀 process default/xwing /usr/bin/curl https://ebpf.io/applications/#tetragon 
-🔌 connect default/xwing /usr/bin/curl tcp 10.32.0.28:45200 -> 104.198.14.52:443 
-💥 exit    default/xwing /usr/bin/curl https://ebpf.io/applications/#tetragon SIGKILL 
-🚀 process default/xwing /bin/bash -c "curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing" 
-🚀 process default/xwing /usr/bin/curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing 
+```
+🚀 process default/xwing /bin/bash -c "curl https://ebpf.io/applications/#tetragon"
+🚀 process default/xwing /usr/bin/curl https://ebpf.io/applications/#tetragon
+🔌 connect default/xwing /usr/bin/curl tcp 10.32.0.28:45200 -> 104.198.14.52:443
+💥 exit    default/xwing /usr/bin/curl https://ebpf.io/applications/#tetragon SIGKILL
+🚀 process default/xwing /bin/bash -c "curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing"
+🚀 process default/xwing /usr/bin/curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing
 ```
 
-The enforces TCP connects see [Enforce Sandbox]({{< ref "#enforce-common-security-policy" >}}) below to further restrict possible
-workaround such as writing through /dev devices and raw sockets application may
-attempt.
+The enforces TCP connects see [Enforce Sandbox]({{< ref "#enforce-common-security-policy" >}})
+below to further restrict possible workaround such as writing through /dev
+devices and raw sockets application may attempt.
 
 ### Enforce File Access Monitoring
 
 The following extends the example from [File Access Monitoring]({{< ref "docs/getting-started/file-events" >}})
 with enforcement to ensure sensitive files are not read. The policy used is the
-[`file-monitoring-enforce.yaml`](https://github.com/cilium/tetragon/blob/main/quickstart/file-monitoring-enforce.yaml)
+[`file-monitoring-enforce.yaml`](https://github.com/cilium/tetragon/blob/main/examples/quickstart/file-monitoring-enforce.yaml)
 it can be reviewed and extended as needed. The only difference between the
 observation policy and the enforce policy is the addition of an action block
 to sigkill the application and return an error on the op.
 
-To apply the policy.
+To apply the policy:
 
 {{< tabpane lang=shell-session >}}
 
-{{< tab Kubernetes >}}          
-kubectl delete -f http://github.com/cilium/tetragon/quickstart/file_monitoring.yaml
-kubectl apply -f http://github.com/cilium/tetragon/quickstart/file_monitoring_enforce.yaml
-{{< /tab >}}                                                                                                                                                                                   
-{{< tab Docker >}}          
-wget http://github.com/cilium/tetragon/quickstart/file-monitoring.yaml
+{{< tab Kubernetes >}}
+kubectl delete -f http://github.com/cilium/tetragon/examples/quickstart/file_monitoring.yaml
+kubectl apply -f http://github.com/cilium/tetragon/examples/quickstart/file_monitoring_enforce.yaml
+{{< /tab >}}
+{{< tab Docker >}}
+wget http://github.com/cilium/tetragon/examples/quickstart/file-monitoring.yaml
 docker stop tetragon-container
 docker run --name tetragon-container --rm --pull always \
   --pid=host --cgroupns=host --privileged               \
@@ -138,10 +134,10 @@ docker run --name tetragon-container --rm --pull always \
 With the file applied we can attach tetra to observe events again,
 
 {{< tabpane lang=shell-session >}}
-{{< tab Kubernetes >}}          
- kubectl exec -ti -n kube-system ds/tetragon -c tetragon -- tetra getevents -o compact --pods xwing
+{{< tab Kubernetes >}}
+kubectl exec -ti -n kube-system ds/tetragon -c tetragon -- tetra getevents -o compact --pods xwing
 {{< /tab >}}
-{{< tab Docker >}}          
+{{< tab Docker >}}
 docker exec tetragon-container tetra getevents -o compact
 {{< /tab >}}
 {{< /tabpane >}}
@@ -149,47 +145,52 @@ docker exec tetragon-container tetra getevents -o compact
 Then reading a sensitive file,
 
 {{< tabpane lang=shell-session >}}
-{{< tab Kubernetes >}}          
- kubectl exec -ti xwing -- bash -c 'cat /etc/shadow'
+{{< tab Kubernetes >}}
+kubectl exec -ti xwing -- bash -c 'cat /etc/shadow'
 {{< /tab >}}
-{{< tab Docker >}}          
+{{< tab Docker >}}
 cat /etc/shadow
 {{< /tab >}}
 {{< /tabpane >}}
 
 The command will fail with an error code because this is one of our sensitive files,
+```shell-session
+kubectl exec -ti xwing -- bash -c 'cat /etc/shadow'
+```
+
+The output should be similar to:
+
 ```
-$ kubectl exec -ti xwing -- bash -c 'cat /etc/shadow'
 command terminated with exit code 137
 ```
 
 This will generate a read event (Docker events will omit Kubernetes metadata),
 
-```shell-session
-🚀 process default/xwing /bin/bash -c "cat /etc/shadow"                   
-🚀 process default/xwing /bin/cat /etc/shadow                             
-📚 read    default/xwing /bin/cat /etc/shadow                             
-📚 read    default/xwing /bin/cat /etc/shadow                             
-📚 read    default/xwing /bin/cat /etc/shadow                             
+```
+🚀 process default/xwing /bin/bash -c "cat /etc/shadow"
+🚀 process default/xwing /bin/cat /etc/shadow
+📚 read    default/xwing /bin/cat /etc/shadow
+📚 read    default/xwing /bin/cat /etc/shadow
+📚 read    default/xwing /bin/cat /etc/shadow
 💥 exit    default/xwing /bin/cat /etc/shadow SIGKILL
 ```
 
 Writes and reads to files not part of the enforced file policy will not be
 impacted.
 
-```shell-session
-🚀 process default/xwing /bin/bash -c "echo foo >> bar; cat bar"          
-🚀 process default/xwing /bin/cat bar                                     
-💥 exit    default/xwing /bin/cat bar 0                          
-💥 exit    default/xwing /bin/bash -c "echo foo >> bar; cat bar" 0 
+```
+🚀 process default/xwing /bin/bash -c "echo foo >> bar; cat bar"
+🚀 process default/xwing /bin/cat bar
+💥 exit    default/xwing /bin/cat bar 0
+💥 exit    default/xwing /bin/bash -c "echo foo >> bar; cat bar" 0
 ```
 
-# What's next
+## What's next
 
-The completes the quick start guides. At this point we should be able to observe
-execution traces in a Kubernetes cluster and extend the base deployment of
-Tetragon with policies to observe and enforce different aspects of a Kubernetes
-system.
+The completes the quick start guides. At this point we should be able to
+observe execution traces in a Kubernetes cluster and extend the base deployment
+of Tetragon with policies to observe and enforce different aspects of a
+Kubernetes system.
 
 The rest of the docs provide further documentation about installation and
 using policies. Some useful links:
diff --git a/docs/content/en/docs/getting-started/execution.md b/docs/content/en/docs/getting-started/execution.md
index 570ab3cd425..6cbae6c4e1b 100644
--- a/docs/content/en/docs/getting-started/execution.md
+++ b/docs/content/en/docs/getting-started/execution.md
@@ -1,13 +1,13 @@
 ---
-title: "Execution monitoring"
-weight: 2
-description: "Execution Traces with Tetragon"
+title: "Execution Monitoring"
+weight: 3
+description: "Execution traces with Tetragon"
 ---
 
 At the core of Tetragon is the tracking of all executions in a kubernetes cluster,
 virtual machines, and baremetal systems. This creates the foundation that allows
 Tetragon to attribute all system behavior back to a specific binary and its
-associated metadata (container, pod, node, and cluster).
+associated metadata (container, Pod, Node, and cluster).
 
 ## Observe Tetragon Execution Events
 
@@ -19,10 +19,10 @@ The following command can be used to observe exec events.
 {{< tabpane lang=shell-session >}}
 {{< tab Kubernetes >}}
 kubectl exec -ti -n kube-system ds/tetragon -c tetragon -- tetra getevents -o compact --pods xwing
-{{< /tab >}}                                                                                                                                                                                   
+{{< /tab >}}
 {{< tab Docker >}}
 docker exec tetragon-container tetra getevents -o compact
-{{< /tab >}}                                                                                                                                                                                   
+{{< /tab >}}
 {{< /tabpane >}}
 
 This will print a compact form of the exec logs. For an example we do the following
@@ -31,20 +31,20 @@ with the demo application.
 
 {{< tabpane lang=shell-session >}}
 {{< tab Kubernetes >}}
- kubectl exec -ti xwing -- bash -c 'curl https://ebpf.io/applications/#tetragon
-{{< /tab >}}                                                                                                                                                                                   
+kubectl exec -ti xwing -- bash -c 'curl https://ebpf.io/applications/#tetragon'
+{{< /tab >}}
 {{< tab Docker >}}
 curl https://ebpf.io/applications/#tetragon
-{{< /tab >}}                                                                                                                                                                                   
+{{< /tab >}}
 {{< /tabpane >}}
 
-The CLI will print a compact form of the event to the terminal
-
-```shell-session
-🚀 process default/xwing /bin/bash -c "curl https://ebpf.io/applications/#tetragon" 
-🚀 process default/xwing /usr/bin/curl https://ebpf.io/applications/#tetragon 
-💥 exit    default/xwing /usr/bin/curl https://ebpf.io/applications/#tetragon 60 
+The CLI will print a compact form of the event to the terminal similar to the
+following output.
 
+```
+🚀 process default/xwing /bin/bash -c "curl https://ebpf.io/applications/#tetragon"
+🚀 process default/xwing /usr/bin/curl https://ebpf.io/applications/#tetragon
+💥 exit    default/xwing /usr/bin/curl https://ebpf.io/applications/#tetragon 60
 ```
 
 The compact exec event contains the event type, the pod name, the binary and the args. The exit event will include the return code, in the case of curl `60` above.
@@ -52,12 +52,12 @@ The compact exec event contains the event type, the pod name, the binary and the
 For the complete exec event in JSON format remove the compact option.
 
 {{< tabpane lang=shel-session >}}
-{{< tab Kubernetes >}}          
+{{< tab Kubernetes >}}
 kubectl exec -ti -n kube-system ds/tetragon -c tetragon -- tetra getevents
-{{< /tab >}}                                                                                                                                                                                   
-{{< tab Docker >}}          
+{{< /tab >}}
+{{< tab Docker >}}
 docker exec tetragon-container tetra getevents
-{{< /tab >}}                                                                                                                                                                                   
+{{< /tab >}}
 {{< /tabpane >}}
 
 This will include a lot more details related the binary and event. A full example of the above curl is hown here,
@@ -149,4 +149,7 @@ Labels among other useful metadata.
 
 ## What's next
 
-Execution events are the most basic event Tetragon can produce. To see how to use tracing policies to enable file monitoring see the [File Access Monitoring]({{< ref "/docs/getting-started/file-events" >}})quickstart. To see a network policy check the [Networking Monitoring]({{< ref "/docs/getting-started/network" >}}) quickstart.
+Execution events are the most basic event Tetragon can produce. To see how to
+use tracing policies to enable file monitoring see the
+[File Access Monitoring]({{< ref "/docs/getting-started/file-events" >}}) quickstart.
+To see a network policy check the [Networking Monitoring]({{< ref "/docs/getting-started/network" >}}) quickstart.
diff --git a/docs/content/en/docs/getting-started/file-events.md b/docs/content/en/docs/getting-started/file-events.md
index 690f50ce2b6..2441f1a38df 100644
--- a/docs/content/en/docs/getting-started/file-events.md
+++ b/docs/content/en/docs/getting-started/file-events.md
@@ -1,7 +1,7 @@
 ---
 title: "File Access Monitoring"
-weight: 2
-description: "File Access Traces with Tetragon"
+weight: 4
+description: "File access traces with Tetragon"
 ---
 
 Tracing Policies can be added to Tetragon through YAML configuration files
@@ -10,11 +10,11 @@ do filtering in kernel to ensure only interesting events are published
 to userspace from the BPF programs running in kernel. This ensures overhead
 remains low even on busy systems.
 
-# File Access Monitoring
-
 The following extends the example from Execution Tracing with a policy to
-monitor sensitive files in Linux. The policy used is the [`file-monitoring.yaml`](https://github.com/cilium/tetragon/blob/main/quickstart/file-monitoring.yaml) it can be reviewed and extended
-as needed. Files monitored here serve as a good base set of files.
+monitor sensitive files in Linux. The policy used is the
+[`file-monitoring.yaml`](https://github.com/cilium/tetragon/blob/main/examples/quickstart/file-monitoring.yaml)
+it can be reviewed and extended as needed. Files monitored here serve as a good
+base set of files.
 
 To apply the policy Kubernetes uses a CRD that can be applied with kubectl.
 Uses the same YAML configuration as Kuberenetes, but loaded through a file
@@ -22,11 +22,11 @@ on disk.
 
 {{< tabpane lang=shell-session >}}
 
-{{< tab Kubernetes >}}          
-kubectl apply -f http://github.com/cilium/tetragon/quickstart/file-monitoring.yaml
-{{< /tab >}}                                                                                                                                                                                   
-{{< tab Docker >}}          
-wget http://github.com/cilium/tetragon/quickstart/file-monitoring.yaml
+{{< tab Kubernetes >}}
+kubectl apply -f http://github.com/cilium/tetragon/examples/quickstart/file-monitoring.yaml
+{{< /tab >}}
+{{< tab Docker >}}
+wget http://github.com/cilium/tetragon/examples/quickstart/file-monitoring.yaml
 docker stop tetragon-container
 docker run --name tetragon-container --rm --pull always \
   --pid=host --cgroupns=host --privileged               \
@@ -36,40 +36,41 @@ docker run --name tetragon-container --rm --pull always \
 {{< /tab >}}
 {{< /tabpane >}}
 
-With the file applied we can attach tetra to observe events again,
+With the file applied we can attach tetra to observe events again:
 
 {{< tabpane lang=shell-session >}}
-{{< tab Kubernetes >}}          
- kubectl exec -ti -n kube-system ds/tetragon -c tetragon -- tetra getevents -o compact --pods xwing
+{{< tab Kubernetes >}}
+kubectl exec -ti -n kube-system ds/tetragon -c tetragon -- tetra getevents -o compact --pods xwing
 {{< /tab >}}
-{{< tab Docker >}}          
+{{< tab Docker >}}
 docker exec tetragon-container tetra getevents -o compact
 {{< /tab >}}
 {{< /tabpane >}}
 
-Then reading a sensitive file,
+Then reading a sensitive file:
 
 {{< tabpane lang=shell-session >}}
-{{< tab Kubernetes >}}          
- kubectl exec -ti xwing -- bash -c 'cat /etc/shadow'
+{{< tab Kubernetes >}}
+kubectl exec -ti xwing -- bash -c 'cat /etc/shadow'
 {{< /tab >}}
-{{< tab Docker >}}          
+{{< tab Docker >}}
 cat /etc/shadow
 {{< /tab >}}
 {{< /tabpane >}}
 
 This will generate a read event (Docker events will omit Kubernetes metadata),
 
-```shell-session
+```
 🚀 process default/xwing /bin/bash -c "cat /etc/shadow"
 🚀 process default/xwing /bin/cat /etc/shadow
 📚 read    default/xwing /bin/cat /etc/shadow
 💥 exit    default/xwing /bin/cat /etc/shadow 0
 ```
 
-Attempts to write in sensitive directories will similar create an event. For example attempting to write in '/etc'.
+Attempts to write in sensitive directories will similar create an event. For
+example attempting to write in `/etc`.
 
-```shell-session
+```
 🚀 process default/xwing /bin/bash -c "echo foo >>  /etc/bar"
 📝 write   default/xwing /bin/bash /etc/bar
 📝 write   default/xwing /bin/bash /etc/bar
diff --git a/docs/content/en/docs/getting-started/install-docker.md b/docs/content/en/docs/getting-started/install-docker.md
index 9204a5ad878..96b5857229a 100644
--- a/docs/content/en/docs/getting-started/install-docker.md
+++ b/docs/content/en/docs/getting-started/install-docker.md
@@ -1,6 +1,6 @@
 ---
 title: "Quick Local Docker Install"
-weight: 1
+weight: 2
 description: "Discover and experiment with Tetragon on your local Linux host"
 ---
 
@@ -21,7 +21,7 @@ and how to run Tetragon on a Mac computer in [this section of the FAQ page](/doc
 The easiest way to start experimenting with Tetragon is to run it via Docker
 using the released container images.
 
-```shell
+```shell-session
 docker run --name tetragon-container --rm --pull always \
     --pid=host --cgroupns=host --privileged             \
     -v /sys/kernel/btf/vmlinux:/var/lib/tetragon/btf    \
@@ -31,6 +31,6 @@ docker run --name tetragon-container --rm --pull always \
 This will start Tetragon in a privileged container. Priviliges are required
 to load and attach BPF programs. See Installation section for more details.
 
-## Whats Next
+## What's Next
 
-[Check for execution events.]({{< ref "/docs/getting-started/execution" >}}).
+Check for [execution events]({{< ref "/docs/getting-started/execution" >}}).
diff --git a/docs/content/en/docs/getting-started/install-k8s.md b/docs/content/en/docs/getting-started/install-k8s.md
index 100a40251d8..ff253e11e21 100644
--- a/docs/content/en/docs/getting-started/install-k8s.md
+++ b/docs/content/en/docs/getting-started/install-k8s.md
@@ -6,7 +6,8 @@ description: "Discover and experiment with Tetragon in a kubernetes environment"
 
 ### Create a cluster
 
-If you don’t have a Kubernetes Cluster yet, you can use the instructions below to create a Kubernetes cluster locally or using a managed Kubernetes service:
+If you don’t have a Kubernetes Cluster yet, you can use the instructions below
+to create a Kubernetes cluster locally or using a managed Kubernetes service:
 
 {{< tabpane text=true >}}
 {{% tab GKE %}}
@@ -65,9 +66,18 @@ several seconds for some pods until they satisfy all the dependencies:
 
 ```shell-session
 kubectl get pods
+```
+
+The output should be similar to this:
+
+```
 NAME                         READY   STATUS    RESTARTS   AGE
 deathstar-6c94dcc57b-7pr8c   1/1     Running   0          10s
 deathstar-6c94dcc57b-px2vw   1/1     Running   0          10s
 tiefighter                   1/1     Running   0          10s
 xwing                        1/1     Running   0          10s
 ```
+
+## What's Next
+
+Check for [execution events]({{< ref "/docs/getting-started/execution" >}}).
diff --git a/docs/content/en/docs/getting-started/network.md b/docs/content/en/docs/getting-started/network.md
index 7b35bb068bd..1c3170f2c30 100644
--- a/docs/content/en/docs/getting-started/network.md
+++ b/docs/content/en/docs/getting-started/network.md
@@ -1,15 +1,14 @@
 ---
 title: "Network Monitoring"
-weight: 2
-description: "Network Access Traces with Tetragon"
+weight: 5
+description: "Network access traces with Tetragon"
 ---
 
-This adds a network policy on top of execution and file tracing
-already deployed in the quick start. In this case we monitor
-all network traffic outside the Kubernetes pod CIDR and service
-CIDR.
+This adds a network policy on top of execution and file tracing already
+deployed in the quick start. In this case we monitor all network traffic
+outside the Kubernetes pod CIDR and service CIDR.
 
-# Kubernetes Cluster Network Access Monitoring
+## Kubernetes Cluster Network Access Monitoring
 
 First we must find the pod CIDR and service CIDR in use. The pod
 IP CIDR can be found relatively easily in many cases.
@@ -21,34 +20,27 @@ export PODCIDR=`kubectl get nodes -o jsonpath='{.items[*].spec.podCIDR}'`
 The services CIDR can then be fetched depending on environment. We
 require environment variables ZONE, PROJECT, and NAME from install steps.
 
-{{< tabpane text=true >}}
-{{% tab GKE %}}
+{{< tabpane lang=shell-session >}}
 
-```shell-session
+{{< tab GKE >}}
 export SERVICECIDR=$(gcloud container clusters describe ${NAME} --zone ${ZONE} --project ${PROJECT} | awk '/servicesIpv4CidrBlock/ { print $2; }')
-```
-{{% /tab %}}
+{{< /tab >}}
 
-{{% tab Kind %}}
-```shell-session
+{{< tab Kind >}}
 export SERVICECIDR=$(kubectl describe pod -n kube-system kube-apiserver-kind-control-plane | awk -F= '/--service-cluster-ip-range/ {print $2; }')
-```
-{{% /tab %}}
+{{< /tab >}}
 
 {{< /tabpane >}}
 
-First we apply a policy that includes the podCIDR and serviceIP list as filters
-to avoid filter out cluster local traffic. To apply the policy,
+First we apply a policy that includes the `podCIDR` and `serviceIP` list as
+filters to avoid filter out cluster local traffic. To apply the policy:
 
-{{< tabpane lang=shell-session >}}
-
-{{< tab Kubernetes >}}          
-wget http://github.com/cilium/tetragon/quickstart/network_egress_cluster.yaml
+```shell-session
+wget http://github.com/cilium/tetragon/examples/quickstart/network_egress_cluster.yaml
 envsubst < network_egress_cluster.yaml | kubectl apply -f -
-{{< /tab >}}
-{{< /tabpane >}}
+```
 
-With the file applied we can attach tetra to observe events again,
+With the file applied we can attach tetra to observe events again:
 
 ```shell-session
  kubectl exec -ti -n kube-system ds/tetragon -c tetragon -- tetra getevents -o compact --pods xwing --processes curl
@@ -61,9 +53,9 @@ sites.
  kubectl exec -ti xwing -- bash -c 'curl https://ebpf.io/applications/#tetragon'
 ```
 
-A connect will be observed in the tetra shell
+A connect will be observed in the tetra shell:
 
-```shell-session
+```
 🚀 process default/xwing /usr/bin/curl https://ebpf.io/applications/#tetragon
 🔌 connect default/xwing /usr/bin/curl tcp 10.32.0.19:33978 -> 104.198.14.52:443
 💥 exit    default/xwing /usr/bin/curl https://ebpf.io/applications/#tetragon 60
@@ -74,23 +66,28 @@ traffic by issuing a curl to one of our services and noting there is no connect
 event.
 
 ```shell-session
-$ kubectl exec -ti xwing -- bash -c 'curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing'
+kubectl exec -ti xwing -- bash -c 'curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing'
+```
+
+The output should be similar to:
+
+```
 Ship landed
 ```
 
-And as expected no new events,
+And as expected no new events:
 
-```shell-session
+```
 🚀 process default/xwing /usr/bin/curl https://ebpf.io/applications/#tetragon
 🔌 connect default/xwing /usr/bin/curl tcp 10.32.0.19:33978 -> 104.198.14.52:443
 💥 exit    default/xwing /usr/bin/curl https://ebpf.io/applications/#tetragon 60
 ```
 
-# Docker/Baremetal Network Access Monitoring
+## Docker/Baremetal Network Access Monitoring
 
 This example also works easily for local docker users as well except it is not as
 obvious to the quickstart authors what IP address CIDR will be useful. The policy
-by default will filter all local IPs '127.0.0.1' from the event log. So we can
+by default will filter all local IPs `127.0.0.1` from the event log. So we can
 demo that here.
 
 Set env variables to local loopback IP.
@@ -101,10 +98,11 @@ export SERVICECIDR="127.0.0.1/32"
 
 To create the policy,
 ```shell-session
-wget http://github.com/cilium/tetragon/quickstart/network_egress_cluster.yaml
+wget http://github.com/cilium/tetragon/examples/quickstart/network_egress_cluster.yaml
 envsubst < network_egress_cluster.yaml > network_egress_cluster_subst.yaml
 ```
-Start Tetragon with the new policy,
+
+Start Tetragon with the new policy:
 ```shell-session
 docker stop tetragon-container
 docker run --name tetragon-container --rm --pull always \
@@ -112,19 +110,21 @@ docker run --name tetragon-container --rm --pull always \
   -v ${PWD}/network_egress_cluster_subst.yaml:/etc/tetragon/tetragon.tp.d/network_egress_cluster_subst.yaml \
   -v /sys/kernel/btf/vmlinux:/var/lib/tetragon/btf      \
   quay.io/cilium/tetragon-ci:latest
-
 ```
+
 Attach to the tetragon output
 ```shell-session
 docker exec tetragon-container tetra getevents -o compact
 ```
+
 Now remote TCP connections will be logged and local IPs filters. Executing a curl
 to generate a remote TCP connect.
 ```shell-session
 curl https://ebpf.io/applications/#tetragon
 ```
+
 Produces the following output:
-```shell-session
+```
 🚀 process  /usr/bin/curl https://ebpf.io/applications/#tetragon
 🔌 connect  /usr/bin/curl tcp 192.168.1.190:36124 -> 104.198.14.52:443
 💥 exit     /usr/bin/curl https://ebpf.io/applications/#tetragon 0
diff --git a/docs/content/en/docs/installation/Docker/_index.md b/docs/content/en/docs/installation/Docker/_index.md
deleted file mode 100644
index 14152f0c34a..00000000000
--- a/docs/content/en/docs/installation/Docker/_index.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-title: "Docker"
-linkTitle: "Docker"
-isShownInList: false
-weight: 3
-description: >
-  Tetragon instructions for running from Docker container,
----
-
diff --git a/docs/content/en/docs/installation/Kubernetes/_index.md b/docs/content/en/docs/installation/Kubernetes/_index.md
deleted file mode 100644
index f05b5d74314..00000000000
--- a/docs/content/en/docs/installation/Kubernetes/_index.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-title: "Kubernetes"
-linkTitle: "Kubernetes"
-isShownInList: false
-weight: 1
-description: >
-  Tetragon installation instructions for Kubernetes,
----
-
diff --git a/docs/content/en/docs/installation/Systemd/_index.md b/docs/content/en/docs/installation/Systemd/_index.md
deleted file mode 100644
index bdcbfcb0922..00000000000
--- a/docs/content/en/docs/installation/Systemd/_index.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-title: "Systemd"
-linkTitle: "Systemd"
-isShownInList: false
-weight: 2
-description: >
-  Tetragon installation instructions for Systemd deployments.
----
-
diff --git a/docs/content/en/docs/installation/_index.md b/docs/content/en/docs/installation/_index.md
index 045a6b32214..954d1f0a2b2 100644
--- a/docs/content/en/docs/installation/_index.md
+++ b/docs/content/en/docs/installation/_index.md
@@ -1,9 +1,5 @@
 ---
-title: "Installion"
-linkTitle: "Installion"
-isShownInList: false
+title: "Installation"
 weight: 2
-description: >
-  Installation instructions and guides.
+description: "Tetragon installation and deployment configuration options"
 ---
-
diff --git a/docs/content/en/docs/advanced-config/container.md b/docs/content/en/docs/installation/container.md
similarity index 94%
rename from docs/content/en/docs/advanced-config/container.md
rename to docs/content/en/docs/installation/container.md
index 3aaa9a748b4..b0a69266ed3 100644
--- a/docs/content/en/docs/advanced-config/container.md
+++ b/docs/content/en/docs/installation/container.md
@@ -14,7 +14,7 @@ To run a stable version, please check [Tetragon quay repository](https://quay.io
 and select which version you want. For example if you want to run the latest
 version which is `{{< latest-version >}}` currently.
 
-```shell
+```shell-session
 docker run --name tetragon --rm -d                   \
     --pid=host --cgroupns=host --privileged          \
     -v /sys/kernel/btf/vmlinux:/var/lib/tetragon/btf \
@@ -28,7 +28,7 @@ To run unstable development versions of Tetragon, use the
 This will run the image that was built from the latest commit available on the
 Tetragon main branch.
 
-```shell
+```shell-session
 docker run --name tetragon --rm -d                  \
    --pid=host --cgroupns=host --privileged          \
    -v /sys/kernel/btf/vmlinux:/var/lib/tetragon/btf \
@@ -48,7 +48,7 @@ There are multiple ways to set configuration options:
 1. Append Tetragon controlling settings at the end of the command
 
     As an example set the file where to export JSON events with `--export-filename` argument:
-    ```shell
+    ```shell-session
     docker run --name tetragon --rm -d \
         --pid=host --cgroupns=host --privileged \
         -v /sys/kernel:/sys/kernel \
@@ -61,7 +61,7 @@ There are multiple ways to set configuration options:
 
 2. Environment variables
 
-    ```shell
+    ```shell-session
     docker run --name tetragon --rm -d \
         --pid=host --cgroupns=host --privileged \
         --env "TETRAGON_EXPORT_FILENAME=/var/log/tetragon/tetragon.log" \
@@ -77,7 +77,7 @@ There are multiple ways to set configuration options:
 
     On the host machine set the configuration drop-ins inside `/etc/tetragon/tetragon.conf.d/` directory according to the [configuration examples](/docs/reference/tetragon-configuration/#configuration-examples), then mount it as volume:
 
-    ```shell
+    ```shell-session
     docker run --name tetragon --rm -d \
         --pid=host --cgroupns=host --privileged \
         -v /sys/kernel:/sys/kernel \
@@ -89,7 +89,3 @@ There are multiple ways to set configuration options:
 
 See [Tetragon daemon configuration](/docs/reference/tetragon-configuration) reference for further details.
 
-## What's next
-
-- See [Explore security observability events](/docs/concepts/tetragon-events/)
-to learn how to see the Tetragon events.
diff --git a/docs/content/en/docs/advanced-config/kubernetes.md b/docs/content/en/docs/installation/kubernetes.md
similarity index 95%
rename from docs/content/en/docs/advanced-config/kubernetes.md
rename to docs/content/en/docs/installation/kubernetes.md
index 5e93fcecf14..9269f9787fa 100644
--- a/docs/content/en/docs/advanced-config/kubernetes.md
+++ b/docs/content/en/docs/installation/kubernetes.md
@@ -22,14 +22,14 @@ in the Tetragon repository. You can use any of the values and override them
 with `--set KEY1=VALUE1,KEY2=VALUE2`.
 {{< /note >}}
 
-```shell
+```shell-session
 helm repo add cilium https://helm.cilium.io
 helm repo update
 helm install tetragon cilium/tetragon -n kube-system
 ```
 
 To wait until Tetragon deployment is ready, use the following `kubectl` command:
-```shell
+```shell-session
 kubectl rollout status -n kube-system ds/tetragon -w
 ```
 
@@ -48,14 +48,14 @@ for details and solutions.
 You can then make modifications to the Tetragon configuration using `helm
 upgrade`, see the following example.
 
-```shell
+```shell-session
 helm upgrade tetragon cilium/tetragon -n kube-system --set tetragon.grpc.address=localhost:1337
 ```
 
 You can also edit the `tetragon-config` ConfigMap directly and restart the
 Tetragon daemonset with:
 
-```shell
+```shell-session
 kubectl edit cm tetragon-config -n kube-system
 kubectl rollout restart ds/tetragon -n kube-system
 ```
@@ -64,7 +64,7 @@ kubectl rollout restart ds/tetragon -n kube-system
 
 Upgrade Tetragon using a new specific version of the helm chart.
 
-```shell
+```shell-session
 helm upgrade tetragon cilium/tetragon -n kube-system --version 0.9.0
 ```
 
@@ -72,6 +72,6 @@ helm upgrade tetragon cilium/tetragon -n kube-system --version 0.9.0
 
 Uninstall Tetragon using the following command.
 
-```shell
+```shell-session
 helm uninstall tetragon -n kube-system
 ```
diff --git a/docs/content/en/docs/advanced-config/package.md b/docs/content/en/docs/installation/package.md
similarity index 95%
rename from docs/content/en/docs/advanced-config/package.md
rename to docs/content/en/docs/installation/package.md
index 523c70f7ce7..849a2df3a87 100644
--- a/docs/content/en/docs/advanced-config/package.md
+++ b/docs/content/en/docs/installation/package.md
@@ -17,14 +17,14 @@ Tetragon as of version 1.0 supports amd64 and arm64 architectures.
 
 1. First download the latest binary tarball, using `curl` for example to download the `amd64` release:
 
-   ```shell
+   ```shell-session
    curl -LO https://github.com/cilium/tetragon/releases/download/{{< latest-version >}}/tetragon-{{< latest-version >}}-amd64.tar.gz
    ```
 
 2. Extract the downloaded archive, and start the install script to install
    Tetragon. Feel free to inspect the script before starting it.
 
-   ```shell
+   ```shell-session
    tar -xvf tetragon-{{< latest-version >}}-amd64.tar.gz
    cd tetragon-{{< latest-version >}}-amd64/
    sudo ./install.sh
@@ -38,7 +38,7 @@ Tetragon as of version 1.0 supports amd64 and arm64 architectures.
 
 3. Finally, you can check the Tetragon systemd service.
 
-   ```shell
+   ```shell-session
    sudo systemctl status tetragon
    ```
 
@@ -80,19 +80,19 @@ To upgrade Tetragon:
 
 1. Download the new tarball.
 
-   ```shell
+   ```shell-session
    curl -LO https://github.com/cilium/tetragon/releases/download/{{< latest-version >}}/tetragon-{{< latest-version >}}-amd64.tar.gz
    ```
 
 2. Stop the Tetragon service.
 
-   ```shell
+   ```shell-session
    sudo systemctl stop tetragon
    ```
 
 3. Remove the old Tetragon version.
 
-   ```shell
+   ```shell-session
    sudo rm -fr /usr/lib/systemd/system/tetragon.service
    sudo rm -fr /usr/local/bin/tetragon
    sudo rm -fr /usr/local/lib/tetragon/
@@ -100,7 +100,7 @@ To upgrade Tetragon:
 
 4. Install the upgraded Tetragon version.
 
-   ```shell
+   ```shell-session
    tar -xvf tetragon-{{< latest-version >}}-amd64.tar.gz
    cd tetragon-{{< latest-version >}}-amd64/
    sudo ./install.sh
@@ -111,7 +111,7 @@ To upgrade Tetragon:
 To completely remove Tetragon run the `uninstall.sh` script that is provided
 inside the tarball.
 
-```shell
+```shell-session
 sudo ./uninstall.sh
 ```
 
@@ -129,7 +129,7 @@ sudo rm -fr /usr/local/lib/tetragon/
 
 To just purge custom settings:
 
-```shell
+```shell-session
 sudo rm -fr /etc/tetragon/
 ```
 
@@ -143,7 +143,7 @@ Tetragon tarball by default listens on `unix:///var/run/tetragon/tetragon.sock`
 
 To access the gRPC API with `tetra` client, set `--server-address` to point to the corresponding address:
 
-   ```
+   ```shell-session
    sudo tetra --server-address unix:///var/run/tetragon/tetragon.sock getevents
    ```
 
@@ -156,19 +156,19 @@ Logs are always rotated into the same directory.
 
 To read real-time JSON events, tailing the logs file is enough.
 
-   ```shell
+   ```shell-session
    sudo tail -f /var/log/tetragon/tetragon.log
    ```
 
 Tetragon also ships a gRPC client that can be used to receive events.
 
 1. To print events in `json` format using `tetra` gRPC client:
-   ```shell
+   ```shell-session
    sudo tetra --server-address "unix:///var/run/tetragon/tetragon.sock" getevents
    ```
 
 2. To print events in human compact format:
-   ```shell
+   ```shell-session
    sudo tetra --server-address "unix:///var/run/tetragon/tetragon.sock" getevents -o compact
    ```
 
diff --git a/docs/content/en/docs/installation/Systemd/install-tetra-cli.md b/docs/content/en/docs/installation/tetra-cli.md
similarity index 98%
rename from docs/content/en/docs/installation/Systemd/install-tetra-cli.md
rename to docs/content/en/docs/installation/tetra-cli.md
index a74ea9e5f2c..3f0cf9d4ffa 100644
--- a/docs/content/en/docs/installation/Systemd/install-tetra-cli.md
+++ b/docs/content/en/docs/installation/tetra-cli.md
@@ -1,6 +1,6 @@
 ---
 title: "Install tetra CLI"
-weight: 5
+weight: 4
 description: "To interact with Tetragon, install the Tetragon client CLI tetra"
 ---
 
@@ -22,7 +22,7 @@ Linux distribution but you can usually find them respectively under the package
 `curl` and `coreutils`.
 {{< /note >}}
 
-```shell
+```shell-session
 GOOS=$(go env GOOS)
 GOARCH=$(go env GOARCH)
 curl -L --remote-name-all https://github.com/cilium/tetragon/releases/latest/download/tetra-${GOOS}-${GOARCH}.tar.gz{,.sha256sum}
@@ -89,7 +89,7 @@ tar -xz tetra-windows-arm64.tar.gz
 fetch precompiled binaries. You can also use it to build from sources (using the
 `--build-from-source` flag) with a Go dependency.
 
-```shell
+```shell-session
 brew install tetra
 ```
 
@@ -101,7 +101,7 @@ at the following URL: https://github.com/cilium/tetragon/releases.
 To download a specific release you can use the following script, replacing the
 `OS`, `ARCH` and `TAG` values with your desired options.
 
-```shell
+```shell-session
 OS=linux
 ARCH=amd64
 TAG=v0.9.0
diff --git a/docs/content/en/docs/tutorials/software-bill-of-materials.md b/docs/content/en/docs/tutorials/software-bill-of-materials.md
index b10e08547d2..fdc947870e4 100644
--- a/docs/content/en/docs/tutorials/software-bill-of-materials.md
+++ b/docs/content/en/docs/tutorials/software-bill-of-materials.md
@@ -1,6 +1,6 @@
 ---
 title: "Software bill of materials"
-weight: 2
+weight: 4
 icon: "reference"
 description: "Download and verify the signature of the software bill of materials"
 ---
diff --git a/docs/content/en/docs/tutorials/try-tetragon-linux.md b/docs/content/en/docs/tutorials/try-tetragon-linux.md
new file mode 100644
index 00000000000..21debbaf1a8
--- /dev/null
+++ b/docs/content/en/docs/tutorials/try-tetragon-linux.md
@@ -0,0 +1,394 @@
+---
+title: "Try Tetragon on Linux"
+weight: 2
+description: "Discover and experiment with Tetragon on your local Linux host"
+---
+
+{{< caution >}}
+This guide is not a tutorial on how to deploy Tetragon standalone (i.e. without
+Kubernetes), you can see the [container deployment]({{< ref "/docs/installation/container" >}})
+and [package deployment]({{< ref "/docs/installation/package" >}}) guides for
+that. This is just a walkthrough to try and experiment Tetragon for the first
+time.
+{{< /caution >}}
+
+{{< note >}}
+This guide has been tested on Ubuntu 22.04 and 22.10 with respectively kernel
+`5.15.0` and `5.19.0` on amd64 and arm64 but
+[any recent distribution](https://github.com/libbpf/libbpf#bpf-co-re-compile-once--run-everywhere)
+shipping with a relatively recent kernel should work. See the FAQ for further details on
+the [recommended kernel versions]({{< ref "/docs/faq#what-is-the-minimum-linux-kernel-version-to-run-tetragon" >}}).
+
+Note that you cannot run Tetragon using Docker Desktop on macOS because of a
+limitation of the Docker Desktop Linux virtual machine. Learn more about this issue
+and how to run Tetragon on a Mac computer in [this section of the FAQ page](/docs/faq/#can-i-run-tetragon-on-mac-computers).
+{{< /note >}}
+
+## Start Tetragon
+
+The easiest way to start experimenting with Tetragon is to run it via Docker
+using the released container images. If you prefer running directly the
+binaries without Docker, please refer to the
+[development setup](/docs/contribution-guide/development-setup) to see how to
+build the binaries.
+
+```shell
+docker run --name tetragon-container --rm --pull always \
+    --pid=host --cgroupns=host --privileged             \
+    -v /sys/kernel/btf/vmlinux:/var/lib/tetragon/btf    \
+    quay.io/cilium/tetragon-ci:latest
+```
+
+Let's break down the previous command:
+- `--name tetragon-container` names our container so that we can refer to it
+  later via a simple name.
+- `--rm` will make Docker delete the container once it exists.
+- `--pull always` will force Docker to download the latest existing image
+  corresponding to the `latest` mutable tag.
+- `--pid=host` is needed to read the procfs for gathering context on processes
+  started before Tetragon.
+- `--cgroupns=host` is needed to detect container feature.
+- `--privileged` is needed for Tetragon to load its BPF programs.
+- `-v /sys/kernel/btf/vmlinux:/var/lib/tetragon/btf` mounts the BTF file inside
+  the Tetragon container filesystem. Tetragon needs a BTF file corresponding to
+  your kernel version to load its BPF programs.
+- `quay.io/cilium/tetragon-ci:latest` is the latest version of Tetragon built
+  from the main branch.
+
+## Observe Tetragon base events
+
+With this default configuration, Tetragon already loaded its base sensors to
+perform [process lifecycle observability]({{< ref "docs/use-cases/process-lifecycle" >}}).
+
+To quickly see the events, you can use the `tetra` CLI already shipped in the
+Tetragon container that was just started, it will connect to the Tetragon gRPC
+server listening on `localhost:54321`. In another terminal, type the following
+command:
+
+```shell
+docker exec tetragon-container tetra getevents -o compact
+```
+
+In a different terminal, you can start a shell like `sh` and start executing
+programs. Here, the commands executed in the shell where `ls`, `uname -a`,
+`whoami`, and `exit`, the output should be similar to this:
+
+```
+🚀 process  /usr/bin/sh
+🚀 process  /usr/bin/ls
+💥 exit     /usr/bin/ls  0
+🚀 process  /usr/bin/uname -a
+💥 exit     /usr/bin/uname -a 0
+🚀 process  /usr/bin/whoami
+💥 exit     /usr/bin/whoami  0
+💥 exit     /usr/bin/sh  0
+```
+
+You can see the start of `sh` first, then the execution of the multiple
+programs, `ls`, `uname` and `whoami`, and finally the exit of `sh`.
+
+{{< note >}}
+Since Tetragon monitors all processes on the host, you may observe events
+unrelated to what was typed in the shell session. Indeed, Tetragon is
+monitoring every process start and exit in your environment.
+{{< /note >}}
+
+## Write a TracingPolicy to extend Tetragon events
+
+Tetragon by default observes only process lifecycles. More advanced use-cases,
+require configuring Tetragon via TracingPolicies. A TracingPolicy is a
+user-configurable Kubernetes custom resource (CR) that allows users to access
+additional functionality, such as tracing arbitrary events in the kernel and,
+optionally, define actions to take on a match. These actions can be, for
+example, used to implement enforcement.
+
+{{< note >}}
+For more details about TracingPolicies and how to write them, refer to the
+[TracingPolicy documentation]({{< ref "/docs/concepts/tracing-policy" >}}).
+{{< /note >}}
+
+### Observability with TracingPolicy
+
+Let's start with a simple policy:
+
+```yaml
+apiVersion: cilium.io/v1alpha1
+kind: TracingPolicy
+metadata:
+  name: "cat-open"
+spec:
+  kprobes:
+  - call: "sys_openat"
+    syscall: true
+    args:
+    - index: 0
+      type: "int"
+    - index: 1
+      type: "string"
+    - index: 2
+      type: "int"
+    selectors:
+    - matchBinaries:
+      - operator: In
+        values:
+        - "/usr/bin/cat"
+```
+
+Copy this policy in a file named `tracing_policy.yaml` in your current working
+directory and restart Tetragon with the following command:
+
+```shell
+docker run --name tetragon-container --rm --pull always \
+    --pid=host --cgroupns=host --privileged             \
+    -v $PWD/tracing_policy.yaml:/tracing_policy.yaml    \
+    -v /sys/kernel/btf/vmlinux:/var/lib/tetragon/btf    \
+    quay.io/cilium/tetragon-ci:latest                   \
+    --tracing-policy /tracing_policy.yaml
+```
+
+We added two flags to our commands:
+- `-v $(pwd)/tracing_policy.yaml:/tracing_policy.yaml` mounts the created local
+  file into the container filesystem.
+- `--tracing-policy /tracing_policy.yaml` indicates Tetragon to load the policy in
+  the provided file.
+
+Now again, in another terminal, open the `tetra` CLI to see the new events
+generated by Tetragon, monitoring the `openat` system call.
+
+```shell
+docker exec tetragon-container tetra getevents -o compact
+```
+
+And in the third terminal, just read the `tracing_policy.yaml` file we created
+using cat with:
+```shell
+cat tracing_policy.yaml
+```
+
+The output from the `tetra` CLI should be similar to:
+
+```
+🚀 process  /usr/bin/cat tracingpolicy.yaml
+📬️ openat   /usr/bin/cat /etc/ld.so.cache
+📬️ openat   /usr/bin/cat /lib/aarch64-linux-gnu/libc.so.6
+📬️ openat   /usr/bin/cat tracingpolicy.yaml
+💥 exit     /usr/bin/cat tracingpolicy.yaml 0
+```
+
+{{< note >}}
+The syscall we choose is `openat` and not `open` because the glibc and most of
+the implementations of the standard C library use the `openat` syscall for
+their `open` wrapper. So `cat` on Linux is using `openat`.
+{{< /note >}}
+
+We can see that during the execution of `cat`, because it is dynamically
+linked, it used the `openat` syscall to open:
+- the cache file for shared libraries `ld.so.cache`;
+- the `libc.so.6` library;
+- the file we actually wanted to read `tracing_policy.yaml`.
+
+This is the kind of information we could obtain by executing the program with
+`strace` for example, but here Tetragon obtains this information directly from
+the kernel, transparently for the executed program.
+
+Please note that `tetra` CLI, with the `-o compact` output format,
+automatically tried to decode the second argument as a string and printed it
+because it has the hardcoded knowledge that the `openat` syscall has an
+interesting string as second argument.
+
+You can use `tetra getevents` to retrieve the whole JSON events and see the
+complete fields and values retrieved from the event. In our situation the
+output should be similar to the following.
+
+```json
+{
+  "process_kprobe": {
+    "process": {
+      "exec_id": "OjEwMTgzOTUyNjg1NjcwNDoyNjIzNw==",
+      "pid": 26237,
+      "uid": 1000,
+      "cwd": "/home/ubuntu",
+      "binary": "/usr/bin/cat",
+      "arguments": "tracing_policy.yaml",
+      "flags": "execve clone",
+      "start_time": "2023-04-06T18:30:03.405730761Z",
+      "auid": 1000,
+      "parent_exec_id": "OjEwMTczMDEyNTQ3MjUxMDoyNjIwOA==",
+      "refcnt": 1
+    },
+    "parent": {
+      "exec_id": "OjEwMTczMDEyNTQ3MjUxMDoyNjIwOA==",
+      "pid": 26208,
+      "uid": 1000,
+      "cwd": "/home/ubuntu",
+      "binary": "/bin/bash",
+      "flags": "execve clone",
+      "start_time": "2023-04-06T18:28:14.004347210Z",
+      "auid": 1000,
+      "parent_exec_id": "OjEwMTczMDEwMjc2NTg0NjoyNjIwNw==",
+      "refcnt": 2
+    },
+    "function_name": "__x64_sys_openat",
+    "args": [
+      {
+        "int_arg": -100
+      },
+      {
+        "string_arg": "tracing_policy.yaml"
+      },
+      {
+        "int_arg": 0
+      }
+    ],
+    "action": "KPROBE_ACTION_POST"
+  },
+  "time": "2023-04-06T18:30:03.406205829Z"
+}
+```
+
+You can see that Tetragon collected information on the process itself, with for
+example, the uid, the binary name, the start_time and much more. It also
+indicates process parent, `/bin/bash` in this case. This is the common base of
+information we also get from the process lifecycle sensors. Finally, we can see
+that Tetragon hooked the function `__x64_sys_openat` (for an arm64 host it
+would be `__arm64_sys_openat`) and that it also collected the arguments' value.
+
+### Enforcement with TracingPolicy
+
+Let's see how we can modify the previous TracingPolicy to do enforcement with
+Tetragon.
+
+{{< warning >}}
+This example is just an illustration and should not be used in a production
+environment.  There are many challenges in building a production-grade policy,
+that go beyond the scope of this guide. For example, filtering an argument for
+security can be difficult, especially with file paths. The `openat` syscall can
+take relative paths as arguments and even absolute path filtering can often be
+bypassed by pseudo filesystems like procfs, for example using a prefix like
+`/proc/self/root/` to access `/`.
+{{< /warning >}}
+
+#### Overriding return values
+
+First, let's say we don't want to stop any program that would try to open the
+`tracing_policy.yaml` but just stop them from actually using the syscall to
+open the file, as if they were not unauthorized to access the file. We could
+write the following TracingPolicy.
+
+```yaml
+apiVersion: cilium.io/v1alpha1
+kind: TracingPolicy
+metadata:
+  name: "file-access"
+spec:
+  kprobes:
+  - call: "sys_openat"
+    syscall: true
+    args:
+    - index: 0
+      type: "int"
+    - index: 1
+      type: "string"
+    selectors:
+    - matchBinaries:
+      - operator: In
+        values:
+        - "/usr/bin/cat"
+      matchArgs:
+      - index: 1
+        operator: "Equal"
+        values:
+        - "tracing_policy.yaml\0"
+      matchActions:
+      - action: Override
+        argError: -1
+```
+
+In the above TracingPolicy, we removed the third argument because we don't
+need to extract it specifically, and we added two filters in our existing
+selector. One `matchArgs` to filter on the value of the index 1 argument, which
+contains the pathname to access, and one `matchActions` to perform on action on
+a such match.
+
+Replace the content of the policy in the `tracing_policy.yaml` file with the
+above and restart Tetragon with the same command as before. If we open tetra
+with `docker exec tetragon-container tetra getevents -o compact` and perform a
+`cat tracing_policy.yaml` on the side, we should now observe an output similar
+to:
+
+```
+🚀 process  /usr/bin/cat tracing_policy.yaml
+📬️ openat   /usr/bin/cat tracing_policy.yaml
+💥 exit     /usr/bin/cat tracing_policy.yaml 1
+```
+
+And the `cat tracing_policy.yaml` should return the following error:
+
+```
+cat: tracing_policy.yaml: Operation not permitted
+```
+
+
+#### Synchronously stopping the process
+
+Now, let's say that accessing this file in this manner is critical and we want
+to stop any process that tries to perform such action immediately. We just need
+to modify the `action` in the `matchActions` filter from `Override` to
+`Sigkill`.
+
+```yaml
+apiVersion: cilium.io/v1alpha1
+kind: TracingPolicy
+metadata:
+  name: "file-access"
+spec:
+  kprobes:
+  - call: "sys_openat"
+    syscall: true
+    args:
+    - index: 0
+      type: "int"
+    - index: 1
+      type: "string"
+    selectors:
+    - matchBinaries:
+      - operator: In
+        values:
+        - "/usr/bin/cat"
+      matchArgs:
+      - index: 1
+        operator: "Equal"
+        values:
+        - "tracing_policy.yaml\0"
+      matchActions:
+      - action: Sigkill
+```
+
+Again, replace the content of the policy in the `tracing_policy.yaml` file with
+the above and restart Tetragon with the same command as before. If we open
+tetra with `docker exec tetragon-container tetra getevents -o compact` and
+perform a `cat tracing_policy.yaml` on the side, we should now observe an
+output similar to:
+
+```
+🚀 process  /usr/bin/cat tracing_policy.yaml
+📬️ openat   /usr/bin/cat tracing_policy.yaml
+💥 exit     /usr/bin/cat tracing_policy.yaml SIGKILL
+```
+
+And the `cat tracing_policy.yaml` should return an error (that is actually
+returned by the shell that invoked the program):
+
+```
+Killed
+```
+
+Now the process will not have the time to catch the error and will be
+synchronously terminated as soon as he triggers the kernel function we hooked
+with our specified argument values.
+
+{{< caution >}}
+Again, the specific filtering is only given as an example, just reading the
+file using `cat ./tracing_policy.yaml` will bypass the policies presented here.
+{{< /caution >}}
+
diff --git a/docs/content/en/docs/tutorials/verify-tetragon-image-signatures.md b/docs/content/en/docs/tutorials/verify-tetragon-image-signatures.md
index 9ce3b7c671c..89672f97ac1 100644
--- a/docs/content/en/docs/tutorials/verify-tetragon-image-signatures.md
+++ b/docs/content/en/docs/tutorials/verify-tetragon-image-signatures.md
@@ -1,6 +1,6 @@
 ---
 title: "Verify Tetragon image signatures"
-weight: 1
+weight: 3
 icon: "overview"
 description: "Learn how to verify Tetragon container images signatures."
 ---
diff --git a/quickstart/file_monitoring.yaml b/examples/quickstart/file_monitoring.yaml
similarity index 100%
rename from quickstart/file_monitoring.yaml
rename to examples/quickstart/file_monitoring.yaml
diff --git a/quickstart/file_monitoring_enforce.yaml b/examples/quickstart/file_monitoring_enforce.yaml
similarity index 100%
rename from quickstart/file_monitoring_enforce.yaml
rename to examples/quickstart/file_monitoring_enforce.yaml
diff --git a/quickstart/network_egress_cluster.yaml b/examples/quickstart/network_egress_cluster.yaml
similarity index 100%
rename from quickstart/network_egress_cluster.yaml
rename to examples/quickstart/network_egress_cluster.yaml
diff --git a/quickstart/network_egress_cluster_enforce.yaml b/examples/quickstart/network_egress_cluster_enforce.yaml
similarity index 100%
rename from quickstart/network_egress_cluster_enforce.yaml
rename to examples/quickstart/network_egress_cluster_enforce.yaml