LexLint

Know the law where your app runs.

LexLint for legal teams

A developer at your organization has run LexLint, or is about to, and this page is what to know before you read what they hand you. LexLint is a lint in the sense engineers use the word: it runs where the software is built, catches the basic questions early, and routes everything that needs judgment to you.

It joins a path that already runs A vertical diagram of where LexLint sits in a path that already runs without it. Reading top to bottom: Developer, who writes the code; Code and database (already true today), stays on their machine; Coding agent (already true today), already reads that code, and the agent calls a cloud model; a boundary: LexLint joins here, only activities and jurisdictions cross; Findings (added by LexLint), cited, dated, written for two readers; The LexLint portal (added by LexLint), one run, kept where counsel can read it; Counsel, who decides what it means. Where LexLint sits It joins a path that already runs Developer Code and database Stays on their machine Coding agent Already reads that code cloud model LexLint joins here Only activities and jurisdictions cross Findings Cited, dated, written for two readers The LexLint portal One run, kept where counsel can read it Counsel
The path runs whether or not LexLint is in it. A coding agent already reads the repository, and the only thing that crosses to LexLint is the declaration: what the app does, and where it runs. What comes back is cited and dated, and it reaches you as a file you can read rather than as the developer's account of it.

What it is not

LexLint does not practice law, and it is built so that it cannot drift into practicing it. A finding is a research summary of a published instrument, with a citation and the date it was last checked against its sources. Findings are not legal advice, they create no attorney-client relationship, and they are never authorization to access any system. LexLint never calls anything "compliant". The word reaches its output only where a research summary describes how a law itself uses it, such as a statute that treats a business already meeting a stricter standard as compliant. Its passing state is "no basic issues found", and the legal conclusion belongs to whoever you designate to give one.

That boundary is conduct rather than a disclaimer. A relevant statute is a start and only a start, and the tool is shaped around that: it can say which obligations attach to what an app does and where it runs, and it stops there. Whether a duty reaches this product, whether an activity is permitted at all, what an unsettled posture means for a launch: those are routed to a lane named counsel, and nobody in the engineering workflow acts on them alone.

What a developer hands you

A run starts from a declaration: what the app does, chosen from a fixed vocabulary of activities, and the jurisdictions it runs in. Nothing else leaves the developer's machine. No source code, schema, or data is uploaded, and the declaration itself is a short file committed in the repository, so it is reviewable in the same place as everything else the team ships.

The run ends as three lists. Changes to make in code. Documents the repository should carry, such as a crawl policy or an AI-usage statement, drafted as the developer's own and marked as discharging nothing. And questions for counsel, each naming the instrument, its citation, its status and the date it was last checked against its sources, linked to a law note on this site that gives the plain reading: what the instrument is, when it took or takes effect, what it asks of an app, and the primary source it was read from. The conversation starts from that file rather than from an interview.

The one-sentence summary on each finding is written for the developer. The citation is written for you. A developer is not expected to parse one, and the law note behind it is the bridge between the two readings.

Your hands on it first

The declaration is a file in the repository, and nothing requires a developer to be the one who writes it. A legal team can author it before anyone runs the lint: the jurisdictions the company operates in, the activities the app performs, and the findings that are already acknowledged, each with who handles it and why. A developer who runs LexLint in that repository starts from your declaration, and every finding it raises is one you already scoped.

Changes to that file are ordinary changes, visible in the diff and subject to the same review as code. That is the whole mechanism today, and it is small on purpose. A configuration a legal team sets once for an organization, before its developers see the tool, is being designed; if you would want that, we would like to hear what it should contain.

Which bodies of law, and which not

LexLint reads a corpus of AI, scraping, privacy, cybersecurity, age-gating, and news-aggregation law. AI and scraping law are tracked across every country, US states, and the EU; privacy, cybersecurity, age-gating and news-aggregation law are researched jurisdiction by jurisdiction. A jurisdiction with no research at all warns rather than passing quietly, and so does a jurisdiction covered on other topics but not yet on one: the lint names the topic it has not researched there. The law page shows which jurisdictions each topic covers. Breach-notification duties that ride on personal-data law sit inside privacy; a duty about a product's own security, a vulnerability in it, or a security programme sits inside cybersecurity.

Cybersecurity coverage is new and still filling. The EU Cyber Resilience Act, the second Network and Information Security Directive, the United Kingdom's product-security statute, and the reasonable-security laws of the first US states are in the corpus. A jurisdiction not yet researched on cybersecurity returns a warning saying so rather than returning nothing. Communications and marketing law, accessibility law, and consumer-protection law are not covered at all. A lint says nothing about an area it does not hold, and the absence of a finding in one of those areas is not a pass. What is tracked, with counts read from the corpus at each build, is on the law page.

Whatever shape your department is

A software-law team with its own tooling will want the corpus more than the workflow: a finding on an instrument carries its citation and date, and the law notes are written to be handed on. A team of a few lawyers covering many engineering teams gets a complete file per app instead of an interview per feature. A single lawyer covering all of a company's technology risk gets triage: the few things to decide, separated from the many things already handled. And a general counsel's office with no technology lawyer gets a map of an area it has not had one for, with a plain reading of each instrument and a clear line that a finding is where a conversation with counsel in that jurisdiction begins.

If a finding is wrong

Tell us. Email hello@ungovr.org with the finding, the citation, and what you believe is wrong, and we will re-check the entry against its primary sources. LexLint is built by engineers and operators rather than lawyers, which the about page says in as many words, and corrections from people who practice in this area are how the corpus gets better. The questions developers ask are answered on their own page.