Skip to content

Scope Change Review

Governance ritual — instantiates Domain–Codomain Delimitation

A recurring review that gathers accumulated boundary violations and edge cases, decides deliberately whether the domain or codomain should change, and versions and announces any revision.

Scope Change Review is the mechanism that keeps a boundary alive rather than frozen. Every other sibling defines or enforces a boundary at a point in time; this one owns the boundary over time. On a recurring cadence it collects the edge cases, rejected inputs, and violations that have piled up at the boundary, reads them as signal, and makes a deliberate call: hold the line, or move it — and if it moves, version the change and tell everyone who depends on it. Its distinguishing role is stewardship: it is the only mechanism here that is allowed to revise the domain or codomain, and it insists that revision be a governed, versioned, communicated act rather than something that happens by accident, one lenient exception at a time.

Example

An internal "expense auto-approval" rule was drawn to auto-approve reimbursements under a set amount in a few clean categories, routing everything else to a manager. Over two quarters, the edge-case catalog fills up: a new category of software subscriptions nobody anticipated, a stream of borderline travel claims that keep getting manually overridden "just this once," and a handful of auto-approvals that later turned out to be duplicates. The quarterly Scope Change Review reads these together. It decides to add the subscription category to the domain (with a cap), to tighten the travel boundary that overrides were quietly eroding, and to add a duplicate-check precondition. It then issues a versioned notice — "auto-approval policy v3, effective next month" — so finance systems and managers migrate together, instead of the boundary drifting invisibly through a thousand individual overrides. The review has converted accumulated boundary friction into one deliberate, announced revision.

How it works

The ritual runs on a cadence and follows the evidence: assemble the catalog of edge cases, rejections, overrides, and violations since last time; classify each as noise, a true gap in the current boundary, or scope creep to resist; decide hold-or-revise for the domain and codomain; and, when revising, produce a versioned scope notice that dependents can migrate against. Its discipline is separating signal (a recurring edge case that reveals the boundary was drawn wrong) from pressure (a one-off request to bend the boundary for convenience) — and never letting the boundary move except through this deliberate, recorded step.

Tuning parameters

  • Cadence — how often the review runs. Frequent reviews keep the boundary current but cost attention; rare ones let edge cases and creep accumulate into a bigger, riskier revision.
  • Evidence threshold — how much a case must recur before it counts as a revision signal rather than noise. A low bar chases every anomaly; a high bar lets real gaps persist.
  • Revision authority — who can actually approve a boundary change (the reviewer, a board, a sign-off chain). Tighter authority resists creep but slows legitimate updates.
  • Versioning granularity — how changes are versioned and how long old boundaries are supported for migration. Longer support windows are safer for dependents but costlier to maintain.

When it helps, and when it misleads

Its strength is that it makes boundary change deliberate and legible: revisions are evidence-driven, versioned, and announced, so dependent systems and people are never surprised, and the slow erosion of a boundary through accumulated exceptions is caught and either ratified or reversed on purpose. Its failure modes are two-sided. Run too eagerly, it ratifies scope creep — blessing every convenient exception until the boundary means nothing.[1] Run too conservatively, it becomes a rubber stamp that never updates a genuinely wrong boundary, so reality and the stated scope diverge. And the classic misuse: removing a boundary because its purpose has been forgotten, when the boundary was load-bearing all along — the discipline is to treat every proposed loosening as requiring a positive reason the original constraint no longer applies, not merely the absence of a remembered one.[2]

How it implements the components

  • scope_stewardship — assigns and exercises the standing responsibility for reviewing violations, deciding revisions, versioning them, and communicating them; this ritual is the stewardship function.
  • edge_case_catalog — the accumulated record of edge cases, overrides, and rejections that the review reads as its primary evidence.
  • versioned_scope_notice — the versioned announcement of any boundary change, so dependent systems and people migrate together rather than discovering the shift by surprise.

It governs the boundary but neither defines nor enforces one on the fly: authoring the domain and codomain is done by Eligibility Criteria, Type Signature, and Output Schema, and the runtime checks are Input Validation Gate and Output Validation — this review only decides whether those boundaries should change.

References

[1] Scope creep — the incremental, often unnoticed expansion of a boundary as small exceptions and additions accumulate. The review exists to make such expansion a conscious, recorded decision rather than an emergent drift. ↩

[2] Chesterton's fence — the principle that one should not remove a boundary until one understands why it was put there. It is the right discipline for a review tempted to loosen a constraint whose original rationale has simply been forgotten. ↩