The short answer
Every relationship should have a clear meaning, direction and reason to exist.
Choose a small set of meaningful relationships, define their direction and evidence rules, and test how the graph handles changes and uncertain links.Begin with the questions the graph must answer
A graph with thousands of links can still be hard to use. If every link means "related," the agent has to work out the relationship again. At the other extreme, dozens of narrowly different relationship types leave you with a schema that takes too much work to maintain.
Write three useful questions first: which decision replaced this one, which task depends on this prerequisite, and which source supports the commitment. Let those questions determine the first relationships.
Say what each relationship means
| Relationship | Meaning to preserve | Common misuse |
|---|---|---|
| supersedes | One decision replaces another within a stated scope. | Treating any newer note as a replacement. |
| depends_on | A prerequisite constrains the dependent item. | Using it for general association. |
| contradicts | Claims cannot both hold in the same scope and time. | Linking different project dates as a conflict. |
| relates_to | An association exists, with no stronger meaning asserted. | Using it when a specific supported relation is needed. |
Gigabrain's supported model includes these relationships. See the product graph explanation for supported relationships and limitations. Use the design worksheet to plan your graph. Follow the product instructions when importing it.
Make direction and scope explicit
"Task A depends on task B" is not the same as the reverse. Keep a plain-language reading for every edge and test whether someone unfamiliar with the schema can explain it.
Scope also matters. An amendment can supersede a delivery date without replacing every provision in the original document. If the graph links whole documents, preserve the narrower claim in the supporting note so an agent does not infer a broader replacement.
Use an evidence rule for consequential links
Proposed edge: decision-new supersedes decision-old
Evidence: The approved amendment identifies the old commitment
Scope: Delivery date for the prototype
Excluded scope: Payment terms and production schedule
Review: Confirmed by the project owner
Unknowns: None recorded for this specific relationshipThis is an illustrative review record. A structural validator can check an allowed relationship name or a referenced node. It cannot establish whether a source actually authorizes the business interpretation.
Plan for schema changes
A relationship that seemed useful may become ambiguous as the corpus grows. Before renaming it, identify every affected edge and the questions that depend on it. Define how older records map to the new meaning and preserve evidence for the migration.
Do not silently reinterpret historical links. Keep a versioned explanation or review record, rerun representative questions and inspect any edge whose meaning changed. A few relationships used consistently usually take less work to review than a large set that people interpret differently.
Add relationships for recurring questions
Use the source-contract worksheet to define edge meaning and evidence on one project. Add a new relationship only when it answers a recurring question more clearly.
Gigabrain includes the knowledge graph and tools to build and maintain it. Review the architecture guide, inspect release evidence and compare System and Pro according to the workflows you want to build or use.
Give a replacement an explicit source
Our fixture records an old budget of 800 dollars and a current budget of 950 dollars. The current decision states that it replaces the earlier budget.
A supersedes edge captures that direction. A generic relatedness edge would lose the replacement meaning. Neither relation should be inferred solely from file modification dates.
| Proposed relation | Review |
|---|---|
| Current budget supersedes old budget. | Supported by the replacement sentence. |
| Old budget supersedes current budget. | Direction contradicts the supplied evidence. |
| Current budget caused the inspection delay. | The sources supply no such causal claim. |
Download the typed-link example. It distinguishes supported frontmatter syntax from the separate graph-ledger proposal interface.
Check structure and meaning separately
A schema validator can reject an unknown relation or malformed field. A structurally valid edge can still misrepresent its source.
Use the correction demonstration to inspect source support after a change. Use the identity guide before joining similarly named entities.
Method note: Gigabrain Labs prepared this material with AI assistance. Fictional teaching examples and executed results are labelled separately.
