sweep the last typographic punctuation out of the components and data files

src/content/projects/edge-ai-platform.md

@@ -3,7 +3,7 @@ title: "Single-Touch Edge AI Platform"
 outcome: "Turned a high-level edge-AI design into a single-press deployment running on Kubernetes at the store edge."
 summary: "Store-edge Kubernetes running GPU-backed AI workloads, deployed from one command, with readiness-gated GPUs so inference never starts before the hardware is ready."
 role: "Infrastructure / DevOps Engineer · Woolworths"
-period: "2025 – Present"
+period: "2025 - Present"
 stack: ["Kubernetes", "Edge", "NVIDIA GPU", "CD pipelines", "Helm", "Python"]
 featured: true
 order: 10
@@ -16,12 +16,12 @@ diagram: "edge-ai"
 Edge AI at retail scale lives or dies on repeatability. A computer-vision workload that
 runs perfectly in a lab has to come up the same way in a store with no on-site engineer,
 flaky connectivity, and a GPU that may not be ready the instant Kubernetes wants to schedule
-against it. The starting point was a high-level design and a pile of manual steps — exactly
+against it. The starting point was a high-level design and a pile of manual steps - exactly
 the gap between "it works" and "it ships."
 
 ## Constraints
 
-- **No hands at the edge.** Deployment has to be hands-off and idempotent — a single press.
+- **No hands at the edge.** Deployment has to be hands-off and idempotent - a single press.
 - **GPU timing.** Inference pods must never schedule before the GPU device plugin is healthy,
   or they crash-loop and poison the rollout.
 - **Heterogeneous stores.** Per-site variables (network, hardware, identity) without forking
@@ -41,15 +41,15 @@ lifecycle management keeps the workload honest from there.
 
 ## Security & reliability decisions
 
-- **Init-gated GPU readiness** — the single biggest reliability win; no more pods racing the
+- **Init-gated GPU readiness** - the single biggest reliability win; no more pods racing the
   GPU at boot.
-- **Single source of truth** for config — drift can't creep in store-to-store.
-- **Spec-driven, documented-as-code** — the deployment *is* the documentation.
+- **Single source of truth** for config - drift can't creep in store-to-store.
+- **Spec-driven, documented-as-code** - the deployment *is* the documentation.
 
 ## Outcome
 
 A high-level idea becomes a real, repeatable deployment on a single press. New edge sites
-come up consistently, GPUs come online reliably, and the manual runbook is gone — replaced
+come up consistently, GPUs come online reliably, and the manual runbook is gone - replaced
 by a pipeline anyone on the team can trigger.
 
 ## Future improvements

src/content/projects/global-infra-modernisation.md

@@ -1,9 +1,9 @@
 ---
 title: "Global Infrastructure Modernisation"
-outcome: "Modernised a global, multi-region estate at scale — ~1,000 VMs, flat-to-segmented networks, and a migration to Azure and Microsoft 365 — on a live 24/7 business."
+outcome: "Modernised a global, multi-region estate at scale - ~1,000 VMs, flat-to-segmented networks, and a migration to Azure and Microsoft 365 - on a live 24/7 business."
 summary: "Across global IT roles at Virtus Health and Linde Asia Pacific: a ~1,000-VM VMware estate managed centrally, a flat-to-segmented network redesign with SD-WAN and Aruba ClearPass, Palo Alto / FortiGate firewall redesigns, and migration to Azure (Blob, AVS) and Microsoft 365."
 role: "Infrastructure Engineer · Virtus Health & Linde Asia Pacific"
-period: "2019 – 2025"
+period: "2019 - 2025"
 stack: ["VMware / vSphere", "Azure (Blob, AVS)", "Microsoft 365", "SD-WAN", "Aruba ClearPass", "Palo Alto / FortiGate", "Veeam"]
 featured: false
 order: 40
