AI tools that pre-fill regulatory forms are easy to ship. Keeping the values they type out of your own logs is the hard part.

Two screens at once. There is the source document, which is usually a referral, a prior authorization PDF, an insurer denial letter, or a structured payload from a payer portal. And there is the destination form inside the system of record: a registration screen in Epic, a charge entry in Cerner, a claim in eClinicalWorks, an authorization screen in Salesforce Health Cloud. The pre-fill is the AI typing values from the source into the destination, in the right order, respecting the destination's validation rules. HIPAA does not care what the source looks like. It cares that the values typed (MRN, DOB, diagnosis codes, insurer member id) never appear in a place a non-treatment-team person can read them. That is what makes the runtime mechanism more important than the marketing posture.

The same shape, with a different threat model. The values are now data subjects' names, addresses, dates of birth, telephone numbers, and identifiers a regulator can tie back to a person under Article 4(1). For a pharma post-market safety team, the destination form is a vigilance case in Veeva Vault Safety or ArisGlobal LifeSphere, or an EudraVigilance E2B(R3) submission. For customer service, it is a CRM record, a refund authorization, or a regulator-facing complaint log. GDPR adds two specific demands: data minimization (Article 5(1)(c), only type the fields you actually need) and the right to be forgotten (Article 17, the data subject can ask you to erase the values that landed in the destination system). A pre-fill tool that keeps copies of the typed values in its own logs creates a second erasure surface the data controller now has to manage.

By redacting them in the executor, before the workflow output is persisted. The function is redact_secrets_from_output in crates/executor/src/services/secrets.rs. After the workflow runs, the executor takes the JSON output, walks every string recursively, and replaces any occurrence of a known secret value with the marker [REDACTED:SECRET_NAME]. The version that lands in the dashboard, the audit store, and ClickHouse is the redacted one. The original ciphertext stays in the org_secrets Postgres table where it started, encrypted under AES-256-GCM with a 96-bit nonce.

False-positive safety. If the org defines a one-character or two-character secret value (a status code, a Y/N flag), the redactor would otherwise greedy-match every character in the output that happened to equal it, turning every J into [REDACTED:STATUS]. The four-character floor is a pragmatic guard. For the regulatory values that matter (MRNs, member ids, tax ids, NPIs, EU national identifiers, claim numbers, policy numbers, device serial numbers), the floor is well below the natural length, so the redaction triggers reliably.

Nested secret values. Imagine a workflow that uses two secrets: PATIENT_NAME = "Maria" and PATIENT_FULL_NAME = "Maria Garcia". Without the sort, an unlucky pass order would replace "Maria" first, leaving the output reading "[REDACTED:PATIENT_NAME] Garcia" and never matching the longer secret at all. By sorting secrets by length descending and substituting the longest first, the redactor handles the full name as a unit and the shorter secret never has a chance to partial-match. A reviewer verifies this on github.com/mediar-ai/terminator with a single ripgrep.

No. The production executor crate at crates/executor in github.com/mediar-ai/terminator has zero references to gemini, claude, openai, or any inference library. A compliance reviewer can verify that with one ripgrep. The model only runs once, during the offline recording-processing pass that authors the workflow file. After the file is checked in, the runtime is deterministic. That is what lets a healthcare compliance officer or a pharma quality lead sign off on the workflow itself the way they would sign off on a SQL stored procedure.

The locator resolver in apps/desktop/src-tauri/src/focus_state.rs walks four strategies before declaring a step failed. It tries the recorded automation id first, then the window handle plus bounds, then the visible text content, then the parent window as a last fallback. Three of those four strategies do not depend on absolute screen position, so a quarterly UI tweak (a panel reorders, a tab gets renamed, a dialog gains a row) usually resolves through strategies one through three. If all four miss, the step fails into the deterministic trace and a human queues that step for re-recording. Nothing is silently retried with a different element.

The TypeScript workflow file is the artifact that defines minimum necessary. Each step has the eight-field semantic record (step_title, user_intent, what_was_clicked, what_was_typed, target_element, parent_window, screenshot_id, side_effect_observed). A privacy officer reads the file the same way they would read a SOP. If the workflow types a diagnosis code into a billing system, the privacy officer sees that step and can challenge it. If the workflow types only the policy number into a claims system, that is also visible. The audit artifact is code, not a black-box model trace.

Two surfaces matter. The first is the destination system of record (Epic, Veeva, Fiserv): erasure there is the system owner's responsibility and is unaffected by Mediar. The second is the workflow execution log itself. Because redact_secrets_from_output replaces every typed regulated value with [REDACTED:NAME] before the log is persisted, an Article 17 request does not require purging Mediar's audit store of values that were typed; the values were never written there in the first place. The ciphertext in org_secrets is what an erasure request operates on, and that row can be deleted by org admins through the standard secrets API.

Part 11 cares about who did what, when, and whether the record can be modified after the fact. The TypeScript workflow file plus the deterministic execution trace give a Part 11 reviewer two of those for free: who (the user that triggered the run, captured at the orchestration layer) and what (the eight-field semantic record per step). The third, immutability, is a property of where the trace is stored, not of the runtime. Most teams write the trace to an append-only ClickHouse instance and gate write access behind a separate role. The trace contains the redacted values, so a Part 11 review of a vigilance case pre-fill in Veeva Vault Safety can run without exposing patient identifiers to the reviewer.

Those tools auto-draft answers in vendor security questionnaires, RFPs, SIG, CAIQ, NIST 800-171. The destination is a SaaS questionnaire portal with HTML inputs. They do real work and pair well with Mediar, but they do not type into the system-of-record forms a regulator audits in healthcare, finance, or pharma. Treating the two as the same product is the most common category mistake a compliance team makes when shopping for this. The pairing pattern is straightforward: questionnaire AI handles the SIG a prospect sends, system-of-record automation handles the SOX, HIPAA, NYDFS, GDPR, or 21 CFR Part 11 evidence trail that has to be written back into Epic, Fiserv, Salesforce, or Veeva.

The execution layer is. The Terminator SDK that performs the UIA calls and the four-strategy element resolution is published as terminator-rs on crates.io and lives at github.com/mediar-ai/terminator under MIT. The redact_secrets_from_output function in crates/executor/src/services/secrets.rs is in scope. A compliance team can clone the repo, run cargo test on the redact_recursive tests, and confirm by reading the source that no LLM is called between the typed value and the log write. The orchestration layer, the cloud workflow runner, and the recording pipeline are commercial.