Architecture · Operations · Validation

How to review the engineering evidence

This page turns the repository documentation into a guided review. Each visual answers a specific operating question, links to the work it supports, and keeps implemented, validated, planned, and intentionally omitted claims separate.

01 · System boundaries

Start with ownership and trust boundaries

Engineering landscape showing public delivery, Google Cloud, local k3s, source control, automation, and observability boundaries — The landscape separates public static delivery, private recovery data, the self-managed cluster, and automation paths. It is a logical view, not a claim that every component shares one availability or security boundary.

The public website is static. The platform and recovery projects are separate engineering environments with explicit identity, storage, and operator boundaries. Start here before reading an individual implementation so a portfolio delivery component is not mistaken for part of the cluster runtime.

Read the hybrid-cloud case study View maintained source notes

02 · Service delivery

Follow a request one handoff at a time

Kubernetes request path from client and DNS through MetalLB, Traefik, Service, EndpointSlice, Pod, and dependencies — The troubleshooting path distinguishes naming, routing, selection, readiness, policy, TLS, and application response rather than treating Kubernetes health as one boolean.

The related analyzer keeps API discovery read-only and makes active DNS, HTTP, and TLS probes explicit. Optional integrations add evidence when available; unavailable APIs and permissions remain visible as coverage limits.

Read the service-path case study Read the operational article View maintained source notes

03 · Data protection

Separate backup presence from recoverability

Sanitized OCI disaster-recovery architecture with validated, implemented, planned, and externally blocked components — The OCI path records one encrypted synthetic PostgreSQL backup and isolated restore. It does not promote that bounded result into a full-cluster recovery claim.

Recovery evidence becomes stronger in stages: artifact presence, transport verification, decryption and inspection, isolated application restore, and finally a timed end-to-end drill. The portfolio states which stage was actually observed for each project.

Read the OCI recovery case Read the validator case study Read the operational article

04 · Change and recovery

Connect maintenance decisions to a return path

Cluster lifecycle showing controlled shutdown, startup, health checks, and failure paths — Shutdown and startup are treated as state transitions with health gates, abort conditions, and rollback paths—not as collections of successful commands.

The same method appears across the maintenance and capacity tools: inspect first, preserve uncertainty, bound mutation behind separate authority, and define the conditions required to return a node or service to use.

Read the maintenance case study Read the operational article View the maintained runbook

What the evidence is designed to show

Operating decisions are tied to specific observed or source-validated evidence.
Professional work and self-managed engineering remain clearly labelled.
Private identifiers, credentials, and employer topology are not published.
Limitations and missing checks remain part of the result instead of being converted into success.

The underlying Markdown, Mermaid, configuration, and project records remain available for technical review. This guide provides the shorter route for hiring managers and interviewers.