# Stakeholder Review Artifacts

Use a stakeholder review artifact when domain context needs to be reviewed, corrected, compared, or decided on by people who will not read a long brief closely.

The goal is not to replace the Domain Context Brief. The goal is to create a readable review surface from it.

This is an optional control for work that benefits from collective review or an explicit decision. Domain Context Modeling does not require stakeholder review for every artifact, action, or workflow.

```text
Durable source
-> stakeholder review artifact
-> decisions, corrections, and open questions
-> updated durable source
```

## When To Use It

Use this output when the team needs to:

- align product, design, engineering, leadership, clients, or other stakeholders
- compare product directions, workflow interpretations, or domain assumptions
- review a complex domain map, lifecycle, or authority boundary
- make sources of truth, evidence gaps, and risky assumptions visible
- collect decisions and unresolved questions before downstream specs, prototypes, code, or agent behavior

Do not use it when the artifact is only a durable written note, a repository document, or a source-of-truth file that needs simple diffs and easy maintenance.

## Format Guidance

Use the format that makes the domain easiest to review and correct.

| Need | Better default |
| --- | --- |
| Durable notes, briefs, repo docs, and source files | Markdown |
| Structured handoff data or agent-readable constraints | JSON, YAML, or MDX |
| Visual planning, stakeholder review, comparison, domain maps, and UX flows | HTML or another browser-viewable artifact |
| Final documentation | Markdown source with an optional HTML companion |

HTML is useful when the artifact benefits from layout, visual grouping, side-by-side comparison, diagrams, navigation, interaction, or export controls. It is heavier than Markdown and harder to diff, so it should earn its keep.

## What To Show

A useful review artifact should show:

- key domain objects and relationships
- lifecycle states
- workflows and handoffs
- sources of truth
- authority boundaries
- risky assumptions
- product opportunities
- decisions needed
- unresolved questions

For stakeholder-safe versions, translate candid internal context before sharing it. Do not expose private names, confidential details, customer data, screenshots, source code, proprietary metrics, employer-owned strategy, or internal sensitivities that the audience should not see.

## Copyable Prompt

```text
Create a self-contained stakeholder review artifact from this Domain Context Brief.

Make it useful for product, design, engineering, and stakeholder alignment.
Use a browser-viewable format if layout, diagrams, comparison, or interaction would improve the review.

Show:
- important domain areas, meaning contexts, and the relevant domain slice when they improve understanding
- key domain objects and relationships
- lifecycle states
- workflows and handoffs
- sources of truth
- authority boundaries
- risky assumptions
- product opportunities
- decisions needed
- unresolved questions

Use clear visual hierarchy, side-by-side comparisons, and diagrams where helpful.
Keep the artifact stakeholder-safe. Do not expose internal-only concerns unless they have been intentionally translated for this audience.

End with a Markdown export containing:
- decisions made
- corrections to the brief
- unresolved questions
- assumptions to verify
- recommended next steps
```

## Review Guardrails

- The artifact should make uncertainty more visible, not smoother.
- The durable brief remains the source of truth.
- The review surface should include a clear export path back to Markdown, JSON, YAML, code, tasks, or another maintained artifact.
- Visual polish should support decision-making. It should not become decorative proof that the domain is understood.
- If the artifact hides sources, confidence, assumptions, or authority boundaries, revise it before using it for stakeholder alignment.