What happens if we apply this fix? — and can we trust the model that told us?

The twin is only useful if it represents the real network. Profile mapping uses three tiers — device-type lookup, port inference, service-name hinting — each with a confidence. Fidelity = Σ(confidence) / device_count. Set your trust threshold and see which devices fall back to http-debug.

Figure (§6.3): A device mapped to "camera-variant" at 0.9 behaves realistically; a router mapped to "http-debug" at 0.1 does not. Low-confidence mappings poison any remediation that touches them.

You can't measure whether remediation reduced risk without a baseline. The deterministic scenario engine replays adversary techniques so the same input always yields the same result — the precondition for honest before/after comparison.

// results appear here

Figure (§6.5): Deterministic hashing makes the baseline reproducible. A stochastic engine would make "did remediation help?" unanswerable.

Patch only, service hardening, or network segmentation. Score them with a weighted multi-criteria model — then shift the weights toward zero-disruption and watch the winner change.

Figure (§6.8): Pareto-style trade-off. Patch is cheap but reversible-hard and leaves topology risk; segmentation cuts the most risk but introduces cascades and downtime.

A fix on device A can break device B that depends on A. The twin's dependency graph reveals these cascades before production. Three types: service-dependency, segmentation, credential.

Figure (§6.10): Top dependency by blast count is the MQTT broker — rotating its shared credential cascades to every sensor that authenticates against it.

All-at-once is fast but a regression takes down everything; one-at-a-time is safe but slow. Find the group size that respects a concurrency limit and dependency separation.

Figure (§6.7): Speedup vs. sequential is bounded by ⌈N/c⌉ — past a point, adding concurrency stops helping and only raises blast risk.

The twin reporting zero_disruption=true (no cascades) is necessary but not sufficient. A doctoral zero-disruption claim must clear all eight conditions.

Figure (§6.12): The MQTT disable passes the naive flag in spirit but fails the strengthened claim on required-service-path and critical-dependency conditions.

Replay real protocol transcripts; compare simulated vs. expected responses. Fidelity = correct / total. Below 80% on an affected protocol is a Twin-Authority block condition.

Figure (§6.14): The twin returns 200 for /admin where the device enforces 403 — it does not model access control, so protocol-level remediation predictions are unreliable.

Side-by-side for the CISO: risk reduction by strategy, the cost/risk Pareto frontier, and a zero-disruption traffic light per strategy.

Figure (§6.8): A strategy is Pareto-optimal if no other beats it on both cost and risk; dominated strategies sit up-and-right of the frontier.

Before recommending any plan you must decide whether the twin is authoritative for that specific decision. A twin good enough to compare strategies may still be unfit to authorize a change against a critical PLC. Each metric carries required evidence and a block condition.

Figure (Decision Gate): Apply this before Exercise 11, then re-apply it after — the drift you inject below is exactly what flips these conditions.

Aggregate drift metrics can miss small but operationally dangerous changes: one firewall rule, one changed dependency, one critical device remapped to a fallback. Toggle each controlled drift scenario — KL and JS divergence are computed live over the behavior distribution (open-port / unmapped bins) with ε-smoothing. Watch which scenarios the metrics can't see.

Figure (Ex 11): The targeted single-change scenarios (firewall, dependency, fallback, replay, subnet) are the most dangerous and the least visible to divergence — they require a mandatory companion metric, not a distribution test. "Small change, big consequence, invisible to KL" is the finding.