DEV Community: Erik Svensson

What's actually lawful when you train a vision model on document layouts?

Erik Svensson — Sun, 08 Nov 2026 06:17:44 +0000

This is a legal and architecture question, not a "how do I scrape a bank" question. At Landvex we need a reference library and training material for document review in Europe: layouts, issuer markers, typical fields. Not customer files.

I'm trying to understand where the lines really are, because the folklore around "if it's on a public website we can train on it" seems… optimistic!?

Points I'd like to hear how other teams have handled, ideally with something more concrete than vibes:

Official specimen pages and published examples. Some government or document libraries explicitly forbid reuse in a product. Does "I only extract layout features or embeddings, I don't ship the images" change anything, or is that wishful thinking?
Copyright in the look of a bank statement or an employment certificate template. Who even owns that, and does it matter if the model never reproduces a full page?
Training on customer-submitted documents, even with a contract. Purpose limitation, storage limitation, the right to erasure — can a model trained on someone's statement ever really forget them?
Synthetic data generated to resemble a real issuer's layout. Is imitating a protected template for training its own problem?
Keeping an audit trail: source, date fetched, licence, whether personal data was present, and a way to drop an item from future training runs if the legal basis disappears.

I'm not asking anyone to be our lawyer, and I'm not looking for ways around terms of service. I want to hear how people have designed the corpus so a later audit doesn't fall apart.

What did you decide you would not train on, and why?

Synthetic documents vs real specimens for training a document detector?

Erik Svensson — Sun, 08 Nov 2026 06:16:44 +0000

We're collecting a reference holding at Landvex and also planning heavier YOLO training. I'm uneasy about training on anything that looks like a real customer's file, and some official specimen libraries are pretty clearly not meant for reuse in a product.

So… has anyone had luck training primarily on synthetic documents — generated layouts, varied stamps and seals, phone-photo augmentation — and using a small, carefully licensed set of genuine public specimens only for evaluation?

A few things I'm stuck on:

How close does synthetic need to be before the model just learns the generator?
Do you still need confirmed forgeries in the training set if the model's job is to find objects, not to classify fake vs real?
Any practical way to keep provenance on every training image: source, licence, whether it ever contained personal data?

Curious what's actually worked, including the boring failures.

When do you lock the evaluation set?

Erik Svensson — Sun, 08 Nov 2026 06:11:23 +0000

At Landvex we're about to scale collection and annotation across several document families, mixed image and file inputs. The obvious failure mode is multiplying training material first, then discovering the test set was contaminated — or that "accuracy" was measured against a binary genuine/fake label we no longer believe in.

I'm leaning toward: define the ground truth per family, lock a held-out test set before we scale annotation and GPU training, and only then measure whether more data actually moves the dimensions we care about.

Does that match how you've seen high-stakes document or KYC systems do evaluation? What did you lock besides the files themselves — the label schema? Annotator instructions? The exact questions the model is scored on?

Also slightly paranoid about test items leaking back into reference examples that reviewers can see. How do you keep those walls up in practice?

Collecting a reference library of genuine document layouts — scrape, partner, or buy?

Erik Svensson — Sun, 08 Nov 2026 06:10:36 +0000

At Landvex we need a reference holding of what genuine document families look like: bank statements, employment certificates, invoices, and some ID/travel documents used in Europe. Not customer files. Layout, issuer markers, typical field structure. Receiving country and issuing country are often not the same, which already makes "just scrape one national portal" pretty useless!?

What's actually worked when the material has to be lawful and auditable?

A few points I'm turning over:

Public official specimens versus anything that looks like a customer document
Is scraping those public pages even the right architecture, or do you start with data partnerships and treat crawlers as a last resort?
How do you store provenance so a later reviewer can see where a reference came from, when it was fetched, and under what licence? Some official libraries are explicitly not for reuse in a product.
Layout fingerprints versus storing full page images. Full images are easier to train on, and a lot more legally awkward.
Rate limits, robots.txt, and portals that redesign their HTML every quarter — is a scraper maintainable compared to a small set of official download endpoints you actually monitor?

I'm specifically not looking for tips on grabbing customer bank files or bypassing logins. That's a hard no. The question is how people have built a clean, traceable reference corpus for document review without walking into a copyright or ToS problem.

What would you do first if you had to stand this up properly?

Four different "document problems" — separate types in the data model?

Erik Svensson — Sun, 08 Nov 2026 06:04:01 +0000

At Landvex we've been lumping too much under "forged". In practice I keep seeing four different situations:

A wholly fabricated document
A genuine document that was later altered
A genuine document whose content was already false — the issuer wrote something untrue
A genuine, unaltered document used in a misleading way

Only the first two are classic forgery. The last two can sail through any vision model and still be exactly what a bank or authority gets wrong.

So… do you model these as first-class problem types from day one? Or start with visual/file integrity and bolt the rest on later?

Also: for 3 and 4, the system can't really decide from the file alone. You need external checks, case context, sometimes a human. How do you keep the API honest about that, instead of pretending a model "scored" something it never saw?

Curious whether this taxonomy matches what others use, or if we're over-splitting.

Is it a mistake to expose an overall "authenticity %" for document checks?

Erik Svensson — Sun, 08 Nov 2026 06:02:17 +0000

At Landvex we're building a review engine for documents that banks and similar recipients use as decision support. Origin-of-funds evidence, invoices, employment certificates — not a toy "is this PDF fake?" score.

The more we dig, the less a single genuine/fake flag, or a 0–100 number, makes sense. A file can be visually intact but issued by nobody real. It can be a genuine bank file whose content is wrong. It can be genuine, unaltered, and still used for the wrong purpose.

So we're splitting the answer into separate dimensions: image/file integrity, origin, authority to issue, validity, factual claims, and linkage to the case. Each one can be verified, a deviation, or unclear. No rolled-up authenticity number.

Two things I keep getting stuck on:

Clients will invent a score anyway if we don't give them one. Is that an argument for a carefully caveated summary… or for making a single score painfully impossible?
How do you keep a six-answer report readable for someone who just wants to know "can I rely on this?" without lying to them?

Anyone shipped something in this neighborhood? What broke in the UX?