From 073b572b06580435314a6a22ab58e6cbffecac41 Mon Sep 17 00:00:00 2001 From: Richard Abrich Date: Wed, 29 Jul 2026 18:16:00 -0400 Subject: [PATCH 1/3] docs: describe v2 qualified decision labels --- docs/DECISION_DELIVERY.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/docs/DECISION_DELIVERY.md b/docs/DECISION_DELIVERY.md index 61177d20..c1716b31 100644 --- a/docs/DECISION_DELIVERY.md +++ b/docs/DECISION_DELIVERY.md @@ -56,6 +56,31 @@ is checkable the same way: by reading a schema, not by trusting a detector. The hosted control plane enforces it a third time in Postgres, in the same style as `human_decision_task_contract_valid`. +## V2: qualification-approved entity wording + +V1 uses only domain-neutral wording such as `record` or `item`. A later V2 task +can carry one useful entity label that the exact qualification contract already +approved. For example, the contract can name a `patient record`, an insurance +`claim`, or a `loan application`. + +This is not runtime inference. The producer reads the label from the exact +qualified step and binds the task to the qualification project, qualification +revision, qualification contract digest, and bundle digest. The task has no +field for a screenshot, OCR output, parameter, application name, observed +identity value, or model input. A label says what class of entity the workflow +handles; it never says which entity is on screen. + +The runner and client use V2 only after explicit schema negotiation. A peer that +does not negotiate V2 receives the byte-compatible V1 task and renders `record` +or `item`. Before any action continues, the customer-controlled runner reads +the live application and revalidates the required identity and effect +contracts. + +!!! note "Release dependency" + This V2 section documents a coordinated Flow, Desktop, Cloud, and Types + release. It must not be published as an available decision path before the + V2 producer, consumer, and negotiated capability are released together. + The one thing this tier gives up is `target_label` — the target control's own accessible name, which `halt_detail._safe_target_label` releases locally after six independent proofs. It stays local. The phone therefore says *"OpenAdapt From 3e6a1e12e68c096b6ce39dc52573ec48f883bb9e Mon Sep 17 00:00:00 2001 From: Richard Abrich Date: Wed, 29 Jul 2026 18:48:30 -0400 Subject: [PATCH 2/3] docs: define controlled remote entity wording --- docs/DECISION_DELIVERY.md | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/docs/DECISION_DELIVERY.md b/docs/DECISION_DELIVERY.md index c1716b31..9f6f8cf4 100644 --- a/docs/DECISION_DELIVERY.md +++ b/docs/DECISION_DELIVERY.md @@ -59,9 +59,14 @@ hosted control plane enforces it a third time in Postgres, in the same style as ## V2: qualification-approved entity wording V1 uses only domain-neutral wording such as `record` or `item`. A later V2 task -can carry one useful entity label that the exact qualification contract already -approved. For example, the contract can name a `patient record`, an insurance -`claim`, or a `loan application`. +can carry one useful entity class that the exact qualification contract already +approved. The remote emitter accepts only the reviewed remote-safe vocabulary. +The canonical vocabulary and cross-vertical examples are in +[Attended decisions and the halt-learn loop](https://docs.openadapt.ai/concepts/halt-learn-loop/#a-qualified-entity-label-not-a-guessed-domain). + +Qualification can retain a custom class for a local operator surface. A remote +task does not carry a custom or unrecognized class. The remote client renders +the signed neutral `record` or `item` fallback instead. This is not runtime inference. The producer reads the label from the exact qualified step and binds the task to the qualification project, qualification @@ -72,9 +77,10 @@ handles; it never says which entity is on screen. The runner and client use V2 only after explicit schema negotiation. A peer that does not negotiate V2 receives the byte-compatible V1 task and renders `record` -or `item`. Before any action continues, the customer-controlled runner reads -the live application and revalidates the required identity and effect -contracts. +or `item`. The same neutral fallback applies when the class is not in the +reviewed remote-safe vocabulary. Before any action continues, the +customer-controlled runner reads the live application and revalidates the +required identity and effect contracts. !!! note "Release dependency" This V2 section documents a coordinated Flow, Desktop, Cloud, and Types From 37cef8d8e75260a56c9d022296c129884dd12c4a Mon Sep 17 00:00:00 2001 From: Richard Abrich Date: Wed, 29 Jul 2026 19:14:13 -0400 Subject: [PATCH 3/3] docs: align v2 labels with reviewed vocabulary --- docs/DECISION_DELIVERY.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/docs/DECISION_DELIVERY.md b/docs/DECISION_DELIVERY.md index 9f6f8cf4..6b8ddd28 100644 --- a/docs/DECISION_DELIVERY.md +++ b/docs/DECISION_DELIVERY.md @@ -64,9 +64,9 @@ approved. The remote emitter accepts only the reviewed remote-safe vocabulary. The canonical vocabulary and cross-vertical examples are in [Attended decisions and the halt-learn loop](https://docs.openadapt.ai/concepts/halt-learn-loop/#a-qualified-entity-label-not-a-guessed-domain). -Qualification can retain a custom class for a local operator surface. A remote -task does not carry a custom or unrecognized class. The remote client renders -the signed neutral `record` or `item` fallback instead. +Qualification selects one class from the reviewed vocabulary. If no specific +class fits, it selects the signed neutral `record` or `item` fallback. This +release does not accept an arbitrary custom class for shared presentation. This is not runtime inference. The producer reads the label from the exact qualified step and binds the task to the qualification project, qualification @@ -77,10 +77,9 @@ handles; it never says which entity is on screen. The runner and client use V2 only after explicit schema negotiation. A peer that does not negotiate V2 receives the byte-compatible V1 task and renders `record` -or `item`. The same neutral fallback applies when the class is not in the -reviewed remote-safe vocabulary. Before any action continues, the -customer-controlled runner reads the live application and revalidates the -required identity and effect contracts. +or `item`. Before any action continues, the customer-controlled runner reads +the live application and revalidates the required identity and effect +contracts. !!! note "Release dependency" This V2 section documents a coordinated Flow, Desktop, Cloud, and Types