MAGPIE AI system discovery, derived from code
ISO/IEC 42001 · EU AI Act

Find the AI systems your register is missing.

Your AI inventory was assembled by asking engineers what they remember shipping. Magpie reads the source code instead and gives you the delta — every system in your code that isn't on your list, with the file and line to check it against.

$ ./gt scan .

One static binary. Runs locally, uploads nothing, opens no socket, never runs git blame. No account required for the scan.

Proof, on a repository you can check yourself

Searching for model names finds two. There are five.

vercel/ai-chatbot is public. Run both commands and compare — this is the whole argument in one screen.

zsh · ~/demo/ai-chatbot
$ grep -rE "claude-[a-z0-9.-]+|gpt-[a-z0-9.-]+" --include='*.ts' .
lib/ai/models.ts:44:    id: "openai/gpt-oss-20b",
lib/ai/models.ts:52:    id: "openai/gpt-oss-120b",

$ ./gt scan .

5 findings — 5 registrable AI systems
  lib/ai/models.ts:30  deepseek/deepseek-v3.2  [model]  — unrecognised
  lib/ai/models.ts:1   moonshotai/kimi-k2.5  [model]  — unrecognised
  lib/ai/models.ts:52  openai/gpt-oss-120b  [model]  — openai
  lib/ai/models.ts:44  openai/gpt-oss-20b  [model]  — openai
  lib/ai/models.ts:60  xai/grok-4.1-fast-non-reasoning  [model]  — unrecognised

The three a search misses aren't hidden. They're declared in a model registry and resolved at runtime, so every call site reads model: getLanguageModel(modelId) — there is no string to match on. That is how a modern TypeScript application is written, and it is why an inventory built by searching for known model names under-reports. A name list also cannot contain a model released after it was written: kimi-k2.5 and grok-4.1 are found because the scanner reads the declaration, not because anyone told it they exist.

What comes back

A delta, and the evidence to defend it

The gap

Point it at your existing register — one system per line, any text format. You get what your list is missing, not another list to reconcile.

A file and a line

Every finding cites a location. When an auditor samples your register and says "show me this one," the answer is a path, not a recollection.

Its own blind spots

Each run prints what it parsed, names every file it could not read, and lists the call sites where a model is chosen at runtime and a human must decide.

A re-runnable procedure

The command to reproduce the result is printed on the report, with the scanner build and the commit it read. Your auditor can re-perform it.

zsh · ~/work/platform  ·  illustrative output
$ ./gt scan . --register=register.csv

Magpie — ~/work/platform

Gap against register
  11 in register · 34 found in code · 23 not in the register

  + services/support/triage.py:42  claude-sonnet-5  [model]  — anthropic
  + apps/web/lib/agent.ts:24  refund_order  [agent_tool]
  + .mcp.json:7  postgres-mcp  [mcp_server]
  + infra/bedrock.tf:1  aws_bedrock_agent.ticket_triage  [config]
  … and 19 more

  This gap is a lower bound. Held-out recall is 66%, so systems
  absent from both the register and this report are expected to exist.

Not resolved — 4 files to review by hand
  apps/router/select.ts:88  openai imported, no model id resolved
  .env.production:31  model id from $GEMINI_MODEL — value not in the repository

Parse coverage
  parsed        1284/1284 files (100.0%) — 1102 code, 182 config
  not scanned   96 files in formats this scanner does not parse
                  .go 41, .java 28, .rb 19, .md 8

gt 0.1.0-phase0 (e3d620d58956)  ·  catalogue 2963 models @ 6446d03d4c40
target ~/work/platform @ 4f1c9a2b7e30
re-run: gt scan ~/work/platform --register=register.csv
Before you ask

What this does not do

It will miss systems. Measured recall is 66%.

Hand-judged against an independent oracle on four real AI products on 2026-07-27. It started at 46%; closing five declaration shapes we could not read moved it to 66% on repositories held out from the fix. Two rounds did not converge the number.

That is exactly why the output is a delta against your register and never a claim to be your register. Static extraction cannot be complete — a model id can live in an environment variable, a customer's database, or a runtime gateway rule. "Here is everything you run" fails on the first missed system. "Here are systems your list is missing" holds at any recall above zero, and it cuts in your favour: the real gap is larger than the scan reports.

Parse coverage is not recall. The percentage of files read and the percentage of systems found are two different numbers, and the report prints them as two different numbers.

Why this exists

Governance platforms only govern what someone registered

That isn't a criticism of them — it's their architecture. They are systems of record fed by a human filling in a form. Nothing in the stack goes and looks at the code.

€35M
Or 7% of global turnover — the EU AI Act's maximum penalty
42001
The ISO standard that explicitly requires an AI system inventory. Companies are certifying now, for sales reasons.
57
Provider deprecations in 12 months across three vendors — how fast the thing you're inventorying moves
Pricing

The scan is free. Start there.

Run it before you talk to us. If the gap is small, you don't need us and you'll know in a minute.

Free scan
$0
Local CLI, full discovery, gap report with file-level locations. No account, no source upload.
Gap assessment
$2–5k
One-off. We scan, you get the delta against your current register, nothing recurs.
Discovery
$1,500/mo
Continuous discovery against your register, change history, drift alerts, ISO 42001 mapping.
Audit
$4,000/mo
EU AI Act classification, data-flow mapping, evidence packs, SSO, policy gates.
Start here

Find out the real number.

One command, locally, nothing uploaded. Then compare it against your register.

Try it
$ ./gt scan .   # single binary, no runtime, nothing installed
$ ./gt scan . --register=register.csv
$ ./gt attribution   # every bundled dependency and its licence

Framework obligations per ISO 42001 / EU AI Act mapping and the EU AI Act timeline — note the high-risk standalone deadline moved to 2 December 2027. Deprecation counts compiled 2026-07-26 from OpenAI, Anthropic and Google primary documentation. The vercel/ai-chatbot result is reproducible against that public repository; the multi-repository scan shown above is an illustrative example, not a measured customer result. Recall of 66% measured 2026-07-27 on four held-out products. Magpie is a working name; domain unverified.