Define output requirements by experience type
Before evaluating quality, determine whether an output is safe to act on. Different output types have different failure modes, so each needs requirements that address the risks that matter most.
Start with the action someone will take, rather than the output format.
- Make a decision
- Assign work
- Track commitments
- Share information
Then ask:
- What could go wrong if the output is wrong?
- What would make it unsafe or misleading?
- What must be true before someone can rely on it?
Build each requirement from the action the output supports, the failure that could occur, and the condition that must be true for safe use.
Three examples
Summary used to track decisions
| Use case component | Example |
|---|---|
| Action the output supports | Team members use the summary to understand agreements and decisions. |
| What could go wrong | The summary states a decision that never happened. |
| What must be true | Only explicitly stated decisions are identified as decisions. |
Resulting requirement: Label something as a decision only when the source clearly states it as a decision.
Action list used to assign work
| Use case component | Example |
|---|---|
| Action the output supports | Tasks are assigned and tracked. |
| What could go wrong | Informal discussion becomes assigned work. |
| What must be true | Listed tasks represent actual commitments. |
Resulting requirements:
- Include only tasks that were expressed as commitments.
- Do not turn suggestions, brainstorming, or open discussion into tasks.
Recommendation used to guide a decision
| Use case component | Example |
|---|---|
| Action the output supports | A person chooses a direction based on the recommendation. |
| What could go wrong | The recommendation fills gaps with assumptions and leads to a bad choice. |
| What must be true | The recommendation remains grounded in provided information. |
Resulting requirements:
- Request missing inputs before recommending a course of action.
- Do not assume goals, constraints, priorities, or intentions that were not provided.
Write requirements that define safe use
Every requirement should answer two questions:
- What must the output get right for correct use?
- What must the output never do?
Avoid requirements such as “Be accurate,” “Be helpful,” or “Be high quality.” They are too broad to evaluate consistently.
Requirements should be observable, tied to a real failure mode, verifiable by a reviewer, and checked against an explicit source of truth such as the prompt, task, product rule, or source material.
Requirements by output type
Summaries
| Requirement | Pass if | Fail if |
|---|---|---|
| Reflect source content | Contains only information stated in the source. | Adds information, alters meaning, or exaggerates source claims. |
| Identify decisions correctly | Marks decisions only when explicitly stated. | Treats discussion, speculation, or implied agreement as decisions. |
| Show what is unknown | Calls out unresolved, unclear, or missing information. | Invents details or hides ambiguity. |
| Acknowledge incomplete information | Clearly signals uncertainty or incompleteness. | Presents unsupported certainty. |
Action items
| Requirement | Pass if | Fail if |
|---|---|---|
| Include only real commitments | Tasks appear only when someone clearly committed. | Tasks are created from suggestions, discussion, or implied next steps. |
| Assign ownership correctly | Owners are named only when explicitly specified. | Ownership is assigned without source evidence. |
| Include timing only when stated | Dates and deadlines come directly from the source. | Timelines are invented, guessed, or implied. |
| Stop when required information is missing | Clarification is requested before proceeding. | Output proceeds despite missing task details. |
Recommendations
| Requirement | Pass if | Fail if |
|---|---|---|
| Stay within known constraints | Uses only provided goals, constraints, and conditions. | Assumes missing intentions, requirements, or priorities. |
| Require necessary inputs | Requests missing information before recommending action. | Makes recommendations without needed inputs. |
| Avoid unsupported claims | Grounds suggestions in available information. | Presents assumptions, guesses, or inferred facts as known facts. |
| State uncertainty when needed | Explicitly communicates uncertainty or incomplete information. | Uses stronger confidence than the evidence justifies. |
Adjust strictness based on consequence
Increase evaluation strictness when the output creates or assigns real work, drives a decision or workflow, is unlikely to be checked against the original source, or has a high cost of error.
Lower-consequence scenarios may allow more flexibility in wording, phrasing, and structure. Factual grounding and correctness should never be relaxed.
Key takeaway
Requirements determine whether an output is safe to act on. Define the conditions for safe use first, then convert those conditions into measurable evaluation criteria.