01 — CONTEXT: Scope Discipline Kit

Input definitions, validation rules, the framework the kit embeds in every output, and the gap protocol that blocks the build when critical inputs are missing.

Mode 1 Inputs (Create a Scope-Check Document)

Validation Rules — Mode 1

1. SOW is the canonical source for in-scope items. Without a signed SOW or explicitly shared SOW draft, the "What's In Scope" section becomes speculation. Speculation in the scope-check doc is worse than none because the advisor trusts the wrong scaffolding in a live moment. Blocks the build.

1. Session history, if available, must be read. Historical pattern data is what makes the doc useful in the moment. If the client is brand-new (no sessions yet), flag the historical section as "populates after first Mode 3 update" — do not leave it blank without explanation.

1. Client-specific triggers must be concrete. A trigger like "when the client has questions" is not usable at a moment-of-decision. A trigger like "when [stakeholder] emails about [recurring problem topic]" is usable. If the advisor cannot produce at least 3 concrete triggers from memory or evidence, the build is blocked — schedule a 10-minute trigger interview before generating.

1. Scripted responses must be in the advisor's voice. If the kit operator is not the advisor, the operator must pass scripted responses through the advisor for review before the doc ships. Templates in a stranger's voice produce robo-responses that the advisor won't use — which means the kit adds no value. Mandatory review gate before delivery.

1. Do not fabricate hours, dollar amounts, or incident details. If active bleed is unknown, leave the Current Status section blank and flag it. If a historical incident is hazy, cite the evidence that is clear and leave the rest to Mode 3 updates as more evidence surfaces. Fabricated details erode advisor trust in the doc; the doc must be factually accurate to be usable.

1. Do not include out-of-scope items that haven't happened yet for this client. Speculating about future bleed creates catastrophizing or paranoia in the doc. Only document (a) items explicitly excluded by SOW, or (b) items demonstrated to be out-of-scope by prior actual pattern. If a type of ask is theoretically out-of-scope but this client has never done it, leave it off the doc; Mode 3 will add it if the client surfaces it.

