Diagnostic Frame
The Constraint Horizon
A team's position on its improvement journey is not a grade. It is the location of the constraint that most limits its flow. The Constraint Horizon names five constraint classes, ordered outward from the team's span of control, and gives a team one question and five tests to find where it stands.
Position is where the constraint lives
The Constraint Horizon defines a team’s position by the class of constraint that binds its flow. There are five classes, ordered outward from nearest the team’s own control to farthest, and each one is a waypoint:
- The team cannot see its work.
- The team cannot finish its work.
- Finished work cannot reach its consumers.
- Delivered work does not change what the team builds next.
- The binding structures belong to the enterprise.
Ask once, test outward, carry one phrase
Using the model takes three steps. Everything else on this page is supporting detail for those steps.
- Ask one question. If everything your team controls went perfectly for a month, what would still be slow? The answer names a constraint.
- Walk the five boundary tests in order. The first test that fails names your waypoint.
- Carry one phrase: the waypoint, the named constraint, and who controls it. For example: Delivery Edges / release authority (external).
Position, ceiling, and control
Three facts stay separate in the model:
- Position is the farthest waypoint the team has truly reached: it can keep meeting that waypoint’s condition even under pressure.
- The environment ceiling records the farthest position the surrounding system permits. What the team can do and what its system allows are different facts, and the model keeps both visible.
- Control is recorded per constraint: team-controlled, jointly controlled, or externally controlled. The model never assumes who owns what.
The five waypoints
All five waypoints at a glance:
| Waypoint | Boundary test |
|---|---|
| Invisible Work | Can the team state, today, what it is working on, what is waiting, and how much is in progress? |
| Own Mechanics | Can the team reliably turn a small batch into finished, verified work its recipients can use, within its own span? |
| Delivery Edges | Does finished work reach the people it is for without waiting on parties outside the team? |
| Learning Edges | Does evidence from delivered work change what the team builds next, within a useful cadence? |
| Enterprise Structures | All four prior tests pass; the binding constraint sits in structures only the enterprise can move. |
Each waypoint in depth:
Invisible Work
The test: can the team state, today, what it is working on, what is waiting, and how much is in progress?
What holds the team back: the team cannot see its own work. Work arrives as assignments to individuals, and queues, interrupts, and work in progress go unmeasured. Integration and acceptance come late, and progress is judged against plan or utilization.
From inside: the team feels busy, unpredictable, and blamed, and nobody can say where the time goes.
You are past it when: work, queues, and intake are visible, the team plans jointly and owns completion, the team keeps an honest work-in-progress count, and at least one short feedback loop actually changes how work is handled.
Own Mechanics
The test: can the team reliably turn a small batch into finished, verified work its recipients can use, within its own span?
What holds the team back: the team cannot finish work at the pace its cadence promises. Quality debt, slow verification, big batches, and internal handoffs set the real pace, no matter what the official rhythm says.
The hazard band: the transition hazards cluster at this waypoint. Debt becomes visible for the first time, morale dips while the team learns to hold itself accountable, and teams regress by taking on too much at once. In the model, this is where adoption stalls most often.
From inside: iterations finish, but each one feels heavier, and the ceremonies keep happening while nothing gets easier.
You are past it when: small batches reliably become finished, verified work within the team’s own span, and internal quality problems no longer set the pace. In software delivery, that means work is tested and releasable, and releasing is a business decision rather than a rescue effort. The condition itself applies in any domain.
Delivery Edges
The test: does finished work reach the people it is for without waiting on parties outside the team?
What holds the team back: finished work cannot move outward. Completed work queues at the boundary, waiting on integration with other teams, on dependencies, on release or sign-off authority held elsewhere, and on environment and platform gaps. The team itself is no longer the bottleneck, so now the edges are.
From inside: we finish and then we wait, and cycle time is dominated by work that other people own.
You are past it when: the team has renegotiated each edge or formally reported it upward with evidence, and the only things limiting throughput are external constraints the team has named, not friction nobody has examined.
Learning Edges
The test: does evidence from delivered work change what the team builds next, within a useful cadence?
What holds the team back: the loop between delivering, learning, and deciding. Work flows out but little flows back, or evidence arrives and nobody acts on it: product decisions take too long, the team is far from its customers, and priorities keep churning. The team can deliver. What it lacks is knowing what to deliver, and being allowed to act on what it learns. You can see the difference from Delivery Edges: there, finished work waits to reach its consumers; here, work reaches them and the team waits to learn or decide.
From inside: the team is fast, stable, and possibly building the wrong thing.
You are past it when: operational and customer feedback routinely changes priorities, experiments, or product decisions within a useful cadence.
Enterprise Structures
The test: all four prior tests pass, and the binding constraint sits in structures only the enterprise can move: funding cadence, architecture, governance policy, team topology, culture.
Two substates: Holding means the team sustains its flow, resists regression, and keeps evidence moving upward while the enterprise decides. Moving means the team is working with people upstream who are actively shifting the constraint, and as it shifts, the team re-enters an earlier waypoint along whichever dimension has opened up.
No final waypoint: the team either repeats the cycle or deliberately stops because where it stands fits its needs.
The locating exercise
The route:
- Ask the recognition question: if everything your team controls went perfectly for a month, what would still be slow?
- Walk the five boundary tests in order. The first test that fails names your waypoint.
- Record the named constraint and its control: team-controlled, jointly controlled, or externally controlled.
Then record three supporting details:
- Honesty marks. Mark each of the six dimensions in the next section as behind, at, or ahead of the position you just recorded.
- Ceiling. Note whether the next waypoint’s condition is blocked by something outside the team (authority, architecture, policy, funding, customer access, platform, or topology) rather than by a capability the team could build itself.
- Amplifier check. Before targeting the next condition, check the four team amplifiers by name: Trust Erosion, Accountability Avoidance, Micromanagement Creep, and Burnout Accumulation. An active amplifier blocks the transition until it is addressed, no matter how capable the team looks. The amplifiers are defined in Applied End-to-End Flow: Team.
Carry one phrase
The carried output is one phrase: waypoint, named constraint, control class. For example: Delivery Edges / release authority (external). Everything else in the exercise is supporting detail used along the way, not something to carry. A position stops being valid once its constraint moves, so re-locating is normal. The team can rebuild the phrase any time by asking the one question again.
An illustrative walkthrough
An illustrative claims-operations team asks the question and answers: if everything we control went perfectly for a month, clean case decisions would still wait days for another department’s sign-off. Walking the tests: the team can state its queue, so Invisible Work passes. It handles cases reliably within its own span, so Own Mechanics passes. Finished decisions wait on an outside sign-off, so Delivery Edges fails, and the first failed test names the waypoint. The constraint is sign-off authority, and it is externally controlled. The ceiling note records that the next condition is blocked by authority, not by anything the team can build. The carried phrase: Delivery Edges / sign-off authority (external). The team’s next job is to gather evidence that supports escalating the constraint.
Capabilities advance unevenly: the honesty marks
Capabilities do not advance in lockstep, so the exercise marks six dimensions as behind, at, or ahead of the working position:
- Work orientation
- Collective agency
- Flow control
- Technical and release integrity
- Feedback and adaptation
- Environment fit and leverage
A team can sit at Delivery Edges with collective agency still behind. Pretending otherwise turns the position into a boast instead of a diagnosis. The marks show where advancement is uneven, without inventing half-stages or a score.
A route, not a law
The order is not arbitrary: fixing the constraints inside one class tends to expose the next class outward, so skipping ahead fails. But the order is a route, not a law. Regression is normal, disruption can move the constraint back inward, and a team can hold a stable mixed position for a long time. None of that is a defect.
What the phrase tells you
The carried phrase is built for reuse. What the constraint is about tells the team where to focus next: if it concerns what gets built and why, the work is alignment; if it concerns how work moves, the work is flow. The control class tells the team what kind of work comes next: a team-controlled constraint means fixing it yourselves, and an externally controlled constraint means gathering the evidence needed to escalate it. The framework deliberately stops there. It names the job, not the method: how a team facilitates, prioritizes, or orders its improvement work is its own choice.
The Horizon locates; it does not grade
Not a maturity model. The output of the locating exercise is a work item, never a level. Waypoints carry names, not numbers. There is no score, no certification, and no cross-team comparison: two teams’ phrases are not comparable and are not meant to be.
A later waypoint is not a better team. Position is defined by where the constraint lives, not by virtue. A team at Enterprise Structures is not superior to a team at Own Mechanics; its constraint simply lives somewhere else.
Stopping can be the right answer. A team whose achieved position fits its need may reasonably stay there. A position that fits your purpose beats a position farther along.
The amplifiers are inhibitors, not positions. A team can meet every capability condition of a waypoint and still fail to move on, because an amplifier undermines the social conditions the work depends on. That is why the amplifier check ends the exercise.
The Horizon locates; it does not move you. The model contains no improvement mechanism. What to do about the named constraint belongs to the rest of the framework and to the team’s own judgment.
The two continuums
The pairing with The VSM Adoption Continuum is deliberate, and so is the difference in shape. The two models measure different things. The enterprise continuum measures capability: what the organization can deliver and how it funds work. The Constraint Horizon measures the constraint: what stands in the team’s way and who controls it. An enterprise waypoint says what the organization can do; a team waypoint says what is in the team’s way. The two meet at the ceiling: when a team’s constraint is externally controlled, the team’s job is to gather evidence for escalation, and that evidence feeds the enterprise-level diagnosis.
Sources and lineage
The Constraint Horizon is an Applied End-to-End Flow concept developed by Curtis Hibbs and Joshua Barnes. Its primary treatment appears in Applied End-to-End Flow: Team, arriving August 2026, which also defines the four team amplifiers named in the locating exercise. The enterprise-altitude sibling, the VSM Adoption Continuum, is treated in Chapter 7 of Applied End-to-End Flow: Enterprise.
Curtis Hibbs and Joshua Barnes are co-creators of Applied End-to-End Flow and co-authors of Applied End-to-End Flow: Enterprise. Their work combines enterprise diagnosis, value-delivery mechanics, and practical intervention patterns across strategy, portfolios, value streams, and teams.