Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
203 changes: 71 additions & 132 deletions LAUNCH_PLAN.md
Original file line number Diff line number Diff line change
@@ -1,134 +1,73 @@
# OpenAdapt Public Launch Plan

Last reviewed: 2026-07-15

## Objective

Launch the real hosted OpenAdapt product end to end. Development mocks may
remain available, but production execution, billing, artifact handling, and run
status must be backed by configured live services. A simulated run must never
be reported as a production success.

## Launch Gate

The launch candidate is accepted only when a clean account can complete this
workflow against production-like infrastructure:

1. Create an account and organization.
2. Select and purchase the configured plan through Stripe Checkout.
3. Record or import a workflow.
4. Produce a sanitized derivative, review it when policy requires, and approve
its exact content hash.
5. Compile, lint, and certify the workflow.
6. Execute it through a real configured runner.
7. Receive authenticated callbacks and inspect the report and audit trail.
8. Halt on induced failure, teach or repair the workflow locally, validate and
activate the replacement on the same hosted workflow, and rerun it.
9. Confirm entitlement, usage, and billing state.
10. Confirm that missing production dependencies cannot fall back to simulated
success.

## Workstreams

| Workstream | Required outcome |
|---|---|
| Cloud mode | Explicit development/mock and production/live behavior with production dependency validation |
| Execution | Real storage, queue/runner dispatch, authenticated callbacks, reports, retries, resume, and failure recovery |
| Billing | Stripe test/live support, configured products and prices, checkout, portal, signed idempotent webhooks, entitlements, and usage metering |
| Artifact privacy | Type-complete sanitized derivatives, local review and correction, verification, manifest, and exact-hash approval |
| Runtime data | Parameters and secrets separated from templates; PHI-bearing observations retained inside the declared trusted boundary |
| Product surfaces | Website, docs, launcher, cloud, and GitHub profile describe the same shipped scope without invented claims or prices |
| Evidence | Bounded subsystem tests plus the clean-account production-like launch lifecycle |

## Fourteen-Step Execution Plan

1. Establish one public product description and canonical repository path.
2. Label every public component with an evidence-backed lifecycle state.
3. Freeze the launch substrate to the browser workflow until its complete gate
passes; keep other backends visibly Experimental or Research.
4. Prove clean-machine install, record, compile, lint, certify, replay, induced
drift, report inspection, and uninstall on every claimed operating system.
5. Produce sanitized derivatives from immutable source copies, inventory every
file, refuse unsupported content, rescan, review locally, and approve exact
hashes.
6. Bind runnable upload to source and bundle hashes, compiler/configuration,
parameter schema, strict lint, certification, risk class, replay evidence,
target boundary, one-time challenge, and deployment allowlists.
7. Make production mode explicit and validate every live dependency at
readiness; never substitute simulated execution when configuration is
absent.
8. Complete Stripe Checkout, portal, signed idempotent webhooks, subscription
linkage, entitlements, metering, cancellation, and refund verification.
9. Dispatch immutable bundle/version/validation snapshots to the real runner;
authenticate callbacks, verify downloaded bytes, isolate runtime parameters
and secrets, require request idempotency and single-flight dispatch, retain
ambiguous acknowledgements for operator reconciliation, reconcile only
provably abandoned work, and meter terminal outcomes exactly once.
10. Complete governed failure handling: structured halt reports, local teaching
or repair, validated replacement activation, checkpoint/resume, and rerun.
11. Publish the actual enterprise data boundary, threat model, credential and
log handling, update/rollback design, audit limitations, and regulated
deployment responsibilities.
12. Align the website, canonical journey-first docs, launcher, desktop surfaces,
pricing, organization profile, examples, and lifecycle registry.
13. Run the clean-account production lifecycle, provider probes, nightly
cross-platform lifecycle, real purchase/refund, backup/restore, incident,
and one high-value fail-closed workflow qualification; release only the
substrate that passes.
14. Publish reproducible evaluation artifacts, failure taxonomy, limitations,
and an arXiv paper after author, disclosure, licensing, sanitized-artifact,
release-identity, and evidence checks pass.

## Artifact And PHI Contract

