Strategy-Aware Retrieval
If strategy has typed layers and explicit relationships, then finding the right information means traversing those relationships — not measuring how similar two strings sound.
When someone asks a generic AI "what should I worry about?", it returns the ten closest vector matches. When someone asks Stratafy the same question, it returns high-impact risks, unvalidated assumptions, and metrics trending below target — because it understands strategic structure, not just semantic similarity.
The Problem with Generic Retrieval
RAG systems retrieve by vector distance. They embed a query, find the nearest chunks, and return them. This works for document Q&A. It fails for strategy because strategic relevance is not semantic similarity.
Hierarchy matters
A risk linked to corporate strategy carries different weight than one attached to an operational sub-initiative. Generic retrieval treats them identically because it cannot see the graph.
Role matters
A CEO needs a portfolio view across all strategies. A product lead needs a focused view of their initiative and its dependencies. Same question, different relevant results.
Relationships matter
An assumption linked to a strategy linked to an initiative linked to a metric creates a chain of relevance. Vector search cannot traverse typed relationships.
Recency and freshness matter
A validated assumption from yesterday is more relevant than a similar-sounding invalidated one from six months ago. Generic retrieval has no concept of strategic freshness.
How Strategy-Aware Retrieval Works
Strategy-aware retrieval combines three approaches, each compensating for the limitations of the others. The strategic schema from Part 1 makes all three possible.
Structured Graph Traversal
Walking the relationship graph from the query context outward. If someone asks about risks to a strategy, the system traverses strategy > linked risks > risk contexts > connected assumptions. The schema defined in Part 1 makes this possible because every relationship is typed and directional.
Semantic Search
pgvector for fuzzy matching when the query does not map cleanly to a graph traversal. This handles natural language questions where the user does not know the exact entity they need. But critically, semantic results are filtered and ranked through strategic context, not returned raw.
Strategic Weighting
Every result is weighted by four factors: hierarchy weight (how high in the strategy tree), link density (how connected to other entities), recency (when last updated or validated), and role context (what the requesting user needs to see). This transforms a flat list into a strategically prioritised response.
What This Enables
When retrieval understands strategic structure, the system can answer questions that no amount of vector similarity could resolve.
Single-query strategic context
Ask one question and get a response that synthesises across strategies, risks, assumptions, metrics, and initiatives. No manual assembly from multiple dashboards or documents.
Natural language strategic queries
"What should I worry about?" returns high-impact risks, unvalidated assumptions, and metrics trending below target — not the ten closest vector matches to the word "worry".
Proactive surfacing
The system does not wait to be asked. When a metric crosses a threshold or an assumption is invalidated, strategy-aware retrieval identifies everything connected and surfaces it before the user searches.
Technical Approach
The retrieval pipeline runs in two passes. The first pass uses graph traversal to collect structurally relevant entities from the typed schema — walking outward from the query context through explicit relationships. The second pass runs semantic search via pgvector to catch entities that are conceptually relevant but not directly linked in the graph.
Results from both passes are merged and ranked using the strategic weighting model: hierarchy position, link density, temporal freshness, and role-based filtering. This prevents the LIMIT starvation problem common in naive retrieval — where a fixed result count is dominated by one entity type at the expense of strategic breadth.
The output is not a list of documents. It is a structured strategic context object that downstream AI tools and agents can reason over directly, with every entity carrying its type, relationships, and strategic weight.