Ontologies are hereGet startedAI made content cheap. Understanding stayed expensive.
Health score
78
+2 this month
Clarity
71
−1 this month
Stability
82
+3 this month
Structure
74
steady
Complexity trend · trailing 6 months
Risk hot-spots · complexity percentile in this repo
Hidden coupling
services/billing.ts ⇄ infra/queues.tf
Changed together in 41 of 43 commits. This PR touches only one of them.
the concentration of real bug fixes inside the smaller review surface Semfora flags, versus an even spread
of 1,773 real bug fixes fell inside a flagged surface covering just 8.4% of the code
public repositories across 8 languages in the study: real fixes, not synthetic benchmarks
The rules your senior engineers keep in their heads, written down once.
An axiom is a claim about your whole system that the code either upholds or breaks. A linter rule reads one file. A test pins one behavior somebody chose to write. An axiom follows call chains across the codebase and answers a different question: is it still true that nothing in admin code can reach the ledger?
The answer is the rule holds, or the exact chain of calls that breaks it. There is no score and no model in the loop.
Declare your axioms in a semfora-ontology.toml at the root of your repository. Every full analysis of your default branch then reports which of them hold and which are broken, with the call chain behind each break, on your dashboard.
Admin tools never reach the ledger.
A property of the whole system, followed across call chains no single file shows.
Database work stays in the server and the worker.
An effect boundary. It holds, or it names the symbol that crosses it.
Nothing in src writes to disk or opens a socket.
An effect rule. The graph either upholds it or names the symbol that breaks it.
Nobody writes these from a blank page
A blank rules editor asks you to do the hardest part first. Instead the engine reads your graph and proposes the rules your code already follows. A candidate with zero violations can be adopted without failing a pull request that passes today.
We ran that on ourselves before asking anyone else to. Semfora now declares its own axioms, every one of them mined from our code and adopted only because our code already followed it. Adopting them broke nothing, because there was nothing to break.
The miner also proposed rules our code did not yet follow. We left those out. A rule that already fails turns the board red on work that was fine yesterday, and that is a decision to make deliberately.
Where this actually is
Results come from a full analysis of your default branch. A pull request check reads your axioms too, but those findings describe that branch, so the page says so rather than presenting them as the repository's own. Adopting an axiom from the web, searching them, and having a broken axiom turn a pull request red are designed and not shipped. We would rather say that here than let you find it out after signing up.
AI made your team faster. How long before the issues start?
Months 0–6
The spike
Output climbs. AI writes the boilerplate, pull requests get bigger, and the velocity charts look better than they ever have. Clarity is the first thing to slip: nobody's understanding grows as fast as the diff.
Months 6–12
The drag
Complexity compounds quietly, and the code AI wrote this quarter starts colliding with the code AI wrote last quarter. Stability follows: reviews slow down and regressions climb.
After
The comprehension gap
Output declines sharply, and the engineers debugging production have read less of the code than any team before them. Incidents arrive in code nobody actually wrote, through dependencies nobody knew existed.
You can't manage what nobody understands. Semfora gives engineering managers and SREs a structural view of what AI is doing to the codebase measured on every merge, in numbers a director can put in a slide and an engineer can act on. Know how your codebase is being affected by leaning on AI, before the curve turns.
The fix is not slowing down. It's aiming. Your best engineers and your best models belong in the most dangerous parts of the codebase, not the safest. In our study, 30.5% of real bug fixes landed in 8.4% of the code. Semfora shows you which 8.4%. Send the senior reviewer and the frontier model there, and let the settings page make do with haiku.
Three surfaces. One map.
Dashboard
updated on every mergeHealth, hotspots, and trends for every repo. Built for engineering leads.
AI chat
grounded in your metricsAsk questions in plain English. Answers cite functions and numbers from your own analysis.
PR gate
same input, same verdictDeterministic pass/fail on every pull request.
Policy on every pull request, from a five-line workflow.
.github/workflows/semfora-gate.yml
name: Semfora Gate
on:
pull_request:
pull_request_review:
types: [submitted] # re-run on approval (waiver flow)
jobs:
gate:
runs-on: ubuntu-latest
steps:
- uses: Semfora-AI/semfora-action@v2
with:
semfora-key: ${{ secrets.SEMFORA_KEY }}semfora.toml · your policy, in your repo
[groups.billing] description = "Money: plans, quotas, subscriptions" files = ["src/server/billing*.ts"] [gate.protected] # touching money turns the PR red severity = "error" groups = ["billing", "auth-boundary"] [gate.complexity] # budgets per changed symbol severity = "warn" max_cc = 25 max_cc_delta = 10
Deterministic, not vibes
The gate is policy evaluation over measured structure: which domain the diff touches, how load-bearing the edited symbols are, what happened to complexity. Same change, same verdict, every run.
Nothing runs on your runner
The action is a thin client. Analysis runs in Semfora's pipeline through your existing GitHub App connection; no checkout, no binary, and the report contains symbol names and numbers only.
Blockable, and waivable
An error finding files a Changes Requested review naming the domain it hit. A qualified reviewer approving the current head commit waives it, so the policy is a checkpoint with an owner, not a wall.
We run this gate on our own repository. The first pull request it denied was ours: a change to our billing code turned the check red and filed the review automatically. The policy held, a reviewer approved the change on its merits, and it merged with the decision on record.
Not another linter. Not another delivery dashboard.
Rule-based quality scanners
Score each file in isolation, on a snapshot. They can tell you a function is complex, but not that it's load-bearing code the rest of the system depends on: the kind you review extra carefully before changing.
Git-mining behavioral tools
See which files change together, but hold no call graph, so they can't separate healthy collaboration from coupling that never appears in the code itself.
Architecture visualization tools
Hold a dependency graph but no history. They show today's structure with no idea where it's been or where it's heading.
Delivery analytics
DORA metrics are good numbers: cycle time, deployment frequency, PR throughput. But they measure how fast work moves, not what the work is doing to the system underneath. Different question, different number.
What you can only measure with both
These feed the scores at the top of every Semfora dashboard: health, clarity, stability, and structure. They're the numbers an engineering manager checks first.
Hidden coupling
Files that change together with no code connection between them: the invisible dependencies that make a “small” change break a feature nowhere near it. Semfora surfaces each pair by name and asks the question a linter can't: these two almost always change together, so why didn't they this time?
Risk concentration
How much complexity and change activity piles onto the code everything else depends on. Load-bearing code isn't bad; it just deserves more care than the rest. When complexity concentrates there, you're a single hero file away from an outage.
AI comprehension cost
How much context an AI assistant, or a new hire, needs to safely change each part of the system. The first codebase metric designed for teams where half the commits are machine-written.
Health with a direction
One score that blends where the codebase is with the direction your own commit history says it has been moving. No forecasts: these curves move slowly, which is exactly why the trend matters. Snapshots hide decay. Trajectories don't.
Measured, not promised
Bug-fix concentration. Real bug fixes landed inside the smaller high-risk surface Semfora flags at 3.63 times the rate an even spread would give. Measured on 1,773 resolvable bug cases.
Fixes inside the flagged surface. 541 of 1,773 real bug fixes fell inside a flagged surface covering just 8.4% of the matched line mass. The broader high-risk band alone held 41.6% of fixes in 14.5% of the code.
Repositories studied. Public open-source repositories across 8 languages. Every case has a real fix commit and changed-line ground truth; no synthetic bugs.
Cases metered with live agents. We metered what AI agents actually spend to work against real code: 1,370 completed runs across five models. Token spend tracked the size and centrality of the change more than anything else we tested. The trend is loose (rank correlation tops out near 0.21) but consistent across models.
Grammars. TypeScript to Terraform to TLA+. Counted from the engine's own language table: 23 languages, the JSX and TSX variants, Markdown, and the config formats that wire a system together.
Names and numbers only. The hard cap on what one analysis can store: function and module names, scores, and counts. No field in the schema can carry your source.
30 grammars, one engine
- TypeScript
- JavaScript
- React
- Python
- Rust
- Go
- Java
- Kotlin
- C++
- C
- C#
- Ruby
- PHP
- Swift
- Scala
- Bash
- Vue
- HTML
- CSS
- SCSS
- Terraform
- Dockerfile
- Gradle
- TLA+
That's 24 chips on the wall, counting React, which rides the JSX and TSX grammars. The engine's own language table has 30 entries: these 23 languages, the JSX and TSX variants, Markdown, and the four config formats that wire a system together (JSON, YAML, TOML, and XML). Config gets parsed and graphed like everything else; we just don't call it a language.
Framework-aware analysis
React
Components, hooks, context
Next.js
App Router, Pages, API routes
Vue
SFCs, Composition API
Angular
Components, services, decorators
Svelte
Components and entry points
Express
Routes, middleware detection
NestJS
Controllers, decorators, modules
Fastify
Routes and plugins
Also framework-aware for Remix, SolidJS, Hono, Koa, tRPC, and Redux. Stack detection recognizes hundreds of libraries across 12 package ecosystems, including 100+ database drivers, ORMs, and schema tools, so your data layer gets read and risk-scored like any other code.
From connect to first report in one merge
Connect GitHub
Pick your repos. Semfora gets read-only access through a GitHub App.
Every merge gets analyzed
An ephemeral container maps the code's structure and posts back metrics: names and numbers, never source.
Ask it anything
The dashboard for your leads, the PR gate for CI, and an AI chat grounded in your own metrics.
Questions, answered straight
What exactly is Semfora?
A cloud code-intelligence platform for engineering teams. Connect a GitHub repo and Semfora compiles every merge into a structural map of your code: every function, what calls it, how complex it is, and how all of that has changed over time. Your dashboard reads that map, your team asks it questions in plain English, and your pull requests get gated against it, deterministically.
What happens to my source code?
Each analysis runs in its own ephemeral container: your repo is checked out, measured, and the workspace is deleted when the run ends. What we store are names and numbers: symbol names, module names, scores, and counts, capped at 128 KB per run. There is no field in our data model that can carry source text, snippets, or diffs. That's a schema constraint, not a policy promise.
How is this different from grep or embeddings?
Grep matches text and embeddings match vibes. Semfora parses your code, so it knows that validateUser calls db.query inside a try block, how complex that function is, and who else calls it. Answers are structural and deterministic: the same question always returns the same result, with file and line attached.
Can it really see where bugs will come from?
We measured where fixes land, across 1,773 real bug cases in 410 public repos. 30.5% of the fixes fell inside a flagged surface covering just 8.4% of the code: a 3.63× concentration over an even spread. That's what the dashboard's hotspot views are built on. It is not bug prediction; it tells you where review attention pays off, not which function breaks next.
How does my team actually use it?
Three surfaces, one map. Engineering leads get the dashboard: health, hotspots, and trends per repo, updated on every merge. Anyone can ask the AI chat questions like “what did this feature do to the codebase?” or “which hotspots changed this week?” and get answers that cite functions and numbers from your own analysis. And CI gets a PR gate that returns the same verdict for the same change, every time.
What do I get when I sign up?
The cloud platform: GitHub-connected analysis on every merge, the manager dashboard, the AI chat grounded on your metrics, and the PR gate for CI. The free tier needs no card. Early customers get direct access to the team and a real say in the roadmap.