Relationships. Make the Implicit Explicit

The knowledge graph that turns scattered objects into institutional memory.

Most operating tools store objects in silos: ideas here, decisions there, projects somewhere else. When the same thread runs through three of them, you don't see it until something fails and you go searching.

Relationships fix that by making the implicit explicit. The link between a pricing decision and the customer-research idea that triggered it is real whether you record it or not, but if you don't record it, you'll forget by the time you need it.

Six months from now, when you're making a similar pricing call, the question isn't "do I remember what we did last time?", it's "what did we decide, what did we learn, what evidence supported it?" The relationship graph is the only thing that makes that question answerable.

Foundry ships 9 relationship types. They are not interchangeable. Each one means something specific, and the meaning is what makes the graph queryable later.

The trick is to ask a single question per type. Pick the relationship whose question gets a clear "yes", that's the right one.

When no type's question gets a clean yes, use LINKED_TO. It's the catch-all and signals "these are related but the semantics aren't sharp." Use it sparingly, too many LINKED_TO relationships and the graph is just a pile.

Three entry points:

From a detail page. Open any idea, asset, decision, or project detail page. The "Related Items" panel lets you pick a target object and a relationship type. Fastest when you already know what to link.

From the Relationships page. /relationships shows the full graph and lets you create links in bulk. Useful for the quarterly portfolio review, link several things at once after you've thought about the connections.

Implicitly via tags. Objects sharing a tag aren't linked, but they're discoverable together. When a tag hits 5+ uses across 2+ object types, RECURRING_THEME fires as a recommendation. That's the system pointing at a strategic thread you may not have named yet.

If you have 8 ideas, 3 decisions, and 2 assets all tagged positioning, you're not casually thinking about positioning, you're actively working on it. The tag theme is the system saying this deserves a project.

The RECURRING_THEME recommendation is your prompt. When it fires:

1. Open the theme on /relationships and read every linked object.
2. Ask: is there a single initiative I could name that would consolidate this work?
3. If yes: create a project, link the existing objects to it (via SUPPORTS, DERIVED_FROM, or LINKED_TO), and start treating the theme as a Layer 3 initiative.
4. If no: the theme is a permanent strategic concern, not an initiative. Acknowledge it but don't force a project.

This is one of the highest-payoff moments in the system, recurring themes that should become projects but don't end up as background hum that drains energy without producing output.

Creating no relationships at all. The Relationships page does not require you to use it. But every object you don't link is a piece of context that won't surface when you need it. Aim for at least one relationship per Decision and at least one REUSABLE_FOR per non-project-specific asset.

Treating tags and relationships as the same. Tags are categorization (many-to-many, untyped). Relationships are claims about how things connect (one-to-one, typed). Use both: tags for "what this is about," relationships for "how this connects to that specific other thing."

Ignoring RECURRING_THEME alerts. They're rarer than other recommendations and almost always meaningful. When one fires, it's the system noticing a pattern you've been creating without naming.