Constraint Box

Why it matters

AI projects fail when teams chase state-of-the-art models without asking whether they have the data, budget, latency budget, or governance structure to deploy them. The Constraint Box prevents fantasy architectures and forces honest scoping - the same discipline used in senior engineering and product leadership.

• Constraints are not enemies of creativity - they define the playable space for good decisions.
• Hard constraints (law, security, SLA) differ from soft constraints (preference, convenience) - classify them explicitly.
• Tight boxes often produce better solutions than unconstrained optimisation (focus beats brute force).
• When constraints conflict, prioritise by risk: safety and compliance before speed, unless explicitly accepted.
• The box changes over time - revisiting constraints quarterly prevents building for a world that no longer exists.

1. 1

   List constraints in five categories: data, compute/infra, people/skills, time, and governance/ethics.

2. 2

   For each AI option, ask: Does it fit inside the box today, or does it require removing a constraint first?

3. 3

   Document trade-offs when you touch the edge of the box (e.g. higher accuracy vs 2× inference cost).

4. 4

   Use the box in vendor and model selection - cheapest API is wrong if latency violates the product constraint.

5. 5

   When teaching, give learners a constraint box for exercises - unlimited problems teach less than bounded ones.

Real-world examples

• Discovering legal or security constraints after build instead of during design.
• Treating budget as the only constraint while ignoring data quality or maintenance load.
• Removing constraints without stakeholder sign-off ("we will ask forgiveness later").
• Confusing aspirational goals with hard constraints - goals motivate; constraints bound.