- Scrubbing transforms a copy and never mutates the source artifact.
- Every file is inventoried and must have an explicit transformer or exclusion;
unknown or unsuccessfully processed content is refused.
- The sanitized derivative is rescanned and accompanied by a versioned manifest
containing source/result hashes, transformations, findings, and policy.
- Recordings and bundles containing or suspected of containing PHI require
local review by default. Review can add redactions or reject the derivative.
- Approval is bound to the exact derivative hash. A later change requires new
approval.
- Schema-minimized break reports may use an automatic policy.
- Automatic artifact approval is disabled by default. A deployment operator
may enable it only for a fully covered, reviewed sanitizer policy; an upload
request cannot enable that capability. Automatic approval must be signed by a
deployment-controlled key in an explicit allowlist over the exact artifact
and approval envelope; the ingest token alone is not sufficient.
- Sanitizing design-time artifacts does not sanitize live execution. Runtime
screenshots or observations that reintroduce PHI remain inside the declared
customer, BYOC, on-prem, or regulated managed boundary.

## Publication Order

1. Engine artifact policy and sanitized-derivative implementation.
2. Cloud live execution, production health, and billing.
3. Canonical product documentation and security architecture.
4. Website launch, checkout, and configured pricing surfaces.
5. Reproducible evaluation artifacts and failure taxonomy.
6. arXiv paper with methodology, identity/effect/refusal design, comparative
evidence, silent incorrect success, over-halt, limitations, and a
reproducibility checklist. Missing results must remain explicitly pending.
7. GitHub organization descriptions, pins, and lifecycle registry.
8. Repository archival and local relocation only after independent clean-tree,
credential, dependency, and worktree checks.

## Evidence Standard
# OpenAdapt Launch Contract

Last reviewed: 2026-07-27

This is the durable public acceptance contract, not a chronological project
plan. Current progress, metrics, and provider state belong in the private
operating status. The product is not organized around a browser-only freeze:
browser, native desktop, RDP, and Citrix/VDI are execution surfaces under one
governed qualification contract.

## Product Outcome

OpenAdapt turns a bounded demonstration into an inspectable workflow, executes
healthy runs without model calls, verifies the declared business effect, and
halts for review when authorization, identity, state, target, or effect cannot
be proven.

The public launch path must let a user:

1. Install the launcher or Desktop cockpit.
2. Record a browser, native, RDP, or Citrix/VDI workflow using the canonical
recorder for that surface.
3. Compile and inspect the workflow without editing internal JSON or Python.
4. Qualify risk, identity, effect strength, parameters, secrets, environment,
and representative fault cases.
5. Certify, seal, encrypt, version, and deploy the exact artifact.
6. Execute it in managed or customer-controlled infrastructure with the
required capabilities and data boundary.
7. Receive `VERIFIED`, `COMPLETED_UNVERIFIED`, `HALTED`, `FAILED`, or
`ROLLED_BACK` with evidence; Standard and Regulated profiles never treat
`COMPLETED_UNVERIFIED` as success.
8. Resolve attended decisions, validate repairs against the same qualification
contract, promote or reject them, and roll back versions.
9. Inspect evidence, usage, billing, and immutable artifact lineage.

Production mode must use real configured dependencies. Missing storage,
runner, callback, verifier, billing, or authorization dependencies must fail
closed and must never produce simulated success.

## Surface Contract

- **Browser:** Playwright-native recording retains DOM identity, source-time
secret redaction, field geometry, and ordered frames.
- **Native desktop:** `openadapt-capture` owns screen, input, timing, and
window-scoped capture; live UIA, macOS Accessibility, or Linux AT-SPI evidence
is retained at action time when available.
- **RDP and Citrix/VDI:** customer-controlled external black-box operation uses
the same window-scoped capture path with OCR, relational anchors, identity
regions, fresh-frame resolution, and two-phase consequential actuation. No
software inside the remote session is required.
- **Cloud:** managed browser execution and the proprietary control plane support
workflow, evidence, attended-operation, usage, and billing journeys.

Portable workflow intent remains separate from environment-specific bindings.
Every runner advertises its observation, actuation, identity, verification,
session, and security capabilities; admission refuses before actuation when the
selected runner cannot satisfy the artifact.

## Evidence Contract

