diff --git a/docs/commercial/battlecards.md b/docs/commercial/battlecards.md deleted file mode 100644 index c28b4d5..0000000 --- a/docs/commercial/battlecards.md +++ /dev/null @@ -1,131 +0,0 @@ -# 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/index.md b/docs/commercial/index.md index 3ad5e50..f3dda0b 100644 --- a/docs/commercial/index.md +++ b/docs/commercial/index.md @@ -3,8 +3,7 @@ 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. +[qualification evidence appendix](../get-started/what-works-today.md). ## The offer ladder @@ -21,12 +20,11 @@ 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 +## Buyer and evaluation resources | 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. | @@ -35,19 +33,16 @@ automate; a well-evidenced "do not automate" is a full-value deliverable. | [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). +- Customer results name the workflow and the result actually reported. See the + [RVU audit customer case](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). +- Commercial terms are established in a customer-specific written proposal and + agreement, not in public templates. diff --git a/docs/commercial/legal-outlines.md b/docs/commercial/legal-outlines.md deleted file mode 100644 index 86ddc3e..0000000 --- a/docs/commercial/legal-outlines.md +++ /dev/null @@ -1,77 +0,0 @@ -# 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 index 281b597..7c746dc 100644 --- a/docs/commercial/oem-brief.md +++ b/docs/commercial/oem-brief.md @@ -80,7 +80,7 @@ your marketing as in ours. 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, + customer-specific design-partner agreement: 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. diff --git a/docs/commercial/procurement-faq.md b/docs/commercial/procurement-faq.md index 9e936c1..87b38fa 100644 --- a/docs/commercial/procurement-faq.md +++ b/docs/commercial/procurement-faq.md @@ -12,7 +12,7 @@ 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). +[Qualification Sprint one-pager](qualification-sprint.md). **Is there a subscription?** OpenAdapt Cloud is $500.00/month for managed browser execution of approved @@ -27,11 +27,11 @@ 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]**. +Any production credit is stated in the customer-specific written proposal. No +credit is implied by this public documentation. **What are the payment terms?** -Per SOW; the template proposes 50% at signature, 50% at delivery for sprints. +The customer-specific written proposal and agreement state the payment terms. ## Licensing and lock-in @@ -53,10 +53,8 @@ operator-verifiable no-egress posture. See ## 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). +No. OpenAdapt does not hold a SOC 2 report and does not claim certification. +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 diff --git a/docs/commercial/qualification-report-outline.md b/docs/commercial/qualification-report-outline.md index 77643f0..886bfb7 100644 --- a/docs/commercial/qualification-report-outline.md +++ b/docs/commercial/qualification-report-outline.md @@ -92,7 +92,7 @@ The seeded-fault results, summarized in the | 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. | +| Modeled savings | Customer-specific economic model using conservative, attributed inputs. | | Costs | Sprint, pilot, production, and operational intervention costs. | ## 9. Evidence pack manifest diff --git a/docs/commercial/qualification-sprint.md b/docs/commercial/qualification-sprint.md index 9171aca..2447447 100644 --- a/docs/commercial/qualification-sprint.md +++ b/docs/commercial/qualification-sprint.md @@ -23,8 +23,6 @@ sprints or scoped extensions. - 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 @@ -74,8 +72,8 @@ We recommend against automation, and say so in the report, when for example: 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. +- The volume and value do not clear an agreed economic threshold under + conservative assumptions. ## Acceptance criteria @@ -114,5 +112,5 @@ qualified fixture set: 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. +[openadapt.ai/qualify](https://openadapt.ai/qualify). The written proposal and +agreement define the exact scope, payment schedule, and production options. diff --git a/docs/commercial/roi-calculator.md b/docs/commercial/roi-calculator.md deleted file mode 100644 index f92976a..0000000 --- a/docs/commercial/roi-calculator.md +++ /dev/null @@ -1,70 +0,0 @@ -# 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 index ad0469a..6fc5aeb 100644 --- a/docs/commercial/scope-checklist.md +++ b/docs/commercial/scope-checklist.md @@ -10,8 +10,8 @@ arrives three weeks after signature. - [ ] 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)). +- [ ] Approximate monthly volume and minutes per manual execution for the + customer-specific economic model. - [ ] The consequence of doing it wrong (wrong record, duplicate, missed entry), stated plainly. This drives the risk class and verification strength. diff --git a/docs/commercial/security-packet.md b/docs/commercial/security-packet.md index 30cd305..805c6ee 100644 --- a/docs/commercial/security-packet.md +++ b/docs/commercial/security-packet.md @@ -46,7 +46,7 @@ append-only, hash-chained audit log. | 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]**. | +| SOC 2 | **Not attested.** OpenAdapt does not hold a SOC 2 report and does not claim certification. Request the current security-controls packet for implementation evidence and remaining gaps. | | 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`). | diff --git a/docs/commercial/sow-template.md b/docs/commercial/sow-template.md deleted file mode 100644 index 3abc169..0000000 --- a/docs/commercial/sow-template.md +++ /dev/null @@ -1,130 +0,0 @@ -# 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 a8be5e5..4eb8a21 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -160,7 +160,6 @@ nav: - 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 @@ -169,9 +168,6 @@ nav: - 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