Perhaps the factory was the first type to provide a comparison operation between objects of the type. This introduction to the factory defines "discreet" in terms of a set of holes. For discreetness fewer holes are better. There is an order on a factory that accepts a key to another factory which queries the first as to the relative merits of the second. The paranoid factory user invokes the first factory proffering a second factory. The factory performs a set inclusion test on the respective hole sets and replies firstly whether the proffered factory was indeed a real factory, and if so whether there are holes in the proffered factory that are not in the invoked factory.

Several points about this pattern are significant here:

• The paranoid needs to test whether any key that purports to designate a factory is indeed a factory. This requires that the paranoid hold a key to a factory that he already trusts.
• The paranoid has probably already a hole policy in place and holds a capability to a factory with those holes. Only the rare programs that discriminate between degrees of confinement will deal with more than one level of factory descretion.
• The holes of a factory are inaccessible to the user of a factory. The user need not have access to the holes that he trusts for discretion.
• Setting a discretion policy can be done by creation and disemination of a factory. The follower of a policy need only test via this factory capability.
• If the user holds some keys that he would trust as holes, he may create a factory with those holes and ask it whether some other factory has more.
• If the user wants to test if a factory has only holes that are in either factories A or B, then he creats a new factory and installs A and B as requestor keys in the new factory. The requestor's key to the new factory now provides a tester for this new criterion.