Lawpatch for engineers

Quickstart

Two ways in. The first is faster and is what most teams use: install the MCP server in the agent you already code with, hand it a pairing code, and let it do the setup and the first scan itself.

1. Sign in and create a project.
2. Add Lawpatch to your agent from /app/connect — one click for Cursor and VS Code, one line for Claude Code and Codex.
3. Copy the pairing code the same page shows and paste the sentence next to it into your agent.
4. The agent calls setup_project, which writes lawpatch.config.json (safe to commit) and stores the key in ~/.lawpatch/credentials.json, outside the repository. Then ask it to scan.

A pairing code lasts ten minutes and works once. Redeeming it is what mints the API key, so the code is worthless both before and after — which is why it is safe to paste into a chat, unlike a key.

Or set the repository up from the terminal:

# with a pairing code from the dashboard
npx @lawpatch/sdk pair ABCD-EFGH-JKMN

# or answer the questions yourself
npx @lawpatch/sdk init

npx @lawpatch/sdk scan --dry-run   # print exactly what would be sent
npx @lawpatch/sdk scan

The SDK needs Node.js 20 or later. Every command needs a Lawpatch account; there is no anonymous mode.

How the analysis works

Nine steps, seven of them agents. Each one is instrumented, so every report carries a trace of what ran, for how long and at what token cost.

The corpus is not prose: every decision carries its holding, the elements of the legal test as applied, the facts that would distinguish it, where it binds and whether it is still good law. That is what lets the analyst reason by analogy instead of by keyword.

CLI reference

Run it with npx @lawpatch/sdk <command>, or install @lawpatch/sdk and use the lawpatch binary. It looks for lawpatch.config.json from the current directory upwards, stopping at the repository root.

Masked scanning

Source code never leaves the machine in any mode, but the naming around it did: repository paths, route addresses, table and column names, the branch. Set "privacy": "masked" in the config (or LAWPATCH_PRIVACY=masked) and each of those is replaced with a stable pseudonym before the payload is submitted — src/lib/user.ts leaves as 430c9bf141/22076fe566.ts. The mapping stays in ~/.lawpatch/masks/ at mode 0600; lawpatch fix and the MCP server translate the report back, so your agent still reads real paths. The dashboard shows the pseudonyms and says the project is masked.

What stays is the legal substance: data classes, the vendors data reaches, route tags, detector messages and the dependency list — a controlled vocabulary, not anything internal. "strict" goes further and also drops line numbers, identifiers the manifest does not already name as public packages, and dependency versions — at the cost of findings that are harder to act on. A masked scan covers the whole project, because an area-scoped scan is checked server-side by path; set LAWPATCH_MASK_SALT as a CI secret if CI and laptops should agree on which file is which.

scan options

init options

--key, --markets EU,UK,US,TR, --model b2b|b2c|both, --sector, --description, --api-url (self-hosted deployments) and --yes (accept defaults without prompting).

Exit codes

0 when the command succeeded and no finding reached the --fail-on threshold; 1 for a threshold breach, a failed analysis, a missing or invalid key, or any other error.

Environment variables

lawpatch.config.json

Written by pair or init at the repository root. It holds no secrets and is meant to be committed.

{
  "$schema": "https://www.lawpatch.studio/schema/lawpatch.config.json",
  "projectId": "…",
  "context": {
    "markets": ["EU", "TR", "US"],
    "businessModel": "b2c",
    "sector": "fitness",
    "description": "Coaching app with AI-generated training plans",
    "audienceIncludesChildren": false
  },
  "exclude": ["legacy", "scripts/fixtures", "**/*.generated.ts"],
  "shareSnippets": false,
  "failOn": "critical"
}

context matters: the same code can be low-risk for a B2B tool and high-risk for a consumer app used by teenagers. Dependency folders, build output and names listed in .gitignore are skipped without being listed here.

Roles, access and project areas

