What does SonarQube Server analyze?

Sonar's current Server documentation describes a scanner that selects files within the configured analysis scope, invokes language analyzers under configured quality profiles, sends issues and metrics to the server, and can return a quality-gate result to CI. Exact rules, languages, features, and editions depend on the installed version and configuration; use the documentation for that deployment.

What is AI Code Assurance in SonarQube Server?

The current documentation describes project labeling for AI code, an AI-qualified quality gate, status in product views, and publishable badges. The recommended Sonar way for AI Code gate includes conditions on new and overall code. A custom gate can also be qualified. That status reports the configured gate outcome; this page does not reinterpret it as a certification, endorsement, runtime result, or proof that every defect was found.

Is static analysis the same as task-relative verification?

No. Static analysis evaluates source and related artifacts against configured analyzers, profiles, and gate conditions. Task-relative verification compares an observed change and test evidence with an external task boundary and acceptance criteria. They can consume overlapping artifacts, but their questions and evidence differ.

Does Reality Graph replace SonarQube?

No. Reality Graph is positioned beside static analysis, tests, review, and runtime controls. It can bind a coding run to declared scope, selected validation, captured receipts, and an operator decision. It is not SonarQube's rule engine, a vulnerability scanner, a runtime monitor, or a substitute for human judgment.

What evidence should a team retain across both workflows?

Retain the exact SonarQube version and edition, analysis scope, quality profiles, gate definition and outcome, issues or metrics used in a decision, plus the task boundary, changed files, executed tests, verification receipts, exceptions, reviewers, runtime observations where relevant, and the final operator decision. Each artifact answers a bounded question.

Comparison

SonarQube and Verification

Last updated: 2026-07-173 min read

SonarQube analysis and task-relative verification answer different questions. SonarQube Server documents source analysis under configured profiles and quality gates. Verification compares an observed change and validation evidence with an external task boundary. Use both where both questions matter; neither substitutes for human review or runtime evidence.

Contents

Start with current documented SonarQube facts

The current SonarQube Server analysis overview describes a scanner selecting files in configured scope, language analyzers applying quality profiles, and the server computing issues, metrics, and optionally a quality-gate result for CI. The AI Code Assurance documentation describes project labels, AI-qualified gates, a recommended Sonar way for AI Code gate, status displays, and badges. Checked 17 July 2026. Exact capabilities depend on product, edition, version, and configuration; this review did not run a SonarQube benchmark.

Fact, interpretation, and positioning boundary

Scope: SonarQube Server source analysis and AI Code Assurance quality gates compared with task-relative verification, governance records, human review, and runtime evidence.
As of: 17 July 2026
Method: Record dated documented product facts first; compare the question, input, output, and limitation of each evidence layer; keep Reality Graph claims to observed local capabilities.
Primary sources: Observed product fact: analysis: Sonar documents a scanner and language-analyzer flow that evaluates files in configured scope under quality profiles and sends issues and metrics to SonarQube Server.SonarQube Server analysis overview · 2026-07-17Actual analyzers, rules, scopes, integrations, editions, and outcomes depend on the deployed version and configuration.
Observed product fact: AI-qualified gate: Sonar documents AI-code project labeling, AI-qualified quality gates, a recommended Sonar way for AI Code gate, status displays, and external badges.SonarQube Server quality gates for AI code · 2026-07-17The documentation also says custom gates can qualify; do not assume one fixed gate or transfer a status beyond its configured conditions.
Editorial interpretation: Rule and gate evidence answers whether configured analysis conditions were met. A separate task-relative check asks whether a change matches an external mission, scope, and acceptance criteria.Evidence-boundary comparison · 2026-07-17This is the article's analytical distinction, not a Sonar statement about every possible integration or workflow.
Not inferred: No benchmark, product ranking, endorsement, customer result, price, or ROI comparison
No claim that a quality-gate result is certification, runtime proof, or complete defect detection
No claim that Reality Graph replaces SonarQube, testing, review, monitoring, or security assessment
Limitations: SonarQube features and terminology vary by product, edition, version, and configuration
This review did not execute or benchmark a SonarQube instance
Runtime behavior and legal or compliance determinations require their own evidence and owners

The comparison starts with current Sonar documentation, then labels editorial distinctions and Reality Graph positioning instead of presenting them as Sonar product facts.

Do not collapse rules, gates, review, verification, and runtime proof

A rule finding reports what one configured analyzer recognized. A quality gate computes whether configured conditions passed. Human review adds accountable context and judgment. Task-relative verification compares a change with declared scope and acceptance.

Governance evidence records authorization, revision identity, selected checks, and observed results. Runtime evidence records what a deployed system did. These artifacts can reinforce one decision, but a pass in one layer does not silently answer the others.

Compare evidence layers by the question they answer

These layers can inform one decision without becoming interchangeable; a pass in one layer does not imply a pass in another.
	Primary question	Typical evidence	Boundary
