Reference pages link to committed OpenAdapt examples for named open-source applications in the openadapt-flow repository. Published results name the oracle and its limits. The historical OpenEMR add-note comparison uses saved-row OCR and says so. Pattern pages describe workflow shapes that you compile from your team's recording.
A card shows trial counts only when its source publishes them. Every published number cites its source. Cards marked “evidence in progress” make no performance claim.
HealthcareMeasured referenceBrowser
Automate patient triage note entry
The canonical OpenAdapt tutorial: a nurse’s triage-note workflow demonstrated once in a synthetic clinic app, compiled into a deterministic local program, and replayed with the note text as a parameter — including the policy gate that refuses to certify it for clinical writes.
18 trials3 VERIFIED / 15 expected halts0 silent incorrect successes0 over-halts0 model API calls per run4.71 s median verified run
View template →
HealthcareMeasured referenceBrowser
Automate patient record creation in OpenEMR
A complete synthetic patient is created from structured demographics on a pinned local OpenEMR 8.0.0.3 fixture. The run returns VERIFIED only when a separately authenticated REST readback agrees with a direct SQL read and a non-target table-delta audit - the screen never certifies its own write.
3 trials3 VERIFIED / 0 expected halts0 silent incorrect successes0 over-halts0 model API calls per run59.8 s median run
View template →
HealthcareHistorical field resultBrowser
Automate patient note entry in OpenEMR
A historical 18-step add-patient-note comparison on the shared OpenEMR public demo. The field result was judged from retained final frames by saved-row OCR, not by an independent read of the stored record.
20 trials19 Saved-row OCR passes / 1 halted runSilent incorrect successes: Not measured in this historical resultOver-halts: Not measured in this historical result0 model API calls per run
View template →
LendingMeasured referenceBrowser
Automate loan application entry in Frappe Lending
The lending reference: a loan application entered once on Frappe Lending, compiled into deterministic local replay, and accepted only when a separately authenticated read-only REST read agrees with direct SQL field readback and an exact table-delta contract.
6 trials6 VERIFIED / 0 expected halts0 silent incorrect successes0 over-halts0 model API calls per run
View template →
InsuranceMeasured referenceBrowser
Automate health insurance claim intake in openIMIS
The insurance reference: a health-facility claim entered once in openIMIS — the open-source system used by national health-insurance schemes — compiled, and replayed with a fresh claim number, with success established only by a direct SQL read of the claim row.
3 trials3 VERIFIED / 0 expected halts0 silent incorrect successes0 over-haltsModel API calls per run: Not measured
View template →
InsuranceMeasured referenceBrowser
Automate insurance eligibility enquiries in openIMIS
The same compiled browser workflow - insuree number in, coverage answer out - run six fresh times against openIMIS 25.10 with synthetic data. When read-only SQL confirmed the policy state, all three runs returned VERIFIED. When SQL returned Ineligible where the declared effect required Eligible, all three runs halted instead of trusting the screen.
6 trials3 VERIFIED / 3 expected halts0 silent incorrect successes0 over-halts0 model API calls per run19.7 s mean run
View template →
Back-office operationsReference implementationBrowser
Process a batch worklist with one demonstrated workflow
The committed loop bundle wraps the real 18-step OpenEMR recording in a LOOP that runs the demonstrated body once per record of a CSV worklist, binding each record's note column to the workflow parameter. The default healthy replay iterates deterministically and makes no generative-model API calls. Every iteration re-runs the same identity gate and effect verifier. It returns VERIFIED only for a proved result, halts before an unsafe action, or returns RECONCILIATION_REQUIRED when delivery might have occurred but the effect cannot be proved.
View template →
Back-office operationsEvidence in progressNative desktop
Automate native desktop application data entry
Data entry into a Windows, macOS, or Linux desktop application - demonstrated once by your team through the native interface, compiled, and replayed with per-record parameters. The runtime resolves targets from native accessibility evidence plus retained visuals.
Evidence in progress. The native execution surface is described on the product surfaces page, but we have not yet published per-workflow trial counts for a desktop-application template. This card makes no performance claim; when qualified evidence exists it will be published here with the same structure as the proven templates.
Back-office operationsEvidence in progressRemote (RDP/Citrix)
Automate updates inside hosted RDP and Citrix applications
A record-keeping update inside an application that lives on a managed remote desktop or Citrix session - driven from the local client window from outside the session, so nothing is installed inside the managed environment. Pixels, keyboard, and mouse carry the same identity and result checks as local surfaces.
Evidence in progress. The external remote lane is qualified today against a deterministic stand-in and a real FreeRDP round trip; a real ICA/HDX environment is qualified per customer before consequential use. No workflow-level trial counts are published yet, so this card makes no performance claim.
Back-office operationsEvidence in progressBrowser
Route exceptions to one authorized human decision
A cross-application workflow that pauses at an approved policy choice, asks one authorized person one clear question on their phone, re-checks the live application after the answer, and only then continues to the verified result. The public Cloud demo shows all six pause types with synthetic data.
Evidence in progress. The pause-and-decide mechanics are demonstrated end to end in the public Cloud demo (six pause reasons, synthetic tasks, runner receipts), but no per-workflow trial counts have been published for this template shape. This card makes no performance claim.
DentalPattern for your recording
Automate dental insurance eligibility checks
Check a patient’s coverage in the payer portal, then carry the answer into the PMS, a worksheet, or the schedule. Your team records and qualifies each execution surface it uses.
View template →
InsurancePattern for your recording
Automate insurance eligibility and coverage checks
For agencies, billers, and back-office teams: the repeated carrier-portal lookup — member or policy number in, coverage answer out — demonstrated once, compiled into a deterministic program, and replayed per case with halting instead of silent wrong answers.
View template →
HealthcarePattern for your recording
Automate new patient record entry
Registration and intake re-keying — demographics from a referral, a form, or an existing structured source entered into the EMR or PMS — demonstrated once by your team, compiled, and replayed per patient with the fields as parameters.
View template →
Back-office operationsPattern for your recording
Automate report exports and verify the file actually arrived
The scheduled export nobody trusts: run the report, download or drop the file, and — the part the screen can’t prove — verify that exactly one conforming file actually landed, with the right name, a plausible size, a fresh timestamp, and optionally the exact expected content.
View template →
Have a workflow that isn't here?
If your team does it the same way every time in a browser, a Windows application, or a remote desktop, it is a candidate. Bring one repeated workflow and the record that proves its outcome.