Owners and admins manage the workspace. Developers can be limited to named projects and codebase areas; lawyers work from legal matters without seeing code; auditors have read-only access. Legacy members retain whole-project developer access.

Project areas are repository-relative globs such as src/payments/**. Define them on the project page or paste a CODEOWNERS file to preview one area per owner before saving. Findings outside every area remain visible only to whole-project readers.

lawpatch areas
lawpatch areas suggest
lawpatch scan --area payments --area billing
lawpatch scan --changed --base origin/main

A scoped scan sends only signals from those areas and is labelled with its scope in scan history. It updates each area's latest scan, but does not overwrite the whole-project risk score or data map.

Legal workspace

Each recurring finding becomes a legal matter that survives re-scans. Three agents write its brief in turn: a technical translator states what the software does as conduct and what each fact means in law, a legal analyst writes the memo — facts, issue, rules, application per jurisdiction, defences, conclusion, exposure, precedents and open questions, all without code — and reviewing counsel red-teams it. Counsel can take the matter, set a deadline, write structured requirements and either publish or send the solution for senior review, and can export the whole thing as a page to print or as Markdown, with every source credited.

When counsel publishes a solution, Lawpatch translates it into an engineering brief. The related finding and get_fix_brief then use that approved brief instead of the scanner's original remediation. Privileged drafts and internal notes never leave the legal workspace.

Governance, outside counsel and notifications

The audit log records membership, key, scan and legal-decision events without recording the text of privileged notes. Owners, admins and auditors see the full log; partners see entries for their projects. The dashboard can export the filtered view as CSV.

Outside counsel must have a project grant and an end date no more than 180 days away. Owners, admins and an in-house partner on those projects can invite or renew them. Expired access is refused by every API until it is deliberately renewed.

The notification bell is the in-app channel for assignments, approvals, published solutions, urgent or overdue matters and expiring access. Lawpatch does not send these notifications by e-mail. Owners can require two-step verification by role from Workspace security; enabling it requires an owner session that already used a second factor, preventing an accidental lockout.

API keys and credentials

• Keys look like olv_…, belong to one project, and are created by pairing or from the project page, where they can be listed, rotated and revoked. The server stores only a SHA-256 hash.
• The CLI and the MCP server keep keys in ~/.lawpatch/credentials.json (mode 600), per repository path, never in the repository. In CI, set LAWPATCH_API_KEY instead.
• A key is only sent over HTTPS (or to localhost), and only to the origin it was issued by, the hosted API, a loopback address, or an origin you name in LAWPATCH_API_URL. A cloned repository or a pull request whose config points somewhere else stops with an error instead of sending the key.

MCP server

The SDK includes an MCP server, so an agent can pair the repository, scan it, read the plan, check a precedent before making a change, implement a fix, mark it and re-scan to verify. The server starts whether or not the repository is paired yet: an unpaired repository answers every tool with the instruction to call setup_project instead of failing. Install it from Connect agents or:

npx @lawpatch/sdk connect cursor      # or vscode, claude, codex

# or by hand
claude mcp add lawpatch -- npx -y @lawpatch/sdk mcp
npx @lawpatch/sdk agents               # tell future agent sessions about Lawpatch
codex mcp add lawpatch --env LAWPATCH_PROJECT_ROOT=/path/to/repo -- npx -y @lawpatch/sdk mcp

Typical loop: check_connection → scan_project → get_scan_status until completed → get_plan → get_fix_brief (which carries counsel's decision, if there is one) → change the code → check_files → mark_finding → scan_project with the changed paths.

Two prompts come with the server and show up as commands in clients that support them (in Claude Code, /mcp__lawpatch__legal_review and /mcp__lawpatch__fix_top_risk): a full review that ends in the fix order, and fixing the first finding through to a re-scan. Agents can also read /llms.txt, which states what the SDK reads, sends and stores.

CI / GitHub Actions

On a pull request Lawpatch leaves three things behind: inline annotations on the exact lines, a sticky comment that is edited in place on every push rather than piling up, and a job summary. Add --fail-on high and the build goes red before the merge.

# .github/workflows/lawpatch.yml
name: Lawpatch
on: [pull_request]
permissions:
  contents: read
  pull-requests: write        # needed for the sticky comment
jobs:
  legal-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v5
        with: { node-version: 22 }
      - run: npx -y @lawpatch/sdk scan --comment --fail-on high
        env:
          LAWPATCH_API_KEY: ${{ secrets.LAWPATCH_API_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

The comment carries the risk score, what changed since the last scan (new / regressed / fixed), the top findings with the precedent behind each one and its source credit, and the recommended fix order. Without a pull request or a token, --comment is skipped and the job summary is still written. Annotations can be turned off with --no-annotations. Other CI systems work the same way with LAWPATCH_API_KEY and --fail-on; use --json to consume the result.

Programmatic API

@lawpatch/sdk is an ES module with TypeScript types. analyze() is the one-call path: it finds the config, verifies the key, scans locally, submits, waits and returns the findings.

import { analyze } from "@lawpatch/sdk";

const { scan, findings, riskScore } = await analyze({
  root: process.cwd(),                  // optional; defaults to the nearest config or repo root
  apiKey: process.env.LAWPATCH_API_KEY, // optional; defaults to the stored credentials
});

const blocking = findings.filter((f) => f.severity === "critical" && f.status === "open");
if (blocking.length) process.exit(1);

It throws when there is no config or key, when the key belongs to another project, or when the analysis fails. For finer control, use the client against the REST API directly:

import { LawpatchClient, LawpatchApiError } from "@lawpatch/sdk";

const client = new LawpatchClient(process.env.LAWPATCH_API_KEY!, "https://www.lawpatch.studio");

const me = await client.whoami();                        // { orgId, projectId, projectName, dashboardUrl }
const { findings } = await client.listFindings({ status: "open" });
const brief = await client.getFinding(findings[0].id);   // the full finding, including agentPrompt
await client.updateFinding(brief.id, "in_progress", "Moving the pixel behind consent");

const { results } = await client.searchPrecedents("session replay before consent", { jurisdictions: ["US"] });

try {
  await client.getScan("unknown");
} catch (e) {
  if (e instanceof LawpatchApiError) console.log(e.status, e.message); // 404 Scan not found
}

REST API

The SDK is a thin client over a JSON API you can call from anything. Base URL https://www.lawpatch.studio; every endpoint except pairing takes the project's key as a bearer token and acts only on that project.

curl https://www.lawpatch.studio/api/v1/whoami \
  -H "Authorization: Bearer $LAWPATCH_API_KEY"

Errors and limits

Errors are JSON with a human-readable message, { "error": "Scan not found" }, and the HTTP status says what kind: 400 invalid input, 401 missing, malformed or revoked key, 404 not found or not in this project, 413 payload too large, 426 the SDK making the call is a version Lawpatch no longer supports (update @lawpatch/sdk), 429 a limit was reached, 500 our fault. Limits apply per key:

Endpoints

{ "orgId": "…", "projectId": "…", "projectName": "Coach", "dashboardUrl": "https://www.lawpatch.studio/app/projects/…" }

{ "areas": [{ "id": "billing", "name": "Billing", "description": null, "paths": ["src/billing/**"] }], "grant": ["billing"] }

{ "scanId": "…", "url": "https://www.lawpatch.studio/app/projects/…/scans/…" }

{
  "id": "…", "projectId": "…", "status": "completed", "stage": "done",
  "riskScore": 62, "counts": { "critical": 1, "high": 2, "medium": 3, "low": 0 },
  "partialFailures": 0, "issueProgress": { "total": 6, "processed": 6, "incomplete": 0 },
  "error": null,
  "diff": { "new": [{ "id": "F-…", "title": "…" }], "regressed": [], "fixed": [] },
  "plan": [{ "findingId": "F-…", "why": "…", "batch": "consent layer", "dependsOn": [] }],
  "portfolioSummary": "…",
  "url": "https://www.lawpatch.studio/app/projects/…/scans/…"
}

{ "scanId": "…", "findings": [ /* Finding */ ] }

