The template
Eight fields make the product argument concrete
- Trigger: What event or condition gives the system a reason to respond?
- Inputs: Which sources, signals, and context may the system use? Name freshness and provenance requirements.
- Evidence: What tested reliability and evidence quality support this behavior? What remains uncertain?
- System action: Does the system suggest, prepare, execute, refuse, or escalate? State the action precisely.
- Authorization: Whose authority permits the action, and which boundary still requires approval?
- Visibility: What must the person see about sources, status, assumptions, and consequences?
- Correction and recovery: How can the person correct the result, undo a change, or repair an external consequence?
- Backoff: When does the system pause, stop, expire its assumption, or hand the task back?
Worked example
Invoice review
Trigger: an invoice enters the monitored mailbox for an enabled legal entity.
Inputs: the original invoice, verified supplier record, purchase order, receipt, current company policy, and prior explicit mappings within the correct team scope.
Evidence: every extracted value stays tied to its source region. The system checks policy version, freshness, independence, and known conflicts.
Action: prepare coding for review. Never approve, post, schedule payment, contact the supplier, or alter supplier details.
Authorization: legal-entity permissions and company policy bound preparation. A named reviewer approves any later action.
Visibility: mark facts, inferences, rule matches, missing evidence, and policy conflicts separately.
Correction and recovery: correct one field without discarding the rest, preserve the original, and keep a version history.
Backoff: route unsupported layouts, conflicting suppliers, bank-detail changes, and repeated corrections to manual review.
Review test
Look for disagreement in the slots
A useful specification gives product, design, and engineering a precise place to disagree. “Make invoice review trustworthy” is not testable. “Hold the item when the supplier record conflicts with the purchase order” is.
Add representative must-act and must-not-act cases before implementation. Verify the resulting state and prohibited behavior, not only one expected sequence of model output.
Use the instrument
Take one feature written as “the system should” and fill the eight fields. If the team cannot name authorization, recovery, or backoff, the behavior is not ready to hide behind a polished interface.