export default integrity-bound-scope

name	integrity-bound-scope
description	Define boundaries where claims or recommendations apply versus break down. Use when: (1) asked to define scope or boundaries, (2) claim presented as universal truth, (3) explaining why pattern works here but not there, (4) advice given without specifying applicable context.

Bound Scope

Mark the boundaries where claims, principles, or explanations hold true and where they fail, making the domain of applicability explicit rather than allowing ideas to spread beyond their valid scope.

Instructions

When bounding scope:

1. Identify the core assertion - Strip away qualifiers to find what's actually being claimed or recommended, since vague assertions resist boundary-setting while specific claims reveal their natural limits.

2. Define where it works - Determine the conditions, contexts, and assumptions that must hold for this principle to apply reliably, recognizing that every claim emerges from specific circumstances and only transfers to contexts sharing those characteristics.

3. Mark where it breaks - Identify boundary conditions where the principle fails by examining what invalidates core assumptions, at what scale complexity overwhelms the approach, and where application would cause harm rather than help.

4. Test the edges - Examine ambiguous cases near the boundaries to understand whether they fall inside or outside scope, revealing whether limits are sharp or fuzzy and exposing nuances that central cases obscure.

5. Name explicit exceptions - State clearly what falls outside by naming specific situations where this doesn't apply, problems where different approaches work better, and contexts where following this advice would be wrong.

6. Use conditional framing - Express the scoped claim as "this applies when X, not when Y" rather than unconditional statements, making scope explicit in the claim itself instead of expecting readers to infer limits.

7. Distinguish core from periphery - Separate where the principle strongly applies from where it weakly applies or requires adaptation, since not all out-of-scope situations sit equally far from the boundary.

Examples

Scoping architectural advice

I'm reviewing guidance that says "microservices improve system scalability and team independence." This is stated as universal advice, but architectural patterns have clear scope boundaries. I examine where this applies: the principle assumes you have multiple teams working on different business capabilities, that independent deployment provides value, that operational complexity is manageable, and that the system has reached a scale where monolithic coordination costs exceed microservice overhead. I mark where it breaks down: early-stage products with small teams gain no independence benefit from splitting, systems with tight transactional consistency requirements fight against service boundaries, organizations without strong DevOps practices drown in operational complexity, and domains with unclear boundaries create chatty cross-service dependencies that destroy the performance benefits. I test edge cases: a system with three services sits at the boundary where you have distribution costs without full independence benefits, a team of five engineers might split into microservices if they're geographically distributed but probably shouldn't if they're co-located, and read-heavy systems might benefit from independent scaling even if they're not yet at massive scale. I call out explicit exceptions: startups optimizing for speed should avoid microservices until they prove product-market fit, systems requiring distributed transactions should look at different patterns, and teams without deployment automation will make microservices more painful than helpful. I reframe the scoped claim: "Microservices improve scalability and team independence when you have multiple teams working on separable business capabilities, operational maturity to manage distributed systems, and scale where coordination costs exceed distribution costs. They create net complexity in early-stage products, small teams, tightly coupled domains, or organizations without strong DevOps practices." Now the advice carries its scope boundaries explicitly rather than implying universal applicability.

Scoping productivity techniques