@@ -14,13 +14,13 @@ cover: "global-infra-modernisation"
 
 Enterprise estates accrete. Flat networks, sprawling VM counts, aging firewalls, and
 on-prem-only services become a security and operations drag. The work: modernise a global,
-multi-region business that runs 24/7 — without breaking it.
+multi-region business that runs 24/7 - without breaking it.
 
 ## Constraints
 
-- **Keep the lights on** — change a live, multi-region estate without downtime.
-- **Security and compliance** — segmentation, patching, and auditability throughout.
-- **Cost-aware** — modernise to cloud where it pays, justified through CapEx/OpEx cases.
+- **Keep the lights on** - change a live, multi-region estate without downtime.
+- **Security and compliance** - segmentation, patching, and auditability throughout.
+- **Cost-aware** - modernise to cloud where it pays, justified through CapEx/OpEx cases.
 
 ## Design
 
@@ -28,10 +28,10 @@ Across global roles I ran and improved a **~1,000-VM VMware estate**, managed ce
 the IT team and operated across regions including the UK. I re-segmented **flat sites into
 isolated VLAN ranges** with ACLs, layering in **SD-WAN** and **Aruba ClearPass** with 802.1x
 onboarding for a tiered, authenticated network. **Palo Alto / FortiGate** firewalls were
-upgraded and redesigned around the new segmentation — RCA, staging through FortiManager, and
+upgraded and redesigned around the new segmentation - RCA, staging through FortiManager, and
 a flat-to-segmented redesign.
 
