Context
BSFG facts cross boundaries between zones such as Enterprise, Cloud, IDMZ, PlantA, and PlantB. Those names are operationally important, but they are not universal constants. Different deployments may have different zone topologies, names, and trust layouts.
The architecture therefore needs to decide whether zone identity should be hard-coded into the protocol as enums or treated as deployment-specific configuration.
This decision affects:
- portability across installations
- how often protocol schemas must change
- whether topology evolution requires code changes
- how envelope metadata relates to authenticated peer identity
Options Considered
| Option | Description | Benefits | Drawbacks |
|---|---|---|---|
| Fixed protocol enum | Define zones as a closed enum such as external, internal, enterprise, plant_a, plant_b. |
compile-time rigidity simple validation logic |
poor fit for evolving topologies schema changes required for naming changes reusable protocol becomes deployment-specific |
| Implicit zone from connection only | Omit zone fields from the envelope and infer origin/destination solely from mTLS identity or network endpoint. | small envelope less duplicated metadata |
weak replay readability transport logs lose explicit declarative routing context less useful for diagnostics and downstream reasoning |
| String zone names validated against deployment policy (Selected) | Use envelope fields such as from_zone and to_zone as strings whose allowed values are deployment configuration, validated against authenticated peer identity. |
portable protocol topology changes do not require schema changes explicit routing metadata remains in replay history works with multi-zone deployments naturally |
zone vocabulary must be governed operationally validation moves from type system to policy/configuration |
| Hierarchical zone path model | Encode zones as structured paths such as enterprise/idmz/plantA/line3. |
descriptive naming supports nested routing semantics |
too much topology leaks into protocol names become brittle and overloaded encourages misuse of zones as semantic hierarchy |
Decision
BSFG treats zone names as deployment configuration, not protocol enums.
from_zone : string
to_zone : string
Examples of valid deployment-specific zone names include:
Enterprise
Cloud
IDMZ
PlantA
PlantB
QC-Lab
Vendor
The envelope carries these as explicit metadata so that replay, diagnostics, and retained facts preserve boundary context.
However, zone strings are not self-authenticating. Implementations must validate that the authenticated peer is authorized to assert the declared origin zone and to target the declared destination zone.
Consequences
Benefits:
- BSFG protocol remains reusable across many installations
- zone topology can evolve without schema churn
- retained messages stay explicit about origin and destination
- trust policy remains in deployment configuration where it belongs
Tradeoffs:
- zone naming standards must be maintained operationally
- misconfigured policy can allow invalid zone assertions if validation is weak
- developers lose some compile-time guarantees in exchange for architectural flexibility