Scope Control and Change Management

Once the scope is approved, the main management task is to not drift from it silently: every expansion changes the budget, the schedule, and the risks, and in client-facing projects it often requires a formal CR or an addendum. In the system, this function is handled by /scope-check.

Important: "small extras" ("while you're at it, do Y too") are not treated as silent backlog. They are recorded.

What /scope-check stores

One living document — scope-check.md — with four sections:

Section	What it holds
Assumptions	The baselines the approved scope rests on: volumes, number of integrations, environments, dates, the commercial basis. 3–5 rows in the standard case, 10–15 in large projects
OOS / change log	Requests that went beyond the scope: type, related assumption, source, impact estimate, status
Change history	An append-only journal: what, when, by whom
Sources	Where the assumptions come from (charter, scope, contract, BRD, plan)

Step 1. Baseline: /scope-check baseline

Type /scope-check baseline (or just /scope-check — if there is no baseline, the agent creates one). The agent extracts the material assumptions from the charter, scope, contract, and BRD — the ones whose breach would move the price or the finish date:

• measurable parameters: module counts, data volumes, number of integrations, environments, jurisdictions;
• explicit inclusions and exclusions;
• implicit boundaries (ambiguity is a scope risk);
• the commercial basis (fixed / capped / T&M / internal) — it sets the strictness, but this is not legal advice.

Each row carries a source, confidence, a status ("holding", "under pressure", "breached"), and sensitivity: what happens if the assumption fails.

Step 2. Assessing a request: /scope-check assess

When a signal appears — a new request, "while you're at it…", a volume growth — the agent assesses it against the baseline:

Class	What it is	Action
In scope	Explicitly covered	No OOS row
Excluded	Explicitly out	OOS — record and raise
Grey zone	A reasonable extension?	The agent shows the evidence — you decide
New work	Not contemplated	OOS — record and raise
Volume breach	Same scope, more quantity	An assumption breach — the path differs from a new-scope CR

The materiality test: would this move the price, the finish date, or a key risk? A trivial variation goes to "watching"; a material one goes to OOS/CR.

At assessment, the source is always recorded: who, when, where (email subject, meeting, ticket key). Without a source, the row is not added.

Step 3. Registering: /scope-check register

Confirmed candidates go into the OOS/CR log: id, what changed, type (expansion / reduction / assumption breach / ambiguity), the related assumption, date, source, impact estimate (a range is fine), whether the client was raised, and the status ("identified" → "assessed" → "notified" → "fee agreed" / "absorbed" / "deferred").

Each row is a draft with your confirmation: the agent proposes, you decide.

Step 4. Client notice: /scope-check notice

For material open items on client-facing work, the agent drafts a notice (in scope-check.md or a separate dated file):

• it starts with what was found, not with the fee;
• it references the original assumption / SOW snippet;
• it offers the options: absorb / defer / formal CR / contract addendum;
• it asks how to proceed; when possible — agreement before the work starts.

No apologetic tone, no adversarial posture. The legal wording — to counsel.

When the check runs on its own

The agent automatically invokes the scope check in two cases (it does not wait for your command):

1. A growth signal — in the conversation, the /manage walk, the delta, or BRD edits, an "and also X", a volume breach, or an out-of-scope ask appeared;
2. New work in the plan — before /plan or /tickets adds blocks, phases, epics, or ticket sets that are not in the approved scope.

In both cases: the assessment first, then — by your decision — absorption, deferral, CR, or a scope revision.

What /scope-check does not do

• Does not rewrite the scope statement — if the structure of the blocks itself must change, that is /scope revise;
• Is not an ITIL CAB — it is a PM working tool, not an organizational procedure;
• Does not invent fees or legal conclusions — impact estimates are ranges with sources; the fee decision is yours.

Where to continue

• Risk management — a material OOS often spawns a new risk.
• Schedule planning — an accepted change enters the plan only after the assessment.
• Reporting for management — open changes in the report.