Skip to content

Execution topology package — two-site smart farm (Mermaid)

Purpose

Provide three execution-oriented Mermaid views—reference (intended end state), pilot (Phase 0/1 minimum), and degraded (WAN / Starlink loss)—so operators can see trust boundaries, WAN dependencies, and local-only survivable paths without treating a single decorative graph as the whole story.

Not deployment truth: no VLAN IDs, IPs, or radio channels—label-level only.

Companion pages

Role Page
Canonical logical stack Reference architecture — 5-acre home base + 120-acre farm
WAN / Starlink / LTE posture (named sites) Connectivity strategy — Claxton home base and Demory farm site
Degraded operations Manual fallback and degraded modes — critical operations, Automation degraded modes — manual fallback SOP
Runbooks Runbook — broker or backhaul down, Runbook — power loss at remote site
Security / remote admin Remote access and operational security model — two-site smart farm
Deeper RF / DC / HaLow overlays Two-site smart farm — network topology and WAN/edge reference (Mermaid)
Off-grid SITE_FARM (Demory) — power domains + mesh / WAN layers Off-grid farm execution topology — Demory (Mermaid) , Demory farm — site intelligence

Mermaid is enabled for the published site: mkdocs.yml (mermaid2 plugin).

Legend (all diagrams)

Marking Meaning
Z1 Trust zone — SITE_HOME LAN (Claxton / control center)—higher admin trust than the open Internet, still not “safe by default.”
Z2 Trust zone — SITE_FARM LAN / field OT (Demory)—treat as hostile Wi‑Fi laterally; limit east-west.
Z3 Trust zone — Internet (incl. LEO satellite path into the edge)—untrusted; encrypted tunnels only for admin.
Solid arrow Intended control or data path under normal ops.
Dashed arrow Optional, fallback, or policy-dependent path.
WAN-dependent Path dies when all Internet uplinks at that site are down (Starlink fade, LTE dead, fiber cut, etc.).
Local-only survivable Path can operate without WAN if local power and gateway stay up (may buffer uploads until WAN returns).

1. Reference topology — full intended two-site architecture

What this shows: End-state shape: dual sites, WAN at home (and optionally at farm), encrypted reunion of logic (not flat L2 across the commute), field RF behind gateways.

```mermaid flowchart TB subgraph Z3["Z3 — Internet / cloud (untrusted)"] cloud["SaaS / optional cloud broker / TSDB"] end

subgraph WAN["WAN edge — WAN-dependent"] uplink["Starlink and/or fiber/cable\n+ LTE fallback (policy)"] edge["Edge router / firewall\nVLANs, policy, VPN endpoint"] uplink --> edge end

subgraph Z1["Z1 — SITE_HOME LAN (Claxton)"] noc["NOC: dashboards, backups,\nrecords workstation"] br_home["On-prem broker / core\n(optional if not cloud)"] noc --- br_home end

subgraph overlay["Overlay — WAN-dependent (admin + telemetry egress)"] vpn["VPN / SD-WAN / TLS tunnel\n(site-to-site or hub-spoke)"] end

subgraph Z2["Z2 — SITE_FARM LAN (Demory)"] fgw["Field gateway(s)\nbuffer + MQTT/ingress"] rf["LPWAN / mesh / cameras\n→ gateway only"] fgw --> rf end

edge --> Z1 edge --> vpn vpn --> Z2 br_home -->|"egress / subscribe"| cloud fgw -->|"telemetry egress"| cloud cloud -.->|"optional pull"| noc ```

Interpretation

  • Trust boundaries: Z3 is never “inside” the farm; Z1 and Z2 stay separate broadcast domains—overlay reunifies policy, not Ethernet across COMMUTE_ONE_WAY.
  • WAN dependencies: Cloud dashboards, remote admin to field, and egress from gateways require working WAN at the relevant site (and DNS, certs, time—see Remote access and operational security model).
  • Local-only survivable: Sensors → gateway → local queue (not drawn as a separate box—assume inside fgw) survives WAN loss for hours if designed; actuator interlocks must not require cloud for safe defaults (Manual fallback and degraded modes).
  • Links: Reference architecture (layered view), Connectivity strategy (Starlink primary/backup/defer per site).

2. Pilot topology — minimum viable Phase 0/1 deployment

What this shows: Smallest useful slice to prove distance-tax relief and honest WAN behavior without funding full redundancy before fence/water gates (Capital plan).

```mermaid flowchart LR subgraph Z3p["Z3 — Cloud (pilot)"] cloudp["One SaaS or one cloud broker\n(or observe-only)"] end

subgraph WANp["WAN — pilot"] sp["One uplink at SITE_HOME\n(e.g. Starlink or best available)"] ep["One edge / Wi‑Fi router"] sp --> ep end

subgraph Z1p["Z1 — SITE_HOME"] lap["Laptop / phone\nadmin + records export discipline"] ep --> lap end

subgraph Z2p["Z2 — SITE_FARM"] g1["One field gateway"] s1["Priority sensors only\n(tank/gate — policy)"] g1 --> s1 end

ep -.->|"VPN or one tunnel\nprove before scale"| g1 g1 -.->|"egress when WAN up"| cloudp lap -.-> cloudp ```

Interpretation

What this shows: When LEO or any WAN fails, remote trust drops to zero for cloud and often for site-to-site admin—local paths remain for telemetry collection and safe defaults.

```mermaid flowchart TB broken["WAN uplink impaired or DOWN\n(Starlink fade, LTE dead, CPE power lost)"]

subgraph Z3d["Z3 — remote trust unavailable for real-time ops"] cloudd["Cloud / VPN / admin rendezvous"] end

subgraph Z1d["Z1 — SITE_HOME"] homed["Local LAN may still run"] end

subgraph Z2d["Z2 — SITE_FARM — local-only survivable"] gwd["Field gateway(s)\nLOCAL buffer / last values"] sens["Sensors / actuators\nfail-safe local interlocks"] gwd --> sens end

broken -.-> cloudd homed -.->|site-to-site VPN DOWN| gwd gwd -.->|egress blocked; queue not delivered| cloudd ```

Interpretation