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

# Part catalogue

> The closed set of steps a workflow can be composed from, and what legally connects to what.

# Part catalogue

Workflows are composed from a closed catalogue. You cannot define an arbitrary step; you wire together published parts whose behaviour, budget and retry policy are fixed.

```bash theme={null}
curl "$BRIEFED_API/api/v1/workflows/catalogue/parts" \
  -H "Authorization: Bearer $BRIEFED_KEY"
```

Always read the catalogue at runtime rather than hardcoding this table. Budgets and versions change, and the live response is authoritative.

## Wire types

Every part declares what it `requires` and what it `produces`. Those are the only things that determine whether two parts can be joined.

| Type                | Meaning                                                                                              |
| ------------------- | ---------------------------------------------------------------------------------------------------- |
| `subjects`          | Pinned canonical companies, supplied by the part's own `terminal.subjectRefs` rather than by an edge |
| `research_document` | A research object produced by a completed step                                                       |
| `table`             | A structured comparison                                                                              |
| `void`              | Produces nothing further; a terminal step in the graph                                               |

An edge from A to B is legal when B's `requires` is empty, or when A's `produces` appears in B's `requires`. Nothing else makes an edge legal, and the rule is applied identically at validation and at save.

## The parts

| Part                            | Kind       | Requires                     | Produces            | Cost (minor units)     |
| ------------------------------- | ---------- | ---------------------------- | ------------------- | ---------------------- |
| `terminal.company.lookup`       | job        | `subjects`                   | `research_document` | 25                     |
| `terminal.company.financials`   | job        | `subjects`                   | `research_document` | 150                    |
| `terminal.market.lookup`        | job        | `subjects`                   | `research_document` | none                   |
| `terminal.company.research`     | job        | `subjects`                   | `research_document` | none                   |
| `terminal.comparative.research` | job        | `subjects`                   | `table`             | 400                    |
| `anya.investigation`            | specialist | `research_document`          | `research_document` | 0 (metered separately) |
| `workflow.pack`                 | transform  | `research_document`, `table` | `research_document` | 5                      |
| `workflow.email_owner`          | transform  | `research_document`          | `void`              | 10                     |
| `workflow.deliver`              | transform  | `research_document`          | `void`              | 15                     |

Costs above are the catalogue's own figures at the time of writing; treat the live response as authoritative.

### Notes on individual parts

**`terminal.comparative.research`** produces a `table`, not a `research_document`. It needs at least two pinned subjects and accepts at most five. Resolve all of them in a single `resolve-subjects` call.

**`workflow.pack`** is what makes a pipeline more than a list of steps: it requires both `research_document` and `table`, so several research steps can feed one pack. This is the usual way to combine parallel work into a single deliverable.

**`anya.investigation`** carries a nominal budget of zero here because its real cost is charged and capped by Anya's own entitlement when the investigation runs. This node dispatches; it does not itself meter. It passes the upstream research document through so later nodes can wait on it.

**`workflow.email_owner`** emails you and only you. When other destination nodes exist on the canvas, prefer `workflow.deliver`, which hands the pack to every destination.

## Scheduling safety

A part carrying the `unattendedSafe` capability may appear in a workflow with a scheduled or event trigger. Request only those parts with:

```bash theme={null}
curl "$BRIEFED_API/api/v1/workflows/catalogue/parts?unattendedSafe=1" \
  -H "Authorization: Bearer $BRIEFED_KEY"
```

Unattended safety rests on the workflow's inputs being fixed at publish time. Pinned subjects and a fixed objective are reviewed once and reused verbatim on every fire; nothing is regenerated per run.

## Events

Event triggers draw from a closed catalogue too:

```bash theme={null}
curl "$BRIEFED_API/api/v1/workflows/catalogue/events" \
  -H "Authorization: Bearer $BRIEFED_KEY"
```