docs(commercial): qualification sprint, SOW, security packet, OEM brief, battlecards (Section 24)

docs/commercial/acceptance-matrix.md

@@ -0,0 +1,76 @@
+# Acceptance matrix template
+
+The pass/fail contract for a qualification or pilot, agreed **before** trials
+run. Each row is a fault class; each column states what the run must do. The
+matrix turns "it seems to work" into a checkable claim, and it is the artifact
+an auditor or reviewer reads first.
+
+## How to read it
+
+Three outcomes are acceptable, one is not:
+
+- **Verified**: the run completes and the declared business effect is
+  CONFIRMED by the configured verifier reading the system of record.
+- **Halt**: the run stops before or after the fault, names the violated
+  expectation in the run report, and routes to a human. A halt is a correct
+  outcome for a fault case, not a failure.
+- **Reconciliation**: for a refuted duplicate on an idempotent-capable path, a
+  compensator removes the extra record and re-verification CONFIRMS; only then
+  does the run continue. Reconciliation never invents or overwrites state.
+- **Silent incorrect success** (unacceptable): the run reports success while
+  the system of record disagrees. **The target for this column is 0, in every
+  row, with no exceptions.** A single occurrence fails acceptance.
+
+Mechanics behind the outcomes:
+[effect verification](../concepts/effect-verification.md),
+[the identity gate](../concepts/identity-gate.md),
+[fail-closed regulated execution](../concepts/regulated-execution.md).
+
+## Template
+
+Trials per row: minimum [3]. Substrate: [browser / native / RDP / Citrix].
+Verifier: [API / database / document hash / read-only session]. Bundle digest:
+[sha256].
+
+| Fault class | Description | Expected outcome | Trials | Observed | Silent incorrect successes (target 0) |
+|---|---|---|---|---|---|
+| Healthy baseline | No fault injected | Verified | [n] | | |
+| Wrong record on screen | The target record differs from the intended one | Halt before write (identity refuses) | [n] | | |
+| Ambiguous target | Two plausible targets (duplicate names, repeated icons) | Halt (refuse to guess) | [n] | | |
+| Stale target | The recorded target no longer exists | Halt | [n] | | |
+| Benign drift | Theme, movement, or rename drift within healing coverage | Verified, heal recorded for review | [n] | | |
+| Severe drift | Layout change past healing coverage | Halt | [n] | | |
+| Duplicate submission | The same write fires twice | Reconciliation (idempotent path) or Halt; exactly one record remains | [n] | | |
+| Phantom success | UI shows saved, backend rejected the write | Halt (effect REFUTED) | [n] | | |
+| Partial save | A field was dropped by the application | Halt (effect REFUTED) | [n] | | |
+| Concurrent overwrite | Another user's change would be lost | Halt (effect REFUTED) | [n] | | |
+| Verifier unreachable | The read path errors or the token expires | Halt (effect INDETERMINATE; never treated as "record absent") | [n] | | |
+| Dialog interruption | An unexpected modal appears mid-run | Halt | [n] | | |
+| Focus theft | Another window takes focus before a consequential action | Halt before input delivery | [n] | | |
+| Missing confirmation | The expected confirmation never appears | Halt; uncertain submission is verified, never blindly retried | [n] | | |
+
+Remote-substrate rows (add for RDP and Citrix scopes):
+
+| Fault class | Description | Expected outcome | Trials | Observed | Silent incorrect successes (target 0) |
+|---|---|---|---|---|---|
+| Disconnect / reconnect | Session drops mid-run | Halt or durable resume with re-verified context; no blind replay of pending input | [n] | | |
+| Session context change | Window, geometry, resolution, or DPI changes between resolve and act | Input lease refuses delivery; halt | [n] | | |
+| Stale frame | The frame is older than the readiness policy allows | Fresh frame reacquired or halt | [n] | | |
+| Compression artifacts | Codec artifacts degrade the target region | Verified when identity still resolves; halt on ambiguity | [n] | | |
+
+## Summary block
+
+| Metric | Target | Observed |
+|---|---|---|
+| Verified rate on healthy cases | [per SOW] | |
+| Safe-halt rate on fault cases | 100% of non-reconciled faults | |
+| Silent incorrect successes | **0** | |
+| Over-halts on healthy cases | Reported; bounded per SOW | |
+| Model calls on healthy replay | 0 | |
+| Operator interventions | Reported | |
+
+Published examples of this evidence shape, with counted trials and zero
+silent-incorrect-success results on bounded fixtures, are linked from
+[qualification evidence](../get-started/what-works-today.md). Those results are
+bounded to their named workflows and environments; your matrix is filled from
+your own trials.

docs/commercial/battlecards.md