I'm encountering advice that "morning routines boost productivity by creating consistent habits." This appears universally applicable but has hidden scope limits. I identify the core assertion: establishing fixed morning behaviors creates momentum that carries through the day. I define where this applies: the principle assumes you have control over your morning schedule, that your energy and focus patterns peak in morning hours, that routine reduces decision fatigue in your specific situation, and that consistency is more valuable than flexibility for your work type. I mark boundaries: shift workers can't maintain morning routines across changing schedules, parents with young children face unpredictable morning demands that resist routinization, people with evening chronotypes might create productive routines at different times, and creative work requiring fresh perspective might benefit more from varied mornings than consistent ones. I test edges: someone with moderate morning demands might have a minimal routine rather than an elaborate one, routines might work weekdays but not weekends, and the same person might need routines during intense work periods but not during creative exploration phases. I call out exceptions: people managing chronic illness need flexibility over consistency, those in reactive roles like emergency response can't protect morning time, and individuals discovering what works shouldn't lock into routines before understanding their patterns. I reframe with conditions: "Morning routines boost productivity for people with schedule control, morning energy peaks, and work requiring sustained focus, particularly when decision fatigue is a factor. They don't fit shift work, unpredictable caregiving demands, evening chronotypes, or situations requiring routine flexibility over consistency. The value depends on your autonomy over time, your chronobiology, and whether your work benefits more from consistency or variation." The scoped version acknowledges the technique's power within its domain while preventing blanket application to situations where it creates friction rather than momentum.

Scoping research findings

I'm reading a study claiming "remote work increases productivity by 15% compared to office work." This quantitative finding invites overgeneralization if scope isn't bounded. I examine the domain: the study measured knowledge workers in software development at companies with existing remote infrastructure, during a period when office workers faced commute costs and open office distractions, using self-reported productivity metrics and commit frequency. I identify boundaries: the finding assumes work is measurable through individual output rather than collaboration, that remote workers have suitable home workspace, that the role doesn't require physical presence or equipment, that team coordination doesn't require high-bandwidth in-person communication, and that company culture supports async work.

I mark where it breaks down: collaborative design work might suffer from reduced spontaneous interaction, new employees lose onboarding benefits of proximity, roles requiring physical equipment or secure facilities can't go remote, and companies without strong documentation culture struggle with remote knowledge transfer. I test edge cases: hybrid models sit at the boundary where some benefits apply, different roles within the same company might show opposite effects, and the productivity gain might vary by individual personality and life situation. I call out exceptions: crisis response teams need co-location for coordination, manufacturing work is inherently on-site, highly regulated industries face compliance barriers to remote work, and early-stage startups might prioritize culture-building over productivity gains. I reframe the scoped claim: "Remote work shows productivity gains of around 15% for individual knowledge work in software development, particularly for experienced employees with home workspace and companies with remote infrastructure and async culture. These gains don't generalize to collaborative roles, physical work, new employees, organizations without documentation culture, or situations requiring high-bandwidth real-time coordination. The effect varies significantly by role type, company maturity, and individual circumstances." The bounded version preserves the finding's validity within its context while preventing misapplication to situations the research didn't study.

Scoping design patterns

I'm documenting that "caching solves performance problems by storing computed results for reuse." This architectural pattern has specific applicability conditions. I define the domain: caching works when computation is expensive relative to storage and retrieval, when the same inputs recur frequently enough to justify cache overhead, when results are deterministic or tolerate some staleness, and when the working set fits in available cache memory. I mark boundaries where it fails: data that changes constantly creates cache invalidation overhead exceeding the benefit, unique queries that never repeat waste cache space, real-time requirements that can't tolerate any staleness make cached data incorrect, and working sets larger than cache capacity create thrashing that destroys performance. I test edge cases: partially cacheable data might benefit from caching components rather than whole results, probabilistic caching might work where deterministic caching doesn't, and read-heavy workloads might justify cache costs that write-heavy workloads can't absorb. I call out exceptions: security-critical data shouldn't be cached if it creates attack surface, personally identifiable information might have regulatory constraints on caching, transactional systems requiring linearizability can't use stale cached data, and memory-constrained environments can't afford cache overhead. I reframe with scope: "Caching solves performance problems for expensive computations with recurring inputs and tolerable staleness, when working sets fit cache capacity and when stale data is acceptable. It creates overhead without benefit for constantly changing data, unique queries, real-time requirements, or memory-constrained systems. The pattern works for read-heavy workloads with deterministic results but not for write-heavy transactional systems or security contexts where cache creates risk." The scoped version guides appropriate application while preventing caching from becoming a default answer to all performance questions.