Define the work boundary: scope, constraints, and out of scope

What this lesson gives you

In the previous lesson, you turned “add a filter to the task list” into a bounded Problem Brief v1: the gap was clear, the observable outcome was clear, and facts, assumptions, and unknowns were separated. One major risk remains. Even with a good problem statement, the change boundary can expand silently. A developer or coding agent may decide to add persistence, redesign the page, alter the data model, or perform nearby refactors because they appear helpful.

This lesson produces Scope Box v1. It makes four decisions reviewable: what the change owns, which constraints the solution must respect, what is deliberately out of scope, and which dependencies the change relies on without taking ownership of them.

This lesson does not define acceptance criteria. FND-001-P03 owns the pass/fail conditions and evidence for the bounded behavior. Here, you define the boundary of the work that P03 will later make testable.

Approximate active time: 45 minutes.

Use this lesson when: the problem is understood, but phrases such as “fix whatever is needed” or “keep it simple” still leave two reviewers with different ideas about what the change is allowed to touch.

Do not use this lesson to: define acceptance criteria, predict every file that will change, modify a shared dependency merely because it makes the local task easier, or authorize unrelated refactoring.

Hard prerequisite — FND-001-P01: you must be able to build a bounded Problem Brief v1 and separate the problem, observable outcome, and fact/assumption/unknown states without hidden decisions.

Short FND-001-P01 prerequisite probe

Fresh request: “Add search to the orders page.” Order numbers are known to exist in the data. It is unknown whether customer names must also be searchable.

Write four lines: actor/context, current gap, observable outcome, and one explicit fact/assumption/unknown. Do not choose a UI, finalize scope, add constraints, or write acceptance criteria yet.

PASS requires 4/4: (1) do not disguise a UI choice as the problem; (2) state an external observable outcome; (3) keep the known order-number field as a fact and customer-name coverage as an assumption or unknown; (4) leave downstream decisions unresolved instead of guessing them.

If any criterion fails, repair only that FND-001-P01 concept and repeat the probe. A precise Scope Box built on a fragile Problem Brief merely formalizes the wrong starting point.

Choose your support route

Every route converges on the same Scope Box v1 and evidence bar. Only the amount of scaffold changes.

Four-concept route probe

Answer each item briefly before reading the explanations below:

1. Scope: Why is “change TaskList.tsx and Filter.tsx” not a sufficient definition of scope?
2. Constraint: What kind of boundary is “the current storage structure must not change,” and how could compliance be inspected?
3. Out of scope / non-goal: What operational effect should “a full visual redesign is not part of this change” have on the diff?
4. Dependency boundary: If filtering relies on existing task status but does not own the data model, what state and risk need to be recorded?

A response passes only if it distinguishes the concept from the thing it is commonly confused with. 4/4 → experienced/Fast Path; 2–3/4 → repair only the fragile concepts; 0–1/4 → foundation route.

• Foundation route: use the shared task-list case and the visible Scope Box template.
• Repair route: revisit only the failed contrast and rebuild that artifact section.
• Experienced / Fast Path: with 4/4, go directly to the independent case; the brief intentionally contains ambiguity and a dependency boundary.

Fast Path exit rule: experience does not lower the bar. The artifact must satisfy the same four critical dimensions.

Mental model: the four walls of a Scope Box

Treat Scope Box as a decision boundary, not a file list and not an implementation plan.

The lesson traceability table represents the same concept → artifact → evidence/boundary relationship. One distinction matters throughout the lesson: a constraint is not an acceptance criterion. A constraint limits the solution or environment. P03 later defines the evidence that shows the expected behavior passes.

The four foundation concepts

1. Scope

Scope is the part of the problem and system this change is specifically responsible for. Do not equate it with the files you currently expect to edit. Files can be discovered later; responsibility still needs a bounded behavioral meaning.

Weak: “Change whatever files are necessary.” Better: “This change owns the task-list behavior for showing unfinished tasks only and returning to the full view.”

Quick check: can every proposed change be traced to an in-scope responsibility?

2. Constraint

A constraint is a rule or condition the solution must respect while achieving the goal. “Keep it simple” is not reviewable enough; two reviewers can interpret it differently.

Better: “The existing task storage structure must not change in this change.” The rule needs an identifiable source or rationale and a later inspection or evidence path.

Boundary: a constraint does not define when the output is accepted. Acceptance criteria belong to FND-001-P03.

3. Out of scope / non-goal

