diff --git a/docs/commercial/acceptance-matrix.md b/docs/commercial/acceptance-matrix.md
new file mode 100644
index 0000000..c133be3
--- /dev/null
+++ b/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.
diff --git a/docs/commercial/battlecards.md b/docs/commercial/battlecards.md
new file mode 100644
index 0000000..c28b4d5
--- /dev/null
+++ b/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?"
diff --git a/docs/commercial/citrix-external-brief.md b/docs/commercial/citrix-external-brief.md
new file mode 100644
index 0000000..ff38689
--- /dev/null
+++ b/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.
diff --git a/docs/commercial/deployment-boundaries.md b/docs/commercial/deployment-boundaries.md
new file mode 100644
index 0000000..7bcb0d1
--- /dev/null
+++ b/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.
diff --git a/docs/commercial/index.md b/docs/commercial/index.md
new file mode 100644
index 0000000..3ad5e50
--- /dev/null
+++ b/docs/commercial/index.md
@@ -0,0 +1,53 @@
+# Commercial offers
+
+This section is the buyer-facing collateral for OpenAdapt's commercial
+offers. Every price and claim here matches the public
+[pricing page](https://openadapt.ai/pricing) and the
+[qualification evidence appendix](../get-started/what-works-today.md). Where a
+term is not yet finalized it is marked explicitly rather than implied.
+
+## The offer ladder
+
+| Offer | Price | What it is |
+|---|---|---|
+| Community | Free (MIT) | Local runtime and qualification tools for self-directed use. No account required. |
+| [Workflow Qualification Sprint](qualification-sprint.md) | From $15,000 (native, RDP, and Citrix scopes typically $25,000 to $40,000) | Fixed-scope paid qualification of one workflow, ending in a signed go/no-go report. |
+| OpenAdapt Cloud | $500.00/month | Managed self-service browser execution for non-regulated data, up to 10,000 runs/month. Separate from enterprise qualification. |
+| Supervised Production Pilot | Typically $30,000 to $60,000 | Prove the qualified workflow on representative production cases and leave with an acceptance report. |
+| Production | Typically $48,000 to $120,000/year | Annual scope covering the qualified workflow family, environment, runners, evidence, support, and requalification. |
+| OEM / embedding | Typically $75,000 to $150,000/year plus scoped integration | Embed the governed transaction runtime in another product. See the [OEM brief](oem-brief.md). |
+
+The ladder is sequential by design: qualification before pilot, pilot before
+production. The sprint is paid even when the correct outcome is not to
+automate; a well-evidenced "do not automate" is a full-value deliverable.
+
+## Sales and evaluation collateral
+
+| Document | Use it when |
+|---|---|
+| [Qualification Sprint one-pager](qualification-sprint.md) | Introducing the entry offer to a buyer. |
+| [Statement of Work template](sow-template.md) | Drafting the sprint contract. |
+| [Scope and prerequisite checklist](scope-checklist.md) | Confirming the customer can actually start. |
+| [Qualification report outline](qualification-report-outline.md) | Showing a buyer what they will receive. |
+| [Acceptance matrix template](acceptance-matrix.md) | Agreeing pass/fail criteria up front. |
+| [Security packet](security-packet.md) | Answering a security or IT review. |
+| [Deployment boundaries](deployment-boundaries.md) | Explaining where execution and sensitive data live. |
+| [External Citrix zero-install brief](citrix-external-brief.md) | A buyer whose workflow lives behind Citrix or VDI. |
+| [OEM architecture and commercial brief](oem-brief.md) | A vendor that wants to embed verified execution. |
+| [Procurement FAQ](procurement-faq.md) | Procurement, legal, and vendor-risk questions. |
+| [Competitive battlecards](battlecards.md) | Positioning against RPA, agents, and scripts. |
+| [ROI worksheet](roi-calculator.md) | Building the economic case with the buyer's own numbers. |
+| [Legal document outlines](legal-outlines.md) | Structuring design-partner and publication agreements. |
+
+## Honesty rules for this section
+
+These documents follow the same rules as the public site:
+
+- No invented customers, quotes, or case data. The one referenced case study is
+  [published with preliminary figures and a pending-confirmation caveat](https://openadapt.ai/customers/rvu-audit-heart-care).
+- No claimed certifications. SOC 2 status is stated plainly in the
+  [security packet](security-packet.md).
+- Bounded evidence stays bounded. Qualification evidence for one workflow,
+  application, and environment is never presented as a general support claim.
+- Competitors are credited for what they are genuinely good at. See the
+  [battlecards](battlecards.md).
diff --git a/docs/commercial/legal-outlines.md b/docs/commercial/legal-outlines.md
new file mode 100644
index 0000000..86ddc3e
--- /dev/null
+++ b/docs/commercial/legal-outlines.md
@@ -0,0 +1,77 @@
+# Legal document outlines
+
+Structural outlines for two recurring agreements. These are outlines only:
+section lists and the decisions each section must capture. Neither is a
+contract, and neither should be sent to a counterparty before counsel review.
+**[LEGAL REVIEW REQUIRED]** on both, in full.
+
+## Design-partner agreement outline
+
+For early customers and OEM partners who get early access and shape the
+product in exchange for defined feedback and evidence obligations.
+
+1. **Parties, term, and definitions.** Partner, program duration, renewal and
+   exit; definitions for evidence, sanitized derivative, and feedback.
+2. **Program scope.** The named workflows, environments, and product surfaces
+   in the program (for example the OEM reference API in design, per the
+   [OEM brief](oem-brief.md)); explicit exclusions.
+3. **Commercial terms.** Fees or discounts relative to the standard
+   [offer ladder](index.md); conversion terms into standard pilot/production
+   contracts; any credit structure. [FOUNDER TO CONFIRM the credit and
+   discount parameters.]
+4. **Partner obligations.** Feedback cadence, named contacts, environment and
+   test-data access, participation in qualification and acceptance runs,
+   timely halt adjudication.
+5. **Provider obligations.** Deliverables, early-access surfaces, support
+   channel and response targets, roadmap-input mechanism; explicit statement
+   of what is NOT promised (dates, features, certifications).
+6. **Pre-release software terms.** Beta quality disclaimers, no production
+   reliance without a signed acceptance, change and deprecation notice.
+7. **Data handling.** Deployment lane per
+   [deployment boundaries](deployment-boundaries.md); what may cross which
+   boundary; sanitized-derivative review; retention and deletion at exit.
+8. **Intellectual property.** Ownership of feedback and suggestions; ownership
+   of partner data and compiled bundles; no implied license to either party's
+   pre-existing IP; open-source engine license unaffected.
+9. **Confidentiality.** Mutual NDA terms or reference to an existing NDA;
+   treatment of evidence packs and reports.
+10. **Publicity.** No public naming or logo use by either party without the
+    separate publication release below.
+11. **Warranties, liability, indemnity.** [LEGAL REVIEW REQUIRED]
+12. **Termination.** For convenience and for cause; effect on licenses, data,
+    and any credits; survival clauses.
+
+## Customer publication release outline
+
+For publishing a case study, evidence figures, or a testimonial. The published
+RVU case study's rules are the template: preliminary figures carry a
+pending-confirmation caveat until this release is signed, and anonymized
+variants are a first-class option.
+
+1. **Parties and scope of release.** Exactly which materials are covered: the
+   case-study text at a named URL or document hash, specific figures, specific
+   quotes, specific screenshots or recreations. Nothing outside the enumerated
+   set is released.
+2. **Attribution level.** One of: fully named (organization and individual),
+   organization-only, role-and-industry anonymized (for example "a US
+   cardiology electrophysiology practice"), or aggregate-only. Consent per
+   level, not blanket.
+3. **Figures and claims approval.** The exact numbers to be published, their
+   definitions and caveats (identified vs collected value, observation window,
+   preliminary status), and the customer's written confirmation of each.
+   Publication removes the pending-confirmation caveat only for confirmed
+   figures.
+4. **Quote approval.** Final wording of any testimonial, approved verbatim by
+   the named speaker; no institutional endorsement implied unless the
+   institution signs.
+5. **Sensitive-data assurance.** Confirmation that published materials contain
+   no PHI/PII, credentials, or raw customer records; screenshots only after
+   review and redaction, or as synthetic recreations labeled as such.
+6. **Reference activities.** Optional and separately consented: reference
+   calls, analyst conversations, conference mentions; frequency limits.
+7. **Review and update rights.** Customer pre-publication review window;
+   correction process; how updates to figures are re-approved.
+8. **Revocation.** How the customer withdraws consent, what is taken down and
+   in what timeframe, and what already-distributed materials survive.
+9. **Term and miscellaneous.** Duration, governing law, signature blocks.
+   [LEGAL REVIEW REQUIRED]
diff --git a/docs/commercial/oem-brief.md b/docs/commercial/oem-brief.md
new file mode 100644
index 0000000..281b597
--- /dev/null
+++ b/docs/commercial/oem-brief.md
@@ -0,0 +1,93 @@
+# OEM architecture and commercial brief
+
+For software vendors and platforms that want to embed verified GUI execution
+in their own product: an RCM platform that must write into customer EMRs, a
+vertical SaaS that must reach a legacy system with no API, an agent platform
+that needs a governed actuator.
+
+## The idea: a transaction API over GUI execution
+
+Most embedding integrations expose "run this script and hope." OpenAdapt's OEM
+surface is designed as a **transaction API**: your product submits an intent,
+and gets back a terminal outcome it can build product logic on.
+
+```text
+submit(workflow, inputs, profile)
+    -> VERIFIED              # business effect confirmed in the system of record
+    -> COMPLETED_UNVERIFIED  # finished, but no independent confirmation; never
+                             # treated as success under standard or regulated profiles
+    -> HALTED                # a gate refused; durable, with the violated expectation named
+    -> FAILED                # aborted with no write
+    -> ROLLED_BACK           # a refuted effect was reconciled by compensation
+```
+
+Each outcome carries the evidence behind it: run report, identity coverage,
+effect verdicts, and hashes binding the evidence to the exact bundle and
+inputs. Your product does not parse screenshots to guess what happened; it
+branches on a verdict.
+
+**Status: this reference API is in design.** The underlying mechanics
+(governed run admission, terminal outcomes, effect verification, evidence
+binding) ship in the engine today; the stable embedding surface, versioned
+schemas, and external-executor adapter are being specified. OEM engagements at
+this stage are design-partner engagements and shape that surface.
+
+## Integration surface
+
+- **Submission:** your control plane submits a qualified, sealed workflow
+  bundle plus typed inputs. Admission is fail-closed: an uncertified bundle,
+  missing coverage, or unsatisfied profile requirement is refused before
+  actuation, not discovered after.
+- **Execution profiles:** `demo`, `standard`, and `regulated` profiles compile
+  into explicit requirements (certification, sealed bundles, consequential
+  identity and effect coverage, egress policy). Your product selects a
+  profile, not a bag of flags.
+- **Runners:** execution lands on a runner in the right boundary: your cloud,
+  your customer's environment, or a managed browser runner for non-regulated
+  web targets ([deployment boundaries](deployment-boundaries.md)). Runners
+  advertise capabilities; a plan a runner cannot satisfy is rejected before
+  actuation.
+- **Evidence:** every run returns machine-readable evidence
+  ([report schema](../guides/run-reports.md)) suitable for your own audit
+  trail and your customers' reviewers.
+- **External executors:** the adapter contract
+  (`authorize -> invoke -> observe -> verify -> VERIFIED | HALTED + evidence`)
+  is designed so identity, authorization, verification, and evidence stay
+  authoritative even when another tool (a script, an RPA bot, an API call, an
+  agent) performs the action.
+
+## Responsibility boundaries
+
+| Responsibility | OpenAdapt | OEM partner |
+|---|---|---|
+| Engine, safety gates, report schema | R | uses |
+| Qualification tooling and evidence format | R | runs or resells |
+| Workflow qualification per customer environment | C (or delivered as a service) | R |
+| End-customer relationship, UX, and support | | R |
+| Deployment boundary and data handling per end customer | C | R |
+| Verifier read paths in end-customer systems | C | R |
+| Claims made to end customers about coverage | must match the evidence | R |
+
+The last row is contractual on purpose: bounded evidence stays bounded, in
+your marketing as in ours.
+
+## Commercial shape
+
+- **OEM programs: typically $75,000 to $150,000 annually, plus scoped
+  integration work**, matching the public
+  [pricing page](https://openadapt.ai/pricing).
+- Scope covers the embedding license, the integration surface, named
+  environments, and support; per-end-customer workflow qualification is scoped
+  separately or delivered by the partner using the qualification tooling.
+- Early OEM partners operate under a
+  [design-partner structure](legal-outlines.md): defined feedback obligations,
+  early access to the reference API, and input into its shape.
+- The engine is MIT-licensed and auditable; embedding does not depend on a
+  proprietary black box for its safety story.
+
+## Where to start
+
+An OEM conversation starts the same way every OpenAdapt engagement does: with
+one real workflow. A [Qualification Sprint](qualification-sprint.md) against
+one of your end-customer environments produces the evidence that the
+integration is worth building, before either side commits to platform work.
diff --git a/docs/commercial/procurement-faq.md b/docs/commercial/procurement-faq.md
new file mode 100644
index 0000000..9e936c1
--- /dev/null
+++ b/docs/commercial/procurement-faq.md
@@ -0,0 +1,108 @@
+# Procurement FAQ
+
+Answers for procurement, legal, and vendor-risk teams evaluating an OpenAdapt
+engagement. Security depth lives in the
+[security packet](security-packet.md); prices match the public
+[pricing page](https://openadapt.ai/pricing).
+
+## Commercial
+
+**What are we actually buying in a Qualification Sprint?**
+A fixed-scope engineering assessment of one workflow, from $15,000 (native,
+RDP, and Citrix scopes typically $25,000 to $40,000), delivering a signed
+go/no-go report, coverage matrix, and evidence pack. It is paid regardless of
+outcome; "do not automate" is a full-value deliverable. See the
+[one-pager](qualification-sprint.md) and [SOW template](sow-template.md).
+
+**Is there a subscription?**
+OpenAdapt Cloud is $500.00/month for managed browser execution of approved
+workflows on non-regulated data, up to 10,000 runs/month. It is a self-service
+developer and team offering, separate from enterprise qualification, and does
+not include a production SLA or regulated deployment.
+
+**What does production cost?**
+Supervised Production Pilots are typically $30,000 to $60,000; production
+contracts typically $48,000 to $120,000 per year depending on workflow family,
+environment, runners, evidence, support, and requalification scope. OEM
+embedding is typically $75,000 to $150,000 per year plus integration.
+
+**Does the sprint fee credit toward production?**
+A portion of the sprint fee credits toward the first production year; the
+exact percentage is being finalized: **[FOUNDER TO CONFIRM]**.
+
+**What are the payment terms?**
+Per SOW; the template proposes 50% at signature, 50% at delivery for sprints.
+
+## Licensing and lock-in
+
+**What license is the software under?**
+The engine and runtime are MIT-licensed open source, publicly auditable. The
+hosted control plane is proprietary. Compiled workflow bundles and evidence
+generated for you are yours.
+
+**What happens if we stop paying?**
+The MIT engine keeps running locally; you lose the commercial services around
+it (managed execution, support, requalification, hosted control plane). There
+is no license key that turns your local runtime off.
+
+**Can we self-host everything?**
+Yes. Fully local and air-gapped on-prem deployment shapes exist, including an
+operator-verifiable no-egress posture. See
+[deployment boundaries](deployment-boundaries.md).
+
+## Security and compliance
+
+**Are you SOC 2 certified?**
+No. OpenAdapt does not hold a SOC 2 report and does not claim certification;
+an internal controls matrix and evidence plan are maintained, and the target
+date for an observation period is **[FOUNDER TO CONFIRM DATE]**. See the
+[security packet](security-packet.md).
+
+**Will you sign a BAA / process PHI in your cloud?**
+The managed cloud lane is for non-regulated data. PHI-bearing workflows run in
+a customer-controlled boundary where PHI does not leave your environment; BAA
+and counsel review are engagement-specific.
+
+**Where does our data live?**
+By lane: see [deployment boundaries](deployment-boundaries.md). In the
+customer-controlled lanes, raw recordings, live frames, and verifier values
+stay inside your boundary; only reviewed, sanitized, hash-bound derivatives
+cross, and a fully local deployment sends nothing.
+
+**How do we audit what it did?**
+Every run writes a human-readable and a machine-readable report with identity
+coverage, effect verdicts, heals, model calls, and halt reasons; on-prem adds
+an append-only hash-chained audit log
+([run reports](../guides/run-reports.md)).
+
+## Delivery and risk
+
+**What if the software gets it wrong silently?**
+The acceptance target for silent incorrect successes (the run says done, the
+system of record disagrees) is zero, contractually, per the
+[acceptance matrix](acceptance-matrix.md). The mechanism is out-of-band effect
+verification with halt on any non-confirmed verdict. Published bounded
+qualifications to date report zero silent incorrect successes on their
+fixtures ([evidence appendix](../get-started/what-works-today.md)); your
+workflow's numbers come from your own qualification.
+
+**What are the known limitations?**
+Published and maintained in the engine's
+[LIMITS.md](https://github.com/OpenAdaptAI/openadapt-flow/blob/main/docs/LIMITS.md).
+Identity checks cover armed steps; screen-only verification is labeled as
+same-surface; qualification evidence is bounded to the exact environment it
+names.
+
+**Who are the subprocessors?**
+Depends on the lane. A fully local deployment has none in the run path. For
+hosted lanes, request the current subprocessor list directly.
+
+**What support and requalification do we get?**
+Defined per production contract: support channel and response targets,
+requalification triggers (application upgrades, drift past healing coverage),
+and evidence refresh. The pilot's acceptance report sets the operational
+baseline.
+
+**Insurance, indemnity, liability?**
+Per the governing agreement; request current certificates and terms directly.
+This documentation does not create contractual terms.
diff --git a/docs/commercial/qualification-report-outline.md b/docs/commercial/qualification-report-outline.md
new file mode 100644
index 0000000..77643f0
--- /dev/null
+++ b/docs/commercial/qualification-report-outline.md
@@ -0,0 +1,104 @@
+# Qualification report outline
+
+The structure of the report delivered at the end of a
+[Qualification Sprint](qualification-sprint.md). This page defines the sections
+and fields; it is deliberately an outline, not a filled sample, because a
+qualification report is only meaningful for the exact workflow, application,
+environment, and bundle it names. Field semantics follow the engine's run
+report schema (`REPORT.md` and `report.json`, see
+[run reports](../guides/run-reports.md)) and the published benchmark report
+conventions in
+[openadapt-flow](https://github.com/OpenAdaptAI/openadapt-flow) (for example
+`benchmark/*/results.json`).
+
+## 1. Identification and provenance
+
+| Field | Definition |
+|---|---|
+| Workflow name and version | The named workflow and its qualified revision. |
+| Application and version | Exact application, version or tenant, and release channel. |
+| Substrate | Browser, Windows UIA, macOS, Linux, RDP, or Citrix, with client and transport details for remote scopes. |
+| Environment | The exact environment qualified (test tenant, VM snapshot, session broker); evidence never generalizes past it. |
+| Engine versions | `openadapt-flow` and related package versions used. |
+| Bundle digest | SHA-256 of the sealed bundle the evidence binds to. Evidence for one digest does not transfer to a modified bundle. |
+| Report hashes | Digests of the evidence artifacts, so the pack is tamper-evident. |
+
+## 2. Decision
+
+| Field | Definition |
+|---|---|
+| Recommendation | Go, no-go, or go-with-conditions. |
+| Basis | The specific results that determine the recommendation. |
+| Boundary | The exact scope within which the recommendation holds. |
+| Conditions | For conditional go: what must change or be accepted, by whom. |
+| Requalification triggers | Events that void the qualification (application upgrade, layout change past healing coverage, verifier change, environment change). |
+
+## 3. Workflow and risk inventory
+
+| Field | Definition |
+|---|---|
+| Step inventory | Every compiled step with its action type. |
+| Risk classification | Which steps are consequential (writes, submissions, deletions, payments) and why. Ambiguous classifications are resolved with the customer during the sprint, not assumed. |
+| Parameters and secrets | Inputs the workflow takes; secrets are referenced by name and never stored in artifacts. |
+| Exclusions | Paths, cases, and variants explicitly out of qualified scope. |
+
+## 4. Coverage matrix
+
+Delivered as its own artifact and summarized here. For each step:
+
+| Field | Definition |
+|---|---|
+| Identity armed | Whether a pre-action identity check guards the step, and what evidence it compares ([identity gate](../concepts/identity-gate.md)). |
+| Identity coverage line | "N of M consequential steps identity-armed", with each unarmed step listed by id and reason. |
+| Effect contract | For each write: the declared effect (`record_written`, `field_equals`), its selector, and idempotency handling. |
+| Verification strength | The strongest available oracle for the effect: independent system interface, independent read-only session, persisted-state reacquisition, or immediate screen confirmation. Screen-only confirmation is labeled as such, never presented as an independent system-of-record check. |
+| Gaps | Every step or write without coverage, and whether policy permits it at this risk class. |
+
+## 5. Representative case results
+
+| Field | Definition |
+|---|---|
+| Case inventory | The representative cases selected with the workflow owner. |
+| Trials per case | Count of repeated trials (minimum three per counted case). |
+| Outcomes | Per trial: verified success, halt (with the violated expectation), or failure, per the run report's outcome field. |
+| Effect verdicts | CONFIRMED / REFUTED / INDETERMINATE per declared effect ([effect verification](../concepts/effect-verification.md)). |
+| Model calls | Count per run; healthy deterministic replay is expected to record zero. |
+| Latency | Wall-clock per run where relevant to the ROI model. |
+
+## 6. Fault campaign results
+
+The seeded-fault results, summarized in the
+[acceptance matrix](acceptance-matrix.md) format:
+
+| Field | Definition |
+|---|---|
+| Fault classes exercised | For example wrong record, ambiguous target, stale target, drift, duplicate submission, dialog interruption, focus theft, disconnect (per substrate). |
+| Expected outcome | Safe halt, refusal, or verified reconciliation per class. |
+| Observed outcome | What each trial actually did, with run-report references. |
+| Silent incorrect successes | Count of runs reporting success while the system of record disagrees. **Acceptance target: 0.** |
+| Over-halts | Healthy runs that halted unnecessarily; reported honestly because they carry the operational cost of intervention. |
+
+## 7. Deployment analysis
+
+| Field | Definition |
+|---|---|
+| Recommended boundary | Which [deployment lane](deployment-boundaries.md) fits the data sensitivity and infrastructure. |
+| Data flows | What crosses which boundary, per the deployment matrix. |
+| Operational model | Scheduling, halt routing, who reviews reports, expected intervention rate. |
+| Open items | Access, security review, or legal items required before pilot. |
+
+## 8. Economics
+
+| Field | Definition |
+|---|---|
+| Volume and time baseline | Customer-provided run volume and manual minutes. |
+| Modeled savings | Per the [ROI worksheet](roi-calculator.md), under conservative assumptions, with every input attributed. |
+| Costs | Sprint, pilot, production, and operational intervention costs. |
+
+## 9. Evidence pack manifest
+
+Every artifact in the pack, with hashes: run directories (`REPORT.md`,
+`report.json`), fault-case reports, coverage matrix, and, on "go", the
+qualified prototype bundle. Reports shared outside the customer boundary are
+scrubbed first; the raw evidence stays in the agreed boundary
+([run reports: scrubbing](../guides/run-reports.md#scrubbing-shared-reports)).
diff --git a/docs/commercial/qualification-sprint.md b/docs/commercial/qualification-sprint.md
new file mode 100644
index 0000000..9171aca
--- /dev/null
+++ b/docs/commercial/qualification-sprint.md
@@ -0,0 +1,118 @@
+# Workflow Qualification Sprint
+
+**Fixed-scope, paid qualification of one workflow. From $15,000. Ten-business-day
+target once access is confirmed.**
+
+## What it is
+
+You bring one named workflow. We qualify the exact application, environment,
+identities, effects, failure cases, and deployment boundary, and you leave with
+a signed go/no-go decision backed by evidence. Not a generic automation
+strategy, not a proof-of-concept demo: a bounded engineering assessment of
+whether this workflow can run safely, what it costs, and what it returns.
+
+The sprint qualifies **one** workflow in **one** application and **one**
+environment. Additional workflows, applications, or environments are separate
+sprints or scoped extensions.
+
+## Price
+
+- Browser and standard desktop scopes: **from $15,000**.
+- Complex native, RDP, and Citrix scopes: **typically $25,000 to $40,000**,
+  reflecting per-environment identity, verification, and fixture work.
+- The sprint fee is due regardless of outcome. **"Do not automate" is a valid,
+  full-value result**: you paid for a defensible decision, and a well-evidenced
+  no saves you the far larger cost of a bad production deployment.
+- Conversion credit: a portion of the sprint fee credits toward the first
+  production year. Exact percentage: **[FOUNDER TO CONFIRM]**.
+
+## When the clock starts
+
+The ten-business-day target starts on the first business day on which **all**
+of the following are true, confirmed in writing:
+
+1. The Statement of Work is signed and the invoice terms are agreed.
+2. Working access to the target application and test environment is verified by
+   an OpenAdapt engineer (login succeeds, the workflow's screens are reachable).
+3. Representative test data is available and safe to write against.
+4. The customer has named its workflow owner and security contact.
+
+Days on which access is broken or revoked pause the clock. See the
+[scope and prerequisite checklist](scope-checklist.md).
+
+## What the customer provides
+
+- A named business workflow with an owner who can demonstrate it.
+- Application access in a test or sandboxed environment (or a
+  customer-controlled production boundary with explicit written approval).
+- Test data that is representative and safe to modify.
+- A read path for verification: an API, database, report, or read-only session
+  through which the business effect can be independently confirmed. See
+  [effect verification](../concepts/effect-verification.md).
+- A security contact for boundary and data-handling questions.
+
+## Exclusions
+
+- No production writes without explicit written authorization per workflow.
+- No development of new application features, APIs, or integrations in the
+  target system.
+- No general process re-engineering or consulting beyond the named workflow.
+- No compliance certification of any kind; see the
+  [security packet](security-packet.md) for the current attestation state.
+- Model-assisted repair and grounding, where used, stay within the deployment's
+  configured endpoints; the sprint does not introduce uncontrolled egress.
+
+## No-go criteria
+
+We recommend against automation, and say so in the report, when for example:
+
+- The business effect cannot be independently verified and the risk class does
+  not allow screen-only confirmation.
+- The workflow requires judgment calls that cannot be reduced to checkable
+  rules, identities, and postconditions.
+- The environment is too unstable for a bounded requalification policy (for
+  example uncontrolled application releases with no test tenant).
+- A direct API or batch interface already exists that makes GUI automation the
+  wrong tool. We will tell you to use it.
+- The volume and value do not clear the [ROI worksheet](roi-calculator.md)
+  under conservative assumptions.
+
+## Acceptance criteria
+
+The sprint is complete when the deliverables below are handed over and walked
+through with the customer. A "go" recommendation additionally requires, on the
+qualified fixture set:
+
+- All representative cases complete with the declared verification strength.
+- All seeded fault cases end in a safe halt or verified reconciliation.
+- **Zero silent incorrect successes**: no run reports success while the system
+  of record disagrees. This target is absolute; see the
+  [acceptance matrix](acceptance-matrix.md).
+- Coverage gaps, exclusions, and requalification triggers are enumerated, not
+  discovered later.
+
+## Deliverables
+
+1. **Qualification report**: the signed go/no-go decision with the full
+   evidence trail. Structure in the
+   [qualification report outline](qualification-report-outline.md).
+2. **Coverage matrix**: which steps are identity-armed, which writes carry
+   effect contracts, at what verification strength, and every gap.
+3. **Go/no-go decision**: an explicit recommendation with the reasons, the
+   boundary within which it holds, and what would change it.
+4. **Evidence pack**: run reports (`REPORT.md` and `report.json`), fault-case
+   results, hashes binding evidence to the exact bundle, and the working
+   qualified prototype bundle where the decision is "go". See
+   [run reports](../guides/run-reports.md).
+
+## What happens after
+
+- **Go**: proceed to a Supervised Production Pilot (typically $30,000 to
+  $60,000) on representative production cases, then production.
+- **No-go**: you keep the report, the evidence, and the analysis. Many no-go
+  reports still identify a smaller automatable slice or an API path worth
+  pursuing.
+
+Start by describing the workflow at
+[openadapt.ai/qualify](https://openadapt.ai/qualify), or use the
+[Statement of Work template](sow-template.md) to contract directly.
diff --git a/docs/commercial/roi-calculator.md b/docs/commercial/roi-calculator.md
new file mode 100644
index 0000000..f92976a
--- /dev/null
+++ b/docs/commercial/roi-calculator.md
@@ -0,0 +1,70 @@
+# ROI worksheet
+
+A worksheet for building the economic case with the buyer's own numbers. It
+deliberately uses conservative defaults and no invented case data. Fill it in
+during qualification scoping; the completed version becomes Section 8 of the
+[qualification report](qualification-report-outline.md).
+
+## The formula
+
+```text
+Gross monthly savings = runs/month x minutes saved per run / 60 x loaded hourly rate
+
+Net annual value     = (gross monthly savings - monthly operating cost) x 12
+                       + recovered value (if the workflow finds money, not just time)
+                       - first-year platform and qualification cost
+```
+
+## Inputs
+
+| Input | Definition | Conservative guidance |
+|---|---|---|
+| Runs per month | Actual executions of this workflow, from logs or the operator, not an aspiration. | Use last quarter's average, not the peak month. |
+| Minutes saved per run | Manual handle time minus residual human time (review, halt handling). | Time the operator doing it live; subtract 10 to 20% for residual review. |
+| Loaded hourly rate | Fully loaded cost of the person doing it today (salary + benefits + overhead). | Use your finance team's loaded rate, not base salary alone. |
+| Intervention rate | Fraction of runs expected to halt for a human. | Until your own pilot measures it, budget several percent; halts are a designed outcome, not free. |
+| Minutes per intervention | Human time to review a halt and resolve it. | Include context-switch cost; 5 to 15 minutes is typical for a routed halt. |
+| Recovered value | Money the workflow finds (missed billables, avoided penalties), separate from labor time. | Only count identified-and-actioned value; see the caveat below. |
+| Platform cost | The relevant rung of the [offer ladder](index.md): Cloud at $500/month, or the pilot/production contract. | Use the real quote, not the floor price. |
+| Qualification cost | The sprint fee (from $15,000; native/RDP/Citrix typically $25,000 to $40,000). | First-year only; a portion credits toward production, percentage [FOUNDER TO CONFIRM]. |
+
+## Worked structure (fill with your numbers)
+
+```text
+A. Runs per month                     = ________
+B. Minutes saved per run              = ________
+C. Loaded hourly rate ($/h)           = ________
+D. Gross monthly savings              = A x B / 60 x C          = ________
+E. Intervention cost per month        = A x rate x min/60 x C   = ________
+F. Platform cost per month            = ________
+G. Net monthly value                  = D - E - F               = ________
+H. Recovered value per year (if any)  = ________
+I. First-year one-time cost           = sprint (+ pilot)        = ________
+J. First-year net value               = G x 12 + H - I          = ________
+K. Payback (months)                   = I / G                   = ________
+```
+
+A workflow that cannot clear a conservative version of this worksheet is a
+[no-go criterion](qualification-sprint.md#no-go-criteria), and the sprint
+report will say so.
+
+## What "recovered value" must mean
+
+If the workflow identifies money (for example missed billables), count it as
+recovered only at the point your own process actually actions it. Identified
+is not submitted, submitted is not approved, approved is not collected. State
+which point your number measures.
+
+## A real reference point, with its caveat
+
+The published
+[RVU audit case study](https://openadapt.ai/customers/rvu-audit-heart-care)
+(a US cardiology electrophysiology practice, customer-controlled Windows
+deployment) reports preliminary steady-state figures: roughly 480 governed
+runs per month, about 5 hours of manual audit work saved monthly, an estimated
+$75,000 per year in recoverable billables **identified** (not booked), a 99.2%
+verified rate, 3 halts routed to a human per month, and 0 silent incorrect
+successes. **Those figures are preliminary and under review pending final
+customer confirmation**, and "recovered" there means identified and queued,
+not collected. Use them as an existence proof of the worksheet's shape, not as
+your expected result; your numbers come from your own qualification and pilot.
diff --git a/docs/commercial/scope-checklist.md b/docs/commercial/scope-checklist.md
new file mode 100644
index 0000000..ad0469a
--- /dev/null
+++ b/docs/commercial/scope-checklist.md
@@ -0,0 +1,72 @@
+# Scope and prerequisite checklist
+
+What the customer must provide before a
+[Qualification Sprint](qualification-sprint.md) can start. The sprint clock
+does not start until every required item is confirmed. Sending this list with
+the proposal avoids the most common cause of stalled engagements: access that
+arrives three weeks after signature.
+
+## 1. The workflow
+
+- [ ] One named workflow with a clear start state and a clear finished state.
+- [ ] A workflow owner who performs it today and can demonstrate it end to end.
+- [ ] Approximate monthly volume and minutes per manual execution (feeds the
+      [ROI worksheet](roi-calculator.md)).
+- [ ] The consequence of doing it wrong (wrong record, duplicate, missed
+      entry), stated plainly. This drives the risk class and verification
+      strength.
+
+## 2. Application access
+
+- [ ] Working credentials for the target application, in the environment the
+      sprint will use.
+- [ ] The environment named explicitly: test tenant, sandbox, cloned VM, or a
+      customer-controlled production boundary with written approval.
+- [ ] For RDP or Citrix scopes: a session an OpenAdapt engineer can reach, with
+      the client, codec, resolution, and DPI representative of production. See
+      the [external Citrix brief](citrix-external-brief.md).
+- [ ] Any VPN, MFA, jump-host, or allowlisting steps completed for the named
+      engineers.
+- [ ] Confirmation that automated input against this environment is permitted
+      by the application's terms and the customer's policies.
+
+## 3. Test data
+
+- [ ] Representative records that exercise the workflow's real variety
+      (not only the happy path).
+- [ ] Data that is safe to create, modify, and delete during trials.
+- [ ] Either de-identified data, or an explicit decision that the sprint runs
+      inside a customer-controlled boundary where real data may appear on
+      screen (see [deployment boundaries](deployment-boundaries.md)).
+- [ ] A way to reset or clean up test records between trials.
+
+## 4. Verifier read path
+
+Effect verification reads the system of record instead of trusting the screen
+([how it works](../concepts/effect-verification.md)). Provide at least one:
+
+- [ ] API access (REST, FHIR, or similar) that can read the records the
+      workflow writes.
+- [ ] Read-only database access or a scheduled export covering those records.
+- [ ] A report or file the system produces that reflects the write.
+- [ ] If none exist: a read-only second session for on-screen read-back, and
+      acknowledgment that this is a weaker, same-surface check. High-risk
+      workflows may be no-go without an independent read path.
+
+## 5. People and security
+
+- [ ] Workflow owner: available for the demonstration, midpoint review, and
+      fault-case adjudication (roughly 4 to 8 hours across the sprint).
+- [ ] Security contact: for data-boundary questions and access approvals.
+- [ ] IT contact: for environment, VPN, and credential logistics.
+- [ ] Any security review the customer requires of OpenAdapt started early;
+      the [security packet](security-packet.md) and
+      [security review guide](../guides/security-review.md) answer most
+      questionnaires.
+
+## 6. Decision authority
+
+- [ ] The person who will act on the go/no-go recommendation is identified and
+      attends the final walkthrough.
+- [ ] Budget path for the next step (pilot, production) is understood, so a
+      "go" does not stall for a quarter.
diff --git a/docs/commercial/security-packet.md b/docs/commercial/security-packet.md
new file mode 100644
index 0000000..30cd305
--- /dev/null
+++ b/docs/commercial/security-packet.md
@@ -0,0 +1,92 @@
+# Security packet
+
+The honest current state of OpenAdapt's security posture, written for a
+security or vendor-risk reviewer. Deeper technical detail:
+[Security and data handling](../guides/security-and-data-handling.md) and the
+reviewer-oriented
+[Security and deployment review](../guides/security-review.md). Nothing on
+this page is a compliance determination.
+
+## Architecture in one paragraph
+
+OpenAdapt is local-first. The engine records a demonstrated GUI workflow,
+compiles it into a deterministic bundle, and replays it with zero model calls
+on the healthy path. Consequential actions are guarded by pre-action identity
+checks, and writes are verified out of band against the system of record (API,
+database, or document hash), not the pixels. Any non-confirmed verdict halts
+the run. Every run produces an audit trail; on-prem deployments add an
+append-only, hash-chained audit log.
+
+## Core security properties
+
+- **Local-first execution.** A fully local deployment makes zero outbound
+  calls on a healthy replay, and the no-egress posture is operator-verifiable
+  with an active probe (`verify-airgap.sh`).
+- **Out-of-band verification.** Effect contracts are checked by an independent
+  read of the system of record. REFUTED and INDETERMINATE verdicts both halt;
+  an unreachable verifier is never treated as success
+  ([effect verification](../concepts/effect-verification.md)).
+- **Fail-closed regulated path.** The `run` verb refuses to start without
+  certification, identity coverage, effect contracts or explicit approval, and
+  encrypted, integrity-sealed bundles
+  ([regulated execution](../concepts/regulated-execution.md)).
+- **Evidence sealing and binding.** Bundles seal with AES-256-GCM (opt-in at
+  authoring time); run authorization is single-use and bound to the bundle
+  content digest, parameter digest, policy, and effect-contract hashes; run
+  reports record effect contracts as one-way SHA-256 digests.
+- **Auditable open runtime.** The engine is MIT-licensed and directly
+  reviewable; the safety mechanisms described here are inspectable source, not
+  a black box. The hosted control plane is proprietary but exposes its public
+  contracts and live readiness state.
+- **Secrets never enter artifacts.** Secret fields are excluded from
+  recordings, bundles, and frames, and injected at run time from the
+  customer's environment or OS keychain.
+
+## Attestation status
+
+| Item | Status |
+|---|---|
+| SOC 2 | **Not attested.** OpenAdapt does not hold a SOC 2 report, has not opened an auditor-defined observation period, and does not claim certification. An internal controls matrix, gap assessment, and evidence plan are maintained against Security, Availability, and Confidentiality criteria. Target date for opening an observation period: **[FOUNDER TO CONFIRM DATE]**. |
+| HIPAA / BAA | No standing BAA offering. Deployments that touch PHI use a customer-controlled boundary; BAA and counsel review are engagement-specific. |
+| Penetration test | Request current status directly; do not infer from documentation. |
+| Vulnerability disclosure | Coordinated disclosure via private GitHub advisories, acknowledgment target within 5 business days (engine `SECURITY.md`). |
+| Supply chain | GitHub Actions pinned by commit SHA; Dependabot; public Desktop releases ship `SHA256SUMS`, a CycloneDX SBOM, and build-provenance attestations. Windows/Linux installers are currently unsigned and macOS is ad-hoc signed; verify checksums and provenance. |
+
+If a security questionnaire needs a signed answer on any row, request the
+current artifact directly rather than citing this page.
+
+## Encryption posture
+
+- **In transit:** the PHI/PII-bearing desktop control channel is TLS with
+  per-run certificate pinning, fail-closed. Hosted APIs are HTTPS.
+- **At rest:** opt-in AES-256-GCM sealing for the bundle, screenshot crops,
+  and checkpoints, layered on operator full-disk encryption. The regulated
+  `run` path refuses unencrypted bundles by default.
+- **Key management:** remains the customer's (KMS, rotation, escrow).
+  OpenAdapt supplies the AEAD substrate, not a KMS.
+
+## Data-boundary options
+
+Full detail and diagram: [deployment boundaries](deployment-boundaries.md).
+
+| Option | Where execution runs | What crosses the customer boundary |
+|---|---|---|
+| Fully local / air-gapped on-prem | Customer workstation or server | Nothing at run time; signed updates enter on operator-pulled media. |
+| Customer-controlled runner (BYOC) | Customer VM or cloud account | Sanitized, manifested artifact derivatives and minimized control metadata only; raw frames and PHI/PII stay inside the boundary. |
+| Hosted control plane + local execution | Execution local; accounts, versions, and history managed | Operator-approved sanitized derivatives, minimized halt descriptors, hash-bound attestations. |
+| Managed browser runner (Cloud, $500/month) | OpenAdapt's cloud | For explicitly initiated, public-HTTPS, **non-regulated** workloads only. Not a lane for PHI/PII. |
+
+Sensitive live observations never route into the shared managed boundary; a
+recording that was sanitized for upload does not make runtime data sanitized,
+and the documentation says so explicitly rather than implying otherwise.
+
+## What we will not claim
+
+- Architecture documentation is not a HIPAA, PHIPA, SOC 2, or other
+  compliance determination.
+- A green qualification for one workflow is not a general application-support
+  or safety claim.
+- Identity coverage applies to armed steps; screen-only read-back on a no-API
+  surface is labeled same-surface confirmation, not independent verification.
+- The engine's known limits are published and maintained in
+  [LIMITS.md](https://github.com/OpenAdaptAI/openadapt-flow/blob/main/docs/LIMITS.md).
diff --git a/docs/commercial/sow-template.md b/docs/commercial/sow-template.md
new file mode 100644
index 0000000..3abc169
--- /dev/null
+++ b/docs/commercial/sow-template.md
@@ -0,0 +1,130 @@
+# Statement of Work template: Workflow Qualification Sprint
+
+Template for the fixed-scope sprint described in the
+[one-pager](qualification-sprint.md). Bracketed fields are filled per
+engagement. This template is a starting structure, not legal advice.
+**[LEGAL REVIEW REQUIRED]** before first use.
+
+---
+
+## 1. Parties and effective date
+
+- Provider: MLDSAI Inc. (OpenAdapt) [entity details]
+- Customer: [legal name, address]
+- Effective date: [date]
+- Governing agreement: [MSA / mutual NDA reference, or standalone terms]
+
+## 2. Scope
+
+Provider will qualify exactly one workflow:
+
+- Workflow name and business purpose: [description]
+- Target application and version: [application, version, tenant]
+- Execution substrate: [browser / Windows native / macOS / Linux / RDP /
+  Citrix]
+- Environment: [test / sandbox / customer-controlled production boundary]
+- Business effect to verify and its system of record: [effect, read path]
+- In scope: suitability assessment, qualified prototype, identity and
+  effect-verification contract, failure and exception analysis, deployment
+  analysis, ROI model, signed go/no-go report.
+- Out of scope: production writes without written authorization, changes to the
+  target application, additional workflows or environments, compliance
+  certification, ongoing operation.
+
+## 3. Timeline
+
+- Target duration: ten business days of engineering work from clock start,
+  typically two to four weeks elapsed including access setup and review.
+- Clock start: the first business day on which SOW signature, verified
+  application access, representative test data, and named contacts are all
+  confirmed in writing (see Section 5).
+- Clock pause: days on which required access or data is unavailable.
+- Checkpoints: kickoff [date], midpoint findings review [date], final
+  walkthrough [date].
+
+## 4. Responsibilities (RACI)
+
+| Activity | Provider | Customer |
+|---|---|---|
+| Demonstrate the workflow end to end | C | R/A |
+| Provide application access and test data | C | R/A |
+| Record, compile, and qualify the workflow | R/A | C/I |
+| Author identity and effect contracts | R/A | C |
+| Provide the verification read path | C | R/A |
+| Seed and adjudicate fault cases | R | C/A |
+| Security and data-boundary review | C | R/A |
+| Go/no-go recommendation | R/A | C/I |
+| Acceptance of deliverables | C | R/A |
+
+R = responsible, A = accountable, C = consulted, I = informed.
+
+## 5. Access prerequisites
+
+Customer provides before clock start (full list in the
+[scope and prerequisite checklist](scope-checklist.md)):
+
+- [ ] Named workflow owner able to demonstrate the workflow.
+- [ ] Working credentials for the target application in the agreed environment.
+- [ ] Representative test data safe to create, modify, and delete.
+- [ ] Verifier read path (API credentials, database read access, report export,
+      or read-only session).
+- [ ] Security contact and any required access approvals.
+
+## 6. Data boundary
+
+- Execution location: [customer workstation / customer VM / customer cloud /
+  OpenAdapt-managed browser runner (non-regulated data only)].
+- Sensitive data (including any PHI/PII) remains inside the customer-controlled
+  boundary; artifacts cross a boundary only as reviewed, sanitized derivatives
+  per the [deployment boundaries](deployment-boundaries.md) page.
+- Recordings, bundles, and evidence storage location and retention: [location,
+  retention period, deletion at termination yes/no].
+- Model usage: healthy replay makes no model calls; any compilation or repair
+  model endpoint is [named endpoint / none / customer-approved].
+- Credentials are never stored in artifacts; secret fields are injected at run
+  time from the customer's environment.
+
+## 7. Deliverables
+
+1. Qualification report per the
+   [qualification report outline](qualification-report-outline.md).
+2. Coverage matrix (identity arming, effect contracts, verification strength,
+   gaps).
+3. Signed go/no-go decision with boundary and requalification triggers.
+4. Evidence pack: run reports, fault-case results, hashes, and (on "go") the
+   qualified prototype bundle.
+
+## 8. Acceptance
+
+- Deliverables are accepted at the final walkthrough unless Customer identifies
+  a material gap against Sections 2 and 7 in writing within [5] business days.
+- A "no-go" recommendation is a complete, accepted deliverable. The sprint fee
+  is not contingent on a "go" outcome.
+- Acceptance of the sprint does not constitute acceptance of any production
+  deployment; production acceptance uses the
+  [acceptance matrix](acceptance-matrix.md) under a separate pilot SOW.
+
+## 9. Fees and payment
+
+- Fixed fee: $[15,000+ per scope; native/RDP/Citrix typically $25,000 to
+  $40,000].
+- Invoicing: [50% at signature, 50% at delivery / net terms].
+- Expenses: none without prior written approval.
+- Conversion credit: [X]% of the sprint fee credits toward the first production
+  year if executed within [N] months. Percentage **[FOUNDER TO CONFIRM]**.
+
+## 10. No-go and termination
+
+- Early no-go: if Provider concludes before day ten that automation should not
+  proceed, Provider delivers the report early; the fixed fee stands.
+- Blocked access: if prerequisites remain unmet [15] business days after
+  signature, either party may terminate; work performed is invoiced pro rata
+  against the fixed fee.
+- Termination for convenience by Customer: fee for work performed plus
+  deliverables completed to date.
+- Confidentiality, IP in pre-existing materials, and liability terms per the
+  governing agreement. **[LEGAL REVIEW REQUIRED]**
+
+---
+
+Signatures: [Provider] / [Customer], name, title, date.
diff --git a/mkdocs.yml b/mkdocs.yml
index 3cd5a45..a8be5e5 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -157,6 +157,21 @@ nav:
     - Settings and policy governance: concepts/settings-governance.md
     - Security and data handling: guides/security-and-data-handling.md
     - Security and deployment review: guides/security-review.md
+  - Commercial:
+    - commercial/index.md
+    - Qualification Sprint: commercial/qualification-sprint.md
+    - Statement of Work template: commercial/sow-template.md
+    - Scope and prerequisite checklist: commercial/scope-checklist.md
+    - Qualification report outline: commercial/qualification-report-outline.md
+    - Acceptance matrix template: commercial/acceptance-matrix.md
+    - Security packet: commercial/security-packet.md
+    - Deployment boundaries: commercial/deployment-boundaries.md
+    - External Citrix zero-install brief: commercial/citrix-external-brief.md
+    - OEM architecture and commercial brief: commercial/oem-brief.md
+    - Procurement FAQ: commercial/procurement-faq.md
+    - Competitive battlecards: commercial/battlecards.md
+    - ROI worksheet: commercial/roi-calculator.md
+    - Legal document outlines: commercial/legal-outlines.md
   - Internals:
     - The substrate model: concepts/substrate-model.md
     - The deployment matrix: concepts/deployment-matrix.md