Every websiteis a graph

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

Logins and session tokensMulti-step formsAutocompleteClosed shadow rootsCross-origin iframesFile uploadsDownloadsPopups and dialogsPagination loopsCAPTCHA hand-over

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.

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.

Königsberg, engraved by Matthäus Merian, c. 1650. Bibliothèque nationale de France, public domain. Over it, Euler's graph: the Kneiphof island (A), the two banks (B, C) and the eastern land (D), joined by the seven bridges.

How a website becomes a graph

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

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 it.

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" }}

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

An offline copy of the site.

From the recordings, Graphdom rebuilds the portal as a sandbox: every page and every response, served with the network off. A spider is tested here, against the tests derived from your experts' sessions, before it may touch the real site.

  • clock fixed at 2026-01-01 09:00
  • randomness seeded
  • locale en-GB, Europe/Amsterdam
  • responses from 38 recordings

The sandbox. Nothing leaves the machine; every answer comes from what was recorded.The real site. A spider gets here only with a passing report, and every real run becomes a new recording.

sandbox · level 2 · network off · illustrative

Every version ships with its proof.

A spider version is accepted only with a passing test report attached. A version that submits data also waits for a person to sign it.

  • Tests come from the recordings: what a correct run must do and return.
  • An approved version never changes. After an upgrade its tests run again in the sandbox, with no model, before its next real run.
  • The report travels with the version, so whoever approves sees the evidence, not the internals.
Test report No. GD-7F3A-0006
illustrative

Submit an import declaration

Spider v6 · portal.meridian-customs.example

Sandbox
level 2, network off
Tests
38 of 38 passed
Sessions
38 replayed, same payment
Effect
submit, approval required

Elena V., Operations
signed 2026-11-03

report sha256
7f3a 91c0 … c9e2

Approvedv6 · 38 / 38

When the site changes.

Portals change without telling you. Graphdom notices on its own, stops before anything is submitted, and its AI detects what changed and proposes the repair, unprompted. The only manual step is a person’s approval. Change the portal below and watch.

the address field, in the DOMdebounce 300 ms
  1. 01portalPortal changes
  2. 02AIAI writes the fix
  3. 03autoSandbox proves it
  4. 04youYou approve
In productionv5 · last run today 09:12

Everything passes.

38 of 38 checks passed on the real site this morning. Now the portal ships its next release.

Simulates the portal’s next release. From here, the AI takes over until approval.

Three ways to automate a portal.

Today a web portal is automated by a model that drives it, or by a recording that replays it. Graphdom is the third way: AI writes and repairs the automation, and never runs it.

Browser agent

A model reads the page and decides each click, on every run.

A model in every run
Yes, paid per run
Learns inputs, branches, loops
Guesses them each time
Same result twice
No
A repair is checked
Nothing to check
Runs on your servers
Rarely

Session recorder

One recorded session, played back the same way every time.

A model in every run
No
Learns inputs, branches, loops
No, one session
Same result twice
Until the page changes
A repair is checked
No, "self-healing" is a guess
Runs on your servers
Often

Graphdom

A program learned from many sessions, proved in the sandbox before it runs.

A model in every run
No, a plain program runs
Learns inputs, branches, loops
Yes, from tens of recordings
Same result twice
Yes, by design
A repair is checked
Yes, in the sandbox, with a report
Runs on your servers
Yes, the whole fleet

How many runs a month?

480,000 model calls a browser agent would make. A Graphdom spider makes none.

Worked out for a 24-step task like the import declaration: runs × 24, at least one model call per step for an agent. A spider is a plain program; only a small local decision model, behind hard checks, may help it choose.

Built for regulated work.

Importers, customs brokers and public bodies run on portals they don't own. Graphdom is built for the teams that answer for what those portals receive.

  • 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 stops the run and hands it to a person.

Bring us one task.

Name the site and what the task does. We record it with your experts, build the sandbox and show you the graph and the test report before anything runs on the real site.

Start a pilot

One site, one task, your experts.

What does the task do?

Tasks that submit data wait for a person to approve each new version.

Closed

We are not taking new pilots yet. Pilots open soon.