Compare
Sonar measures code against static quality and security conditions. FalseGreen decides whether the requested bounded outcome is actually complete.
Quick answer
Sonar is designed for continuous static analysis across reliability, maintainability, security, coverage, duplication, and related quality-gate metrics. FalseGreen is designed for independent Job acceptance. A Sonar quality gate can establish that configured code metrics passed; it does not by itself establish that the human-requested engineering outcome was completed.
Alternative or additional layer?
No—not if you need continuous static code-quality and security analysis. Sonar is the specialist for those checks. FalseGreen is a separate acceptance layer for determining whether a bounded Job satisfied its human-defined outcome, potentially using Sonar results as evidence.
What Sonar is good at
Where the overlap is
Both can stop a change from being trusted when configured conditions fail. Sonar produces code-quality and security evidence; FalseGreen can treat that evidence as one part of a broader decision over the bounded Job.
The architectural difference
A Sonar quality gate evaluates analysis metrics against configured conditions. FalseGreen freezes a human-readable outcome before implementation is judged, then decides whether all available evidence establishes that outcome for the exact source. Passing the quality gate and completing the Job are different claims.
Side by side
✓ means central and explicit. ◐ means partial or adjacent. — means not the product’s primary function.
| Capability | FalseGreen | Sonar |
|---|---|---|
| Primary purposeThe main problem the product is designed to solve. | Independent bounded acceptance | Static code quality and security |
| Dedicated security or static analysisSpecialized analysis for code quality, vulnerabilities, or security findings. | — Not primary | ✓ Yes |
| Frozen human-defined definition of doneThe bounded acceptance target is established before implementation is judged. | ✓ Yes | ◐ Partial |
| Frozen Job target preserved through repairThe agreed Job target remains authoritative while the implementation is repaired and reverified. | ✓ Yes | ◐ Partial |
| Separate Job acceptance authorityA distinct authority decides whether the separately bounded Job is accepted. | ✓ Yes | — Not primary |
| Job or outcome-level acceptanceAnswers whether the requested bounded engineering outcome is complete. | ✓ Yes | — Not primary |
| Heterogeneous evidence for acceptanceTests, CI, scanners, formal tools, behavior, and inspection can inform one Job decision. | ✓ Yes | ◐ Partial |
| Explicit bounded resultReturns Accepted, Failed, or Insufficient Evidence for the bounded Job. | ✓ Yes | ◐ Partial |
| Durable evidence and limitationsPreserves what was checked, the relevant source, supporting evidence, and limitations. | ✓ Yes | ◐ Partial |
FalseGreen exact-source enforcement is marked partial because PR Gate remains coming soon. “Not primary” describes product scope, not an unsupported universal absence claim.
When to choose Sonar
Choose Sonar when you primarily need continuous static code-quality and security analysis, technical-debt visibility, and quality gates across the codebase.
When to use FalseGreen
Use FalseGreen when the question is whether a consequential migration, lifecycle change, infrastructure outcome, or other bounded Job actually satisfied its agreed definition of done.
Better together
Sonar can provide high-value quality and security evidence. FalseGreen does not replace that analysis; it can use the relevant result alongside behavioral, test, source, and other evidence for Job acceptance.
The builder layer stays open
The coding-agent layer remains swappable. FalseGreen sits outside the builder, regardless of which supported agent or underlying model performs the implementation.
Official references
When “done” needs authority