<!-- templates/reports/fan-out-unit.template.md -->
---
unit-id: {{UNIT_ID}}
domain: {{DOMAIN}}
<!-- depends-on example: [unit-001] (use [] if there are no dependencies) -->
depends-on: {{DEPENDS_ON}}
recommended-next-phase: {{NEXT_PHASE}}
---

# Fan-out Unit: {{UNIT_ID}} ({{DOMAIN}})

> Packet produced by requirements-discovery fan-out. Start a new task-key with `okstra-run --task-brief <this file's path>`.
> This file is the input packet for that run.

## Scope

<!-- Self-contained description of the single work item this unit covers. Do not mix it with other units. -->

## Requirement Provenance

<!-- Where this unit's scope came from. One bullet per source. Every bullet must be
     `brief:EB-001` / `brief:PB-001` / `brief:EO-001` — an end-state id the brief
     declares — or `contract:<rule>` (an okstra-mandated artifact). Citing a heading
     is rejected when the brief pins ids: every brief carries the same generic
     headings, so a heading cannot say WHICH reporter line demanded this unit. Only a
     brief authored before the end-state sections existed still takes the older
     `brief:<heading>` form, and there the heading must literally exist in it.
     A unit you cannot source this way is not a work item — raise it as a
     clarification instead of inventing it.
     Unlike a planning report, `derived:<parent> — <reason>` is NOT accepted here: a
     packet is validated on its own, so the parent it names cannot be resolved. -->

- brief:EB-001

## Evidence

<!-- path:line evidence. Locations that requirements-discovery confirmed via file inspection. -->

## Depends-on rationale

<!-- One line per unit listed in depends-on explaining why it depends on that unit. Use _(none)_ if there are none. -->