Static analysis	What issues or metrics do configured analyzers report for the selected source scope?Evidence-layer question · 2026-07-17Teams can combine or extend layers in their own workflow.	Scanner configuration, quality profiles, issues, metrics, and versionTypical artifactExact artifacts depend on configuration and process.	Does not by itself establish task intent, runtime behavior, or complete defect absenceClaim boundary · 2026-07-17No cross-layer pass is inferred.
Quality gate	Did the computed measures satisfy the configured gate conditions?Evidence-layer question · 2026-07-17Teams can combine or extend layers in their own workflow.	Gate definition, branch or new-code context, computed result, and exceptionsTypical artifactExact artifacts depend on configuration and process.	A pass is scoped to those conditions; it is not certification or universal code assuranceClaim boundary · 2026-07-17No cross-layer pass is inferred.
Human review	Are design, trade-offs, maintainability, risk, and context acceptable to accountable reviewers?Evidence-layer question · 2026-07-17Teams can combine or extend layers in their own workflow.	Comments, approvals, requested changes, decisions, and reviewer contextTypical artifactExact artifacts depend on configuration and process.	Coverage and judgment vary; approval is not runtime proofClaim boundary · 2026-07-17No cross-layer pass is inferred.
Task-relative verification	Does the observed change and validation evidence match the declared task, scope, and acceptance criteria?Evidence-layer question · 2026-07-17Teams can combine or extend layers in their own workflow.	Mission boundary, changed files, tests, receipts, deviations, and operator decisionTypical artifactExact artifacts depend on configuration and process.	Depends on the quality of the task and selected checks; it is not static analysis or runtime monitoringClaim boundary · 2026-07-17No cross-layer pass is inferred.
Governance evidence	Who authorized what, which checks ran, and what was observed at a specific revision?Evidence-layer question · 2026-07-17Teams can combine or extend layers in their own workflow.	Approval, commit identity, validation receipts, proof, and transition historyTypical artifactExact artifacts depend on configuration and process.	Traceability does not make the underlying code correct or secureClaim boundary · 2026-07-17No cross-layer pass is inferred.
Runtime evidence	What happened in the deployed environment under observed traffic and configuration?Evidence-layer question · 2026-07-17Teams can combine or extend layers in their own workflow.	Deployment provenance, telemetry, incidents, traces, logs, and live checksTypical artifactExact artifacts depend on configuration and process.	Observed runtime windows do not cover every future input or conditionClaim boundary · 2026-07-17No cross-layer pass is inferred.

These layers can inform one decision without becoming interchangeable; a pass in one layer does not imply a pass in another.

Where Reality Graph fits

Reality Graph can sit beside SonarQube, build and test systems, code review, and runtime tooling. It can bind one AI coding run to a mission scope, allowed paths, validation commands, captured receipts, changed files, approval, and commit identity. It does not implement Sonar analyzers or quality profiles, discover every vulnerability, replace reviewers, or observe production unless deployment and live evidence are explicitly captured. The relevant question is which evidence layers a decision needs-not which tool wins a universal contest. Whether the declared commands actually ran or were only reported as run is recorded separately from what any analyzer concluded. See also code review versus verification.

This comparison can show

Which Sonar analysis and AI-qualified-gate features its current public documentation describes
How static-analysis, gate, review, verification, governance, and runtime evidence answer different questions
Where Reality Graph can preserve task-scope, validation, approval, and revision evidence beside existing tools

It does not establish

That either product is categorically superior, complete, endorsed by the other, or suitable for every team
That Reality Graph replaces SonarQube, static analysis, testing, review, monitoring, or security assessment
That a badge, gate pass, governed receipt, or live check is certification, compliance, or universal runtime proof

Reality Graph and SonarQube can contribute different artifacts to one engineering decision; neither product label settles every quality, security, runtime, or compliance question.

FAQ

What does SonarQube Server analyze?: Sonar's current Server documentation describes a scanner that selects files within the configured analysis scope, invokes language analyzers under configured quality profiles, sends issues and metrics to the server, and can return a quality-gate result to CI. Exact rules, languages, features, and editions depend on the installed version and configuration; use the documentation for that deployment.
What is AI Code Assurance in SonarQube Server?: The current documentation describes project labeling for AI code, an AI-qualified quality gate, status in product views, and publishable badges. The recommended Sonar way for AI Code gate includes conditions on new and overall code. A custom gate can also be qualified. That status reports the configured gate outcome; this page does not reinterpret it as a certification, endorsement, runtime result, or proof that every defect was found.
Is static analysis the same as task-relative verification?: No. Static analysis evaluates source and related artifacts against configured analyzers, profiles, and gate conditions. Task-relative verification compares an observed change and test evidence with an external task boundary and acceptance criteria. They can consume overlapping artifacts, but their questions and evidence differ.
Does Reality Graph replace SonarQube?: No. Reality Graph is positioned beside static analysis, tests, review, and runtime controls. It can bind a coding run to declared scope, selected validation, captured receipts, and an operator decision. It is not SonarQube's rule engine, a vulnerability scanner, a runtime monitor, or a substitute for human judgment.
What evidence should a team retain across both workflows?: Retain the exact SonarQube version and edition, analysis scope, quality profiles, gate definition and outcome, issues or metrics used in a decision, plus the task boundary, changed files, executed tests, verification receipts, exceptions, reviewers, runtime observations where relevant, and the final operator decision. Each artifact answers a bounded question.

Keep reading

ComparisonAI Code Review Tools 2026The market in four groups - dedicated PR reviewers, static+AI platforms, assistant-integrated reviewers, local approaches - with dated prices, attributed benchmarks, and no fake winner.ComparisonWhy AI Self-Review Is Not EnoughLLM evaluators recognize and favor their own generations - measured, not folklore. The independence ladder from self-check to verification against the written task, with the research behind it.All articlesThe whole collection - 58 cited, dated guides on verifying AI-generated code.

Sources

Want to see what your last agent run would have looked like?

Request access