# Write good stakeholders and consequences

> What to put in the context, which stakeholders to include, and how to list consequences.

Eevo answers only from what you send, so it cannot account for anything you leave out. Follow these guidelines when you write a request.

## The context

- Say what is being decided, by whom, and by when.
- Include the facts that separate the options: numbers, deadlines, constraints, what is known and what is not.
- Invent nothing. If a fact that would decide it is missing, say that it is unknown.

## Stakeholders

- Include everyone the decision materially affects, not only the one who asked. Usually two to five: your organization, the affected customers, the affected team, and the environment when the options differ environmentally.
- Merge groups whose interests are the same.
- Give each a short, stable `id` (`customers`, `team`) and use it in every request. The console's Conflicts page and the log's stakeholder filter group by id. Do not put personal data in ids.
- Add `values` when what the stakeholder cares about matters to the choice.

## Consequences (Default mode)

- One effect per consequence: what happens, to whom, how much. "About 200 customers see a wrong invoice total for 40 more minutes", not "customer impact".
- Eevo takes no probability: it sizes each consequence as if it happens. List the effects you expect.
- Two to six per option is usually enough. At most 20 may affect one stakeholder, and 40 in all.
- Give each a short `label` (up to 60 characters) for the result views.
- Do not list the same effect twice in different words.
- Use one baseline for every option: what would happen to the stakeholder if none of the options were taken (the current situation, including risks that already exist). Describe each consequence as a CHANGE from that baseline that its option causes. Do not list, as a benefit or harm of an option, that it leaves something as it is ("keeps X as it is", "avoids the cost that option A would have", "remains exposed to the existing risk", "gives up the gains of option B"). Those are not changes; they are the other option's consequences seen from this side, and that option already lists them. Do not describe an option relative to another option ("less than A", "instead of losing it entirely"); describe it relative to the baseline. State amounts in each description: how much, how many, for how long. When consequences are in different units (money, time, people, risk, emissions), also state each consequence's approximate value to the stakeholder in one common unit, e.g. "worth about $40,000 a year to the company", if a reasonable estimate exists. Don't invent precision; a rough figure is better than none.
- Use `stakeholders` to limit a consequence to the stakeholders it affects, and a `valence` map when it is a benefit for one and a harm for another.