diff --git a/ai-edge/dns-setup.mdx b/ai-edge/dns-setup.mdx
new file mode 100644
index 0000000..696642e
--- /dev/null
+++ b/ai-edge/dns-setup.mdx
@@ -0,0 +1,280 @@
+---
+title: "DNS Setup for AI Edge"
+description: "Create a DNS zone, apex ALIAS record, and subdomain CNAME to point a domain at a Datum AI Edge endpoint."
+---
+
+This guide prepares a domain for use with a Datum AI Edge by creating a DNS zone, an apex ALIAS record, and a subdomain CNAME — all pointing at the AI Edge endpoint.
+
+<Note>
+This guide assumes your domain is already delegated to Datum nameservers. See [DNS](/domain-dns/dns) for nameserver details and ALIAS record behavior.
+</Note>
+
+---
+
+## Prerequisites
+
+- `datumctl` installed and authenticated
+- A valid **Project**
+- Domain delegated to Datum nameservers
+
+---
+
+## Configuration Steps
+
+### Step 1: Set Variables
+
+The `TARGET` value is your AI Edge endpoint hostname. Find it in the Datum portal under your AI Edge's generated hostname, or via:
+
+```bash
+datumctl get httpproxy <name> --namespace default -o yaml
+```
+
+#### Windows (PowerShell)
+
+```powershell
+$PROJECT   = "your-project-id"
+$NAMESPACE = "default"
+$ZONE      = "your-zone-name"
+$DOMAIN    = "your-domain.example.com"
+$TARGET    = "your-endpoint.datumproxy.net."
+```
+
+#### macOS / Linux
+
+```bash
+PROJECT="your-project-id"
+NAMESPACE="default"
+ZONE="your-zone-name"
+DOMAIN="your-domain.example.com"
+TARGET="your-endpoint.datumproxy.net."
+```
+
+<Warning>
+`TARGET` must include a trailing dot. Without it, the value will be treated as a relative name and DNS resolution will fail.
+</Warning>
+
+---
+
+### Step 2: Create the DNS Zone
+
+#### Windows (PowerShell)
+
+```powershell
+@"
+apiVersion: dns.networking.miloapis.com/v1alpha1
+kind: DNSZone
+metadata:
+  name: $ZONE
+  namespace: $NAMESPACE
+spec:
+  dnsZoneClassName: datum-external-global-dns
+  domainName: $DOMAIN
+"@ | datumctl apply -f - --project $PROJECT --validate=false
+```
+
+#### macOS / Linux
+
+```bash
+cat <<EOF | datumctl apply -f - --project $PROJECT --validate=false
+apiVersion: dns.networking.miloapis.com/v1alpha1
+kind: DNSZone
+metadata:
+  name: $ZONE
+  namespace: $NAMESPACE
+spec:
+  dnsZoneClassName: datum-external-global-dns
+  domainName: $DOMAIN
+EOF
+```
+
+<Note>
+`--validate=false` disables client-side schema validation. It is required here because `datumctl` does not bundle schemas for DNS API types locally.
+</Note>
+
+Verify the zone is accepted and programmed:
+
+```bash
+datumctl get dnszones --project $PROJECT --namespace $NAMESPACE
+```
+
+Wait until both `ACCEPTED` and `PROGRAMMED` show `True` before proceeding.
+
+---
+
+### Step 3: Create the Apex ALIAS Record
+
+Points the root domain (`@`) at the AI Edge endpoint.
+
+#### Windows (PowerShell)
+
+```powershell
+@"
+apiVersion: dns.networking.miloapis.com/v1alpha1
+kind: DNSRecordSet
+metadata:
+  name: ${ZONE}-apex
+  namespace: $NAMESPACE
+spec:
+  dnsZoneRef:
+    name: $ZONE
+  recordType: ALIAS
+  records:
+    - name: "@"
+      ttl: 300
+      alias:
+        content: $TARGET
+"@ | datumctl apply -f - --project $PROJECT --validate=false
+```
+
+#### macOS / Linux
+
+```bash
+cat <<EOF | datumctl apply -f - --project $PROJECT --validate=false
+apiVersion: dns.networking.miloapis.com/v1alpha1
+kind: DNSRecordSet
+metadata:
+  name: ${ZONE}-apex
+  namespace: $NAMESPACE
+spec:
+  dnsZoneRef:
+    name: $ZONE
+  recordType: ALIAS
+  records:
+    - name: "@"
+      ttl: 300
+      alias:
+        content: $TARGET
+EOF
+```
+
+---
+
+### Step 4: Create a Subdomain CNAME
+
+Points a subdomain (e.g., `app.your-domain.example.com`) at the same endpoint.
+
+#### Windows (PowerShell)
+
+```powershell
+@"
+apiVersion: dns.networking.miloapis.com/v1alpha1
+kind: DNSRecordSet
+metadata:
+  name: ${ZONE}-app-cname
+  namespace: $NAMESPACE
+spec:
+  dnsZoneRef:
+    name: $ZONE
+  recordType: CNAME
+  records:
+    - name: "app"
+      ttl: 300
+      cname:
+        content: $TARGET
+"@ | datumctl apply -f - --project $PROJECT --validate=false
+```
+
+#### macOS / Linux
+
+```bash
+cat <<EOF | datumctl apply -f - --project $PROJECT --validate=false
+apiVersion: dns.networking.miloapis.com/v1alpha1
+kind: DNSRecordSet
+metadata:
+  name: ${ZONE}-app-cname
+  namespace: $NAMESPACE
+spec:
+  dnsZoneRef:
+    name: $ZONE
+  recordType: CNAME
+  records:
+    - name: "app"
+      ttl: 300
+      cname:
+        content: $TARGET
+EOF
+```
+
+---
+
+## Verification
+
+### Check Record Status
+
+```bash
+datumctl get dnsrecordsets --project $PROJECT --namespace $NAMESPACE
+```
+
+Both records should show `ACCEPTED=True` and `PROGRAMMED=True`.
+
+---
+
+### Check DNS Resolution
+
+#### Windows (PowerShell)
+
+```powershell
+Resolve-DnsName $DOMAIN
+Resolve-DnsName "app.$DOMAIN"
+```
+
+#### macOS / Linux
+
+```bash
+dig $DOMAIN
+dig app.$DOMAIN
+```
+
+Both names should resolve to the AI Edge endpoint.
+
+---
+
+## Cleanup
+
+### Windows (PowerShell)
+
+```powershell
+datumctl delete dnsrecordset ${ZONE}-app-cname `
+  --project $PROJECT --namespace $NAMESPACE --ignore-not-found
+
+datumctl delete dnsrecordset ${ZONE}-apex `
+  --project $PROJECT --namespace $NAMESPACE --ignore-not-found
+
+datumctl delete dnszone $ZONE `
+  --project $PROJECT --namespace $NAMESPACE --ignore-not-found
+```
+
+### macOS / Linux
+
+```bash
+datumctl delete dnsrecordset ${ZONE}-app-cname \
+  --project $PROJECT --namespace $NAMESPACE --ignore-not-found
+
+datumctl delete dnsrecordset ${ZONE}-apex \
+  --project $PROJECT --namespace $NAMESPACE --ignore-not-found
+
+datumctl delete dnszone $ZONE \
+  --project $PROJECT --namespace $NAMESPACE --ignore-not-found
+```
+
+---
+
+## Troubleshooting
+
+| Symptom | Root Cause | Resolution |
+|---------|------------|------------|
+| Zone stuck at `PROGRAMMED=False` | Domain not delegated to Datum nameservers | Update nameservers at your registrar |
+| `nslookup` / `dig` returns NXDOMAIN | Zone not yet propagated | Wait 1–2 minutes and retry |
+| ALIAS resolves to wrong address | `TARGET` missing trailing dot | Re-apply the record with a trailing dot on the target |
+| Record not appearing | `--validate=false` omitted | Re-apply with `--validate=false` |
+
+---
+
+## Summary
+
+- DNS zones use `kind: DNSZone` at `dns.networking.miloapis.com/v1alpha1`
+- The DNS zone class is always `datum-external-global-dns` — it is platform-provided and not user-configurable
+- Use `recordType: ALIAS` for the apex (`@`) and `recordType: CNAME` for subdomains
+- The `TARGET` value must include a trailing dot
+- All DNS apply commands require `--validate=false`
+- Delete record sets before deleting the zone
diff --git a/ai-edge/host-header-override.mdx b/ai-edge/host-header-override.mdx
new file mode 100644
index 0000000..877d7b7
--- /dev/null
+++ b/ai-edge/host-header-override.mdx
@@ -0,0 +1,184 @@
+---
+title: "Host Header Override with HTTPProxy"
+description: "Rewrite the Host header on upstream requests using an HTTPProxy RequestHeaderModifier filter."
+---
+
+This guide shows how to override the `Host` header when forwarding requests to an upstream backend using a Datum `HTTPProxy`.
+
+This is useful when:
+
+- The upstream expects a specific `Host` header
+- You are proxying to a shared or virtual-hosted service
+- The backend's DNS name does not match the public hostname
+
+---
+
+## Overview
+
+At a high level, this setup:
+
+1. Accepts public traffic at a configured hostname
+2. Forwards all requests to an upstream backend
+3. Rewrites the `Host` header **before** the request reaches the upstream
+
+---
+
+## Prerequisites
+
+- `datumctl` installed and authenticated
+- A valid **Project**
+
+---
+
+## Configuration Steps
+
+### Step 1: Set Variables
+
+#### Windows (PowerShell)
+
+```powershell
+$PROJECT    = "your-project-id"
+$NAMESPACE  = "default"
+$PROXY_NAME = "host-header-demo"
+$HOSTNAME   = "your-app.example.com"
+```
+
+#### macOS / Linux
+
+```bash
+PROJECT="your-project-id"
+NAMESPACE="default"
+PROXY_NAME="host-header-demo"
+HOSTNAME="your-app.example.com"
+```
+
+---
+
+### Step 2: Apply Host Header Configuration
+
+The `RequestHeaderModifier` filter overwrites the `Host` header before the request is forwarded upstream. The `type` field is required.
+
+#### Windows (PowerShell)
+
+```powershell
+@"
+apiVersion: networking.datumapis.com/v1alpha
+kind: HTTPProxy
+metadata:
+  name: $PROXY_NAME
+spec:
+  hostnames:
+  - $HOSTNAME
+  rules:
+  - name: host-header-override
+    matches:
+    - path:
+        type: PathPrefix
+        value: /
+    filters:
+    - type: RequestHeaderModifier
+      requestHeaderModifier:
+        set:
+        - name: Host
+          value: example.internal
+    backends:
+    - endpoint: https://httpbin.org
+"@ | datumctl apply --project $PROJECT --namespace $NAMESPACE -f -
+```
+
+#### macOS / Linux
+
+```bash
+cat <<EOF | datumctl apply --project $PROJECT --namespace $NAMESPACE -f -
+apiVersion: networking.datumapis.com/v1alpha
+kind: HTTPProxy
+metadata:
+  name: $PROXY_NAME
+spec:
+  hostnames:
+  - $HOSTNAME
+  rules:
+  - name: host-header-override
+    matches:
+    - path:
+        type: PathPrefix
+        value: /
+    filters:
+    - type: RequestHeaderModifier
+      requestHeaderModifier:
+        set:
+        - name: Host
+          value: example.internal
+    backends:
+    - endpoint: https://httpbin.org
+EOF
+```
+
+---
+
+## Verification
+
+`httpbin.org/headers` echoes the request headers received by the upstream, making it easy to confirm the rewrite.
+
+```bash
+curl https://$HOSTNAME/headers
+```
+
+Look for `Host` in the response:
+
+```json
+{
+  "headers": {
+    "Host": "example.internal",
+    ...
+  }
+}
+```
+
+If `Host` shows `example.internal`, the rewrite is working correctly.
+
+---
+
+## Cleanup
+
+### Windows (PowerShell)
+
+```powershell
+datumctl delete httpproxy $PROXY_NAME `
+  --project $PROJECT --namespace $NAMESPACE --ignore-not-found
+```
+
+### macOS / Linux
+
+```bash
+datumctl delete httpproxy $PROXY_NAME \
+  --project $PROJECT --namespace $NAMESPACE --ignore-not-found
+```
+
+---
+
+## Troubleshooting
+
+| Symptom | Root Cause | Resolution |
+|---------|------------|------------|
+| API rejects the resource | `type` field missing from filter | Add `type: RequestHeaderModifier` to the filter |
+| `Host` header not rewritten | Filter applied at wrong level | Confirm `filters` is under `rules[].filters`, not `backends[].filters` |
+| Upstream returns 404 or 421 | Upstream rejects the rewritten `Host` value | Verify the upstream accepts the hostname you configured |
+| `Host` shows original value | `set` vs `add` confusion | Use `set` to overwrite; `add` appends to an existing value |
+
+---
+
+## Best Practices
+
+- Use `set` to overwrite the `Host` header — `add` appends to any existing value instead of replacing it
+- Keep the rewritten hostname consistent with what the upstream backend expects in its virtual host configuration
+- Test with `httpbin.org/headers` before pointing at a real upstream — it removes backend variables from the equation
+
+---
+
+## Summary
+
+- Host header rewriting uses a `RequestHeaderModifier` filter on the rule's `filters` list
+- The `type: RequestHeaderModifier` field is required — omitting it will cause the API to reject the resource
+- `set` overwrites the header; `add` appends
+- The rewrite happens at the proxy — the client sees no change to the URL or response
diff --git a/ai-edge/https-redirect.mdx b/ai-edge/https-redirect.mdx
new file mode 100644
index 0000000..a81c8f3
--- /dev/null
+++ b/ai-edge/https-redirect.mdx
@@ -0,0 +1,174 @@
+---
+title: "HTTP to HTTPS Redirect with HTTPProxy"
+description: "Force HTTPS by redirecting all plain HTTP requests using a RequestRedirect filter on a Datum HTTPProxy."
+---
+
+This guide shows how to configure an explicit HTTP to HTTPS redirect on a Datum `HTTPProxy` using a `RequestRedirect` filter.
+
+<Note>
+AI Edge enforces HTTPS by default. This guide applies when you have disabled that enforcement, or when you need a custom redirect configuration — for example, redirecting from a specific path or returning a `302` instead of the default `301`.
+</Note>
+
+---
+
+## Overview
+
+A `RequestRedirect` filter responds to the client with a redirect response directly — no backend is reached. The AI Edge handles the redirect at the proxy layer.
+
+At a high level, this setup:
+
+1. Matches all incoming requests on a hostname
+2. Returns a `301 Moved Permanently` redirect to the same URL using `https`
+
+---
+
+## Prerequisites
+
+- `datumctl` installed and authenticated
+- A valid **Project**
+- An existing `HTTPProxy` hostname, or create a new one with this guide
+
+---
+
+## Configuration Steps
+
+### Step 1: Set Variables
+
+#### Windows (PowerShell)
+
+```powershell
+$PROJECT    = "your-project-id"
+$NAMESPACE  = "default"
+$PROXY_NAME = "https-redirect-demo"
+$HOSTNAME   = "your-app.example.com"
+```
+
+#### macOS / Linux
+
+```bash
+PROJECT="your-project-id"
+NAMESPACE="default"
+PROXY_NAME="https-redirect-demo"
+HOSTNAME="your-app.example.com"
+```
+
+---
+
+### Step 2: Apply the Redirect Configuration
+
+The `RequestRedirect` filter requires `type: RequestRedirect`. No backend is needed — the redirect is returned immediately by the proxy.
+
+#### Windows (PowerShell)
+
+```powershell
+@"
+apiVersion: networking.datumapis.com/v1alpha
+kind: HTTPProxy
+metadata:
+  name: $PROXY_NAME
+spec:
+  hostnames:
+  - $HOSTNAME
+  rules:
+  - name: https-redirect
+    matches:
+    - path:
+        type: PathPrefix
+        value: /
+    filters:
+    - type: RequestRedirect
+      requestRedirect:
+        scheme: https
+        statusCode: 301
+"@ | datumctl apply --project $PROJECT --namespace $NAMESPACE -f -
+```
+
+#### macOS / Linux
+
+```bash
+cat <<EOF | datumctl apply --project $PROJECT --namespace $NAMESPACE -f -
+apiVersion: networking.datumapis.com/v1alpha
+kind: HTTPProxy
+metadata:
+  name: $PROXY_NAME
+spec:
+  hostnames:
+  - $HOSTNAME
+  rules:
+  - name: https-redirect
+    matches:
+    - path:
+        type: PathPrefix
+        value: /
+    filters:
+    - type: RequestRedirect
+      requestRedirect:
+        scheme: https
+        statusCode: 301
+EOF
+```
+
+---
+
+## Verification
+
+Test that a plain HTTP request receives a redirect:
+
+```bash
+curl -I http://$HOSTNAME/
+```
+
+Expected response:
+
+```
+HTTP/1.1 301 Moved Permanently
+Location: https://your-app.example.com/
+```
+
+Confirm that the `Location` header uses `https` and preserves the path.
+
+---
+
+## Cleanup
+
+### Windows (PowerShell)
+
+```powershell
+datumctl delete httpproxy $PROXY_NAME `
+  --project $PROJECT --namespace $NAMESPACE --ignore-not-found
+```
+
+### macOS / Linux
+
+```bash
+datumctl delete httpproxy $PROXY_NAME \
+  --project $PROJECT --namespace $NAMESPACE --ignore-not-found
+```
+
+---
+
+## Troubleshooting
+
+| Symptom | Root Cause | Resolution |
+|---------|------------|------------|
+| API rejects the resource | `type` field missing from filter | Add `type: RequestRedirect` to the filter |
+| Redirect loop | Both HTTP and HTTPS rules redirect | Ensure the redirect rule only targets HTTP traffic |
+| `Location` header has wrong hostname | Hostname not set | Add `hostname` to `requestRedirect` to override |
+| Client receives `302` instead of `301` | Default or explicit `statusCode: 302` | Set `statusCode: 301` for a permanent redirect |
+
+---
+
+## Best Practices
+
+- Use `statusCode: 301` for permanent redirects — browsers and crawlers cache these
+- Use `statusCode: 302` only when the redirect is temporary (e.g., maintenance)
+- If redirecting to a different hostname, set `requestRedirect.hostname` explicitly rather than relying on the `Host` header
+
+---
+
+## Summary
+
+- HTTP to HTTPS redirects use `type: RequestRedirect` with `scheme: https`
+- The `type` field is required on all filters
+- No backend is needed — `RequestRedirect` is a terminal filter that responds to the client directly
+- `statusCode` accepts `301` (permanent) or `302` (temporary)
diff --git a/ai-edge/path-routing.mdx b/ai-edge/path-routing.mdx
new file mode 100644
index 0000000..527328c
--- /dev/null
+++ b/ai-edge/path-routing.mdx
@@ -0,0 +1,195 @@
+---
+title: "Path-Based Routing with HTTPProxy"
+description: "Route requests to different backends based on URL paths using a Datum HTTPProxy."
+---
+
+This guide shows how to configure **path-based routing** on a Datum AI Edge using an `HTTPProxy` resource. The example routes one exact path to a dedicated backend and sends all remaining traffic to a default backend.
+
+---
+
+## Overview
+
+Path-based routing lets you split traffic across backends based on the URL path, without changing your application or DNS.
+
+At a high level, this setup:
+
+1. Defines an **exact** path match for a specific route (e.g., `/login`)
+2. Adds a **catch-all** prefix rule for all other traffic
+3. Applies both rules in a single `HTTPProxy` resource
+
+---
+
+## Prerequisites
+
+- `datumctl` installed and authenticated
+- A valid **Project**
+
+Verify access:
+
+```bash
+datumctl get httpproxy
+```
+
+---
+
+## Configuration Steps
+
+### Step 1: Set Variables
+
+#### Windows (PowerShell)
+
+```powershell
+$PROJECT    = "my-project"
+$NAMESPACE  = "default"
+$PROXY_NAME = "my-proxy"
+$HOSTNAME   = "app.example.com"
+```
+
+#### macOS / Linux
+
+```bash
+PROJECT="my-project"
+NAMESPACE="default"
+PROXY_NAME="my-proxy"
+HOSTNAME="app.example.com"
+```
+
+---
+
+### Step 2: Apply Path Routing Configuration
+
+The `/login` path is matched exactly. All other requests fall through to the catch-all `/` rule.
+
+Place the exact match rule **before** the catch-all. Rules are evaluated in order, and a prefix of `/` matches everything.
+
+<Note>
+Each rule currently supports only a single backend. Multiple backends per rule are not yet supported.
+</Note>
+
+#### Windows (PowerShell)
+
+```powershell
+@"
+apiVersion: networking.datumapis.com/v1alpha
+kind: HTTPProxy
+metadata:
+  name: $PROXY_NAME
+spec:
+  hostnames:
+  - $HOSTNAME
+  rules:
+  - name: login-exact
+    matches:
+    - path:
+        type: Exact
+        value: /login
+    backends:
+    - endpoint: https://auth-origin.example
+
+  - name: catch-all
+    matches:
+    - path:
+        type: PathPrefix
+        value: /
+    backends:
+    - endpoint: https://web-origin.example
+"@ | datumctl apply --project $PROJECT --namespace $NAMESPACE -f -
+```
+
+#### macOS / Linux
+
+```bash
+cat <<EOF | datumctl apply --project $PROJECT --namespace $NAMESPACE -f -
+apiVersion: networking.datumapis.com/v1alpha
+kind: HTTPProxy
+metadata:
+  name: $PROXY_NAME
+spec:
+  hostnames:
+  - $HOSTNAME
+  rules:
+  - name: login-exact
+    matches:
+    - path:
+        type: Exact
+        value: /login
+    backends:
+    - endpoint: https://auth-origin.example
+
+  - name: catch-all
+    matches:
+    - path:
+        type: PathPrefix
+        value: /
+    backends:
+    - endpoint: https://web-origin.example
+EOF
+```
+
+---
+
+## Verification
+
+### Exact Path Match
+
+```bash
+curl -v https://app.example.com/login
+```
+
+Expected: request reaches `auth-origin.example`.
+
+---
+
+### Negative Test — Exact Is Truly Exact
+
+```bash
+curl -v https://app.example.com/login/reset
+```
+
+Expected: `/login/reset` does **not** match the `Exact /login` rule and falls through to the catch-all backend. Verify this to confirm the exact match boundary is working correctly.
+
+---
+
+### Catch-All
+
+```bash
+curl -v https://app.example.com/
+```
+
+Expected: request reaches `web-origin.example`.
+
+---
+
+## Cleanup
+
+### Windows (PowerShell)
+
+```powershell
+datumctl delete httpproxy $PROXY_NAME `
+  --project $PROJECT --namespace $NAMESPACE --ignore-not-found
+```
+
+### macOS / Linux
+
+```bash
+datumctl delete httpproxy $PROXY_NAME \
+  --project $PROJECT --namespace $NAMESPACE --ignore-not-found
+```
+
+---
+
+## Best Practices
+
+- Always include a `PathPrefix /` catch-all so no requests are dropped unexpectedly
+- Place more-specific rules (e.g., `Exact`, longer prefixes) before less-specific ones
+- Use distinct, descriptive rule `name` values — they appear in logs and aid debugging
+- Test both the matching path and a near-miss (e.g., `/login/reset`) to confirm exact boundaries
+
+---
+
+## Summary
+
+- Path-based routing is configured using a **`HTTPProxy`** resource at `networking.datumapis.com/v1alpha`
+- Use `type: Exact` for single endpoints like `/login`
+- Use `type: PathPrefix` with value `/` as a catch-all for all remaining traffic
+- Rule order matters — place specific matches before the catch-all
diff --git a/ai-edge/proxy-waf.mdx b/ai-edge/proxy-waf.mdx
new file mode 100644
index 0000000..06e926b
--- /dev/null
+++ b/ai-edge/proxy-waf.mdx
@@ -0,0 +1,148 @@
+---
+title: "HTTPProxy and WAF Capabilities"
+description: "Reference overview of the HTTPProxy and TrafficProtectionPolicy resources that make up Datum's AI Edge."
+---
+
+Datum's AI Edge consists of two resources that work together:
+
+- **`HTTPProxy`** — Layer 7 routing and traffic control
+- **`TrafficProtectionPolicy`** — OWASP Core Rule Set WAF protection
+
+The proxy determines where traffic goes and how requests are shaped before reaching your origin. The WAF determines whether traffic is observed or blocked based on security rules. The WAF attaches to a proxy using `targetRefs`.
+
+---
+
+## HTTPProxy
+
+The `HTTPProxy` resource handles Layer 7 routing and request processing. It supports hostname routing, path and header matching, redirects, rewrites, CORS, header manipulation, traffic mirroring, and TLS configuration to origin.
+
+### Inspect the Schema
+
+```bash
+datumctl explain httpproxy --recursive
+```
+
+### List and Inspect Proxies
+
+```bash
+# List all proxies
+datumctl get httpproxies --namespace default
+
+# View a specific proxy
+datumctl get httpproxy <name> --namespace default -o yaml
+```
+
+### Feature Reference
+
+```text
+HTTPProxy
+ ├── metadata
+ │    ├── name
+ │    ├── namespace
+ │    └── annotations
+ │
+ └── spec
+      ├── hostnames[]
+      │
+      └── rules[]
+           ├── name
+           │
+           ├── matches[]
+           │    ├── path
+           │    │    ├── type (Exact | PathPrefix | RegularExpression)
+           │    │    └── value
+           │    ├── headers[]
+           │    │    ├── name
+           │    │    ├── type (Exact | RegularExpression)
+           │    │    └── value
+           │    ├── queryParams[]
+           │    └── method (GET | POST | PUT | ...)
+           │
+           ├── filters[] (rule-level)
+           │    ├── RequestRedirect
+           │    ├── RequestHeaderModifier
+           │    ├── ResponseHeaderModifier
+           │    ├── RequestMirror
+           │    ├── URLRewrite
+           │    ├── CORS
+           │    └── ExtensionRef
+           │
+           └── backends[]
+                ├── endpoint
+                ├── connector
+                ├── tls
+                └── filters[] (backend-level)
+```
+
+<Note>
+Each rule currently supports a single backend. Multiple backends per rule are not yet supported.
+</Note>
+
+---
+
+## TrafficProtectionPolicy (WAF)
+
+The `TrafficProtectionPolicy` resource provides application-layer security using the OWASP Core Rule Set. It attaches to an `HTTPProxy` using `targetRefs` and can target the entire proxy or a specific named rule via `sectionName`.
+
+### Inspect the Schema
+
+```bash
+datumctl explain trafficprotectionpolicy --recursive
+```
+
+### List and Inspect WAF Policies
+
+```bash
+# List all WAF policies
+datumctl get trafficprotectionpolicies --namespace default
+
+# View a specific policy
+datumctl get trafficprotectionpolicy <name> --namespace default -o yaml
+```
+
+### Feature Reference
+
+```text
+TrafficProtectionPolicy
+ ├── metadata
+ │
+ └── spec
+      ├── mode (Observe | Enforce | Disabled)
+      ├── samplingPercentage
+      ├── ruleSets[]
+      │    └── OWASPCoreRuleSet
+      │         ├── paranoiaLevels
+      │         │    ├── detection
+      │         │    └── blocking
+      │         ├── scoreThresholds
+      │         │    ├── inbound
+      │         │    └── outbound
+      │         └── ruleExclusions
+      │              ├── ids
+      │              ├── idRanges
+      │              └── tags
+      │
+      └── targetRefs[]
+           ├── group
+           ├── kind
+           ├── name
+           └── sectionName (optional — target a specific rule)
+```
+
+**Mode values:**
+- `Observe` *(default)* — Logs rule matches without blocking traffic. Use this to evaluate impact before enforcing.
+- `Enforce` — Blocks requests that exceed the score threshold.
+- `Disabled` — WAF is inactive.
+
+**Paranoia levels** control how aggressively rules are applied. Higher levels catch more threats but increase false-positive risk. Separate levels can be set for detection (logging) and blocking.
+
+**`samplingPercentage`** controls what fraction of traffic is evaluated by the WAF. Useful for gradual rollout or high-throughput environments.
+
+---
+
+## Next Steps
+
+- [Path-Based Routing](/ai-edge/path-routing) — Route requests to different backends by URL path
+- [HTTP Basic Authentication](/ai-edge/basic-auth) — Add username/password protection to a route
+- [OIDC with Google](/ai-edge/oidc-google) — Protect a route with Google sign-in
+- [OIDC with Auth0](/ai-edge/oidc-auth0) — OIDC with email-based allow-lists via Auth0
diff --git a/ai-edge/url-rewrite.mdx b/ai-edge/url-rewrite.mdx
new file mode 100644
index 0000000..9143789
--- /dev/null
+++ b/ai-edge/url-rewrite.mdx
@@ -0,0 +1,245 @@
+---
+title: "URL Rewrite with HTTPProxy"
+description: "Rewrite the path or hostname on upstream requests using a URLRewrite filter on a Datum HTTPProxy."
+---
+
+This guide shows how to rewrite the URL path before a request is forwarded to an upstream backend using a Datum `HTTPProxy`.
+
+URL rewriting is useful when:
+
+- Your public API path structure differs from your backend's internal paths
+- You want to strip a path prefix before forwarding (e.g., `/api/v1/users` → `/users`)
+- You need to replace the full path for a specific route
+- You need to rewrite the hostname the backend sees (separate from `Host` header modification)
+
+---
+
+## Overview
+
+The `URLRewrite` filter modifies the path and/or hostname of the forwarded request. Unlike `RequestHeaderModifier`, which sets arbitrary headers, `URLRewrite` is purpose-built for path and authority rewriting and is the recommended approach for path manipulation.
+
+At a high level, this setup:
+
+1. Matches requests on a path prefix
+2. Rewrites the path before forwarding to the backend
+3. The client sees no change to the URL
+
+---
+
+## Prerequisites
+
+- `datumctl` installed and authenticated
+- A valid **Project**
+
+---
+
+## Configuration Steps
+
+### Step 1: Set Variables
+
+#### Windows (PowerShell)
+
+```powershell
+$PROJECT    = "your-project-id"
+$NAMESPACE  = "default"
+$PROXY_NAME = "url-rewrite-demo"
+$HOSTNAME   = "your-app.example.com"
+```
+
+#### macOS / Linux
+
+```bash
+PROJECT="your-project-id"
+NAMESPACE="default"
+PROXY_NAME="url-rewrite-demo"
+HOSTNAME="your-app.example.com"
+```
+
+---
+
+### Step 2: Apply URL Rewrite Configuration
+
+This example strips the `/api` prefix. Requests to `/api/users` are forwarded to the backend as `/users`.
+
+`ReplacePrefixMatch` must be paired with a `PathPrefix` match on the same prefix — mixing match types will cause the route to be rejected.
+
+#### Windows (PowerShell)
+
+```powershell
+@"
+apiVersion: networking.datumapis.com/v1alpha
+kind: HTTPProxy
+metadata:
+  name: $PROXY_NAME
+spec:
+  hostnames:
+  - $HOSTNAME
+  rules:
+  - name: strip-api-prefix
+    matches:
+    - path:
+        type: PathPrefix
+        value: /api
+    filters:
+    - type: URLRewrite
+      urlRewrite:
+        path:
+          type: ReplacePrefixMatch
+          replacePrefixMatch: /
+    backends:
+    - endpoint: https://api-backend.example.com
+"@ | datumctl apply --project $PROJECT --namespace $NAMESPACE -f -
+```
+
+#### macOS / Linux
+
+```bash
+cat <<EOF | datumctl apply --project $PROJECT --namespace $NAMESPACE -f -
+apiVersion: networking.datumapis.com/v1alpha
+kind: HTTPProxy
+metadata:
+  name: $PROXY_NAME
+spec:
+  hostnames:
+  - $HOSTNAME
+  rules:
+  - name: strip-api-prefix
+    matches:
+    - path:
+        type: PathPrefix
+        value: /api
+    filters:
+    - type: URLRewrite
+      urlRewrite:
+        path:
+          type: ReplacePrefixMatch
+          replacePrefixMatch: /
+    backends:
+    - endpoint: https://api-backend.example.com
+EOF
+```
+
+---
+
+## Path Rewrite Options
+
+### Replace Prefix
+
+Replaces the matched prefix and preserves the rest of the path.
+
+```yaml
+filters:
+- type: URLRewrite
+  urlRewrite:
+    path:
+      type: ReplacePrefixMatch
+      replacePrefixMatch: /new-prefix
+```
+
+| Incoming Path | Match Prefix | Replace With | Forwarded Path |
+|---------------|-------------|--------------|----------------|
+| `/api/users` | `/api` | `/` | `/users` |
+| `/api/orders/123` | `/api` | `/` | `/orders/123` |
+| `/api/v2/items` | `/api/v2` | `/v1` | `/v1/items` |
+
+The match rule's `path.value` and `replacePrefixMatch` must use the same prefix. Using `ReplacePrefixMatch` with an `Exact` or `RegularExpression` match will cause the route to be rejected.
+
+---
+
+### Replace Full Path
+
+Replaces the entire path, ignoring what was matched.
+
+```yaml
+filters:
+- type: URLRewrite
+  urlRewrite:
+    path:
+      type: ReplaceFullPath
+      replaceFullPath: /health
+```
+
+| Incoming Path | Forwarded Path |
+|---------------|----------------|
+| `/status` | `/health` |
+| `/ping` | `/health` |
+| `/anything` | `/health` |
+
+Useful for mapping multiple public paths to a single backend endpoint.
+
+---
+
+### Hostname Rewrite
+
+Rewrites the authority (hostname) the backend sees without changing request headers separately.
+
+```yaml
+filters:
+- type: URLRewrite
+  urlRewrite:
+    hostname: internal-api.example.com
+```
+
+`hostname` and `path` can be combined in a single `URLRewrite` filter.
+
+---
+
+## Verification
+
+`httpbin.org/anything` reflects the path received by the upstream. Use it to confirm the rewrite before pointing at a real backend.
+
+Update your rule's `backends[].endpoint` to `https://httpbin.org` temporarily, then:
+
+```bash
+curl https://$HOSTNAME/api/users
+```
+
+Look for the `url` field in the response — it should show `/users`, not `/api/users`.
+
+---
+
+## Cleanup
+
+### Windows (PowerShell)
+
+```powershell
+datumctl delete httpproxy $PROXY_NAME `
+  --project $PROJECT --namespace $NAMESPACE --ignore-not-found
+```
+
+### macOS / Linux
+
+```bash
+datumctl delete httpproxy $PROXY_NAME \
+  --project $PROJECT --namespace $NAMESPACE --ignore-not-found
+```
+
+---
+
+## Troubleshooting
+
+| Symptom | Root Cause | Resolution |
+|---------|------------|------------|
+| Route rejected (`Accepted=False`) | `ReplacePrefixMatch` used with non-prefix match | Change match `type` to `PathPrefix` |
+| Path not rewritten | `type` field missing from `urlRewrite.path` | Add `type: ReplacePrefixMatch` or `type: ReplaceFullPath` |
+| API rejects the resource | `type` field missing from filter | Add `type: URLRewrite` to the filter |
+| Prefix partially matched | Prefix match is not path-element-aware | `/api` matches `/api/`, `/api/foo` but not `/apiv2` — this is correct behavior |
+
+---
+
+## Best Practices
+
+- Use `ReplacePrefixMatch` for stripping versioned path prefixes (e.g., `/v1`, `/api`)
+- Use `ReplaceFullPath` when mapping multiple routes to a single backend endpoint
+- Test rewrites with `httpbin.org/anything` before switching to a production backend — it reflects the exact path the upstream receives
+- Keep match prefix and `replacePrefixMatch` prefix consistent to avoid rejected routes
+
+---
+
+## Summary
+
+- URL path rewriting uses `type: URLRewrite` with a `path` block
+- `path.type` is required: `ReplacePrefixMatch` or `ReplaceFullPath`
+- `ReplacePrefixMatch` must be paired with a `PathPrefix` match on the same prefix
+- `hostname` can be set alongside `path` in the same filter
+- The rewrite is transparent to the client — only the upstream sees the modified path
diff --git a/ai-edge/waf-configuration.mdx b/ai-edge/waf-configuration.mdx
new file mode 100644
index 0000000..6b77806
--- /dev/null
+++ b/ai-edge/waf-configuration.mdx
@@ -0,0 +1,322 @@
+---
+title: "WAF Configuration with TrafficProtectionPolicy"
+description: "Enable and configure the Coraza OWASP WAF for a Datum AI Edge using TrafficProtectionPolicy."
+---
+
+This guide shows how to attach and configure a Web Application Firewall (WAF) to a Datum `HTTPProxy` using a `TrafficProtectionPolicy` resource.
+
+The WAF is powered by [Coraza](https://www.coraza.io/) and the OWASP Core Rule Set (CRS). It inspects HTTP requests and responses for common attack patterns including SQL injection, XSS, and other OWASP Top 10 threats.
+
+---
+
+## Overview
+
+At a high level, this setup:
+
+1. Creates a `TrafficProtectionPolicy` in `Observe` mode to baseline traffic without blocking
+2. Reviews detected violations
+3. Transitions to `Enforce` mode once the ruleset is tuned
+
+<Note>
+WAF policies default to `Observe` mode when `mode` is not specified. Always start in `Observe` mode before enforcing — this prevents unexpected blocking of legitimate traffic.
+</Note>
+
+---
+
+## Prerequisites
+
+- `datumctl` installed and authenticated
+- A valid **Project**
+- An existing `HTTPProxy` to attach the policy to
+
+Verify your proxy exists:
+
+```bash
+datumctl get httpproxy --project $PROJECT --namespace $NAMESPACE
+```
+
+---
+
+## Configuration Steps
+
+### Step 1: Set Variables
+
+#### Windows (PowerShell)
+
+```powershell
+$PROJECT    = "your-project-id"
+$NAMESPACE  = "default"
+$PROXY_NAME = "your-proxy-name"
+$WAF_NAME   = "${PROXY_NAME}-waf"
+```
+
+#### macOS / Linux
+
+```bash
+PROJECT="your-project-id"
+NAMESPACE="default"
+PROXY_NAME="your-proxy-name"
+WAF_NAME="${PROXY_NAME}-waf"
+```
+
+---
+
+### Step 2: Apply WAF in Observe Mode
+
+Start by attaching the WAF in `Observe` mode. Violations are logged but traffic is not blocked.
+
+#### Windows (PowerShell)
+
+```powershell
+@"
+apiVersion: networking.datumapis.com/v1alpha
+kind: TrafficProtectionPolicy
+metadata:
+  name: $WAF_NAME
+  namespace: $NAMESPACE
+spec:
+  mode: Observe
+  ruleSets:
+  - type: OWASPCoreRuleSet
+    owaspCoreRuleSet:
+      paranoiaLevels:
+        detection: 2
+        blocking: 1
+      scoreThresholds:
+        inbound: 5
+        outbound: 4
+  targetRefs:
+  - group: networking.datumapis.com
+    kind: HTTPProxy
+    name: $PROXY_NAME
+"@ | datumctl apply --project $PROJECT --namespace $NAMESPACE -f -
+```
+
+#### macOS / Linux
+
+```bash
+cat <<EOF | datumctl apply --project $PROJECT --namespace $NAMESPACE -f -
+apiVersion: networking.datumapis.com/v1alpha
+kind: TrafficProtectionPolicy
+metadata:
+  name: $WAF_NAME
+  namespace: $NAMESPACE
+spec:
+  mode: Observe
+  ruleSets:
+  - type: OWASPCoreRuleSet
+    owaspCoreRuleSet:
+      paranoiaLevels:
+        detection: 2
+        blocking: 1
+      scoreThresholds:
+        inbound: 5
+        outbound: 4
+  targetRefs:
+  - group: networking.datumapis.com
+    kind: HTTPProxy
+    name: $PROXY_NAME
+EOF
+```
+
+---
+
+### Step 3: Verify Policy Attachment
+
+```bash
+datumctl get trafficprotectionpolicy $WAF_NAME \
+  --project $PROJECT --namespace $NAMESPACE -o yaml
+```
+
+Confirm the policy shows `Accepted=True` and is attached to the correct proxy.
+
+---
+
+### Step 4: Switch to Enforce Mode
+
+After observing traffic and confirming no false positives, switch the mode to `Enforce`.
+
+#### Windows (PowerShell)
+
+```powershell
+@"
+apiVersion: networking.datumapis.com/v1alpha
+kind: TrafficProtectionPolicy
+metadata:
+  name: $WAF_NAME
+  namespace: $NAMESPACE
+spec:
+  mode: Enforce
+  ruleSets:
+  - type: OWASPCoreRuleSet
+    owaspCoreRuleSet:
+      paranoiaLevels:
+        detection: 2
+        blocking: 1
+      scoreThresholds:
+        inbound: 5
+        outbound: 4
+  targetRefs:
+  - group: networking.datumapis.com
+    kind: HTTPProxy
+    name: $PROXY_NAME
+"@ | datumctl apply --project $PROJECT --namespace $NAMESPACE -f -
+```
+
+#### macOS / Linux
+
+```bash
+cat <<EOF | datumctl apply --project $PROJECT --namespace $NAMESPACE -f -
+apiVersion: networking.datumapis.com/v1alpha
+kind: TrafficProtectionPolicy
+metadata:
+  name: $WAF_NAME
+  namespace: $NAMESPACE
+spec:
+  mode: Enforce
+  ruleSets:
+  - type: OWASPCoreRuleSet
+    owaspCoreRuleSet:
+      paranoiaLevels:
+        detection: 2
+        blocking: 1
+      scoreThresholds:
+        inbound: 5
+        outbound: 4
+  targetRefs:
+  - group: networking.datumapis.com
+    kind: HTTPProxy
+    name: $PROXY_NAME
+EOF
+```
+
+---
+
+## Configuration Reference
+
+### Paranoia Levels
+
+Paranoia level controls how aggressively the CRS applies rules. Higher levels catch more threats but increase false-positive risk.
+
+| Level | Behavior |
+|-------|----------|
+| 1 | Core rules only. Lowest false-positive risk. Recommended starting point. |
+| 2 | Adds more rules. Suitable for most production applications. |
+| 3 | Stricter rules. May require tuning for complex applications. |
+| 4 | Maximum coverage. High false-positive risk without tuning. |
+
+`detection` and `blocking` can be set independently. A common pattern is to detect at a higher level than you block, allowing you to see what stricter rules would catch before enforcing them.
+
+---
+
+### Score Thresholds
+
+The OWASP CRS uses anomaly scoring — each rule match adds to a running score. The request is blocked when the score exceeds the threshold.
+
+| Field | Default | Description |
+|-------|---------|-------------|
+| `inbound` | 5 | Score threshold to block an inbound request |
+| `outbound` | 4 | Score threshold to block an outbound response |
+
+Lower thresholds block more aggressively. The defaults (5 inbound, 4 outbound) are the OWASP CRS recommended starting values.
+
+---
+
+### Rule Exclusions
+
+Use rule exclusions to suppress specific rules causing false positives. Exclusions apply globally to the policy.
+
+```yaml
+owaspCoreRuleSet:
+  ruleExclusions:
+    ids:
+      - 920350    # Disable a specific rule by ID
+    idRanges:
+      - "941100-941200"   # Disable a range of rules
+    tags:
+      - "attack-sqli"     # Disable all rules with a tag
+```
+
+Use the minimum exclusion scope needed — prefer specific `ids` over broad `tags`.
+
+---
+
+### Targeting a Specific Rule (sectionName)
+
+By default, a `TrafficProtectionPolicy` applies to the entire `HTTPProxy`. To scope it to a single named rule, use `sectionName`:
+
+```yaml
+targetRefs:
+- group: networking.datumapis.com
+  kind: HTTPProxy
+  name: your-proxy-name
+  sectionName: your-rule-name
+```
+
+`sectionName` must match the `name` field of a rule in the target `HTTPProxy`.
+
+---
+
+## Verification
+
+### Test with a Known Attack Pattern
+
+Send a request containing a SQL injection pattern to confirm the WAF detects it:
+
+```bash
+curl -I "https://your-app.example.com/?id=1' OR '1'='1"
+```
+
+In `Observe` mode: request passes through, violation is logged.
+In `Enforce` mode: expected response is `403 Forbidden`.
+
+---
+
+## Cleanup
+
+### Windows (PowerShell)
+
+```powershell
+datumctl delete trafficprotectionpolicy $WAF_NAME `
+  --project $PROJECT --namespace $NAMESPACE --ignore-not-found
+```
+
+### macOS / Linux
+
+```bash
+datumctl delete trafficprotectionpolicy $WAF_NAME \
+  --project $PROJECT --namespace $NAMESPACE --ignore-not-found
+```
+
+---
+
+## Troubleshooting
+
+| Symptom | Root Cause | Resolution |
+|---------|------------|------------|
+| Policy not attaching | `targetRefs.group` incorrect | Use `networking.datumapis.com` |
+| Policy not attaching | `targetRefs.kind` incorrect | Use `HTTPProxy` (not `HTTPRoute`) |
+| Legitimate traffic blocked | Paranoia level too high | Lower `blocking` level or add rule exclusions |
+| Known attack not blocked | Mode is `Observe` | Switch `mode` to `Enforce` |
+| Known attack not blocked | Score threshold too high | Lower `inbound` threshold |
+| `sectionName` not found | Rule name mismatch | Verify rule `name` in the `HTTPProxy` spec |
+
+---
+
+## Best Practices
+
+- Always start in `Observe` mode and run for at least a few days of representative traffic before enforcing
+- Set `detection` one level higher than `blocking` to preview the impact of stricter rules before applying them
+- Use specific rule `ids` for exclusions rather than broad `tags` — this minimizes the attack surface opened by exclusions
+- Keep `scoreThresholds.inbound` at 5 or higher initially; tuning downward after false positives are addressed
+- Apply one policy per proxy, targeting with `sectionName` when you need different rules for different routes
+
+---
+
+## Summary
+
+- WAF policies use `kind: TrafficProtectionPolicy` at `networking.datumapis.com/v1alpha`
+- `mode` defaults to `Observe` — always confirm before assuming enforcement is active
+- `ruleSets[].type` must be `OWASPCoreRuleSet` — it is currently the only supported ruleset type
+- `targetRefs` requires `group`, `kind`, and `name` — use `sectionName` to scope to a single route rule
+- Start with paranoia level 1 blocking, level 2 detection, and OWASP default score thresholds (5/4)
diff --git a/datumctl/working-with-resources.mdx b/datumctl/working-with-resources.mdx
new file mode 100644
index 0000000..60905dd
--- /dev/null
+++ b/datumctl/working-with-resources.mdx
@@ -0,0 +1,77 @@
+---
+title: "Working with Resources"
+description: "Core patterns for creating, inspecting, and managing Datum resources using datumctl."
+---
+
+`datumctl` follows the same resource model as `kubectl`. If you are familiar with Kubernetes, these patterns will feel immediately familiar. If not, a small set of commands covers most day-to-day work.
+
+---
+
+## Core Commands
+
+| Command | Purpose |
+|---------|---------|
+| `datumctl get <resource>` | List resources |
+| `datumctl get <resource> <name> -o yaml` | View a full resource definition |
+| `datumctl explain <resource>` | Inspect the API schema for a resource type |
+| `datumctl explain <resource> --recursive` | View the full schema tree |
+| `datumctl apply -f <file>` | Create or update a resource from a file or stdin |
+| `datumctl delete <resource> <name>` | Delete a resource |
+
+---
+
+## What You Can Configure with `datumctl`
+
+`datumctl` is the primary interface for:
+
+- **AI Edge** — HTTP proxy routing, WAF policies, and authentication
+- **DNS** — Manage DNS records and domain verification
+- **Routing** — Inspect and debug routing configuration
+- **Secrets and ConfigMaps** — Store credentials and configuration referenced by gateway policies
+
+---
+
+## Declarative Configuration
+
+Datum resources are defined declaratively. This means you can:
+
+- Inspect the API structure directly from the platform using `datumctl explain`
+- Store resource definitions in version control
+- Automate deployments via CI/CD pipelines
+- Treat network configuration as code
+
+A typical workflow looks like this:
+
+```bash
+# Inspect the schema
+datumctl explain httpproxy --recursive
+
+# Apply a configuration
+datumctl apply --project my-project --namespace default -f proxy.yaml
+
+# Verify the result
+datumctl get httpproxy my-proxy --namespace default -o yaml
+```
+
+---
+
+## Namespaces
+
+All resources are created in a namespace. Current examples use the `default` namespace:
+
+```bash
+--namespace default
+```
+
+If your CLI defaults to `default`, you may omit it from commands. To check your current context:
+
+```bash
+datumctl config view
+```
+
+---
+
+## Next Steps
+
+- [Authentication](/datumctl/authentication) — Log in and manage credentials
+- [CLI Reference](/cli/options) — Full flag-level reference for every command