The SemDAG, and why order matters

A pile of facts is not knowledge. Knowledge is facts in the right order, each one resting on the ones before it. That ordering is the whole job of the SemDAG.

Dependencies point downstream

In Cortex, an edge a -> b means a's context flows into b. So b depends on a. Foundations are the springs at the top of the river; the module you author is the confluence at the bottom.

Here is a small commerce graph:

database   inventory   payments      (foundations)
   |   \      |   \       |
 users   catalog    pricing          (built on foundations)
   |  \    |   \    /   |
  cart  orders   shipping            (built on those)
      \     |     /
        checkout                     (the module you author)

Flattening with a topological sort

To teach an agent checkout, we linearize the subgraph so every dependency comes before the thing that needs it. That is a topological sort. We break ties by insertion order so the result is stable and reads top-of-river to confluence.

01  database
02  inventory
03  payments
04  users
05  catalog
06  pricing
07  cart
08  orders
09  shipping
10  checkout      <- your module

By the time the agent reaches line 10, it has already read everything checkout rests on. No dangling reference, no fact introduced before the thing it depends on.

Why not just dump the files?

You could concatenate ten markdown files and hope. But order is not cosmetic. A model reading pricing before it has seen payments has to hold an unresolved reference and reconcile it later, if it can. Reading them in dependency order means each fact lands on solid ground.

This is the difference between a folder and a graph. The folder gives you the bytes. The graph gives you the bytes and the sequence, which is the part that was always living in someone's head.

The graph gives you the bytes and the sequence. The sequence was always the hard part.

Same content, taught the way a person would teach it. That is what makes it stick.