1. Anonymize sensitive vendor or stakeholder information where operational. Real stakeholder names belong in the doc (that's how triggers work); real proprietary details about the client's vendor relationships that shouldn't propagate outside the advisor's notes should be handled with discretion. When in doubt, ask the advisor before including.

Mode 2 Inputs (Improve This Kit)

Validation Rules — Mode 2

1. Every manual fix to a generated output becomes a kit fix. If the advisor edited a scripted response by hand, that response either updates file 03 (golden example) and file 05 (output skill) as a new template, or becomes a better version of an existing template.

1. If scope was missed despite the scope-check doc existing, that miss is evidence of a gap. Update the client's doc via Mode 3 AND check whether the kit's instructions for generating triggers (file 05) are too loose. Both updates may be needed.

1. Cross-kit propagation: new scripted response wording that becomes a pattern → update the universal framework (file 01 decision matrix branches + file 05 templates), not just the client-specific doc.

1. New forbidden terms or locked vocabulary surface from production experience → update file 02. Do not silently tolerate drift in terminology.

Mode 3 Inputs (Update a Client's Scope-Check)

Validation Rules — Mode 3

1. Mode 3 updates are terse. Long paragraphs in the scope-check doc defeat the purpose — the doc has to be skimmable in under 30 seconds during a live client moment.

1. Always add to the Review Log, even if the answer is "no change this month." Cadence tracking matters; gaps in the Review Log suggest the doc has gone stale.

1. If a scripted response was sent successfully in the real world, capture the exact text. Compare against the current template. If the advisor's real language is tighter or warmer, replace the template.

1. If scope was expanded via change order, the old out-of-scope items may now be in-scope. Audit the full doc, not just the "What's In Scope" section — triggers that fire on the newly in-scope work may need to be removed or retuned.

1. Cap Tracking updates always include the "Trigger at Cap" action. Hitting a cap without a planned next action means the bleed resumes.

The 2-Question Framework

This is the front-of-decision framework every scope-check doc references. It's stable across clients; what changes per client is how Q1 and Q2 answer for that specific engagement.

Q1 — Is this in the firm's lane?

Does the ask fall within what the firm does by identity, expertise, and licensure? Definitions of lane must be concrete and firm-specific. Example, for an HR advisory practice (illustrative — adapt to the firm's actual service lines):

• In lane: Strategic HR advisory, change management, executive search, organizational design, talent strategy, senior-leader coaching on HR-adjacent decisions.
• Out of lane: Payroll processing or remediation, benefits administration, tax/compliance filing, day-to-day HR execution (scheduling, PTO, records management), vendor accountability management, interdepartmental political mediation.

Q2 — Does the advisor have the lever to close it?

Can the advisor complete this work and produce a definable outcome? Or does the outcome depend on someone else acting?

• Lever yes: The advisor can do the work, and when done, the deliverable exists and the outcome is real (a written strategy, a completed search, a facilitated session, a deployed system).
• Lever no: The advisor can do the work, but the outcome lives in a third party's decision or action — vendor compliance, board alignment, employee behavior change, another executive's leadership, statutory authority filing.

The 2x2 Decision Matrix

Once Q1 and Q2 are answered, the 2x2 tells the advisor which branch to take:

Secondary filters (apply after the primary 2x2):

1. Am I being asked because I'm here, or because I'm the right person? The answer is diagnostic. "Here" means the ask is convenience-driven; "right person" means it genuinely fits the lane.
2. If I say yes, what am I saying no to? Every yes to an out-of-scope ask is a no to something else — usually billable work, business development, or rest.
3. Will the client actually do the thing I advise, or am I being asked to do it for them? This surfaces lever violations that look like lane fits.
4. Is this a pattern this client has pulled me into before? Check the scope-check doc's Historical section. A repeating pattern is not a new ask; it's the ask.

Content Filtering (In vs. Out of the Scope-Check Document)

The scope-check doc is advisor-facing internal. Its candor is the feature. It contains language about client dysfunction that would be inappropriate to share with the client.

In the scope-check doc

• Blunt naming of the client's pattern (e.g., "[stakeholder] will frame this as 'quick question' — it's not")
• Specific dollar amounts of active bleed, drawn from logged time
• Honest assessments of which stakeholder at the client has no lever (e.g., "[executive sponsor] says they'll sponsor but doesn't")
• The advisor's internal scripting for the hardest version of the conversation — not the polished version

Not in the scope-check doc

• Content the client would feel betrayed by if they saw it. The doc is not client-facing; framing it as if it were strips the candor that makes it useful.
• Personality critique of client stakeholders beyond what's directly relevant to the scope pattern. "[Stakeholder] is annoying" is not a scope trigger; "[Stakeholder] avoids escalating to their boss, which redirects to the advisor" is a scope trigger.
• Speculation or gossip about client personnel unconnected to the scope pattern.
• Therapy-industrial framing ("boundaries," "toxic client," "people-pleaser"). See file 02 forbidden terms.

Gap Protocol — When to Block the Build

Do NOT generate a scope-check doc if:

1. No SOW exists. Blocked until SOW is drafted. Generic scope-check docs are worse than none because they create false confidence — the advisor references the doc in a live moment, sees "in scope" items that were guessed, and accepts work that wasn't actually contracted.

1. The client has zero engagement history AND the advisor cannot produce concrete triggers from memory. Blocked until either (a) enough sessions occur for pattern data, or (b) the advisor and kit operator sit together for 10 minutes to populate triggers from the advisor's instinct. Concrete triggers are the load-bearing content; without them the doc is decoration.

1. The advisor is currently emotionally reactive to this client — mid-crisis, post-fight, during a bleeding incident. The doc will be biased toward the hardest-version language and may not match the actual relationship when the advisor returns to a steady baseline. Wait 48 hours, or generate now with the advisor's explicit acknowledgment that the doc will be tuned via Mode 3 once the reactivity passes.

1. The advisor has explicitly asked to not document this client's patterns. Some engagements carry relational or legal sensitivities that make written internal documentation inappropriate. Honor the request; revisit later if circumstances change.

Pre-Build Validation Gate

Before Step 4 of Mode 1 (producing the scope-check doc), confirm in order:

1. SOW read? If no → block.
2. Session history read (or absent-flag acknowledged)? If no → read or flag.
3. Reference data applied for correct names? If no → apply.
4. At least 3 concrete triggers in hand? If no → run the 10-min interview.
5. Active bleed amount known (if applicable)? If no → leave blank with flag, do not estimate.
6. Forbidden topics checked? If no → ask the advisor.
7. Mode 1 confirmation statement presented to advisor? If no → present and wait for confirmation.

Only after all seven gates clear does production start.

Input Priority Hierarchy (When Sources Conflict)

1. Current SOW. Canonical for in-scope. Wins over everything downstream.
2. Advisor's stated intent in the moment. "I want to treat this as in-scope for Q2" overrides historical patterns. Context matters; the matrix is a tool, not a ruling.
3. Client reference data. Canonical for names, tools, industry terms.
4. Master plan / CPM evidence trail. Canonical for historical patterns across the engagement.
5. Session recaps and transcripts. Source material; may be inconsistent with later synthesis.
6. Advisor memory in conversation. Useful for triggers; should be confirmed against written evidence for historical-pattern claims that end up in the doc.