A non-goal is something intentionally not solved by this change even though it is nearby or attractive. “Maybe later” is too weak unless it affects work now.

Example: “A full visual redesign and unrelated CSS cleanup are not part of this change.” Diff that performs those changes needs to be rejected or separated into another Change Request.

4. Dependency boundary

A dependency may be necessary for the task without becoming the task’s target. Record the state you need from it, its owner or authority if known, any unresolved ownership, and the impact if the assumption fails.

Example: the filter relies on existing completed/unfinished task status. This scope does not authorize changing the shared status contract merely because that would be the fastest local implementation.

Build Scope Box v1 from the Problem Brief

Start from Problem Brief v1, not from a preferred solution. Carry forward only what is needed to close the four boundaries.

Blank Scope Box v1 template

Fill this template for a fresh request; every entry needs a reason, evidence, or an explicit unknown.

• Problem Brief trace: source problem/outcome — …
• In scope: behavior or responsibility owned by this change — …
• Constraints: rule + source/rationale + inspection path — …
• Out of scope / non-goals: deliberately excluded work + operational effect — …
• Dependency boundary: dependency + required state + owner/authority or unknown + failure impact — …
• P03 handoff: pass/fail decisions that still need evidence — …

A strong Scope Box is independently reviewable. If two reviewers cannot agree on what the change is allowed to touch, the boundary is not closed.

Where AI helps—and where it stops

AI can suggest possible scope-creep risks, critique whether a constraint is inspectable, surface forgotten non-goals, or identify candidate dependencies for review. Those suggestions are not authority. AI must not silently turn an unknown into a requirement, widen scope, or act as the human acceptance oracle.

Worked case: a Scope Box for the unfinished-task filter

From P01 we have a bounded Problem Brief: users cannot quickly restrict a mixed task list to unfinished items; the observable outcome is that they can see unfinished tasks and return to the full list. Persistence remains unknown.

Dangerous version: “Add the filter, change any files needed, clean up the page, fix the data model if necessary, and make the selection persistent.” Almost every boundary has disappeared.

Scope Box v1:

• In scope: task-list behavior that supports a full-task view and an unfinished-only view, with a way to move between those behavioral states.
• Constraint: the current task storage structure is not changed by this work. Rationale: the shared worked case explicitly sets that boundary. Inspection path: data/schema changes in the review must be absent or justified by a separate Change Request.
• Out of scope / non-goals: a full page redesign, schema redesign, and unrelated cleanup/refactoring. Persistence across sessions is deliberately not classified here because its authority is still unknown.
• Unresolved boundary note: persistence across sessions is neither declared in scope nor declared a non-goal. Until valid authority resolves that boundary, keep it explicit as unknown; implementation must not silently add or prohibit it.
• Dependency boundary: filtering relies on the existing completed/unfinished status. Required state: the status is available and has usable semantics for current tasks. A named owner is not supplied by the current brief and must not be invented. If status semantics are inconsistent or ambiguous, record that as a dependency risk and escalate it for a decision; until authority is clear, do not take ownership of the shared status contract inside this change.
• Handoff to P03: P03 must define the conditions and evidence that demonstrate the bounded behaviors actually pass. This artifact does not pre-invent those criteria.

A reviewer can now evaluate every new proposal against four questions: does it trace to scope, violate a constraint, enter a non-goal, or take ownership of a dependency without authority?

Four plausible failure modes

Failure 1: scope becomes a file list

“Only change these two files” can be useful context, but it is not the behavioral boundary. Repair it by describing responsibility first and treating file guidance as implementation context.

Failure 2: a vague slogan becomes a constraint

“Keep it simple” or “make it clean” is not independently judgeable. Repair it with a rule that has a source/rationale and an inspection path. Do not turn it into an acceptance criterion.

Failure 3: a non-goal has no operational effect

“We are not redesigning the page unless it looks better” does not exclude anything. Repair it so redesign-related diff requires a separate Change Request.

Failure 4: a dependency is seized because it is convenient

An agent edits a shared contract or data model because that is the fastest local path. Repair it by recording required state, owner/authority or unknown, and failure impact. A dependency can be required without becoming the target of the change.

The shared rule is simple: speed does not authorize boundary removal. A traceable unknown is safer than a fictional requirement.

Experienced bridge: contradictory evidence and unclear ownership

Real briefs contain contradictions. A ticket may say “unfinished only,” an old screenshot may show three filter states, and an old team message may mention persistence. Meanwhile, task status comes from a shared package whose ownership is not identified in the brief.

