Some operating problems are too large to prosecute honestly as one case. DGS should not flatten those problems into a fake whole-system answer. The stronger path is to frame the larger problem, select a bounded theater, prosecute that theater, and preserve what remains outside the proof boundary.
When the problem contains multiple theaters, DGS should identify candidate theaters and make the selected theater explicit. The output should tell the reader whether it is judging the whole bounded case or one selected theater inside a larger problem.
- The selected theater is the scope of prosecution.
- The larger problem boundary remains visible as a non-claim.
- Unprosecuted theaters stay unresolved until separately run or reviewed.
When multiple theaters have been completed, DGS can synthesize the frozen theater outputs into a campaign-level view: which theaters were prosecuted, how they depend on each other, what intervention sequence follows, and where confidence remains bounded.
A pilot implementation package converts campaign authority into practical deployment mechanics. It can include executive readout, operator playbook, metrics and evidence packet, pilot charter, go-live checklist, RACI matrix, shift cadence, status transition rules, stop/go rules, and data templates.
A campaign or pilot package is not a claim that the whole organization has been fixed. It is a grounded way to start a controlled pilot from prosecuted authority while naming the evidence still needed for wider rollout.