Public claim level: concept. This article explains why a green build and complete feature-level static evidence are different claims, using TraceMap's checked-in contract, rule catalog, and synthetic fixtures. A build answers whether a selected toolchain accepted selected inputs. It does not automatically prove that every framework convention, generated artifact, binding, event flow, route, dependency, or downstream feature was understood by a static analyzer. The companion article modernizing Web Forms without running it showed what static evidence can observe; this one is about what a clean compile does and does not add.
Four different questions are hiding inside “the build is green.”
In TraceMap's contract these are separate layers, and collapsing them is where review mistakes enter:
- TraceMap's own build and tests. Whether the TraceMap product compiled and its own test suite ran green. This says nothing about any target repository.
-
Target-repository build state. Whether the selected
projects of the repository being scanned loaded or compiled well enough
for semantic analysis, recorded as a build status of
Succeeded,FailedOrPartial, orNotRunnext to an analysis level such asLevel1SemanticAnalysis,Level1SemanticAnalysisReduced, orLevel3SyntaxAnalysis. -
Analyzer capability. Which semantic, syntax-fallback,
project/config, package/restore, generated-design-time, legacy-toolchain,
and downstream-analysis capabilities were
available,reduced,unavailable,not-requested,unknown, ornot-applicableduring the scan. - Feature and downstream coverage. Whether one particular page, event flow, route, data surface, dependency, or report composition had enough evidence for its bounded claim, or carries a coverage label and a gap instead.
The manifest contract states the boundary directly:
Level1SemanticAnalysis and Succeeded mean the
scanner has full semantic evidence for the selected scan scope,
and compiler errors, unresolved dependencies, project-load failures,
skipped files, or syntax-only fallback must produce reduced coverage. A
build status is a statement about one layer, not a certificate about the
other three.
What Succeeded actually records.
For the .NET adapter, a build status of Succeeded records that
the workspace loaded the selected projects and the compiler reported no
errors for them. That is a meaningful, bounded fact. It is also an
incomplete review answer, because it does not establish runtime behavior,
business correctness, application completeness, analyzer feature support,
or complete downstream composition. A repository can compile cleanly while
a generated designer file is missing, a binding cannot be resolved, or a
report has no supported bridge for a surface it was asked about.
Downstream consumers therefore do not treat the build status alone as
coverage. Full coverage in the reducer requires the conjunction of
Level1SemanticAnalysis, Succeeded, and a real
commit identity. For a single-index reduction, anything less routes
no-evidence outcomes to NoEvidenceReducedCoverage instead of
NoEvidenceFullCoverage, and the acceptance contract is
explicit that reduced coverage never produces
NoEvidenceFullCoverage. Combined-index reduction reports the
same reduced-versus-full split through
UnknownAnalysisGap versus NoImpactEvidence. In
other words: when coverage is reduced, “not found” must not be sold as
“not there.”
Evidence can be strong in one area and reduced in another.
The layers move independently, which is the point of separating them.
Compiler-resolved symbols can coexist with missing generated or design-time
linkage: a code-behind type resolves at
Tier1Semantic while the designer linkage capability stays
unknown with an unknown-gap coverage effect.
Project and config inspection can remain available with a
config-only effect while semantic compilation is
reduced. Syntax fallback can preserve useful declarations,
member names, and markup facts without any of it being upgraded to semantic
evidence—the contract forbids upgrading tiers because a pattern is likely.
Reduction also propagates honestly downstream where extractors carry build
awareness into their facts. A Web Forms flow projected under a build status
other than Succeeded keeps a reduced coverage label on its own
facts, and a report that lacks a supported bridge for a composition records
the missing capability rather than an empty success. Data-surface coverage
labels describe their own metadata completeness instead, so a static
mapping fact can stay full even when an unrelated C# build is
FailedOrPartial. Each of these is a different failure shape
than a failed compile, and each deserves its own label rather than one
shared “build issue.”
Capability facts make the analyzer's own limits reviewable.
Capability diagnostics are deterministic, rule-backed rows that describe what the analyzer could do during one scan, each with a capability code, a state, a coverage effect, and a hard evidence-tier cap:
-
CSharpSemanticCompilation,MSBuildProjectLoad, andReferenceAssemblyResolutionunderanalyzer.capability.semantic.v1— semantic compilation, project load, and reference assembly capability, capped atTier2Structuralbecause they are derived status rows, not compiler symbol observations. -
SyntaxFallbackAvailableunderanalyzer.capability.syntax-fallback.v1, capped atTier3SyntaxOrTextual— fallback evidence exists, and it cannot prove compiler-resolved behavior. -
LegacyProjectConfigInspectionunderanalyzer.capability.project-config.v1andLegacyNuGetRestoreAwarenessunderanalyzer.capability.package-restore.v1— static project and package-shape awareness. Restore that wasnot-requestedis scan-option context, not evidence that packages are missing. -
GeneratedDesignerLinkageunderanalyzer.capability.generated-design-time.v1, capped atTier3SyntaxOrTextual— missing, malformed, or unlinked design-time artifacts cap confidence without suppressing valid syntax and config facts. -
LegacyWebStackShapeunderanalyzer.capability.legacy-toolchain.v1— static framework and web-stack signals, informational unless observed scan behavior reduced coverage. -
DownstreamNoEvidenceCoverageunderanalyzer.capability.downstream-coverage.v1, capped atTier4Unknown— emitted only when some other capability isreduced,unavailable, orunknown, telling downstream readers to keep no-evidence conclusions coverage-relative.
Sanitized build-environment rows under
build.environment.workspace-diagnostic.v1 carry the categories
that explain why semantic coverage dropped, with the standing
limitation that they explain coverage, not runtime compatibility. The
legacy .NET evidence lane and the
site limitations page keep the full lists.
A bounded synthetic example, layer by layer.
Consider a synthetic legacy repository where the scan proceeds like this:
the project loads and compiles, so the build status is
Succeeded for the selected scope (target build state). The
compiler resolves a code-behind type (semantic evidence). A control and its
event attribute are observed in markup (structural evidence). The generated
designer file is missing, so GeneratedDesignerLinkage reads
unknown (capability). The event attribute matches no
code-behind method, so the handler connection is recorded as a
MissingWebFormsHandler gap rather than a resolved symbol
(gap). A downstream report asked to compose that flow
into a workflow view finds no supported bridge, so it records
DownstreamNoEvidenceCoverage context and keeps the row
coverage-relative (downstream coverage). The reviewer's packet ends with a
specific question: who can regenerate the design-time linkage and locate
the missing handler so this flow can be re-scanned at full strength?
Every step is labeled by layer and evidence strength—semantic, structural, syntax fallback, candidate, or gap—and none of it came from private validation. The useful output is not a verdict; it is the named, bounded next action.
Why partial evidence is still useful.
A scan with reduced coverage still produces an inventory of pages, routes, bindings, and dependency surfaces that an owner interview can start from. It still feeds migration planning with declared surfaces instead of guesswork, and it identifies the missing generated files or toolchain prerequisites that blocked deeper analysis—often the cheapest thing to fix next. It supports selecting focused tests through the test-planning handoff, and it keeps “not found” honestly separated from “not proven.” The failure it prevents is quiet: a green build being mistaken for complete understanding.
What should happen when coverage is reduced.
TraceMap's contract answers this operationally: preserve the evidence that is independently provable, emit rule-backed gaps for what is not, and keep the repository and commit identity, source spans, and provenance attached so the reduced result is still auditable. Identify the missing capability by code and rule, give the reviewer a bounded next action, and never silently convert missing analysis into a clean result. The evidence map shows which surfaces currently have public proof paths, and the review handoff matrix turns each reduced row into an owner question with a stop condition.
What none of this can prove.
Neither a green build nor TraceMap's static evidence is proof of runtime reachability; that a page or control was visible; that an event fired; that dependency injection selected an implementation; that SQL or any other operation executed; business correctness; test completeness; migration success; feature parity; release safety; production behavior; or complete application coverage. A clean compile of the analyzer's own product is a separate fact from the target repository's build state, and both are separate from what any one feature's evidence supports. See the static-versus-runtime boundary for how to read these claims.
TraceMap's scanner and reducer contain no LLM calls, embeddings, vector databases, or prompt-based classification.