- Comparative claims require at least three trials per task and condition.
- Results must name the task, environment, oracle, run count, failure taxonomy,
authoring effort, maintenance interventions, latency, model calls, cost,
silent incorrect success, over-halt, and recovery time.
- Mock, synthetic, analog, and real-application results must be labeled
separately.
- Code presence and a green UI are not evidence of a live remote execution.
- The arXiv paper and marketing pages may cite only checked-in, reproducible
results and must preserve the limitations disclosed by the engine.

## Scope Control

Launch only the backends that pass the complete gate. Other backends remain
visible with their measured maturity. Do not add repositories or unrelated
features before the launch gate passes. Do not move dirty, credential-bearing,
or registered-worktree directories into `_deprecated`.
- Results name the task, application, version, environment, oracle, run count,
failure taxonomy, latency, model calls, silent incorrect success, and
over-halt.
- Mock, synthetic, public-application, customer-qualified, and production
evidence remain distinguishable.
- A screen banner or model judgment alone cannot produce `VERIFIED` for a
consequential write.
- Artifact and live-observation privacy boundaries are evaluated separately;
compiling a recording does not make it safe to upload.

The public website, documentation, launcher, engine, Desktop, Cloud, repository
descriptions, and organization profile must describe this same product.
48 changes: 25 additions & 23 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,33 +1,35 @@
# OpenAdaptAI Organization Configuration

This repository owns the public organization profile and the lifecycle registry.
It does not change GitHub organization settings automatically.
This repository owns the public organization profile, lifecycle registry, and
the intended GitHub metadata for the repositories presented as the product. It
does not change GitHub organization settings automatically.

The cross-repository delivery sequence and acceptance criteria are maintained in
[LAUNCH_PLAN.md](LAUNCH_PLAN.md).
The durable cross-repository launch acceptance contract is maintained in
[LAUNCH_PLAN.md](LAUNCH_PLAN.md). Current execution state belongs in the
workspace `STATUS.md`, not in this public repository.

## Manual GitHub Actions

Organization owners should apply these settings after this branch is merged:

1. Set the organization description to: `Deterministic, governed automation for repeated work trapped behind GUIs.`
2. Change the `OpenAdapt` repository description to: `Beta launcher for openadapt-flow: compile demonstrated GUI workflows into deterministic, governed local replay.`
3. Change the `openadapt-flow` description to: `Canonical OpenAdapt engine: compile demonstrated GUI workflows, replay locally without model calls on healthy runs, and govern repair and refusal.`
4. Change the `openadapt-desktop` description to: `Experimental desktop authoring and teaching surface for OpenAdapt workflows.`
5. Change the `openadapt-cloud` description to: `OpenAdapt Cloud: managed execution of locally authored, attested browser workflows, with billing and structural reports.`
6. The currently observed pins are `OpenAdapt`, `openadapt-retrieval`,
1. Set the organization description to the `organization_description` value in
[`repository-lifecycle.yml`](repository-lifecycle.yml).
2. Apply the `repository_descriptions` values from that file. In particular,
the live `openadapt-desktop` description still advertises the superseded
screen-recording/training-data direction. The live `openadapt-agent`
description was already aligned when this file was reviewed.
3. Replace the currently observed pins (`OpenAdapt`, `openadapt-retrieval`,
`openadapt-evals`, `openadapt-grounding`, `openadapt-capture`, and
`openadapt-privacy`.
7. Pin these five public repositories: `OpenAdapt`, `openadapt-flow`,
`openadapt-desktop`, `openadapt-ops`, and `openadapt-evals`. Leave the sixth
slot empty rather than substituting an unrelated component. The cloud source
repository is private and cannot be a public organization pin.
8. The examples surface currently lives under `openadapt-flow/docs/showcase`;
do not link or pin a nonexistent `openadapt-examples` repository. Revisit the
empty slot only after a standalone examples repository actually exists and
carries an evidence-backed lifecycle label.
9. Apply the archive queue in [REPOSITORY_LIFECYCLE.md](REPOSITORY_LIFECYCLE.md) only after each repository has an archive notice and any dirty local work is preserved.
`openadapt-privacy`) with the exact `pinned_repositories` list. It keeps the
1.6k+ stars correctly attached to the overall `OpenAdapt` project while
putting the canonical engine and Desktop cockpit beside it.
4. The Cloud implementation repository is private and cannot be a public
organization pin. The documentation implementation is Internal and remains
reachable through the public docs link instead of occupying a product pin.
5. Apply the archive queue in
[REPOSITORY_LIFECYCLE.md](REPOSITORY_LIFECYCLE.md) only after each repository
has an archive notice and any dirty local work is preserved.

