Dependency direction
Which way an arrow points in a dependency diagram: toward the stable abstraction, not toward whichever concrete detail happens to be called.
Dependency direction is about which side of a relationship is allowed to change the other. Two pieces of code that interact aren't automatically equal: one of them names the other, imports it, knows its shape. That one depends on the other, and it's the one that breaks first when the other changes.
The naive direction usually follows control flow. A business rule that calls the database directly "depends on" the database in the code: it imports the driver, builds the query, knows the schema. That's backwards from what actually matters. The business rule is the part worth protecting; the database is a replaceable detail. Making the rule depend directly on it means every decision about storage leaks into the one place that should be the most stable.
Flipping it doesn't change what happens at runtime, the database still gets called. It changes who's allowed to force a change in whom. Both sides depend on an interface instead: the rule defines the shape it needs, and the database implements it.
That's the whole idea behind dependency inversion: not eliminating the dependency, just pointing it at something stable enough to be worth depending on.