A constraint is a real limit. A ghost constraint is a limit that used to be real and isn't anymore, but the organization still plans around it.
The headcount freeze ended eight months ago, but the engineering team still plans as if they cannot hire. The partnership exclusivity expired last year, but the GTM team still routes everything through the partner channel. The original product architecture forced a specific deployment model, but the rewrite shipped in Q1 and nobody updated the sales motion.
Ghost constraints shape goals quietly. The team sets a modest growth target because they believe they cannot hire. The sales team sets a partner-dependent revenue target because they believe they cannot sell direct. The product team sets a conservative release cadence because they believe the old architecture still constrains them.
In each case, the goal is set against a limit that is no longer there. The team executes perfectly against the goal and delivers a modest outcome that could have been far more ambitious if someone had tested the constraint.
How ghost constraints form
Every real constraint has a lifecycle. It starts as a deliberate decision or an external limit. Over time, decisions accumulate on top of it. New processes, new goals, new plans are built assuming the constraint is permanent. Eventually, the original limit changes or is removed - but the structures built on top of it remain.
Nobody runs around the organization shouting "the constraint is gone." The change happens quietly - a budget approval, a contract expiration, a technology migration - and the teams that planned around the constraint never revisit their plans.
This is a specific form of decision debt: the accumulated cost of past decisions that have outlived their context. Ghost constraints are decision debt in its most concrete form - a specific limit that was real, is no longer real, but still shapes what the organization believes is possible.
The planning audit
The antidote is a constraint audit during every planning cycle. Before setting goals, list everything the team is treating as fixed and categorize each one:
Verified constraint. It was tested or confirmed within the last cycle. The budget is approved at this level. The regulation requires this compliance step. The platform contract locks us in until this date.
Assumed constraint. It was set during a previous cycle and has not been re-examined. Nobody knows whether it is still valid. The answer to "when was this last tested?" is some version of "I think it's always been that way."
Expired constraint. It was valid when set but circumstances have changed. The budget freeze is over. The competitive dynamic has shifted. The technology limitation was resolved.
Assumed and expired constraints should be tested before goals are set against them. Sometimes the test confirms the constraint is real - which is also valuable, because it turns an assumption into a verified fact. Often the test reveals that the constraint is a ghost, and the goal can be set against a much wider field of possibility.
Why it matters for execution
Goals set against ghost constraints produce execution that is perfectly aligned to the wrong target. The team hits the number and the organization underperforms, because the number was set based on limits that don't exist.
This is different from the usual execution risk of misaligned effort. In ghost-constraint scenarios, effort and goals are aligned. The problem is upstream: the goals themselves were calibrated against the wrong reality. The strategy execution gap starts not at the work level, but at the planning level.
The Vindaris view
Vindaris connects goals and KPIs to the projects, tasks, and resources supporting them. When a constraint changes - a headcount increase, a product migration, a market shift - the Work Graph shows which goals were set under the old assumption and whether the effort allocation still matches the updated reality. Execution risk includes not just effort misaligned to goals, but goals misaligned to constraints.