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

# Strategies

> Operate one business outcome through a root workstream and its campaign workstreams.

# Strategies

A **Strategy** is an operating role played by an existing [Workstream](/workstreams). It is not a
separate Erdo resource. Use a long-lived root workstream for the business outcome and attach each
campaign workstream directly beneath it with the existing `workstream` resource type and `child`
relationship.

Experiments remain hosted by the workstream doing the work. A campaign experiment therefore lives
on its campaign workstream, while the root workstream supervises the portfolio.

## Attach campaign workstreams

```bash theme={null}
erdo workstream attach brickell-lead-strategy \
  --type workstream \
  --id <campaign-workstream-uuid> \
  --rel child \
  --title "Google Search · Brazilian buyer"
```

The same operation is available through `erdo_attach_workstream_resource` and
`POST /v1/workstreams/:slug/resources`.

## Read the portfolio

`erdo workstream ledger <strategy-slug>`, `erdo_read_workstream_ledger`, and
`GET /v1/workstreams/:slug/ledger` return a one-level `child_portfolio`. Each entry contains the
child workstream, experiment counts, and open-attention count.

The read is deliberately one level deep and includes only direct children in the same organization
and project. Deeper execution detail remains on each child workstream's own ledger.

<Warning>
  The project filter compares each child against the **root's** project, and attaching across
  projects is not an error. A child created in a different project attaches successfully, returns
  `200`, and is then absent from `child_portfolio` — so the portfolio reads as empty while the
  resource link plainly exists. Create campaign workstreams in the same project as their root, or
  read them through their own ledgers.
</Warning>

## Scope work and authority

The shared Work feed and approval list accept an exact workstream slug:

```bash theme={null}
erdo activity --workstream brickell-lead-strategy
erdo approvals list --status pending --workstream brickell-lead-strategy
erdo approvals decide <id> --approve --scope always_this_workstream
```

MCP and REST use `workstream_slug` on `erdo_list_activity_feed`,
`erdo_list_approvals`, `GET /v1/activity/feed`, and `GET /v1/approvals`. Exact scope is applied
before pagination, so unrelated urgent or organization-level items cannot displace matching work.

`always_this_workstream` creates a standing approval policy for that action and its parameter
constraints on this workstream only. It does not grant authority to another workstream, and all
provider writes continue through the existing approval system.
