docs: show human judgment capture and decision paths

docs/assets/ui/PROVENANCE.txt

@@ -30,3 +30,17 @@ mobile-decision-result.jpg
   314 x 784. From the same source and capture sequence as the request. It is the
   completed runner result with the verified_and_resumed reason code. The data
   is synthetic OpenEMR application data.
+
+business-decision-qualification-capture.png
+  SHA-256: 1876efdba92d3995cffcdca126d32d9e2493f7e4ffaf46b131f8580c09994862
+  860 x 3542. Byte-identical source: OpenAdaptAI/openadapt-cloud,
+  Cloud PR #281 merge commit 176595db43c3bfbf0a0bd4a1100e035e922396c0,
+  public/demo/qualification-judgment/judgment-capture-request.png. It is a
+  synthetic qualification capture. It is not a live execution request.
+
+business-decision-runtime-request.png
+  SHA-256: cf9ab3f36f6869ec80758ae70ff6aa2466d73615997de5d5eed351d2cdca1a65
+  520 x 880. Byte-identical source: OpenAdaptAI/openadapt-cloud,
+  Cloud PR #278 merge commit 167b2f0843229c5938f3d9e97de46f68b66e3476,
+  public/demo/judgment/business-decision-request.png. It is a synthetic
+  mobile live-run decision request. It does not report an execution result.

docs/concepts/human-judgment.md

@@ -54,6 +54,15 @@ realistic cases with the relevant facts and the human choice. Then record a
 ask the reviewer to explain the permitted result. This separates a real policy
 rule from a one-off preference or an accidental action.
 
+The qualification capture below is not an attended run. It records reviewed
+context, a role, the finite options, and the selected policy treatment before
+the workflow is certified. The synthetic example shows a scheduling exception.
+
+<figure markdown>
+  ![A synthetic qualification screen asks a scheduling lead which approved policy applies to a scheduling exception.](../assets/ui/business-decision-qualification-capture.png){ width="430" }
+  <figcaption>Qualification capture: the reviewer records policy evidence before the workflow can use a decision node. It does not send a live execution request.</figcaption>
+</figure>
+
 The qualification review must preserve the distinction between these three
 outcomes:
 
@@ -109,6 +118,11 @@ The mobile or desktop surface shows one request, its reviewed context, and only
 the options that the contract permits. It cannot add a new option or free-text
 instruction.
 
+<figure markdown>
+  ![A synthetic mobile decision screen asks an operations lead to choose one approved exception route.](../assets/ui/business-decision-runtime-request.png){ width="330" }
+  <figcaption>Live-run decision: a qualified workflow has reached a declared human-authority point. The phone shows only the reviewed finite choices for this task.</figcaption>
+</figure>
+
 1. The route authenticates the person and verifies their permitted role.
 2. It submits one signed option with an idempotency key.
 3. The runner validates the task, policy, presentation, role, option, expiry,
@@ -142,6 +156,10 @@ The remote route does not receive raw cases or screen content. If a person must
 inspect protected live evidence to make the choice, use the runner-local
 operator surface or a customer-controlled delivery route.
 
+The screenshots on this page come from accepted synthetic Cloud demo sources.
+They show the two separate product surfaces. This page uses the retained,
+versioned captures rather than depending on a public demo route.
+
 ## Related documentation
 
 - [Attend a paused run and teach a correction](halt-learn-loop.md) for a