How to write a behavior specification

Eight fields make the product argument concrete

01Trigger

What event or condition gives the system a reason to respond?

02Inputs

Which sources, signals, and context may the system use? Name freshness and provenance requirements.

03Evidence

What tested reliability and evidence quality support this behavior? What remains uncertain?

04System action

Does the system suggest, prepare, execute, refuse, or escalate? State the action precisely.

05Authorization

Whose authority permits the action, and which boundary still requires approval?

06Visibility

What must the person see about sources, status, assumptions, and consequences?

07Correction and recovery

How can the person correct the result, undo a change, or repair an external consequence?

08Backoff

When does the system pause, stop, expire its assumption, or hand the task back?

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.

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.