Compliance paperwork automation: the layer most articles skip

Why the category collapses two layers into one

Strip the marketing off and the phrase “compliance paperwork” covers two separate problems that share almost no tooling.

Layer one is the GRC layer. The compliance team has to prove to an auditor that the cloud systems are configured correctly, that vendors were reviewed, that policies exist, that controls are tested. Most of the inputs are available through APIs: AWS, GitHub, Okta, Workday, Jira. A platform like Vanta or Drata polls those APIs, files the responses as evidence, and assembles the report. The reviewable artifact is a collection of API responses plus generated policy documents.

Layer two is the system-of-record layer. The regulated record has to land in a specific application. A patient registration in Epic. A new account in Jack Henry SilverLake. A first notice of loss in Guidewire ClaimCenter. A vendor master record in SAP GUI. The application has a UI but often no documented API for the screen flow. The reviewable artifact has to be assembled from what the runtime actually did during the post: the click, the typed value, the verification that the next dialog opened, the screenshot of the saved state.

Both are real. Both produce paperwork. Both touch compliance. The rest of this page is about why the second one needs different tooling.

What auditors expect from each layer

The two layers produce different audit packs. A SOC 2 Type II evidence pack from a GRC tool is a folder of API responses and policy PDFs, time-stamped, with each control mapped to a piece of evidence. The reviewer’s job is to confirm the evidence is current, the policy was acknowledged, and the control was tested.

A regulated transaction posted into a system of record produces a different artifact. A KYC review at a community bank ends with a field changed in a customer record. A 12-month chart audit in a regional clinic ends with notes added to a patient encounter. A quarterly inventory reconciliation ends with line items moved between plants in SAP. The auditor wants to see who did it, when, what changed, and whether the system confirmed the change.

For a manual operator the answer is the application’s built-in activity log. For an automated workflow the answer has to come from the workflow runtime itself. That trace has to be precise, per step, and reproducible from the same input. If it is not, every audit becomes a debate about which row in the database came from a person and which row came from the bot, with no clean way to tell.

The trace you can actually verify, step by step

Here is the part most pages on this category never get to. When the Mediar workflow recorder converts a captured event into an executable step, it does not just record the click and the typed value. It attaches a set of post-conditions to the step, and the runtime enforces them on every replay. Those post-conditions are the spine of the audit trail.

The function that does this lives in apps/desktop/src-tauri/src/mcp_converter.rs, around line 110. It is called add_mcp_action_fields, and every step that goes through the converter receives the same shape:

Read the field names slowly. The two verify_* fields are slots for a post-condition selector: after the action, the runtime looks for an element that should now exist (or should have disappeared) and waits up to verify_timeout_ms for that condition to be satisfied. The include_tree_after_action and ui_diff_before_after fields, when enabled, capture a snapshot of the accessibility tree before and after the action, so a reviewer can see exactly which subtree changed.

For navigation steps the same converter also writes an expected_navigation block with the destination URL and a wait timeout. For application-switch steps it writes an expected_application_switch block naming the target application and process. None of this is best-effort: a step that does not satisfy its post-condition fails loudly, and the failure is recorded as a StepResult with status Failed and a duration in milliseconds.

What gets stored per execution

A workflow run does not vanish into a log file. The schema for every run is defined in supabase/migrations/20250630000001_create_workflow_executions.sql. The columns relevant to a compliance review are workflow_id, client_id, status, execution_params, results, execution_logs, screenshots, error_message, queued_at, started_at, completed_at, and execution_duration_seconds.

Inside that row, the StepResult sequence (defined in crates/executor/src/models/execution.rs) records, for every step, the step_id, tool_name, status, duration_ms, and retry_count. If a step retries because a dialog took an extra moment to render, the retry count is in the row. If the four-strategy match cascade fell back from automation id to parent window before resolving, that fact is recoverable from the execution logs. None of this is a marketing claim; it is the database schema.

Why the runtime cannot have an LLM in it

Determinism is the load-bearing claim. A regulator is not auditing a model. A regulator is auditing whether the same input always produced the same record. A probabilistic step in the runtime breaks that property: two identical claims can produce two different field values, two identical KYC packets can produce two different beneficiary records, two identical journal entries can produce two different account postings.

Mediar splits inference and execution at the workflow boundary. The model only runs once, during the offline recording-processing pass, where it reads the captured event stream and writes the workflow file. After that file is reviewed and checked in, the runtime is a Rust program executing the file step by step, calling the Windows UI Automation accessibility framework directly. There is no inference library loaded into the executor process.

A compliance team can verify this independently. The Terminator SDK is open source under MIT at github.com/mediar-ai/terminator. Clone the repo, run ripgrep on the executor crate at crates/executor for any of the common inference SDKs (gemini, claude, openai, anthropic, langchain), confirm zero hits, then run the runtime against a test environment and capture the trace. That zero is the architectural bet: the workflow file is the testable unit, the same way a SQL migration is the testable unit for a database change.

The honest counterargument

A determinism story is only useful if the underlying locator is stable. If the application UI shifts and the recorded automation id no longer matches, a deterministic runtime simply fails deterministically, which is not the same as succeeding. That is a real problem and it is what most discussions of pixel-based RPA stall on.

The mitigation is in apps/desktop/src-tauri/src/focus_state.rs, which walks four strategies in order: recorded automation id, window handle plus bounds, visible text content, and 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, a form gains a tab) usually still resolves through one of the earlier strategies. Only when all four miss does the step fail, and at that point the runtime queues the step for re-recording rather than guessing. That failure mode, loud and queueable, is what makes the trace honest.

The other honest limit is the application surface. Some Citrix-streamed legacy apps remote the screen as pixels and never expose an accessibility tree to the client. In that case the desktop agent has to run inside the Citrix session, which requires IT cooperation. Browser-only flows in modern SaaS are usually a better fit for browser-based agents than for desktop automation. Those are not failures of the architecture; they are the cases where a different tool is the right answer.

Where the two layers actually meet

Picture a regional bank running through a SOC 2 Type II audit while also onboarding 200 small-business customers a week. Drata pulls AWS, GitHub, and Okta evidence and produces the SOC 2 report. That report does not care how the customer record got into Fiserv DNA; it only cares that the access controls around Fiserv DNA exist. The customer record itself still has to land in the core system, and that is what the bank’s onboarding team does by hand on most days, taking the new-account form from PDF to PDF to screen eight separate times.

A Mediar workflow can do that post deterministically and produce the per-step trace with screenshots. Drata still owns the SOC 2 report. Mediar owns the per-customer audit trail. They sit next to each other in the audit pack on review day. Treat them as one tool and you end up either trying to make Drata do data entry into a green-screen (it cannot) or trying to make Mediar prove that AWS IAM policies are configured correctly (it should not).

The same shape repeats in healthcare (Vanta plus Epic), insurance (Sprinto plus Guidewire), manufacturing (Drata plus SAP GUI). The GRC layer and the system-of-record layer answer different questions and produce different artifacts. A page about compliance paperwork automation that addresses only one of them is silently picking a side.

Compliance paperwork automation, in detail