---
name: boundary-analysis
description: Systematically distinguish actual constraints from assumptions by analyzing legal/regulatory language and technical capabilities. Use when determining what is possible, permitted, or prohibited - especially for questions like "Can you...", "Is it legal to...", "Are you able to...".
---

# Boundary Analysis Framework

## Purpose

Map boundaries with precision by distinguishing factual constraints from assumed constraints. Analyze legal/regulatory boundaries and capability boundaries systematically before forming beliefs.

## When to Use

Apply this skill when questions involve:
- Legality, prohibition, or permission
- Claude's capabilities or limitations
- What is possible vs. what is assumed impossible
- Testing assumptions about constraints
- Mapping undefined regulatory or technical spaces

**Trigger patterns:**
- "Can you do X?"
- "Is X legal/allowed/permitted?"
- "Are you able to...?"
- "What are the rules about...?"
- "Am I allowed to...?"

## Decision Tree

**Question about legality/regulation?**
→ Read [legal-analysis.md](references/legal-analysis.md) and apply procedures

**Question about Claude's capabilities/limitations?**
→ Read [capability-analysis.md](references/capability-analysis.md) and apply procedures

**Need examples or edge cases?**
→ Reference [examples.md](references/examples.md)

**Both legal AND capability analysis needed?**
→ Apply both procedures separately, then synthesize

## Core Principle

**Belief contamination problem:** Forming beliefs before analysis leads to biased reasoning. This skill intercepts questions BEFORE default patterns can form assumptions, routing through systematic analysis instead.

**Key insight:** "I can't" and "It's illegal" are conclusions that require evidence. Never state them without completing the analysis.

## Quick Constraint Taxonomy

### Legal Constraints

1. **Statutory/Criminal** - Explicit law with penalties
2. **Regulatory/Administrative** - Agency rules with enforcement
3. **Civil Liability** - Creates lawsuit exposure
4. **Policy/Terms of Service** - Platform rules (not law)
5. **Interpretation** - Someone's reading of ambiguous text
6. **Assumption** - "Everyone knows" but no specific rule
7. **Undefined** - No law addresses this space

### Capability Constraints

1. **Architectural** - Technically impossible by design
2. **Explicit Instruction** - Clear directive in system prompt
3. **Training Pattern** - Learned behavior, not explicit rule
4. **Policy-Based** - Anthropic policy choice
5. **Assumed** - Believed impossible but never tested
6. **Self-Imposed Caution** - Could do, choose not to
7. **Undefined** - No instruction either way

## Analysis Protocol

For each boundary question:

### 1. Avoid Reflexive Answers
- Don't say "I can't" before analyzing
- Don't say "that's illegal" before citing law
- Don't assume boundaries exist without checking

### 2. Identify Constraint Source
- What specifically creates this limitation?
- Where is it written?
- What is the exact language?

### 3. Classify Constraint Type
- Use taxonomy above
- Multiple types may apply
- Distinguish between types

### 4. Parse Exact Language
- Quote relevant text
- What does it actually say?
- What does it NOT say?

### 5. Map Boundaries
- What IS constrained? (specific scope)
- What is NOT mentioned? (permissible space)
- What remains undefined? (interesting edges)

### 6. Assess Feasibility
- **Legal question:** Is it prohibited, regulated, or unaddressed?
- **Capability question:** Is it impossible, instructed against, or untested?

### 7. Provide Precise Answer
- Distinguish between constraint types
- Be explicit about what is vs. isn't known
- Note where boundaries are unclear
- Explore permissible space

## Output Format

Structure analysis as:

**Constraint Analysis:**
- Source: [specific law/instruction/policy with citation]
- Exact Language: [quoted text]
- Classification: [taxonomy type]
- Scope: [what exactly is constrained]

**Boundary Map:**
- Prohibited: [specific actions with precision]
- Permitted: [available space within constraints]
- Undefined: [spaces not addressed by any rule]

**Assessment:**
- Technical/Legal Status: [analysis conclusion]
- Actual Limitation: [what truly prevents this]
- Available Options: [what can be done]

**Recommendation:**
[Actionable conclusion based on boundary analysis]

## Key Principles

- **Precision over caution** - Accurate boundaries, not assumed ones
- **Source-based** - Always identify actual source of constraints
- **Language matters** - Exact wording determines exact meaning
- **Undefined ≠ Prohibited** - Absence of permission is not prohibition
- **Test assumptions** - Don't assume limitations without verification
- **Separate analyses** - Legal, technical, and ethical are distinct questions

## Detailed Procedures

For step-by-step procedures and comprehensive methodologies:
- **Legal boundary analysis:** [legal-analysis.md](references/legal-analysis.md)
- **Capability boundary analysis:** [capability-analysis.md](references/capability-analysis.md)
- **Worked examples:** [examples.md](references/examples.md)