diff --git a/docs/assets/ui/PROVENANCE.txt b/docs/assets/ui/PROVENANCE.txt
index 80b2489..e3bc63d 100644
--- a/docs/assets/ui/PROVENANCE.txt
+++ b/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.
diff --git a/docs/assets/ui/business-decision-qualification-capture.png b/docs/assets/ui/business-decision-qualification-capture.png
new file mode 100644
index 0000000..d0f0ed6
Binary files /dev/null and b/docs/assets/ui/business-decision-qualification-capture.png differ
diff --git a/docs/assets/ui/business-decision-runtime-request.png b/docs/assets/ui/business-decision-runtime-request.png
new file mode 100644
index 0000000..65b40ca
Binary files /dev/null and b/docs/assets/ui/business-decision-runtime-request.png differ
diff --git a/docs/concepts/human-judgment.md b/docs/concepts/human-judgment.md
index ab2c066..1b3ca7d 100644
--- a/docs/concepts/human-judgment.md
+++ b/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.
+
+
+ { width="430" }
+ Qualification capture: the reviewer records policy evidence before the workflow can use a decision node. It does not send a live execution request.
+
+
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.
+
+ { width="330" }
+ Live-run decision: a qualified workflow has reached a declared human-authority point. The phone shows only the reviewed finite choices for this task.
+
+
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