In his book, "The Goal", Goldratt gives the example of the scout troop on a hike. The goal of Alex Rogo as I understand it was to get the troop to the campground in some reasonable amount of time while keeping the group close enough together to maintain adult supervision.

The constraint was identified as Herbie, the slowest moving boy in the troop. He was easily identified by the queue of boys behind him and the growing space (starved queue) between Herbie and the boys in front of him.

The term "constraint" as used in the story above is the resource within a system which prevents system output from reaching a goal. The constraint is easily identifiable by the queue which forms before it and the starved resources which follow it.

The term "constraint" is used in the TOC literature in several other ways:
constraint = anything that limits the output of a system
constraint = any boundary condition.
constraint = any cause of a limiting resource

To continue with the hiking example: Alex Rogo tried to make the best of Herbie's capability by encouraging Herbie and by keeping breaks short. This "exploit" was not enough to meet the goal.

The troop was subordinated to Herbie's walking speed. This kept the group together, but it wasn't enough to meet the goal. Alex then did a cause and effect analysis to elevate the constraint and chose the root cause "heavy backpack". He then solved the problem by distributing Herbie's supplies among the faster hikers. Alex was vigilant to again evaluate the hike for a new constraint. Luckily Herbie remained the constraint but his increased capacity was sufficient to meet the goal.

The above story uses a "capacity limiting resource" definition of the constraint. The "capacity limiting resource" definition produced an observable testable constraint that is not dependent upon the thinking process of the observer. In the example above Herbie is clearly the constraint.

Now here is where is where things begin to get a little fuzzy in TOC. In TOC parlance, the cause of a resource constraint can be a "policy constraint". Using this logic, it could be said that the true constraint was Herbie's policy of placing large amounts of food and supplies in his backpack. Herbie was doing a local optimization for his personal food supply and comfort at camp. In the process he sub optimized the system.

We could arbitrarily choose other "policy constraints". For example, Herbie's pack was too heavy. Suppose we decide the solution to the problem is that packs should be less than a certain weight before hikers are permitted to go on hikes. In this case a "policy constraint" might have been - the Scout troop does not check pack weight before hikes.

The "policy constraints" mentioned above are causes selected at convenient locations in the cause effect continuum. As such they are not uniquely determined but are instead determined by the preferred solution.

When we allow the definition of constraint to include the solution space of the cause and effect network which is related to elevating the capacity limiting resource, then there can be no singular constraint. It is this type of "constraint" which is the source of much confusion.

Policy constraints are not measurable system attributes. It is not possible to measure a policy, it is only possible to measure the effect a policy has on a system, subsystem, or individual resource capacity.

"The constraint", when it is a "capacity limiting resource constraint" is a measurable attribute of a system. Measurement units would typically be a production rate. It is very much different from a "policy constraint".

In my opinion, TOC would gain considerable clarity if there were a special term that applied only to system capacity limiting resources. In honor of Goldratt's story about the scout troop, I propose we call the resource that limits system output the herbie.

The herbie is easily testable and falsifiable. If a resource is a herbie, and if we elevate the capacity of that resource, then system capacity must increase. If we lower the capacity of the herbie, system capacity must decrease. If we vary the capacity of any other resource, we should expect no change in system capacity. Test construction should consider the possibility of balanced resources which would allow a reduced system capacity when the initial herbie capacity is reduced but would result in a new herbie when initial herbie capacity is increased.