Scan every pull request for the concepts worth protecting.
The Obviously Concept Scanner runs inside your CI pipeline and surfaces a codebase's distinctive technical mechanisms on every push. Engineering vocabulary only, no legal conclusions. Bring your own model: a remote OpenAI-compatible provider, or local Ollama on a self-hosted runner.
Code scanners ask what is wrong. Concept Scanner asks what is distinctive.
Not a patent scanner. It reads your code for distinctive technical concepts. That is engineering work, not legal work. Whether any concept is worth patenting is a separate question for a patent attorney.
Concept discovery, wired into your pipeline.
Most distinctive concepts are found by hand, long after they ship. Run the scan where the code already lives, in CI on every change, and get back a ranked, evidence-backed review queue of the distinctive concepts in your code.
On every pull request
Add one workflow file and each change gets scanned for distinctive engineering concepts, so nothing worth protecting ships unnoticed.
Bring your own provider
The Action ships no default model or key. Point it at any remote OpenAI-compatible endpoint, or a self-hosted runner with local Ollama for a no-egress scan.
Engineering-only output
Distinctive mechanisms scored on technical axes. No patentability claims, no legal conclusions. Legal review stays a separate step for qualified humans.
Add one workflow file.
It checks out your repository and runs a scan. The API key comes from a repository secret, never inline.
# .github/workflows/concept-scan.yml
name: concept-scan
on: [workflow_dispatch]
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: Obviously-Not/concept-scanner@v1
with:
provider: openai-compatible
base-url: <your provider's /v1 URL>
model: <a remote model id>
api-key: ${{ secrets.OPENROUTER_API_KEY }}The scanner is a Docker action, so it runs on Linux runners only. GitHub-hosted runners cannot run a local LLM, so use a remote provider there. A self-hosted runner with Ollama can scan with zero egress. Concrete endpoints and model strings live in the repo's PROVIDERS.md. Output quality tracks the model you point it at: a stronger remote model, or a larger local model on a self-hosted runner, surfaces more.
Or run it in Docker.
The same image is published to GHCR and Docker Hub. Point it at a directory and scan outside of Actions.
docker run --rm -v "$PWD:/workspace" \
ghcr.io/obviously-not/concept-scanner:v1 \
scan /workspace --ollama-host http://host.docker.internal:11434ghcr.io/obviously-not/concept-scanner:v1 and leegitw/concept-scanner:v1What it hands back.
Structured output your team, or an agent, can act on directly.
Scored and classified
Each mechanism is scored on four engineering-quality axes (technical distinctiveness, implementation depth, problem specificity, generality) and classified as distinctive, borderline, or textbook.
Grounded, with context
Every concept traces back to the specific files it came from, with a validation state, plus git authorship and dependency-license context. A reviewer can check it against the real code. Output is machine-readable JSON, shape-matched to the platform's code_scan schema.
Nothing hidden
Textbook concepts are held back by default, but the count is always reported. The scanner never silently drops a finding, and every result carries prioritized, ready-to-run next steps for a human or an agent.