A process, its execution and a decision
I separated the workflow definition from a particular run and from the decision it requests. The editor explains what should happen; the inspector shows what actually ran; the review screen gives a person the evidence and choices needed at a checkpoint.
The workflow list brings both examples together and surfaces the two tasks waiting for a person. Users can enter the editor or go directly to the pending decision.

Make parallel work readable
Document intake feeds an orchestrator, which starts Legal, Finance and Compliance agents in parallel. Their results meet at the Risk Aggregator before Human Approval. Consistent ports, routed connections and execution direction make the branching explicit.
A node shows its role, status and output rather than just a name. Selecting a node opens its settings in context. Agent configuration makes sources, the playbook, output rules and escalation boundaries inspectable.


Trace a conflict back to its source
In the example, four findings become two conflicts across four files. The inspector preserves the per-agent results. The conflict view then puts the opposing passages together: 30 days in the main agreement versus 45 days in the payment schedule.
Document names, page numbers and clause references stay beside each passage. The same pattern handles the second conflict: liability limits of 100,000 and 250,000 dollars. A specialist can assess the discrepancy before choosing what to do.



Record the decision and keep the process paused
The specialist chooses 30 days and a 250,000-dollar liability cap, adds a rationale and requests revisions. This records the desired terms; it does not approve the existing documents or resolve the inconsistency by itself.
The confirmation names the recorded choices and the next dependency: a revised document package. The run remains paused, so the user can distinguish a recorded decision from completed work.


Build a hypothesis from different signals
The second example moves beyond documents. A checkout service has elevated errors. Telemetry, Change and Runbook agents examine metrics and logs, a recent configuration change and the recovery instructions in parallel.
The connection pool changed from 80 to 8 before the spike. The interface presents this as the leading explanation, not a proven cause. An evidence snapshot and runtime revision make the proposed action reviewable at a specific point in time.


Approve one change, then verify the result
The engineer authorizes the exact change DB_POOL_MAX: 8 → 80 for one service and region. The screen shows the required revision, evidence freshness and a ten-minute approval lease. A changed precondition or failure stops execution; the tool must not retry the mutation automatically.
After the update, the example verifies an error rate below 0.5%, p95 latency below 500 ms and no pool timeouts for two minutes. The timeline retains the approval and applied revision. Passing these checks leaves the incident in Monitoring, rather than closing it automatically. All chart values are illustrative.



Review and act without the whole editor
On a phone, the task is to understand what needs attention and make a grounded decision. I replaced the canvas with stage cards, concise evidence and a persistent action. The contract flow leads from status to source passages and a revision request; the incident flow leads from diagnosis to a bounded approval and verified outcome.






A connected concept, ready for evaluation
HeroUI Figma Kit V3 provides the base components. I adapted them to the product and designed the workflow nodes, evidence layouts, decision states and mobile journeys. Figma retains editable layers, Auto Layout, component variants and shared tokens. HeroUI remains the author of its original assets; this case shows finished interface images, not a redistributed kit.
The next step is to evaluate the two critical decisions with domain specialists: can a contract reviewer explain the conflict using the cited passages, and can an on-call engineer state exactly what the approval permits? I would also check whether people distinguish “revision requested” from “approved” and “mitigated” from “closed”. These evaluations have not been conducted.
What I would evaluate next
Planned evaluation criteria; these are not measured results.
| Task | What to observe |
|---|---|
| Explain the payment conflict | Can the reviewer locate both clauses and explain the 30/45-day difference? Record lookup errors and requests for help. |
| Explain what the approval permits | Can the engineer name the exact setting, service, region and expiry? Record overlooked limits before an action is approved. |
| Choose the next step after review | Does the person understand that revised documents are still needed and the mitigated incident is still open? Record mistaken next actions. |





