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 decides 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 a lab or non-production path
3. Mechanism-first scope decision path
- Identify the target or workflow. Confirm the exact target identity and environment.
- Identify the authority source. Confirm the policy or approval source that authorizes this class of work.
- Identify the allowed action class. Confirm the intended action is allowed for this role and objective.
- Identify constraints and exclusions. Confirm boundaries, disallowed targets, and sensitivity limits.
- Evaluate the in-scope decision. Determine whether execution is authorized under the current facts.
- Choose the outcome. Proceed, do not proceed, escalate, or shift to the lab or non-production exception path.
4. Required decision inputs
At minimum, a scope decision requires:
- target identity (system, account, artifact, or workflow)
- objective statement (why the work is requested)
- authority source (policy, approval, or 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 or approval records, declared scope, target facts, action constraints | none beyond the documented inputs |
| Inferred | whether the 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
A documented scope method reduces drift. It does not remove judgment.
7. Decision outcomes
| Outcome | Condition | Action |
|---|---|---|
| Proceed | inputs are clear and authorization is valid | continue under the 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 a 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? |