Glossary | PatchLabs docs

Glossary

The words you’ll meet in reports and these docs, in plain English. Engineers will know most of them; founders shouldn’t have to.

A

Anonymous visitor (anon): Someone using your app without signing in. In the lab, the identity that uses only your public anon key. If it can read personal data, so can anyone on the internet.
Anon key: Supabase’s public API key. It is built into your frontend, so treat it as known to everyone. It’s meant to be public; your policies are what keep data private.
app_metadata: Per-user data in Supabase Auth that only a server with the service role key can change. The right place for a role. Compare user_metadata. Guide.
API key (PatchLabs): A pl_live_… key for one workspace, used by CI, scripts and the MCP server. Shown once, stored as a hash, revocable. More.
App: A repo you monitor in a workspace. Verified once, then re-checked on a schedule. More.
Approve: A decision that says “this is a real leak; we’re applying the fix”.

Badge: A small dated image for your README showing your app’s latest result. Off until you turn it on. More.
Business question: A plain-English question in a report that only the owner can answer, such as whether sellers’ emails should be public. Comes with a recommended answer. More.

Check: One run of the lab against your repo: rebuild, probe, fix, prove, plus the key scan. Ends with a report and a receipt.
Client label: A short name on an app, such as the client it belongs to. Shown in the dashboard and every alert.
Code (PatchLabs Code): The product line that reads your repo without running it: keys in code and history, Edge Functions, webhooks, CORS, admin checks, raw HTML, Firebase rules and dependencies. Its findings carry a file and line, and are not lab-proven. More.
Coming: A finding ID with a published page that PatchLabs does not test for yet (currently PL-012 to PL-016). It won’t appear in a report until it ships.

Decision: A recorded approve or reject on a finished check, with who, when and why. Included in the signed receipt.
Default branch: The branch GitHub shows first, usually main. Verification and every check read this branch.
Diff: What changed between an app’s last two checks: new leaks, fixed, still leaking, and marked as intended.
Dependency finding: PL-023: a package version in your lockfile that matches a published advisory in the OSV database. Its severity comes from the advisory.

Ed25519: A widely used digital signature scheme. We sign receipts with it so anyone can check them against our published public key.
Edge Function: Server-side code in a Supabase project (Deno), in supabase/functions. The right home for secret keys, as long as it checks who is calling. Guide.

Finding: One problem in a report, in a fixed shape: ID, line, severity, object, file and line, evidence, whether it was proven, and the fix. The fields.
Finding ID: A stable code for a kind of problem, from PL-001 (anyone with the public key can read personal data) to PL-026 (any website can call a signed-in function). Lab IDs are PL-001 to PL-008; Code IDs are PL-009 to PL-011 and PL-017 to PL-026; PL-012 to PL-016 are coming. IDs never change meaning. The index.
Fix: A SQL migration (plus any code change it notes) that closes a leak. Called a proven fix once it passes the lab proof.
Fix (PatchLabs Fix): The product line that writes the migration, proves it in a fresh lab, asks your business questions and waits for your engineer to approve. More.

Key scan: The part of a check that looks for exposed AI, payment and database keys in your code and its full git history.

Lab: A disposable local Postgres that copies Supabase’s roles, auth functions and default grants. We rebuild your database in it from your migrations, test it, and throw it away. It never touches your live app. PatchLabs Lab is the product line built on it; its findings are proven by real queries.
Lab proof: The three tests a fix must pass: anonymous visitor denied, signed-in stranger denied, owner still reads their own rows.
Leak: Personal data that the wrong people can read: an anonymous visitor, or a signed-in user who doesn’t own it.

MCP: Model Context Protocol: a standard way for AI coding agents to use outside tools. PatchLabs runs a remote MCP server. More.
Migration: A SQL file in supabase/migrations/ that changes your database’s structure or rules. Migrations run in filename order, which is why fix files start with a timestamp.

Needs review: A check status meaning leaks were found but no fix passed the proof on its own, so a person reviews it before you apply anything.

Owner (in the lab): The test user who owns a seeded row. After a fix they must still read their own data, or the proof fails.
Owner (in a workspace): The role that manages a workspace: invites, roles, webhook and name. The other role is member. More.
OSV: An open database of published vulnerabilities (osv.dev), keyed by package and version. The dependency check sends package names and versions to it, nothing else.

Personal data: Information about a person, such as an email address, phone number, home address or date of birth. These are the columns a check looks for.
Policy: A row level security rule in Postgres that says who may read or change which rows, for example “users can read their own profile”.
Proven fix: A fix that has passed the lab proof. A scanner gives you a finding; a proven fix is one you’ve seen work.
Proven (finding): A finding the Lab reproduced with a real query against the rebuilt database. Code findings are read from the code and are not marked proven.

Re-check: Another check of the same app, on a schedule, from Run now, CI or MCP. The quickest way to confirm a fix is live.
Receipt: A signed record of a finished check: result, tables, whether the proof passed, the fix’s hash, and every decision and answer. More.
Reject: A decision that says “these tables are meant to be readable”. Creates a suppression.
RLS (row level security): The Postgres feature Supabase uses to decide which rows each user can see. When it’s off, or a policy is too broad, data leaks.

Seeded rows: Fake rows we put in the lab database so there is something to read. Never real data.
SECURITY DEFINER: A Postgres function that runs with its creator’s rights instead of the caller’s. Useful, but risky if anyone can call it or its search_path isn’t fixed.
Service role key: Supabase’s secret key that bypasses every policy. It must never appear in frontend code or a repo; the key scan looks for it.
Signed-in stranger: In the lab, a freshly signed-up user who owns nothing. If they can read other people’s rows, anyone who signs up can.
Suppression: A table your team marked as intended for one app. Later checks list it as “marked as intended” and don’t alert on it. More.

user_metadata: Per-user data in Supabase Auth that users can change themselves, at sign-up and with updateUser. Fine for a display name; never for roles (PL-019). Guide.

Verification file: patchlabs-verify.txt, committed with a one-time code to prove you control the repo. More.

Webhook: A URL we POST to when a check finishes. Works with Slack and Discord incoming webhooks. More.
Watch (PatchLabs Watch): The product line that re-checks on a schedule, shows diffs, sends alerts and signs every result. More.
Workspace: Where apps, members, API keys, the webhook and the plan live. You can belong to several. More.

Updated 10 Nov 2026Something unclear or wrong? Tell the founder