| name | deciding-constraint-inventory |
| description | Systematically identify and catalog all constraints that bound a decision or solution space. Use when: (1) asked to propose solutions without first identifying what constraints bound the problem, (2) constraints are presented as equally immutable without distinguishing negotiable from non-negotiable, (3) historical constraints are assumed without validating they still apply, (4) solutions are rejected for violating constraints that were not identified upfront. |
Constraint-Inventory
Enumerate the limits that define what solutions are possible before exploring which solution is best.
Instructions
When I face a decision or design task, I inventory constraints by making explicit what boundaries exist that might not be immediately obvious, distinguishing what cannot be changed from what can be negotiated, and understanding what limits apply at this specific scope.
-
Identify constraint categories - I examine the technical constraints inherent to the technology and architecture, the business constraints from requirements and timelines, the team constraints based on expertise and capacity, and the time constraints from deadlines and dependencies, recognizing that each category surfaces different boundaries on what's feasible.
-
Distinguish hard from soft - I separate immutable constraints that cannot be changed under any circumstances from negotiable constraints that could be adjusted with trade-offs, as treating a soft constraint as hard prematurely limits options while treating a hard constraint as soft leads to impossible proposals.
-
Question assumed constraints - I examine which constraints are externally verified versus inherited from past decisions or conventions, asking whether each limit is a real boundary or an assumption I've carried forward without validation, since assumed constraints often block creative solutions unnecessarily.
-
Map scope-specific constraints - I identify which constraints apply uniquely at this level of the system, recognizing that function-level constraints differ from module-level constraints which differ from system-level constraints, as understanding scope helps me avoid applying constraints that don't actually limit this decision.
-
Document non-obvious constraints - I make explicit the constraints that wouldn't be apparent to someone without my context, particularly those from past decisions, organizational policies, or domain-specific requirements, as hidden constraints often cause proposed solutions to fail validation unexpectedly.
-
Test the inventory - I validate my understanding by explaining why each constraint exists and what would happen if I violated it, ensuring I haven't missed critical limits or included constraints that aren't actually binding, as an incomplete inventory leads to solutions that can't be implemented while an over-constrained inventory blocks feasible options.
Examples
Implementing input validation in a form handler
I'm writing a function that processes user registration data. Before choosing validation approaches, I inventory the constraints that bound my solution. The technical constraints include that this runs in a Node.js environment with existing Zod schemas, the input is already parsed JSON from Express middleware, and validation errors must be serializable for API responses. The business constraint is that email validation must match the existing user lookup logic to prevent duplicate accounts with different email formats. The team constraint is that the codebase uses Zod consistently and the team expects that pattern. The time constraint is that this ships in this sprint. Testing the inventory, I distinguish that using Zod is effectively a hard constraint because deviating would create maintenance burden and team confusion, while the specific error message format is a soft constraint I could negotiate if there were compelling reasons. The business rule about email normalization is hard because it affects data integrity. This inventory shows me I'm not choosing between validation libraries but rather how to structure Zod schemas and where to place normalization logic, which is a much smaller decision space than if I'd started exploring options without cataloging limits.
Designing a caching layer for API responses
I'm adding response caching to reduce database load in a REST API. Before evaluating caching strategies, I inventory what constrains my options. The technical constraints include that we're running on serverless functions with no persistent local memory, the database is PostgreSQL with materialized views already handling some caching, and responses range from tiny user records to multi-megabyte report results. The business constraints include that user data must reflect changes within five seconds for consistency with real-time features, reports can be stale up to an hour, and we have budget for Redis but not for additional infrastructure services. The team constraints include that we have Redis expertise but nobody has experience with CDN edge caching, and the on-call rotation requires that debugging tools are familiar. The operational constraint is that cache invalidation must be explicit and traceable for audit compliance. Distinguishing hard from soft, the five-second staleness for user data is hard because it's tied to product requirements, but the budget constraint is soft because we could make a case for additional spend with ROI data. The serverless limitation is hard and rules out in-memory caching entirely. Questioning assumptions, I verify that the five-second requirement actually applies to all user data or just specific fields, discovering that profile updates can be slower than permission changes. This inventory reveals that I'm not choosing whether to cache but rather how to implement tiered caching with different TTLs per data type in Redis, and the scope-specific constraint is that this is a single service so I don't need to solve for distributed invalidation across services yet.
Establishing authentication patterns across microservices
I'm defining how authentication works across eight services being migrated from a monolith. Before proposing auth strategies, I inventory the constraints that bound solutions. The technical constraints include that four services are already deployed with JWT bearer tokens, the API gateway validates tokens but doesn't transform them, and services need to verify permissions locally without calls to the auth service on every request. The business constraints include that we must support the existing mobile app without requiring updates, session duration is regulated at 24 hours maximum for compliance, and we're committed to OAuth2 for third-party integrations. The organizational constraints include that the security team must approve any changes to token structure, we have a six-month timeline to complete the migration, and three teams are simultaneously working on different services with different schedules. The operational constraints include that we can't have downtime during token format transitions and monitoring must distinguish auth failures from other errors. Testing this inventory, the JWT format is hard because changing it breaks deployed services, but the claims structure is soft because we can add fields with backward compatibility. The 24-hour session limit is hard due to compliance. The six-month timeline is soft because we could negotiate for more time with evidence of complexity. The constraint that services verify permissions locally is hard because network calls on every request were the performance problem we're solving. This inventory shows that I'm not choosing an auth protocol but rather how to evolve JWT claims and propagate changes across services without breaking compatibility, and the scope-specific constraints are about orchestrating migration across autonomous teams rather than technical implementation details, which means my solution must account for partial deployment states and team coordination as first-order constraints.