{ "status": "resolved", "note": "Session replay now starts after consent" }   →   { "ok": true }

{ "feedback": [{
  "matterId": "…", "findingId": "F-…", "title": "…", "severity": "high",
  "status": "published", "codeStatus": "detected", "assigned": true, "dueAt": null, "overdue": false,
  "solution": { "text": "…", "requirements": [ … ], "publishedBy": "…", "publishedAt": "…" },
  "engineering": { "status": "ready", "brief": { … }, "agentPrompt": "…" },
  "riskAcceptance": null, "questionsForEngineering": [], "updatedAt": "…"
}] }

{
  "mode": "semantic",
  "results": [{
    "id": "…", "title": "…", "citation": "…", "forum": "…", "jurisdiction": "US", "date": "2025-04-03",
    "url": "https://…", "holding": "…", "softwareLesson": "…",
    "elements": ["…"], "distinguishing": ["…"], "penalty": null,
    "treatment": "good-law", "verified": false, "similarity": 0.82,
    "attribution": { "text": "Source: …", "licence": { "name": "…", "url": "…" } }
  }]
}

{ "code": "ABCD-EFGH-JKMN" }
→ { "apiKey": "olv_…", "projectId": "…", "projectName": "…", "apiUrl": "https://www.lawpatch.studio",
    "context": { "markets": ["EU"], "businessModel": "b2c", … }, "dashboardUrl": "…" }