The current public organization tagline, `AI for Desktops.`, and several
repository descriptions are GitHub settings. Editing `profile/README.md` cannot
change them.
Organization descriptions, repository descriptions, and pins are GitHub
settings. Editing `profile/README.md` does not change them; an organization
owner must apply the machine-readable values after merge.
10 changes: 5 additions & 5 deletions REPOSITORY_LIFECYCLE.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# OpenAdapt Repository Lifecycle Registry

Last reviewed: 2026-07-15
Last reviewed: 2026-07-27

This public registry separates the product from experiments and records the
intended lifecycle of organization repositories. It does not authorize moving
Expand Down Expand Up @@ -30,9 +30,10 @@ The machine-readable source is [`repository-lifecycle.yml`](repository-lifecycle
|------------|-----------|------|
| `OpenAdapt` | **Beta** | Launcher/meta-package and unified CLI |
| `openadapt-flow` | **Beta** | Canonical compiler and governed runtime |
| `openadapt-desktop` | **Experimental** | Desktop authoring and teaching surface |
| `openadapt-cloud` | **Beta** | Hosted browser-workflow control plane, execution, billing, structural reports, and validated replacement activation; authoring and repair remain local |
| `openadapt-desktop` | **Beta** | Desktop cockpit for local recording, qualification, execution, evidence review, and governed repair |
| `openadapt-cloud` | **Beta** | Proprietary control plane for managed browser and customer-controlled execution, attended operations, evidence, usage, and billing |
| `openadapt-capture` | **Experimental** | Optional native recorder |
| `openadapt-agent` | **Experimental** | Local MCP and Agent Skills bridge for compiled, governed Flow workflows |
| `openadapt-privacy` | **Experimental** | Optional scrubbing component |
| `openadapt-types` | **Experimental** | Interoperability schemas |
| `openadapt-web` | **Internal** | Marketing website implementation |
Expand All @@ -43,7 +44,7 @@ The machine-readable source is [`repository-lifecycle.yml`](repository-lifecycle
|-------|--------------|
| **Research** | `openadapt-ml`, `openadapt-evals`, `openadapt-retrieval`, `openadapt-grounding`, `openadapt-verifier` |
| **Internal** | `openadapt-ops`, `openadapt-wright`, `openadapt-herald`, `openadapt-crier`, `openadapt-consilium`, `openadapt-presenter`, `openadapt-bootstrap`, `openadapt-telemetry`, `openadapt-viewer`, `openadapt-blog`, `openadapt-internal`, `openadapt-yc` |
| **Experimental UI/support** | `openadapt-console`, `openadapt-tray`, `openadapt-agent` |
| **Experimental UI/support** | `openadapt-console`, `openadapt-tray` |
| **Labs/forks** | `OmniMCP` (`omnimcp` locally), `SoM`, `PydanticPrompt` |
| **Historical directions** | `OpenAdapter`, `OpenReflector` |
| **Superseded** | `OpenSanitizer` (successor: `openadapt-privacy`) |
Expand All @@ -54,7 +55,6 @@ The machine-readable source is [`repository-lifecycle.yml`](repository-lifecycle
|------------|-----------|---------------|
| `openadapt-gitbook` | **Archived** | Keep an archive notice and route documentation traffic to `docs.openadapt.ai`. |
| `openadapt-new` | **Archived** | Keep read-only historical context and route product traffic to `OpenAdapt` and `openadapt-flow`. |
| `openadapt-agent` | **Experimental (repurposed v2)** | Agent-facing bridge: compiled `openadapt-flow` workflows exposed as MCP tools and Agent Skills; governed runs only. Legacy v1 at tag `v0.1.0`. |
| `OpenSanitizer` | **Superseded** | Add a successor notice for `openadapt-privacy`, then decide whether to archive. |
| `OpenReflector` | **Historical** | Decide Archive versus Labs before changing organization state. |
| `OpenAdapter` | **Historical** | Decide Archive versus Labs before changing organization state. |
Expand Down
Loading