Is This In Scope?
A decision page for determining whether a target, workflow, or action is authorized before work begins.
Use this page to decide whether a target, workflow, or action is authorized before execution begins.
Scope is not a description of intent. It is the boundary that determines whether execution is authorized at all.
1. Problem this page solves
Scope ambiguity causes unsafe execution, weak evidence, and approvals that cannot be defended later.
This page defines a concrete decision path for scope authorization before work starts.
2. What you should understand after reading
After this page, you should understand:
- what scope check means in practice
- which inputs are required before execution
- which questions must be answered before proceeding
- when to proceed, stop, escalate, or move to lab/non-production path
3. Mechanism-first scope decision path
- Identify target/workflow. Confirm exact target identity and environment.
- Identify authority source. Confirm policy/approval source that authorizes this class of work.
- Identify allowed action class. Confirm intended action is allowed for this role and objective.
- Identify constraints/exclusions. Confirm boundaries, disallowed targets, and sensitivity limits.
- Evaluate in-scope decision. Determine whether execution is authorized under current facts.
- Choose outcome. Proceed, do not proceed, escalate, or shift to lab/non-production exception path.
4. Required decision inputs
At minimum, scope decision requires:
- target identity (system/account/artifact/workflow)
- objective statement (why work is requested)
- authority source (policy, approval, role boundary)
- action class and expected impact
- exclusions and escalation boundaries
If one of these is unclear, scope is not yet established.
5. Observed vs inferred
| Layer | What is observed | What is inferred |
|---|---|---|
| Observed | policy/approval records, declared scope, target facts, action constraints | none beyond documented inputs |
| Inferred | whether available inputs are sufficient for safe execution | depends on judgment quality and context completeness |
6. Trust assumptions
Scope decisions depend on assumptions that may fail:
- scope inputs can be incomplete or stale
- approvals can be broad but operationally ambiguous
- correct judgment still depends on truthful upstream facts
Documented scope method reduces drift; it does not eliminate judgment.
7. Decision outcomes
| Outcome | Condition | Action |
|---|---|---|
| Proceed | inputs clear and authorization valid | continue under governed path |
| Do not proceed | explicit out-of-scope or disallowed action | stop execution |
| Escalate for clarification | ambiguity in target, authority, or impact | escalate before action |
| Shift to lab/non-production path | normal scope cannot apply but controlled exception is justified | use documented exception controls (Lab Mode and Scope Bypass) |
8. Next-page handoff
Next, read What Evidence Is Required? to define the minimum record standard for whatever scope decision outcome follows.
| When to stop | Stop when the target, environment, or objective is ambiguous. |
| Escalation trigger | Escalate when the next step affects privileged accounts, production systems, sensitive data, or broad tenant scope. |
| Evidence required | Record the target, objective, planned action, and why you believe it is authorized. |
| Next path | Do I Need to Escalate? |