BSFG Reference Environment Topology

Purpose

This document describes the conceptual estate topology for BSFG deployments spanning Enterprise, IDMZ, and one or more Plant zones.

It is intentionally environment-level and conceptual:

• it explains zone purpose and placement
• it shows how zones relate structurally
• it identifies the recommended mediation shape
• it does not replace deployment patterns, interaction patterns, runbooks, or validation checklists

Role in the Documentation Stack

This document is a reference environment topology overview.

It sits below the pattern documents and above environment-specific realization documents:

• Reference Deployment Pattern: Triad-HA with Keepalived Failover
• Reference Interaction Pattern: Cross-Zone BSFG Federation
• Environment Deployment Map
• Federation Relationship Matrix

Use this document to understand the estate shape.
Use the other documents to deploy, operate, and validate specific instances of that shape.

Canonical Environment Shape

The canonical BSFG estate spans multiple zones connected by firewalled boundaries.

Recommended structure:

• Enterprise
• IDMZ
• One or more Plant zones

This shape is suitable for industrial environments that must preserve:

• network segmentation
• plant autonomy
• asynchronous cross-zone replay
• zone-owned durability
• explicit, auditable cross-zone exchange

Zone Definitions

A zone is a trust, operational, and durability boundary.

Each zone has:

• its own operational ownership
• its own zone-local durability
• its own BSFG deployment instance
• its own federation relationships to selected peer zones

Important Clarification

A zone is not “a single BSFG node.”

In the current recommended substrate model, each participating zone is typically realized using the Triad-HA deployment pattern:

• Alpha
• Beta
• Gamma
• zone VIP
• local JetStream quorum
• active/passive BSFG controller behavior

This document describes the conceptual environment topology, not the internal substrate realization of each zone.

For internal zone realization, see:

• Reference Deployment Pattern: Triad-HA with Keepalived Failover

Recommended Three-Zone Mediation Model

flowchart LR
  subgraph ENT["ENTERPRISE"]
    ENT_APPS["Apps / Integrators / Analytics / Cloud APIs"]
    ENT_ZONE["Enterprise Zone"]
    ENT_APPS --> ENT_ZONE
  end

  subgraph IDMZ["IDMZ"]
    IDMZ_ZONE["IDMZ Zone"]
  end

  subgraph PLANT["PLANT"]
    PLANT_APPS["MES / PLC / Historian / Quality Systems"]
    PLANT_ZONE["Plant Zone"]
    PLANT_APPS --> PLANT_ZONE
  end

  ENT_ZONE <-->|"Federated BSFG relationship"| IDMZ_ZONE
  IDMZ_ZONE <-->|"Federated BSFG relationship"| PLANT_ZONE

Zone Characteristics

IDMZ Clarification

The IDMZ in this model is a real zone, not merely a transparent firewall hop.

That means:

• the boundary network itself must not host durable middleware
• the IDMZ zone may host its own BSFG deployment and zone-owned durable substrate
• facts and artifacts that must transit or be retained under IDMZ policy may be stored inside the IDMZ zone
• durability belongs to zones, never to firewalls, routers, or boundary transport devices

Recommended Mediation Rule

Default recommendation:

• Enterprise ↔ IDMZ
• IDMZ ↔ Plant
• No direct Enterprise ↔ Plant in the canonical model
• No direct Plant ↔ Plant in the canonical model

This preserves:

• segmentation
• auditability
• operational ownership boundaries
• simpler peer policy

Direct links may exist by explicit exception, but they are not the canonical reference shape.

Multi-Plant Expansion

The mediation model scales by adding more plant zones behind the IDMZ.

flowchart TD
  ENT["Enterprise"]
  IDMZ["IDMZ"]
  PA["Plant A"]
  PB["Plant B"]
  PC["Plant C"]

  ENT <--> IDMZ
  IDMZ <--> PA
  IDMZ <--> PB
  IDMZ <--> PC

Each plant remains its own autonomous zone.
A failure or partition involving one plant must not collapse the autonomy of the others.

Cross-Zone Interaction Shape

Cross-zone interaction is governed by the Cross-Zone BSFG Federation pattern.

Key properties:

• asynchronous
• cursor-driven
• receiver-driven by default
• explicitly authorized
• idempotent under replay
• independent per peer relationship

This topology document does not define the detailed interaction contract.
For that, see:

• Reference Interaction Pattern: Cross-Zone BSFG Federation

Conceptual Cross-Zone Flow

flowchart LR
  ZA["Zone A Producer"] --> ZAB["Zone A BSFG"]
  ZAB -.->|"Fetch / Replay / Artifact Access"| ZBB["Zone B BSFG"]
  ZBB --> ZC["Zone B Consumer"]

Important constraints:

• no shared database across zones
• no shared JetStream across zones
• no implicit replication
• no broker mirroring as the cross-zone synchronization primitive
• no remote availability dependency for local durable work

No Durable Middleware at the Boundary

Critical rule: the boundary network itself must not contain durable middleware.

This means:

• ❌ no Kafka broker living in the boundary transport path
• ❌ no PostgreSQL database living in the boundary transport path
• ❌ no shared message queue living in the boundary transport path
• ✅ routers, firewalls, gateways, VPNs, and other connectivity infrastructure
• ✅ durable BSFG substrate inside zones, including IDMZ as a real zone

Topology Variants

Canonical Mediated Variant

• Enterprise ↔ IDMZ ↔ Plant
• recommended default for industrial estates

Multi-Plant Mediated Variant

• Enterprise ↔ IDMZ ↔ Plant A / Plant B / Plant C
• recommended default for multi-plant estates

Direct IT/OT Variant

• Enterprise ↔ Plant
• simpler, but less mediated and less flexible
• use only where IDMZ is intentionally absent

Relationship to Lower-Level Documents

For specific deployment and policy realization, use:

• Reference Deployment Pattern: Triad-HA with Keepalived Failover
• Reference Interaction Pattern: Cross-Zone BSFG Federation
• Environment Deployment Map: Enterprise + IDMZ + 2 Plants
• Federation Relationship Matrix: Enterprise + IDMZ + 2 Plants
• Runbook: Triad-HA Zone Deployment
• Runbook: Cross-Zone Federation Bring-Up

What This Document Does Not Define

This document does not define:

• exact IP addresses
• exact hostnames
• exact certificates
• exact peer allow-lists
• exact exported streams
• exact artifact permissions
• exact cursor initialization policy
• deployment sequences
• commissioning checklists

Those belong in environment realization documents and operational docs.

Related Documentation

• Reference Deployment Pattern
• Reference Interaction Pattern
• Environment Deployment Map: Enterprise + IDMZ + 2 Plants
• Federation Relationship Matrix: Enterprise + IDMZ + 2 Plants
• Network Policy
• Identity Model
• Observability and Operations