What it is
The execution hierarchy is an ordered set of levels — however many your organization has configured, with whatever names it gave them (a common setup is two levels ending in "Epic," but yours may differ) — sitting above the fixed Tasks level. It determines how work from your connected providers (Jira epics, GitHub issues, and so on) is grouped and rolled up on the canvas, and which canvas layer each level appears in: higher-order levels stack above lower ones.
How to read it
Each level renders as Sankey-style flow bands showing allocated capacity, expected progress, estimated effort, and buffer for that level. A project's position in the hierarchy determines which level's flow bands it appears in, and which items can be its parent — a task's parent must be a valid candidate at the level directly above it.
What to do about it
If work isn't rolling up the way you expect, check how your connected provider's issue types are mapped to hierarchy levels — a common cause of confusing rollups is an issue type mapped to the wrong level. Use the hierarchy to decide where to look for risk: a buffer or allocation problem visible at one level usually traces down to specific tasks, findable via that project's Dependency Status.