Dependencies are used to define the relationships between records. The basic form of a dependency would be as follows.

Block B cannot be scheduled until block A has been scheduled

In this example, block B would be called a Successor of block A and block A would be called a Predecessor of block B. We define the dependencies of a block by specifying its predecessors, that is the blocks that must be mined before it can itself be mined.

All but the simplest XPAC projects require many thousands of dependencies, making it impossible to specify them individually. We therefore create dependencies using generic dependency rules that are applied to large areas of the deposit. A simple example would be a dependency rule for The Block Above, which would be applied to every block in an open pit deposit to prevent under-cutting.

To simplify their management, related dependency rules are grouped into sets and different sets can be applied to different portions of the deposit. For example, in an open pit, the dependency rules needed to maintain an acceptable pit slope would normally be grouped into a single dependency rule set. This could be applied to all blocks in the pit other than the southern wall, which could use an alternative rule set of their own.

By default, dependency rules are applied to whole records such that Every activity in the predecessor record must be completed before Any of the activities in the successor record can be started. This default option is referred to as ALL activities in both the predecessor and successor records.

When required, this default can be over-ridden and dependencies can be assigned to a specific activity in the predecessor record, the successor record or both. Some examples are shown below.