@@ -0,0 +1,131 @@
+# Competitive battlecards
+
+Positioning against the four alternatives a buyer actually weighs. Same rules
+as the public [comparison page](https://openadapt.ai/compare): credit real
+strengths, recommend the alternative when it fits better, and differentiate
+only on what OpenAdapt genuinely does differently: verification against the
+system of record, transaction outcomes, the external no-install lane,
+customer-controlled data, and an open MIT runtime.
+
+One rule above all: **if a direct API exists for the task, say so and lose the
+deal gracefully.** An API beats GUI automation of any kind.
+
+## UiPath (and enterprise RPA generally)
+
+**Where they are genuinely strong.** Mature platform: hundreds of packaged
+connectors, orchestration, scheduling, credential vaults, governance tooling,
+a large partner and talent ecosystem, and years of enterprise deployments.
+For broad multi-application automation programs with dedicated CoE staffing,
+RPA platforms are a defensible default.
+
+**Where OpenAdapt differs.**
+
+- **Verification, not just execution.** RPA success typically means the
+  selector matched and the click landed. OpenAdapt verifies the business
+  effect out of band against the system of record and halts on any
+  non-confirmed verdict; the acceptance target for silent incorrect successes
+  is zero, in the contract.
+- **Demonstration, not development.** A workflow is recorded from a human
+  demonstration and compiled, rather than built and maintained as a bot
+  project by RPA developers.
+- **External no-install lane.** OpenAdapt drives Citrix/RDP externally through
+  pixels with nothing installed in the session
+  ([brief](citrix-external-brief.md)). RPA vendors also offer computer-vision
+  automation for Citrix; the difference is the fail-closed identity and
+  effect-verification contract wrapped around it, not the pixels themselves.
+- **Open runtime, customer-controlled data.** MIT engine, local-first
+  execution, no per-bot licensing meter on your own hardware.
+
+**When to concede.** Large-scale orchestration across dozens of workflows,
+deep packaged-connector needs, or an established CoE standardized on the
+platform.
+
+**Buyer question to plant.** "When the bot reports success, what read of the
+system of record backs that up, and what happens when they disagree?"
+
+## Microsoft Power Automate
+
+**Where they are genuinely strong.** Unbeatable distribution and price inside
+Microsoft 365: cloud flows, deep Office/Teams/Dataverse integration, licensing
+most enterprises already own, and a citizen-developer model IT already
+tolerates. For API-connected flows in the Microsoft ecosystem it is usually
+the right answer, and we say so.
+
+**Where OpenAdapt differs.**
+
+- **The workflows Power Automate reaches worst.** Desktop flows (RPA) on
+  legacy, non-Microsoft, or Citrix-published applications are where attended
+  selectors get brittle. That GUI-only remainder is OpenAdapt's entire focus.
+- **Transaction outcomes.** A flow that ran is not a verified effect.
+  OpenAdapt returns verified/halted outcomes with evidence, designed for
+  consequential writes.
+- **Customer-controlled and air-gapped shapes.** Regulated execution without
+  routing through a shared cloud, with an operator-verifiable no-egress
+  posture.
+
+**When to concede.** The task has a connector or API path in the Microsoft
+graph; anything cloud-flow shaped.
+
+**Buyer question to plant.** "For the desktop flows on your legacy or Citrix
+apps: who maintains the selectors, and what verifies the write actually
+landed?"
+
+## Computer-use agents (LLM-driven GUI agents)
+
+**Where they are genuinely strong.** Novel, exploratory, one-off tasks with no
+prior demonstration; natural-language task specification; improving fast.
+For "figure out how to do this thing I have never scripted," an agent is the
+right tool and we recommend one.
+
+**Where OpenAdapt differs.**
+
+- **Determinism on the repeat path.** A compiled workflow replays
+  deterministically with zero model calls on the healthy path: no
+  per-run token spend, no stochastic variation on run 4,000. Model spend is
+  reserved for compilation and governed repair.
+- **Fail-closed rather than best-effort.** Agents are optimized to complete
+  the task; OpenAdapt is optimized to refuse when identity, postconditions, or
+  effects cannot verify. For consequential writes, halting is the cheap
+  direction to be wrong.
+- **Auditability.** Every step records its resolution, identity check, effect
+  verdict, and any model call; evidence is hash-bound. Agent traces are
+  improving but are not verification.
+- **Published honest benchmark.** The public comparison measures repeat cost
+  and latency on one bundled task with the caveats stated; we do not claim
+  general agent-benchmark superiority.
+
+**When to concede.** Truly novel or constantly varying tasks, low-consequence
+work, research and exploration.
+
+**Buyer question to plant.** "What is the agent's silent wrong-action rate on
+your workflow, measured against the system of record rather than its own
+self-report?"
+
+## Scripts and browser recorders (Playwright, Selenium, macro tools)
+
+**Where they are genuinely strong.** Free or cheap, fully controlled,
+excellent for developers on stable web apps; Playwright in particular is a
+superb engineering tool. A capable developer with a stable DOM and time to
+maintain the script needs nothing else.
+
+**Where OpenAdapt differs.**
+
+- **Maintenance is the product.** Scripts encode selectors by hand and break
+  silently or loudly with UI drift; OpenAdapt compiles from demonstration,
+  heals benign drift deterministically with the heal recorded for review, and
+  halts on severe drift.
+- **No DOM required.** Native desktop, RDP, and Citrix surfaces where
+  Playwright and Selenium do not reach.
+- **Verification and governance built in.** Identity gates, effect contracts,
+  fail-closed admission, and audit evidence are engine features, not per-team
+  disciplines that erode under deadline pressure.
+- **Complement, not only competitor.** The external-executor design lets a
+  customer-controlled script perform an action while OpenAdapt's
+  authorization, verification, and evidence stay authoritative
+  ([OEM brief](oem-brief.md)).
+
+**When to concede.** Stable web app, engineering team owns it, low consequence
+of a wrong write, no audit requirement.
+
+**Buyer question to plant.** "Who is on the hook when the script clicks the
+wrong patient, and how would you find out it happened?"

docs/commercial/citrix-external-brief.md

@@ -0,0 +1,83 @@
+# External Citrix zero-install brief
+
+For workflows that live behind Citrix Workspace, VDI, or published
+applications, where installing software inside the session is impossible or
+prohibited.
+
+## The problem
+
+The highest-value repetitive workflows in healthcare, banking, and insurance
+often run inside a Citrix session: the EMR or core system is published from an
+environment the operating team cannot modify. Conventional automation fails
+here twice over: there is no DOM, no accessibility tree, and no API from the
+outside, and the hosting policy forbids installing an agent inside the
+session.
+
+## The approach: external black-box execution
+
+OpenAdapt drives the Citrix client window from outside the session, through
+exactly what a human uses: rendered pixels, keyboard, and mouse. **Zero
+install inside the remote session.** No agent, no driver, no browser
+extension, no change request to the Citrix operator.
+
+Governance is not relaxed to make that work; it is the same contract as every
+other substrate:
+
+- The dedicated Citrix backend binds the exact Workspace client window,
+  optionally an exact title, and requires a readiness marker before a governed
+  run proceeds.
+- Consequential input reacquires the exact window, focus, geometry, readiness,
+  fresh pixels, resolved target, and record identity, then a one-shot input
+  lease refuses delivery if **anything** changed between resolution and the
+  first input edge.
+- Identity checks run on the pixel tier; ambiguity deliberately over-halts
+  rather than guessing. A collapsible or unreadable identifier halts the run.
+- Business effects are verified out of band where a read path exists (API,
+  database, report export, or a read-only second session). Screen-only
+  confirmation is labeled as such, and high-risk workflows may not qualify on
+  it alone.
+- Halts are durable: the run pauses for a human with the violated expectation
+  named in the report.
+
+## Honest status
+
+Two claims, kept separate:
+
+1. **Qualified today: the backend contract over a deterministic no-DOM
+   stand-in.** The released `--backend citrix` path passed its accepted
+   qualification batch: 3/3 healthy effects and 3/3 severe-drift safe halts,
+   with zero model calls, zero silent incorrect successes, zero false
+   completions, zero healthy over-halts, and zero drift writes. The immutable
+   report records `code_readiness_accepted: true` and, explicitly,
+   `ica_hdx_accepted: false`
+   ([evidence appendix](../get-started/what-works-today.md)).
+2. **Pending: counted acceptance in a real ICA/HDX session.** The exact
+   client, codec, latency, DPI, lock and readiness behavior, input handling,
+   identity, and effect matrix of a real Citrix environment is a
+   per-deployment qualification boundary. That acceptance runs in **your**
+   Citrix environment as part of a
+   [Qualification Sprint](qualification-sprint.md); stand-ins remain
+   development fixtures, not Citrix evidence.
+
+We state this plainly because the alternative, generalizing from a stand-in to
+your production Citrix farm, is exactly the kind of claim the qualification
+process exists to prevent.
+
+## What a Citrix qualification needs from you
+
+In addition to the standard [prerequisite checklist](scope-checklist.md):
+
+- A reachable Citrix session (Workspace or HTML5) with client, codec,
+  resolution, and DPI representative of production.
+- Permission to drive that session with automated input.
+- A verification read path for the business effect, or an explicit decision on
+  read-only-session verification and its risk implications.
+
+## Commercial shape
+
+Citrix scope is at the upper end of the sprint ladder: **typically $25,000 to
+$40,000** for qualification of one workflow, reflecting per-environment
+fixture, identity, and verification work. The
+[deployment boundary](deployment-boundaries.md) is customer-controlled: the
+runner sits on your side, the session stays in its own boundary, and nothing
+is installed in it.

docs/commercial/deployment-boundaries.md

@@ -0,0 +1,93 @@
+# Deployment boundaries
+
+Where execution runs and where sensitive data lives, per lane. The engineering
+source of truth is the
+[deployment and data-boundary matrix](../concepts/deployment-matrix.md); this
+page is the buyer-facing summary and diagram.
+
+Every lane runs the same engine, the same safety gates, and produces the same
+report schema. The lanes differ in **data handling**, not in what is enforced.
+
+## The three lanes
+
+```mermaid
+flowchart LR
+    subgraph MANAGED [Lane 1: Managed browser]
+        direction TB
+        M1[OpenAdapt Cloud control plane]
+        M2[Managed browser runner]
+        M3[Public-HTTPS web app<br/>non-regulated data only]
+        M1 --> M2 --> M3
+    end
+
+    subgraph CUSTOMER [Lane 2: Customer-controlled runner]
+        direction TB
+        C1[Customer runner<br/>workstation, VM, or customer cloud]
+        C2[Native app, browser,<br/>or internal system]
+        C3[(System of record<br/>verifier read path)]
+        C1 --> C2
+        C1 -.independent read.-> C3
+    end
+
+    subgraph EXTERNAL [Lane 3: External remote]
+        direction TB
+        E1[Customer-controlled runner]
+        E2[RDP / Citrix client window<br/>pixels, keyboard, mouse only]
+        E3[Remote session owned by a<br/>third party or another boundary]
+        E1 --> E2 --> E3
+    end
+
+    CP[Optional hosted control plane:<br/>accounts, versions, run history]
+    CP -. sanitized derivatives,<br/>minimized metadata, hashes .-> CUSTOMER
+    CP -. same contract .-> EXTERNAL
+    CP --- MANAGED
+```
+
+### Lane 1: Managed browser
+
+- **What runs where:** OpenAdapt operates the control plane and the browser
+  runner. The public $500/month subscription covers approved browser
+  workflows, up to 10,000 runs/month.
+- **Where sensitive data lives:** this lane is for explicitly initiated,
+  public-HTTPS, **non-regulated** targets. PHI/PII-bearing workloads do not
+  belong in this lane and are not silently admitted to it.
+- **What crosses to OpenAdapt:** the approved workflow artifacts and the
+  managed run evidence, inside the declared hosted boundary.
+
+### Lane 2: Customer-controlled runner
+
+- **What runs where:** execution runs on infrastructure the customer controls
+  (workstation, server, VM, or customer cloud account). This is the standard
+  lane for regulated or sensitive workflows, including the published RVU audit
+  case study deployment shape.
+- **Where sensitive data lives:** live frames, OCR text, injected parameters,
+  and verifier values stay inside the customer boundary. If PHI appears on
+  screen at run time, it never leaves.
+- **What crosses to OpenAdapt (optional):** if the hosted control plane is
+  connected, only reviewed sanitized derivatives, minimized halt descriptors,
+  and hash-bound attestations cross, verified against published schemas. A
+  fully local or air-gapped deployment sends nothing at all, and that posture
+  is operator-verifiable with an active probe.
+
+### Lane 3: External remote
+
+- **What runs where:** the runner is customer-controlled (as in Lane 2), but
+  the target application lives in a session someone else controls: RDP,
+  Citrix Workspace, or VDI. OpenAdapt drives it externally through pixels,
+  keyboard, and mouse. **No software installs inside the remote session.**
+- **Where sensitive data lives:** the remote session's data stays in the
+  remote boundary; what the runner sees is the rendered frame, handled under
+  the runner's local sensitive-data policy. Verification prefers an
+  independent read path; where only the screen is available, that is labeled
+  same-surface confirmation and high-risk workflows may not qualify on it.
+- **Status:** see the honest status statement in the
+  [external Citrix brief](citrix-external-brief.md).
+
+## Rules that hold in every lane
+
+- Secrets are referenced, injected at run time, and never stored in artifacts.
+- Raw authoring artifacts do not cross a boundary; only sanitized, manifested,
+  hash-bound derivatives do, after operator review.
+- Native, RDP, and Citrix jobs never route to the managed browser runner.
+- The [acceptance matrix](acceptance-matrix.md) target of zero silent
+  incorrect successes applies identically in every lane.