-On the platform side: workloads and identity moved to **Azure** (Blob storage, AVS — lifting
+On the platform side: workloads and identity moved to **Azure** (Blob storage, AVS - lifting
 existing vSphere environments) and **Microsoft 365**, with a **hybrid AD sync** I architected
 to bridge on-prem and cloud identity. The estate work also covered an **ERP hardware refresh
 with a new DR / mainframe solution**, file shares to Azure Blob over Kerberos auth, **Veeam**
@@ -39,14 +39,14 @@ backups, and a region-wide **PBX-to-VoIP** migration (RingCentral).
 
 ## Security & reliability decisions
 
-- **Flat → segmented** — isolation by design, not by exception.
-- **Authenticated access** (ClearPass, 802.1x) — the network knows who's on it.
-- **Patched, current firewalls** — closing the easy doors first.
-- **DR built in** — recovery designed, not assumed.
+- **Flat → segmented** - isolation by design, not by exception.
+- **Authenticated access** (ClearPass, 802.1x) - the network knows who's on it.
+- **Patched, current firewalls** - closing the easy doors first.
+- **DR built in** - recovery designed, not assumed.
 
 ## Outcome
 
-A more secure, segmented, cloud-leaning estate that's cheaper to run and easier to operate —
+A more secure, segmented, cloud-leaning estate that's cheaper to run and easier to operate - 
 delivered against live-business constraints across multiple regions.
 
 ## Future improvements

src/content/projects/gpu-as-code.md

@@ -1,9 +1,9 @@
 ---
 title: "GPU-as-Code on the Edge"
-outcome: "Brought GPUs online as code — passthrough, readiness-gated, and reproducible across the fleet."
+outcome: "Brought GPUs online as code - passthrough, readiness-gated, and reproducible across the fleet."
 summary: "GPU passthrough configured through ESXi via code with end-state manifests and Helm, paired with readiness probes, watchdogs, and DCGM-based health reporting."
 role: "Infrastructure / DevOps Engineer"
-period: "2025 – Present"
+period: "2025 - Present"
 stack: ["GPU passthrough", "ESXi", "DCGM Exporter", "Prometheus", "Bash", "Watchdogs"]
 featured: false
 order: 30
@@ -18,9 +18,9 @@ to refuse to start until both are true. Doing that by hand, per site, doesn't sc
 
 ## Constraints
 
-- **As-code, not click-ops** — GPU passthrough defined in code, not the ESXi UI.
-- **Fail safe** — a not-ready GPU must block the workload, not crash it.
-- **Observable** — GPU health has to be visible alongside the rest of the platform.
+- **As-code, not click-ops** - GPU passthrough defined in code, not the ESXi UI.
+- **Fail safe** - a not-ready GPU must block the workload, not crash it.
+- **Observable** - GPU health has to be visible alongside the rest of the platform.
 
 ## Design
 
@@ -33,9 +33,9 @@ platform signal does.
 
 ## Security & reliability decisions
 
-- **Readiness gating** — pods wait for the hardware; no boot-time races.
-- **End-state manifests** — the node's GPU config is declarative and reproducible.
-- **DCGM telemetry** — GPU failures are detected, not discovered.
+- **Readiness gating** - pods wait for the hardware; no boot-time races.
+- **End-state manifests** - the node's GPU config is declarative and reproducible.
+- **DCGM telemetry** - GPU failures are detected, not discovered.
 
 ## Outcome
 

src/content/projects/iac-fleet-automation.md

@@ -1,9 +1,9 @@
 ---
 title: "IaC Fleet Automation"
-outcome: "Stood up identical edge sites from code — every store comes up the same way, every time."
-summary: "Ansible/AWX playbooks wired through a single source-of-truth pipeline: GPU operator, templated networking, image pre-pull and secrets — with air-gapped registry mirroring for disconnected sites."
+outcome: "Stood up identical edge sites from code - every store comes up the same way, every time."
+summary: "Ansible/AWX playbooks wired through a single source-of-truth pipeline: GPU operator, templated networking, image pre-pull and secrets - with air-gapped registry mirroring for disconnected sites."
 role: "Automation Engineer"
-period: "2025 – Present"
+period: "2025 - Present"
 stack: ["Ansible", "AWX", "GitOps", "ACR / NVCR", "Image pre-pull", "Secrets mgmt"]
 featured: true
 order: 20
@@ -15,13 +15,13 @@ diagram: "iac-fleet"
 
 A fleet only behaves like a fleet if every node is built the same way. Hand-configuring GPU
 drivers, CNI, image caches and secrets per site is slow, error-prone, and impossible to
-audit — and at the edge, half the sites can't reach the internet when you need them to.
+audit - and at the edge, half the sites can't reach the internet when you need them to.
 
 ## Constraints
 
-- **Repeatability over cleverness** — the same playbook must produce the same node anywhere.
-- **Air-gapped reality** — disconnected edge sites still have to build from local images.
-- **No secrets in code** — credentials delivered at deploy time, never committed.
+- **Repeatability over cleverness** - the same playbook must produce the same node anywhere.
+- **Air-gapped reality** - disconnected edge sites still have to build from local images.
+- **No secrets in code** - credentials delivered at deploy time, never committed.
 
 ## Design
 
@@ -36,14 +36,14 @@ internet path at the moment it matters.
 
 ## Security & reliability decisions
 
-- **Secrets management at deploy time** — nothing sensitive in git.
-- **Pre-staged, mirrored images** — supply chain stays available and pinned, even offline.
-- **AWX job-level reporting** — every run is visible and auditable.
+- **Secrets management at deploy time** - nothing sensitive in git.
+- **Pre-staged, mirrored images** - supply chain stays available and pinned, even offline.
+- **AWX job-level reporting** - every run is visible and auditable.
 
 ## Outcome
 
 New edge sites are provisioned from code with consistent results, manual build steps are
-removed wherever logic allows, and the whole fleet is reproducible — an IaC-first build
+removed wherever logic allows, and the whole fleet is reproducible - an IaC-first build
 instead of a runbook.
 
 ## Future improvements

src/content/projects/network-automation-fleet.md

@@ -1,9 +1,9 @@
 ---
 title: "Network Automation at Fleet Scale"
-outcome: "Took a multi-region switch fleet from hand-managed to single-pane — automated config backup, bulk change in minutes, and credentials secured and rotated."
-summary: "Productionised a vendor-agnostic network config-management platform (Unimus) with NetBox as the source-of-truth across an AU/NZ/PNG switch fleet: scheduled config backups, mass config push, and a centrally vaulted, rotated credential model — community tooling stood up ground-up under a corporate-supported licence."
+outcome: "Took a multi-region switch fleet from hand-managed to single-pane - automated config backup, bulk change in minutes, and credentials secured and rotated."
+summary: "Productionised a vendor-agnostic network config-management platform (Unimus) with NetBox as the source-of-truth across an AU/NZ/PNG switch fleet: scheduled config backups, mass config push, and a centrally vaulted, rotated credential model - community tooling stood up ground-up under a corporate-supported licence."
 role: "Global IT Infrastructure Engineer · Linde Asia Pacific"
-period: "2019 – 2022"
+period: "2019 - 2022"
 stack: ["Unimus (NCM)", "NetBox (IPAM / SoT)", "Config backup & DR", "Bulk config push", "Credential vaulting + rotation", "Multi-vendor switching"]
 featured: false
 order: 45
@@ -18,49 +18,49 @@ links:
 
 ## Problem
 
-A multi-region switch fleet — Australia, New Zealand and PNG — was maintained by hand.
+A multi-region switch fleet - Australia, New Zealand and PNG - was maintained by hand.
 Configs drifted, backups were "hope someone saved the last one," bulk changes were pushed
 box-by-box, and device credentials were scattered across people and scripts. For a network
 that production depends on, there was no real recovery path and no audit trail.
 
 ## Constraints
 
-- **Live production network** — change the fleet without taking sites down.
-- **Mixed-vendor estate** — the tooling had to be vendor-agnostic, not tied to one OS.
-- **Credentials are the crown jewels** — secured, rotated, and never sitting in a script.
-- **Cost-justified** — a lean tool that earns its place through a real CapEx/OpEx case.
+- **Live production network** - change the fleet without taking sites down.
+- **Mixed-vendor estate** - the tooling had to be vendor-agnostic, not tied to one OS.
+- **Credentials are the crown jewels** - secured, rotated, and never sitting in a script.
+- **Cost-justified** - a lean tool that earns its place through a real CapEx/OpEx case.
 
 ## Design
 
-I productionised **Unimus** — a vendor-agnostic Network Configuration Management platform —
+I productionised **Unimus** - a vendor-agnostic Network Configuration Management platform - 
 as the automation backbone, and stood it up **ground-up**: install, device onboarding,
 backup scheduling, and change workflows. It gave the fleet three things it never had from one
 place: **automated, scheduled config backups**, **change tracking with config diffs**, and
 **mass / bulk config push** across many devices at once.
 
 Paired with it, **NetBox** served as the **IPAM and source-of-truth** for the device
-inventory the automation runs against — so the fleet is driven from a single, accurate model
+inventory the automation runs against - so the fleet is driven from a single, accurate model
 of what exists rather than tribal knowledge. Both are lean, community-rooted tools adopted
 under a **corporate-supported licence**, which made them viable inside an enterprise change
-process — the open-source-into-corporate pattern, done properly.
+process - the open-source-into-corporate pattern, done properly.
 
 ## Security & reliability decisions
 
-- **Centralised, vaulted credentials with rotation** — the network's secrets live in one
+- **Centralised, vaulted credentials with rotation** - the network's secrets live in one
   scoped, rotated place, never embedded in scripts or shared by hand.
-- **Config backup = real network DR** — every device restorable from a known-good config.
-- **Diffs + auditing** — every configuration change is visible, attributable, and reversible.
-- **Source-of-truth driven** — automation acts on NetBox's model, not on guesswork.
+- **Config backup = real network DR** - every device restorable from a known-good config.
+- **Diffs + auditing** - every configuration change is visible, attributable, and reversible.
+- **Source-of-truth driven** - automation acts on NetBox's model, not on guesswork.
 
 ## Outcome
 
 The switch fleet across AU/NZ/PNG was maintained from a single pane: configs backed up
 automatically, bulk changes pushed in minutes instead of days, credentials secured and
-rotated, and — for the first time — a genuine recovery path for network configuration. A lean
+rotated, and - for the first time - a genuine recovery path for network configuration. A lean
 community toolset, productionised with enterprise rigour.
 
 ## Future improvements
 
-Drive the automation deeper from the source-of-truth — intent in NetBox, pushed to the fleet
-through Unimus — and template standard site configs so a new location onboards straight from
+Drive the automation deeper from the source-of-truth - intent in NetBox, pushed to the fleet
+through Unimus - and template standard site configs so a new location onboards straight from
 the inventory.

src/content/projects/self-hosted-ai-homelab.md

@@ -1,6 +1,6 @@
 ---
 title: "Self-Hosted AI & Homelab Platform"
-outcome: "A production-grade homelab — GitOps from bare metal to local AI, and the platform that serves this very site."
+outcome: "A production-grade homelab - GitOps from bare metal to local AI, and the platform that serves this very site."
 summary: "Proxmox with PCIe passthrough under Talos and OpenShift clusters, all driven by ArgoCD GitOps: local LLM inference, split-horizon DNS, 2FA/SSO VPN, full observability and NAS-backed backups."
 role: "Owner / Operator"
 period: "Ongoing"
@@ -13,38 +13,38 @@ diagram: "homelab"
 
 ## Problem
 
-The best way to stay sharp on platform engineering is to run a real platform — one with the
+The best way to stay sharp on platform engineering is to run a real platform - one with the
 same rigour as production, where the only person on call is you. The goal: a homelab that's a
 genuine proving ground for Kubernetes, GPUs, AI and security, not a pile of containers.
 
 ## Constraints
 
-- **Run it like production** — GitOps, backups, observability, no snowflake config.
-- **Secure by default** — nothing exposed that doesn't need to be.
-- **Reproducible** — rebuild a node from code, not from memory.
+- **Run it like production** - GitOps, backups, observability, no snowflake config.
+- **Secure by default** - nothing exposed that doesn't need to be.
+- **Reproducible** - rebuild a node from code, not from memory.
 
 ## Design
 
 Proxmox provides the hypervisor layer with **PCIe passthrough** (GPU and storage) into
-single-node **Talos** and **OpenShift** clusters. Everything is **ArgoCD GitOps** — the
+single-node **Talos** and **OpenShift** clusters. Everything is **ArgoCD GitOps** - the
 cluster state lives in git and reconciles itself. On top: **local LLM inference** on a
 Blackwell-class GPU, **split-horizon DNS** via Pi-hole, a VPN with **2FA/SSO**, and a
 **Prometheus / Grafana** observability stack. ZFS handles storage tiering; restic ships
-**NAS-backed backups**. Public services reach the internet through a **Cloudflare Tunnel** —
+**NAS-backed backups**. Public services reach the internet through a **Cloudflare Tunnel** - 
 which is exactly how this site is served.
 
 ## Security & reliability decisions
 
-- **GitOps as the source of truth** — drift is reconciled, not chased.
-- **2FA / SSO and segmented access** — least privilege across the lab.
-- **Back up state, not just volumes** — restores are drilled, not hoped for.
-- **Outbound-only public exposure** — a tunnel, not an open port.
+- **GitOps as the source of truth** - drift is reconciled, not chased.
+- **2FA / SSO and segmented access** - least privilege across the lab.
+- **Back up state, not just volumes** - restores are drilled, not hoped for.
+- **Outbound-only public exposure** - a tunnel, not an open port.
 
 ## Outcome
 
 A homelab that behaves like a platform: rebuildable from code, observable, backed up, and
 secure enough to host a public site on. It's where new patterns get proven before they go
-anywhere near real infrastructure — and it's running right now, under this page.
+anywhere near real infrastructure - and it's running right now, under this page.
 
 ## Future improvements