System Scope Definition

Define the system-of-interest boundary so analysis, responsibility, measurement, and intervention target the right whole.

Solution archetype #

1052

Problem family

Boundary, Scope, Access & Spillover Failure

Problem subfamily

Frame, Scope & Applicability Misdefinition

The Diagnostic Story

Symptom: The same project meeting keeps returning to what are we actually solving and who owns this because no one ever stated what is inside the system and what is not. Metrics contradict each other because different people are counting different populations. Work expands through adjacent requests without a conscious decision to include them. Analysis alternates between too narrow to explain the problem and too broad to act on.

Pivot: State the boundary explicitly — what is inside, what is outside, what is adjacent, and what crosses the line — then connect that boundary to responsibility, measurement, handoffs, and review. The scope decision becomes visible and governable rather than assumed.

Resolution: Participants are reasoning about the same system-of-interest, so analysis is coherent and metrics are comparable. Responsibility aligns with the declared boundary: what is inside is owned; what is adjacent is visible but not implicitly committed. Scope disagreements can be raised and resolved without restarting the entire initiative.

Reach for this when you hear…

[software project management] “We're six weeks in and product and engineering still disagree on whether the notification system is in scope — that ambiguity needs to be a one-page decision document before we write another line of code.”

[public health evaluation] “The intervention covers the clinic population, but we're being held accountable for community outcomes we have no control over — we need to be explicit about what the program boundary actually is.”

[systems analysis] “Every time we model this we either get a toy that ignores the supply chain or a diagram so big no one can identify a lever — we need to agree on the boundary before we go further.”

When This Archetype Applies

No catalog groundingNone of the structural conditions is currently represented by an accepted prime or domain-specific abstraction.

Diagnostic problem

A problem, project, model, or intervention lacks a clear boundary, causing unclear responsibility, inconsistent measurement, scope creep, contested assumptions, or misdirected action.

What this problem means

The structural problem is **scope ambiguity**. A system is being discussed, measured, governed, modeled, or changed, but its boundary is not explicit enough to support coordinated action.

This ambiguity causes several recurring failures. Responsibility is diffuse because no one knows which part of the world the actor owns. Measurement is inconsistent because different people count different populations or time horizons. Analysis is unstable because causes move in and out of view. Work expands because adjacent requests are never consciously admitted or rejected. Interfaces fail because handoffs to adjacent systems were not named.

The root tension is between focus and completeness. A useful scope must be narrow enough to support action and broad enough to preserve the relevant whole.

Show the applicability expression

Applicability expression4 distinct conditions

Divergent system definitionsandUndefined system boundaryandUnconscious scope expansionandMisattributed outcomes

Algebraic1∧2∧3∧4

groundedpartly groundedopen

4 conditions, all required.

4Required in every casenumbered 1–4

These hold no matter which pattern applies.

1

Divergent system definitions · open

Different actors use different implicit definitions of the system they are discussing. more

and — also required

2

Undefined system boundary · open

Responsibilities, measurements, or intervention targets are ambiguous because no one has stated what is inside the system-of-interest. more

and — also required

3

Unconscious scope expansion · open

Work expands through adjacent requests, exceptions, or dependencies without a conscious scope decision. more

and — also required

4

Misattributed outcomes · open

A model, policy, project, or service is being judged by outcomes that it may not actually own. more

Other requirements and context (1)

Why these sit outside the expression

Goal — a goal states an intended outcome or evaluation criterion, not a pre-existing situation that independently summons the archetype.

• GoalA boundary has to be made explicit before another intervention can be chosen. more

Coverage

0 of 4 conditions grounded · 4 open.

Read the methodology · Download the trigger-logic data

Mechanisms / Implementations

• System-of-Interest Definition: A method for naming the system under consideration, its environment, and its interfaces.
• Project Scope Statement: A project document that records included work, excluded work, deliverables, assumptions, dependencies, and acceptance criteria.
• Model Boundary Definition: A modeling artifact that states what a model represents, omits, assumes, and where its outputs are valid.
• Jurisdictional Scope: A legal or administrative definition of the territory, matter, population, or authority an actor governs.
• Service Boundary Definition: An operational definition of what a service owns, exposes, depends on, and hands off.
• Research Inclusion/Exclusion Criteria: Protocol criteria specifying which participants, cases, studies, observations, or evidence sources are included or excluded.
• Operational Responsibility Map: A map connecting parts of a scoped system and its interfaces to owners, handoffs, escalation paths, and decision rights.

Related Abstractions

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (3)

• Boundary: Defines system limits.
• Representation: Model complex ideas.
• Set and Membership: Groups and categorizes elements.

Also references 3 related abstractions

• Boundary Critique: Examines inclusion/exclusion assumptions.
• Constraint: Limits possibilities to guide outcomes.
• Holism: Whole exceeds sum of parts.

Variants

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Project Scope Definition · domain variant · recognized

Defines the included work, excluded work, deliverables, actors, interfaces, and decision rights for a project or initiative.

Model Scope Definition · implementation variant · recognized

Defines what a model represents, what it abstracts away, and which interfaces connect model outputs to real-world decisions.

Responsibility Scope Definition · governance variant · recognized

Defines which actors or units are responsible for which parts of a system, including handoffs and shared interfaces.

Research Scope Definition · domain variant · recognized

Defines the population, cases, variables, time horizon, and evidence base included or excluded from a research claim.

Editorial Notes

Problem Classification

Classification: Boundary, Scope, Access & Spillover Failure → Frame, Scope & Applicability Misdefinition

Problem kernel: the system boundary is too ambiguous for ownership or measurement

Rationale: Earliest causal condition: A problem, project, model, or intervention lacks a clear boundary, causing unclear responsibility, inconsistent measurement, scope creep, contested assumptions, or misdirected action.

Independent corroboration: The earliest necessary condition in the frozen evidence is: A problem, project, model, or intervention lacks a clear boundary, causing unclear responsibility, inconsistent measurement, scope creep, contested assumptions, or misdirected action. That is a frame scope and applicability misdefinition problem because A problem, project, model, role, or impact perimeter omits consequential elements, expands without control, or is applied beyond the domain in which its claims and responsibilities remain valid.

Review outcome: Independent reviewer agreement; high confidence.