Nomos observes a person completing a multi-application Windows task, induces an executable program from what it observed, runs it deterministically, and repairs the program when the applications change underneath it. Deployed by Onpar Labs engineers, inside the client's perimeter, on the client's software.
A native agent in the interactive session captures six signals at once: input, application events, focus, the element under every action, the whole subtree at boundaries, and the screen at settle. Values are salted and hashed before anything reaches disk.
Five demonstrations with different data become one versioned state graph. What varies across runs is data; what does not is identity. The joins between applications are recovered from value equality, so the program is the data flow, not the clicks.
On a healthy run each step is a dictionary lookup, a settle wait, and one adapter call. No model, no network. When the application changes, a five-level ladder localizes, repairs, verifies against the system of record, and writes the repair back into the artifact.
Capture and replay are necessary. They are not the product. The product is what happens the morning after the vendor ships an update. The repair loop is the product.
Every step resolves the observed screen to exactly one node of the graph, with a score above threshold and a margin over the runner-up. When it cannot, the ladder climbs one rung at a time. Each rung is cheaper than the next, and a verified repair at any rung is appended to the artifact so the same break never costs anything twice.
Nomos emits a versioned state graph. Human-readable, git-shaped, reviewable by the client's own engineers. It is the deliverable, and it is where every repair accumulates. Nothing is learned into model weights.
workflow: purchase-voucher-from-portal version: 8 surfaces: s1: {lane: cdp, app: chrome, origin: "https://portal.vendor.co/*"} s2: {lane: pixel, app: tally.exe@3.0.1, probe: {uia_tree: absent, ocr: required, oracle: tally_xml}} params: invoice_no: {type: str, source: s1/n3 field "Invoice #"} amount: {type: money, source: s1/n3 field "Total"} vendor: {type: str, source: clipboard@e9, from: portal.vendor.co} nodes: n7: surface: s2 key: {lane: pixel, layout_sig: sha:9f2c.., chrome_ocr: ["Voucher Creation", "Purchase", "Ref"]} settle: dirty_area < 0.2% for 3 frames AND no StructureChanged 250ms edges: e19: {from: n11, to: n12} action: key(ctrl+a) target: [uia:AutomationId=btnAccept, anchor:label_right_of("Accept"), # heal-promoted, v8 pixel:region(0.82,0.94)] # last resort precondition: [foreground(s2), at(n11)] effect: COMMIT idempotency: {check: oracle.voucher_exists(${invoice_no}), on_true: skip} post: [oracle.amount(${invoice_no}) == ${amount}] evidence: [run1#44, run3#47, run5#46, heal:h44@v8] oracle: kind: tally_xml endpoint: http://guest:9000
Nothing in the world changes if it runs twice. The ladder heals it and promotes the repair the moment the oracle verifies it.
Typing into a form that has not yet been posted. Recoverable by clearing the field. Healed autonomously, promotion accepted.
Never healed autonomously. The model's only permitted response on a COMMIT edge is Abort. Before any re-execution the oracle is asked whether the effect already landed. If it did, the step is skipped, not retried.
A toast stealing focus mid-type is how an account number ends up in a chat window. The cheapest assertion in the system and the highest value.
The clipboard is global mutable state. Anything on the machine can stomp it between copy and paste, so the value is checked, never assumed.
The Healer receives parameter types, not data. It can only reference values already bound from source documents. It cannot hallucinate an amount.
Never in weights. Every repair is a readable patch with evidence attached.
Never per step. Model calls per run is the health metric, and it must decay.
Pixel hashing is a masked fallback lane, never the primary key.
Used for both observing and acting, so the player never sees an application differently from the recorder.
COMMIT is never healed autonomously. Safety is not bolted on afterwards.
Not the screen. A confirmation screen is exactly what a silent failure looks like.
Per-tenant persisted salt. Equality survives, content does not.
Six sensors, one shape, one timeline. Traces are comparable across runs and machines.
Only redacted derivatives leave the machine. The Healer can run where the raw data is not permitted to go.
Share of deliberately induced failures repaired unattended, against a mock that is broken in the same ways the real application is.
Must decay. A plateau means the application is changing faster than Nomos converges, which is information about that deployment.
Runs finished with no human involvement, verified by the oracle rather than by the final screen.
The true operating cost of the workflow, and the basis on which Nomos is priced.
From the first demonstration to a working, reviewable automation on the client's machine.
Nobody in the category publishes recovery rate under mutation. That absence is itself a signal.
Nomos runs on the client's Windows estate, against the client's applications, with the client's system of record as oracle. Onpar Labs engineers survey the surfaces, record the demonstrations, induce and mutation-test the artifact, and hand the client's team a program they can read. Nothing leaves the perimeter except redacted derivatives.
Every application is probed once: tree depth, staleness, API, whether OCR is required. Lane and oracle chosen per surface and written into the artifact.
The client's own operator performs the task five times with different data. The Recorder runs in their session; values are hashed before they touch disk.
The graph is induced, reviewed line by line with the client, and every COMMIT edge is assigned its oracle check before it is allowed to run.
Controls moved, labels renamed, dialogs inserted, a real vendor upgrade applied. Recovery rate is measured and reported before anything goes live.
The workflow runs unattended. Each verified heal is promoted and versioned. Model calls per run decay toward zero, and the client's engineers own the artifact.
Every Nomos deployment begins with an evaluation of the institution and its workflow. Five questions. If the workflow, the applications, and the system of record are real, Onpar Labs responds with a written view on whether it would deploy, and on what terms.