Security model

• What leaves your machine: rule ids, repo-relative paths, line numbers, safe tokens (package names, field names), dependency names/versions/licences, your project context and, only if enabled, masked one-line snippets. Never file contents. Credential files (.env, keys, credential JSON) are never opened, and anything shaped like a secret is withheld before sending.
• What we store: scan metadata (counts, languages, frameworks, branch/commit) and findings (file:line references plus analysis). Raw signals are held in memory during analysis and discarded.
• Model calls: OpenAI Responses API with store: false, or any OpenAI-compatible provider you configure. For contractual zero data retention, enable ZDR on the organisation your deployment uses.
• Spend and stability: every scan runs under a token ceiling and per-call timeout; an identical payload re-submitted within a day returns the existing report instead of paying for the same analysis twice.
• Sub-processors (default deployment): Vercel (hosting), Google Firebase / Cloud Firestore (database, auth), OpenAI (analysis).
• Keys: API keys are stored as SHA-256 hashes, can be rotated from the dashboard, and are scoped to one project.

Precedent corpus

A curated set of court decisions and regulator actions across the US, UK, EU, Türkiye and the ECtHR, each summarised as a holding and a concrete lesson for software teams and embedded for semantic retrieval. A weekly job ingests new decisions and enforcement actions from sources whose terms allow commercial reuse: US federal courts of appeals through GovInfo, the FTC, the CFPB, the ICO, the EDPB, EUR-Lex and the EU's Consumer Protection Cooperation network. Each precedent carries the credit its source's licence asks for. Machine-summarised entries are labelled until an editor verifies them, and an ingested court decision is marked as not yet checked for later appellate history. The counsel agent can only cite decisions that exist in the corpus; a citation guard removes anything else.

Limitations

• Static signals can miss behaviour configured outside the repository (tag managers, CMS, vendor dashboards).
• “Absence” findings (e.g. no cancellation flow found) may be false positives if the feature lives elsewhere — mark them as accepted risk.
• A scan's analysis has a time budget; a very large repository can finish with part of the analysis incomplete, which the scan reports.
• Lawpatch is not a law firm. Reports are risk analysis, not legal advice.