> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mindset.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Strategies

> The container for everything. The 'why' that makes every decision and every work item intelligible.

## The Container for Everything

A **Strategy** is the top-level construct in Memex AI. It represents an objective the team is trying to achieve: a product initiative, an architectural migration, a platform capability, a compliance requirement. It's the answer to *"why are we doing any of this work?"*

## What a Strategy contains

<CardGroup cols={2}>
  <Card title="Purpose statement" icon="bullseye" iconType="solid">
    The problem or opportunity, in enough depth that anyone (human or AI) can understand the motivation without a briefing.
  </Card>

  <Card title="Architectural vision" icon="compass" iconType="solid">
    How the solution fits into the broader system, and what principles guide it.
  </Card>

  <Card title="Decisions" icon="circle-question" iconType="solid">
    The non-obvious design choices that must be resolved to move forward.
  </Card>

  <Card title="Work Items" icon="list-check" iconType="solid">
    The scoped units of implementation, linked to decisions and to each other.
  </Card>
</CardGroup>

Strategies are the boundary that prevents context from sprawling. When an agent picks up a work item, it loads the strategy that contains it, not the entire organisational knowledge base. A team might have five active strategies. Each is self-contained: its own decisions, its own work items, its own dependency graph.

## The promotion path

Work sometimes outgrows its container. A work item scoped as *"add a caching layer"* might reveal a design problem with its own market context, architectural trade-offs, and multiple sub-work-items. When this happens, the work item is **promoted** to its own Strategy. The link to the parent strategy is preserved, so you can always trace how a strategy was born.

## Cross-strategy dependencies

Strategies are self-contained but not isolated. A work item in Strategy B might depend on infrastructure delivered by Strategy A. These cross-strategy links are explicit and tracked. When Strategy A's work item ships, Strategy B's blocked items are automatically unblocked.

## Why this matters

Without a strategy, decisions and work items are just a flat list. The strategy provides the *why* that makes every decision intelligible and every work item purposeful.

<CardGroup cols={2}>
  <Card title="Without a Strategy" icon="xmark" iconType="solid">
    *"We decided to use PostgreSQL."*

    Arbitrary. Untraceable. Forgotten in a month.
  </Card>

  <Card title="With a Strategy" icon="check" iconType="solid">
    *"We decided to use PostgreSQL because our discovery matching engine needs pgvector for embedding similarity, and the strategy requires sub-100ms lookups across 3,000 occupation vectors."*

    Traceable to a goal. Intelligible to any agent or human.
  </Card>
</CardGroup>

<Note>
  In the old world, this was an Epic. But an Epic is a label on a group of tickets. A **Strategy is a living document** that holds the reasoning, the open questions, and the architectural context that every agent needs before touching the code.
</Note>