Decision: definition and contract

A Decision records an attributable approval, rejection, repair, exception, or release consequence tied to exact Journey evidence. It identifies who acted, under which authority and policy, why they acted, what evidence they considered, and what changed as a result.

A Decision is not a comment

Discussion, assignment, and AI suggestions can help coordinate Review. They do not authorize a product or release consequence. A Decision is a separate lifecycle event with explicit authority, rationale, evidence references, and supersession history.

AI may propose a classification, repair, explanation, or next action. It may not approve its own repair or silently elevate trust. The final Decision must remain attributable to the authorized actor or policy boundary that made it effective.

Decision types

• Approve: accept the observed change or output for its declared consequence.
• Reject: deny the change or output and retain the evidence behind that result.
• Repair: authorize a bounded target, state, content, or product correction.
• Exception: accept a documented risk under scope, authority, and expiry.
• Release consequence: allow, block, reopen, or qualify release readiness.

What a Decision retains

A durable Decision includes the selected Run, Observation, context, step or difference, decision type, rationale, actor, authority, policy version, timestamp, expiry when applicable, supersession, and owning-object consequence.

Example: changed checkout confirmation

Review may determine that the new confirmation copy is intentional, the outcome still holds, and the visual change is approved. That Decision can mark the Journey current while identifying affected documentation and demo Renditions for editorial refresh. A comment saying “looks fine” cannot produce the same auditable consequence.

Decisions feed downstream Publications and Release Books without rewriting the underlying Observation. See the Review documentation for the application path.