# Engineering Landscape

## Purpose and scope

This diagram shows the logical boundaries between public delivery, source
control, a self-managed k3s environment, automation, Google Cloud delivery and
backup services, and the separate Oracle Cloud recovery foundation. It remains
a logical view; dated inventory below does not make it continuous monitoring.

**Source:** `sources/engineering-landscape.mmd`  
**Generated:** `generated/engineering-landscape.svg`

![Engineering Landscape](generated/engineering-landscape.svg)

## Components and trust boundaries

The public boundary contains DNS/TLS, Firebase Hosting, and the static site. The
source boundary contains Git and the dev-only validation/deployment workflow.
The local boundary contains k3s, ingress, services, and persistent storage. The
Google Cloud boundary contains IAM/WIF, private Cloud Storage, monitoring, and
budget controls. The Oracle Cloud boundary contains private Object Storage,
scoped IAM, Vault/key escrow metadata, lifecycle, and budget controls.
Terraform, Bash, Python, and Ansible cross these boundaries only through their
scoped credentials and APIs.

## Data flow and failure paths

Public delivery flows from Git through validation to Firebase and then through
DNS/TLS to the visitor. The separate backup path does not query Secret objects
and reduces ConfigMaps to names and keys, then sends the allowlisted export
through compression, age encryption, federation, and private storage. Retained
workload specifications can still contain literal values, so encryption is the
publication boundary. Source checks, deployment authentication, DNS/TLS,
cluster export, federation, upload, and alert delivery can fail independently.
A second controlled path creates a client-side encrypted recovery artifact for
private OCI Object Storage and keeps restore authority separate from the
scheduled uploader.

## Omissions and verification

Addresses, account/project IDs, credentials, keys, internal topology, and data
values are omitted. On 24 July 2026, read-only checks covered the six-node k3s
environment, Firebase routes, aggregate GCP resource types and controls, and
aggregate OCI resource types and controls. GCP showed active Firebase, WIF,
private storage, monitoring, and no VM/GKE/Cloud Run/Cloud SQL runtime. OCI
showed the private DR foundation with no compute or OKE. Current k3s source,
storage, and backup degradation is documented separately and is not hidden by
this logical landscape.

Related: [hybrid-cloud](hybrid-cloud.md), [security](security.md), and
[visualization guidelines](../visualization-guidelines.md).

**Validation:** `npm run diagrams:check` and `git diff --check`.