Decision checks incoming work against your rules and sends it to the right person or agent.
- Run
- Wait
- Stop
- Escalate
Decision
Approve the work, ask for more information, or stop it.
Decision shows incoming tasks and the information needed to review them. Your team can approve, reject, request evidence, or stop an action.
Map shows where the Decision sits, which systems are affected, and what Proof must be recorded after the action.
- Composition: signal-decision-proof
- Hub: Map
Decision operating boundary
One surface. Three questions.
Read what this view shows, how it works, and where to go next.
01 / 03 See the boundary
Decision owns the queue.
Decision routes whether the next step can run, must wait, or should stop with a named owner.
RUN WAIT STOP
Signal
A watched source says something changed or needs attention.
Decision
The queue routes the update to a human, agent, policy rule, or stop point.
Map
The map keeps the owner, system boundary, and downstream impact visible.
Proof
The decision produces evidence, outcome, receipt, audit trail, and rollback note.
Evidence
- Signal: A watched source says something changed or needs attention.
- Decision: The queue routes the update to a human, agent, policy rule, or stop point.
- Map: The map keeps the owner, system boundary, and downstream impact visible.
- Proof: The decision produces evidence, outcome, receipt, audit trail, and rollback note.
Receipts
Surface: queue4 connected states
02 / 03 Inspect ownership
See what this view does and which records it keeps.
In production, Decision is required because it owns review owner, run-wait-stop state, allowed action, escalation and policy reason.
Each task shows the reviewer, proposed action, applicable rule, and why it is running, waiting, or stopped.
Start with a specific update, its source, the tool it affects, and why it needs review.
Decision produces the minimum proof needed for the next operator to understand what happened and why.
Evidence
- The review owner
- The incoming Signal
- A proof requirement
Receipts
review ownerrun-wait-stop stateallowed actionescalation and policy reason
03 / 03 Continue with context
Map shows how this view connects to the rest of the workflow.
Keep the workflow plan, incoming tasks, approvals, and results connected.
Evidence
- Signal
- Map
- Proof
Receipts
Signal inboxMapProof graphProduct overview
Decision implementation
Attach this surface to a real workflow.
Start with one live task. Agree on who approves it and what record your team needs afterward.
- Owner
- Decision operator
- Authority
- Decision production contract
- Proof
- Connected workflow receipt
- State
- review
- 01 / Queue Define the operator action
Decide what a reviewer can approve, reject, route, request, or stop.
- 02 / Policy Name the decision rule
Turn hidden judgment into a policy rule or owner approval path.
- 03 / Proof Require the evidence
Make the queue ask for the proof record before the workflow moves on.