added links in the tech overview (#475)

Author: anners

technical-overview.md

@@ -10,24 +10,26 @@ And because Edera doesn’t rely on nested virtualization, it runs wherever cont
 
 ## How Edera Works
 
-At its core, Edera uses a custom hypervisor based on Xen, with key components rewritten in Rust for safety, performance, and maintainability. Edera introduces the concept of **zones**—independent, fast-booting virtual machines that serve as security boundaries for container workloads.
+At its core, Edera uses a [custom hypervisor](https://edera.dev/stories/rust-or-bust-our-rewrite-of-the-xen-control-plane) based on [Xen](https://edera.dev/stories/why-edera-built-on-xen-a-secure-container-foundation), with key components rewritten in Rust for safety, performance, and maintainability. Edera introduces the concept of **zones**—independent, fast-booting virtual machines that serve as security boundaries for container workloads.
 
 Each zone runs its own Linux kernel and minimal init system. The kernel and other system components are delivered via OCI images, keeping things composable, cacheable, and consistent.
 
-Zones are paravirtualized using the Xen PV protocol. This keeps them lightweight and fast—no hardware virtualization required. But when hardware support is available (e.g., on x86 with VT-x), Edera uses it to get near bare-metal performance.
+Zones are [paravirtualized](https://docs.edera.dev/concepts/paravirtualization/) using the Xen PV protocol. This keeps them lightweight and fast—no hardware virtualization required. But when hardware support is available (e.g., on x86 with VT-x), Edera uses it to get near bare-metal performance.
 
 ## How Edera Runs & Secures Containers
 
 Edera allows you to compose your infrastructure the same way you compose workloads: using OCI images.
 
 Each zone consumes a small number of OCI images:
+
 - A **kernel image** that provides the zone kernel.
 - One or more **system extension images** that provide init systems, utilities, and kernel modules.
 - Optionally, **driver zones**—zones that provide shared services (like networking) to other zones.
 
-Inside each zone, container workloads run via a minimal OCI runtime called **Styrolite**, written in Rust. Unlike traditional setups (like Kata Containers, which layer containerd and runc as external processes), Styrolite is embedded inside the zone itself.
+Inside each zone, container workloads run via a minimal OCI runtime called [**Styrolite**]((https://github.com/edera-dev/styrolite/)), written in Rust. Unlike traditional setups (like Kata Containers, which layer containerd and runc as external processes), Styrolite is embedded inside the zone itself.
 
 ### Key Benefits of This Design
+
 - No external container runtime processes  
 - Zone init system directly manages containers  
 - Minimal attack surface, optimized for secure execution
@@ -68,19 +70,26 @@ This causes the pod to be scheduled to a node running Edera’s hypervisor. The
 An Edera zone is a minimal VM built from OCI-delivered components. At launch time, the Edera daemon unpacks:
 
 ### Kernel Image
+
 Located under `/kernel` in the OCI image:
+
 - `image`: the Linux kernel (vmlinuz)
 - `metadata`: key-value pairs for boot parameters
 - `addons.squashfs`: includes kernel modules in `/modules`
 - `config.gz`: the kernel configuration file
 
 ### Initramfs Contents
+
 Packaged in a CPIO archive, typically mounted from:
 `usr/lib/edera/protect/zone/initrd`
 
 The initramfs includes:
+
 - `/init`: static Rust binary that initializes the zone
 - `/bin/styrolite`: embedded container runtime
 - `/bin/zone`: control plane for managing containers and services via IDM (inter-domain messaging)
 
 This structure lets Edera launch zones rapidly, with well-defined boundaries and no dependency on the host OS kernel. Everything the workload touches is defined, versioned, and validated.
+
+---
+If you want to know more check out our [docs site](https://docs.edera.dev)