Hierarchy establishes which information overrules which other information. The higher level should take precedence and prevent local deviation, but if local deviations do occur there is not an automatic slap-back. Instead the assessment should be made whether it is an improvement worthwhile to echo back up the hierarchy and thus down again to other places; or whether to bring it back in line. The main thing there is to get lower levels in the habit of updating the documentation to what they are doing, and not lock it down so practice deviates from description without being noticed.
Then, hierarchies should not work in 'levels'. Many a time an additional level of the same type but with adjacent scopes for more detail would have been handy. So do not let the 'depth' into the hierarchy define what something is. Hierarchy to me is more about scopes; the authority is a consequence of that.
A bit like the federal government generally being above states, who are above municipalities etc., but there are state national guards, but also a national army; or state government being above provinces, who are above municipalities, while also allowing for trans-provicinial/municipal organizations such as water/roadway maintenance not being national but differing by type of transportation.
When it comes to numbering do so without including type into it, going into the depths by putting a separator for each step down.
The exception is forms. Decouple forms from the depth numbering, because often you will see a form flowing across multiple processes, or the same form being initiated by multiple processes.
Pure policies are above anything else, but commitments and policies are often in the manual as well to cut down on separate documents. If anything it is important to distinguish within the manual what is descriptive and what is policy, and be careful in the wording for which policies are hard (nobody is allowed to deviate from it) and which are soft (the preferred option is stated, but rationalized deviations may occur). This often gets lost in the textbook like style of manuals.
Though that's what I'd do if starting fresh, alas my reality is not so. Currently we have process flows as the first section within our procedures, with section references for the details of the steps, and a policy that read and understood training is only assigned if mentioned within the procedure. This works well enough. Sometimes we either sidestep a procedure which should be under another one, or we have documents below procedures which are written as if work instructions, but with the authority of a procedure. The decoupling of forms is something that would make our lives easier, but isn't a disaster in comprehension. A hugely important but oft forgotten document for us is the overview of where to store the records generated from a form once it is completed, and what the retention policy is (duration, digital scan allowed, off-site storage allowed etc). This is an odd one out when it comes to the usual types (we call it overview) but of significant value in keeping things tidy and being able to find stuff by personnel not involved daily in the use of such records (e.g. during audits).