This is an excellent breakdown of a subtle but critical modeling problem. The analogy to event-driven architectures is spot on.

We face a structurally similar challenge in investment simulation, but with time-series data. A user's portfolio is the central hub ("event broker"), and historical market events (drawdowns, volatility spikes, earnings) are the producers/consumers. If we model relations naively, we lose which specific historical regime caused a given rule violation.

Our solution aligns with your "Solution 1: More specificity": we pre-compute and tag regime-specific metrics (e.g., "max drawdown during 2020 Q1", "volatility during 2018 Fed hikes"). This allows the engine to answer "why was this stock excluded?" with a precise historical scenario, not just a generic violation.

Question: In your experience, is there a performance/readability trade-off threshold where adding this specificity (like your firewall rules or our regime tags) becomes counterproductive for the diagram (or system) comprehension?

Got to love the relational model. Learned about fan traps in data modelling course at uni in the early 80s
Solution 4: Break the fan. Change it into smaller boxes each with the fan name.

Service A -> Firewall -> Service X

Service C -> Firewall -> Service Z