Do not resolve the conflict by intuition. Close only the supported scope, derive constraints and non-goals from actual authority, preserve contradictory evidence as an explicit unknown, and record the dependency risk. If a high-impact boundary decision lacks authority, a human MODIFY or DEFER decision is stronger than fabricated certainty.

What counts as a useful boundary—and what does not

Three artifact designs fail for different reasons:

• Scope too broad: implementation freedom is high, but scope creep becomes impossible to distinguish from legitimate work.
• Scope too file-specific: control feels precise, but the artifact becomes brittle when implementation discovers another file or structure.
• Mega-spec scope: downstream decisions are settled too early and the lesson absorbs P03 and later responsibilities.

The target balance is clear behavioral responsibility + inspectable constraints + operational non-goals + explicit dependency boundaries. Pass/fail criteria remain downstream in P03.

Guided and independent practice

Guided case

An internal orders tool receives the request “add order search.” The Problem Brief says operators currently page through orders to find a specific one, and order numbers exist in the data. It is unknown whether customer-name search is needed. The team also states that the order schema must not change in this task.

Build Scope Box v1 with:

1. one in-scope behavior that traces directly to the Problem Brief;
2. the schema constraint and an inspection path;
3. at least two nearby non-goals;
4. the order-number data dependency with required state, owner-or-unknown, and risk;
5. one P03 handoff line without writing acceptance criteria.

Independent case — Fast Path destination

The authoritative input for this exercise is this bounded Problem Brief v1:

• Actor/context: a learner uploads one file for an assignment from the submission page.
• Current gap: support evidence shows that some learners submit the same file again before they can tell whether the first upload was recorded.
• Observable outcome: after an upload attempt, the learner can determine whether that submission was recorded before deciding whether to submit again.
• Facts/authority: duplicate submissions have been observed; the current page uses the existing upload API; the team explicitly states that this API contract must remain compatible with the current page, the storage provider must not be replaced, and redesigning the course page is not part of this request.
• Unknowns: the exact UI feedback, whether automatic retry is needed, and whether any deep upload-pipeline change is authorized are unresolved. The upload service/storage integration is a dependency for this behavior, but no owner/authority for changing it is supplied by this brief.

An AI proposal says: “Add a progress bar, refactor the upload system, and add automatic retry so the experience is robust.” Treat this as a critique target, not as new authority.

Create Scope Box v1 without copying the task-list wording. For each field, record a reason/evidence or an explicit unknown. End by stating what P02 closes and what must remain for FND-001-P03.

Verification: when is the Scope Box strong enough?

Check four critical dimensions:

1. Concept closure: all four concepts are present and correctly distinguished.
2. Artifact traceability: in-scope behavior traces to the Problem Brief; constraints have source/rationale and inspection paths; non-goals have operational effect; dependencies record state, authority-or-unknown, and risk.
3. Neighbor boundary: P02 has not written acceptance criteria or absorbed FND-001-P03.
4. Human judgment/evidence: high-impact boundary decisions are evidence-backed or explicitly unresolved; AI is not treated as the scope or acceptance authority.

Sufficient evidence for this lesson is Scope Box v1, a boundary explanation, and at least one human-owned decision justified by evidence or explicit uncertainty. Machine validation is necessary, not sufficient.

Assessment and transfer

The assessment checks five moves: explain a bounded distinction, build a Scope Box from a fresh case, diagnose a plausible artifact failure, make a human decision on an ambiguous AI proposal, and transfer the artifact to another domain.

Blocking items require inspectable artifact evidence and rationale. In transfer, preserve the four invariants rather than copying task-list wording, and identify which decisions still belong to FND-001-P03.

References and freshness

The four concepts and the lesson boundary are defined by this course design. No external standard or vendor workflow defines the Scope Box v1 format.

For requirements-engineering context, ISO/IEC/IEEE 29148 was rechecked on 2026-09-05. The 2018 Edition 2 remains the published, current International Standard but is marked “to be revised.” Edition 3 is currently a Draft International Standard under development and has not normatively replaced the 2018 publication.

The live Codex, GitHub Copilot, and Claude Code documentation was also rechecked on the same date. This lesson does not use current product behavior as learner-facing authority, so future changes to those tools do not redefine Scope, Constraint, Non-goal, or Dependency boundary. Any future product-specific claim must be rebound to a current primary source.