Before you add a dependency, try reading the Module without the proposed prerequisite. Which decision would the reader misunderstand? If you can name that decision, you have a useful starting point for the edge.
A SemDAG dependency expresses a requirement for understanding. The Module needs knowledge owned elsewhere, so it declares that knowledge as a prerequisite. This gives an agent a way to receive the explanation with its context intact.
Start with the meaning of a subject
Consider a fictional Module about invitations. It says that accepting an invitation creates a membership in an Account. The reader needs to understand what membership means and what boundary an Account establishes. Those subjects belong upstream.
A page about the company’s hiring plans may mention invitations too. That shared word does not make the hiring page a prerequisite for understanding how invitations work. Similarity can help you discover candidates, but the dependency needs a stronger reason: the target relies on that knowledge.
Give each rule a home
Suppose several Modules explain that a person’s identifier must remain stable when their email changes. If each Module owns a copy of that rule, a future change requires finding every copy. A missed copy leaves different agents with different instructions.
Place the rule and its reason in the Module that owns identity. Other Modules can depend on identity when their subject requires it. A flash follows the dependency, so the same rule is available without being rewritten downstream.
This does not remove the need for examples. A downstream Module can show how the rule applies to its subject while leaving the original rule with its owner.
Separate understanding from work order
An implementation task may need another task to finish first. That is a dependency between pieces of work. A knowledge dependency answers a different question: what must the reader understand before this Module makes sense?
For example, a new invitation screen might wait for an API endpoint to be implemented. That scheduling constraint does not, by itself, determine the knowledge graph. The screen’s Module should depend on the concepts and contracts required to understand its intended behavior.
Cortex uses Issues to coordinate work and Modules to describe knowledge. Keeping those roles explicit helps the graph remain useful after a particular implementation task is complete.
Review the assembled result
After declaring dependencies, read the whole bundle for the target Module. Check whether definitions arrive before they are used. Look for repeated rules, contradictory instructions, and sections that never change a decision for this subject.
A shared prerequisite should appear once. If two Modules state the same rule, graph deduplication cannot fix the duplicate writing: they are still two different Modules. Move the rule to its narrowest owner and have the other Module use that dependency.
When the graph becomes large, inspect the transitive dependencies too. A single edge can bring in a whole branch. Keep the edge when the target needs that branch, and revisit it when the subject has changed.
Use the graph as maintained knowledge
A SemDAG reflects the understanding people record. It cannot prove that the recorded rules are complete, current, or correct. Owners need to review changes, and agents still need evidence from the system they are working on.
Start with a subject that keeps requiring explanation. Write the rule and its reason, connect the prerequisites, and read the assembled bundle. The worked assembly example shows what happens to those edges when an agent requests context.
Read the SemDAG overview for the full model and the Cortex documentation for using Modules in the product.