The cheapest moment to pre-fill a regulatory form is the second the resolution decision lands.

Resolution is the moment a case stops being open and the system of record needs the regulatory artifact written. In insurance, that is the moment a claim is adjudicated and a CMS-1500 or a FNOL update has to land in Guidewire or the carrier's policy admin system. In banking, it is the moment a Reg E or Reg Z dispute is decided and a provisional credit reversal plus the SAR/CTR thresholds have to be evaluated and filed in Jack Henry, Fiserv, or FIS. In healthcare, it is the moment a grievance or appeal is closed and the response form has to be entered in Epic or Cerner under the regulatory deadline. Pre-fill means the AI workflow is already populating the form when the human reviewer opens it, not afterwards.

Two reasons. The first is the regulator's deadline: Reg E gives a bank 10 business days to decide a dispute and provide written notice, a HIPAA grievance has to be acknowledged within 10 days and resolved in 30, a state insurance regulator can require a FNOL inside 24 hours of notice. The second is data quality: a clerk re-keying from a ticket two days after resolution introduces transcription errors that a downstream audit will eventually surface. Pre-fill at resolution time captures the values from the same record the decision was made against, with no hand-off layer in between.

Through whatever interface the resolution app already exposes. If the upstream system is a modern SaaS app, that is usually a webhook or a queue. If the upstream is itself a Win32 app (a green-screen claims adjudication system, a mainframe terminal, a custom tool the carrier built in 1998), the same accessibility-tree primitives that fill the regulatory form on the way out can read the resolved record on the way in. The workflow file declares both: the upstream read step and the downstream form-fill steps, and the executor runs them in order.

It is a single MCP tool called type_into_element, defined in apps/desktop/src-tauri/src/mcp_converter.rs at lines 2298 and 2460. The tool takes a structured locator and a string, walks the live Windows UI Automation tree to find the matching node, and either invokes EditPattern.SetValue or falls back to a Win32 keystroke simulation. There are no pixel coordinates and no image matching anywhere in the production executor. The same primitive types into Epic, Cerner, Guidewire, Fiserv DNA, Jack Henry SilverLake, FIS Profile, SAP GUI, and any AS/400 emulator that exposes a Windows accessibility tree.

The locator resolver in apps/desktop/src-tauri/src/focus_state.rs walks four strategies before giving up: the recorded automation id, the window handle plus bounds, the visible text content, and finally the parent window as a last fallback. Three of those four strategies do not depend on absolute position, so a routine UI tweak (a panel reorders, a button shifts down a row, the form gets a new tab) usually resolves through strategies one, two, or three. Only when all four miss does the step fail, at which point the runtime queues that one step for re-recording and emits a failure record into the deterministic trace. None of this involves a model call at runtime.

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 reviewer can verify that with a single ripgrep. The model only runs once, during the offline recording-processing pass, where it reads the captured event stream and writes a TypeScript file. After that file is checked in, the runtime is deterministic. That is what lets a compliance team sign off on the workflow itself, the same way they would sign off on a SQL stored procedure.

Through the TypeScript workflow file. 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). The what_was_typed field accepts a string literal or a reference to a value pulled from the upstream payload. A workflow that pre-fills a regulatory form receives the resolution record at the top of the file, names each value (claim_id, decision, provisional_credit_amount, etc.), and references those names in subsequent type_into_element steps. A reviewer can read the file and see exactly which upstream field landed in which downstream control.

Yes, and most regulated form workflows want that. The recording captures the natural review point in the form (the field that says 'review and submit' or the modal that asks 'confirm decision'). The workflow file leaves that step as an explicit human-in-the-loop pause: the runtime fills every field up to that point, opens the screen for the reviewer, and stops. The reviewer sees a populated form, validates it, and submits manually. The audit trace records the pause and the human action. That pattern is what makes regulators comfortable with pre-fill specifically, because the human signature still happens at the moment the form leaves the building.

The runtime captures the validation event from the application (UIA emits a property-changed event on most validation pop-ups), writes it to the deterministic trace, and stops the workflow at the failing step. The form is left in the state where the human reviewer can read the validation message, correct the upstream record or the form value, and either resume or restart the step. The trace shows exactly which value the runtime tried to write and which control rejected it. A naive form-fill that ignores validation pop-ups corrupts data in a way the audit team will eventually find; the deterministic-pause approach surfaces the problem at the moment it happens.

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 MCP tools (type_into_element, click_element, set_value, etc.) are documented there. The orchestration layer, the cloud workflow runner, the recording pipeline, and the no-code builder are commercial. A team that wants to wire resolution-time form-fill primitives into their own queue can build directly on Terminator without paying for the cloud product, and an auditor can read the Rust source that does the typing.