Every website
is a graph.

Graphdom learns a task on a website from the people who do it every day, rebuilds the site offline, and turns the task into a program that must pass its tests there before it touches the real site.

See it work Why a graph

Learns from your experts, in their own Chrome

Proves in an offline copy of the site

Runs as a plain program, with no model

Repairs itself, a person approves

In 1736, a city became a graph.

Königsberg had seven bridges and an old puzzle: can you walk through the city crossing each one exactly once? Leonhard Euler proved you can’t, by drawing the city as four dots and seven lines.

Engraved bird’s-eye map of Königsberg in the 17th century, the river Pregel dividing the city around the Kneiphof island — A website is a city of the same kind. Its pages and elements are the places, and what people do on them are the bridges. Graphdom draws that graph from your experts’ own sessions.

A
the Kneiphof island

BC
the two banks of the Pregel

D
the eastern land

seven bridges, seven edges

Königsberg, engraved by Matthäus Merian, c. 1650. Bibliothèque nationale de France, public domain. Over it, Euler’s graph.

How a website becomes a graph.

Four steps, on a real kind of task: an import declaration on Meridian, a fictional customs portal.

A page is a tree.

Every page your experts open is a DOM: a tree of elements. Graphdom records it at every action, inside closed shadow roots and cross-origin frames too.

A session is a path.

A recording is a walk through those trees: what was typed, what was chosen, what was clicked, and which request answered. Session 07 has 418 events, and the duties on screen are traced back to the request that carried them.

Many paths make a graph.

Thirty-eight sessions by five experts don’t all go the same way. Where they part is where the inputs, branches and loops are: five attached a certificate of origin, three went back to fix the address.

The graph is the program.

Graphdom keeps the graph as a spider: a JSON program you can read, diff and review. It runs on Graphdom’s runtime, or compiles to a Playwright script.

spiders/import-declaration.v6.json

{  "id": "address",  "do": "choose",  "effect": "read",  "target": "address",  "query": { "input": "address" },  "cadenceMs": 90,  "option": "suggestions",  "commit": "click",  "match": { "rule": "address-eu" }}

// compiled from spider v6, step "address"const field = page.getByRole('combobox', {  name: 'Consignee address' });await field.pressSequentially(input.address, {  delay: 90 });const pick = matchAddressEu(input.address);await page.getByRole('option', {  name: pick }).click();await expect(field).toHaveValue(pick);

One node of seven: “choose Address”. Hover or focus here to find it in the graph.

From one expert’s session to a program you can sign.

These are the screens of Graphdom Studio, redrawn on the same customs task. Press play, then follow the task from tab to tab.

portal.meridian-customs.example/Submit an import declaration/session 07 Local archive

Session 07

418 events · 2:47 · expert 3 · recorded over CDP

0:00 / 2:47

MERIDIANDeclarationsTariffAccount/login

Pages

Actions

Network

Console

38 sessions · 5 experts · a few shownWhere sessions differ, Graphdom found an input. Where some skip a step, a branch.

Drift detectedrun 4,812
AI proposes a fix3 tries offline
Sandbox proves it38 / 38
A person approvesthe one manual step

Stopped before submit. Nothing was sent.

The portal shipped a release overnight. The page looks the same, but the address field moved into a closed shadow root, and the spider stopped at the first check that failed.

form#declaration x-address #shadow-root (closed) input · Consignee address button · Calculate duties

spider v5 → v6proposed · not applied

Watching the portal…

Record

An expert does the task in their own Chrome. Graphdom keeps every action, the element it touched and the request that answered it.

AI writes the automation. It never runs it.

Today a portal is automated by a model that drives it, or by a recording that replays it. Graphdom is the third way: what runs is a plain program, and it ships only with its test report attached.

Question Browser agentA model reads the page and decides each click, on every run. Session recorderOne recorded session, played back the same way every time. GraphdomA program learned from many sessions, proved offline before it runs.

A model in every runYes, paid per runNoNo, a plain program runs

Learns inputs, branches, loopsGuesses them each timeNo, one sessionYes, from tens of recordings

Same result twiceNoUntil the page changesYes, by design

A repair is checkedNothing to checkNo, “self-healing” is a guessYes, in the sandbox, with a report

Runs on your serversRarelyOftenYes, the whole fleet

Portals change without telling you. The loop closes on its own.

Graphdom notices the drift, stops before anything is submitted, and its AI detects what changed and proposes the repair, unprompted. The sandbox proves it with the same tests. The only manual step is a person’s approval.

RecordExperts do the task. Every session is kept locally.
GraphSessions align into inputs, branches and loops.
SpiderThe graph, kept as a JSON program you can diff.
SandboxNetwork off, clock fixed, responses replayed.
ApproveA person signs the version that submits data.
RunOn the real site. Every run is a new recording.

Built for the teams that answer for what a portal receives.

Importers, customs brokers and public bodies run on portals they don’t own. Graphdom runs where their data already is.

On your servers
Recordings, sandboxes and the fleet run on your own infrastructure.
Nothing else to audit
Node.js standard library and Chrome. No third-party runtime packages.
No model at run time
A spider is a plain program: same site, same inputs, same result.
Passwords never stored
Secrets are injected at run time and never written to disk.
Approval before submit
A version that submits data waits for a person’s sign-off, report attached.
A person, not a guess
A CAPTCHA or new terms stop the run and hand it to a person.