Public claim level: concept. TraceMap requires every fact to carry a location, but not every fact describes a source line. This article explains how TraceMap preserves location truth when evidence applies to a source declaration, a project, a container, a repository, a workspace, or a downstream composition rather than an exact line. The working principle is strict: a precise-looking false location is worse than an explicit scope-level anchor or an unavailable span. Companion articles own neighboring ground—how a gap becomes a rule owns the hardening lifecycle, and a successful build can still have reduced feature coverage owns build, capability, and coverage distinctions. This article owns location honesty and span readback.

Why evidence systems want locations.

A location turns a claim into something a reviewer can check. A repository-relative path, a one-based line span, a commit SHA, and a rule ID together answer: which bytes, which version, which interpretation? TraceMap's language adapter contract requires every fact to carry a file path and line span plus extractor identity, and to store snippet hashes rather than raw source by default. A span supports the bounded declaration or relationship the fact represents, and nothing more. A location is evidence provenance, not proof of causality.

Why some evidence has no honest source line.

Three honest situations break the file-and-line model. A workspace condition—project load failure, unresolved toolchain, a scan-scope exclusion—is a property of the environment, not of one declaration. A binary container such as a Microsoft Access database holds objects with no source-file line model at all. And an older or downstream artifact may retain a relationship without complete span metadata. In each case a line number exists only if someone invents it. The honest options are a labeled anchor at the correct scope, or an explicit unavailable span—never a fabricated line.

Five location classes.

  1. Exact source span. A parser, compiler, or structured format supplies a real repository-relative file and a one-based line range that bounds the declaration or relationship represented by the fact, as with csharp.semantic.declarations.v1 at Tier1Semantic or csharp.syntax.declarations.v1 at Tier3SyntaxOrTextual.
  2. Supporting declaration span. A wider diagnostic or capability state can have an honest supporting project or config declaration. The location anchors the supporting evidence; it does not show that every consequence occurs on that line.
  3. Owning-container anchor. A binary or container-backed object has no source-file line model. Access catalog objects anchor at the repository-relative database path at span 1:1, and the rule catalog states the convention directly: the owning database path at span 1:1 anchors the container and is not a fabricated source line. Logical object identity—kind, safe name, stable key—remains in structured properties.
  4. Workspace/repository anchor. A project-load, toolchain, inventory, or workspace-wide gap has no reliable source file. TraceMap's documented convention anchors such facts at the repository path . with line 1 and explicit scope metadata such as sourceScope set to workspace. That anchor is never presented as a real source line.
  5. Span unavailable. An older schema or downstream artifact may lack usable span metadata. The honest output preserves unavailable or an explicit compatibility/provenance gap. Unavailable location metadata is not evidence absence.

Line 1 can be an anchor without being a source-line claim. But not every line-one span means the same thing: a real declaration that starts on line 1, a container anchor, and a workspace convention are three different facts. Verify every cited convention against its owning rule or specification before reusing it.

Why fabricated precision is dangerous.

A precise-looking false location is worse than no location because it is checkable in the wrong place. It sends a reviewer to a line that never supported the claim, lets grouping and deduplication silently merge unrelated facts, and upgrades a scope-level statement into a line-level one that no extractor observed. Once a fabricated span is persisted, every downstream report inherits the error as if it were evidence. A downstream consumer must not strengthen an anchor into an exact source claim. A producer must never substitute line zero, a local host path, an undocumented line one, or an unrelated fact's span for missing metadata.

Synthetic example A: a workspace toolchain diagnostic.

  1. gap: In a synthetic legacy repository, project loading cannot resolve a required legacy toolchain, so semantic extraction cannot complete for the scan scope.
  2. unavailable: No single source declaration explains the whole condition, so no exact one-based span exists to cite.
  3. workspace anchor: The diagnostic keeps the documented workspace anchor—repository path ., line 1—with scope metadata, under rules such as build.environment.workspace-diagnostic.v1 or csharp.semantic.workspace.v1.
  4. supporting declaration: Where a project or config declaration genuinely supports part of the state, a per-project fact may anchor there; the location supports the declaration without claiming every consequence occurs on that line.
  5. gap: The tier ceiling and limitation stay bounded—the workspace gap itself remains Tier4Unknown, the categories explain why semantic coverage was reduced, and they do not establish runtime compatibility—leaving the reviewer a toolchain or project-owner question, not a verdict.

Synthetic example B: container evidence from an Access catalog.

  1. exact evidence: A neutral synthetic Access database at a repository-relative path such as samples/access/catalog-sample.accdb is observed as a checked-in container under legacy.access.database.inventory.v1 at Tier2Structural.
  2. container anchor: A catalog object such as a table anchors at the owning database path at span 1:1 under legacy.access.schema.v1; line 1 anchors the container.
  3. container anchor: The logical object identity stays in safe structured properties—object kind, safe name, stable key—rather than in the line span.
  4. exact evidence: Where VBA module text supplies real line coordinates, legacy.access.vba.v1 uses those real module lines while keeping the database as the evidence path.
  5. gap: No source-line or runtime claim is made about the anchored object; the row carries its documented limitation and the open question stays with the container's owner.

Synthetic example C: an unavailable downstream span.

  1. exact evidence: A compatible older index retains a relationship row together with whatever provenance it does carry.
  2. unavailable: The artifact lacks complete span metadata, so the location renders as unavailable rather than a borrowed line.
  3. gap: A compatibility or provenance gap keeps the schema limitation visible, consistent with analyzer.capability.downstream-coverage.v1, which requires unsupported schema versions to surface as gaps rather than being silently dropped.
  4. gap: No unrelated location is substituted—not line zero, not a local path, not another fact's span—and rules such as impact.reverse.gap.v1 retain real relationship evidence locations only when available.
  5. gap: Downstream composition stays coverage-relative, leaving the producer question: who can re-emit the artifact with complete span metadata.

Persistence and downstream composition.

Anchors persist verbatim. A workspace or container anchor written to machine-readable facts and the SQLite index keeps its path, span, rule ID, tier, and limitations through readback, and the span is part of each fact's stable identity. The cross-adapter conformance contract requires rule ID, tier, path, span, extractor identity, coverage, and limitations to survive persistence, and requires missing fields to be reported as capability gaps rather than manufactured. A complete location record therefore carries: repository identity and commit SHA; scan ID where applicable; rule ID; evidence tier; repository-relative path; a valid one-based span where available; extractor ID and extractor version; supporting fact IDs where available; scope or container metadata; and coverage with limitations. The outputs reference describes where these fields land in the generated artifacts.

Questions reviewers should ask.

  • What does this location anchor—a declaration, a container, a workspace, or nothing because the span is unavailable?
  • Which rule ID documents the convention, and what does that rule say the span means?
  • What evidence tier and limitations travel with the row, and is the claim scoped to the anchor rather than to a line?
  • Could this span have been borrowed, defaulted, or strengthened by a downstream consumer?

The gap guide and evidence model define the shared vocabulary, and the test-planning handoff shows how anchored rows become bounded questions rather than verdicts.

What a location does not establish.

A path or span does not independently prove causality, runtime reachability, execution, business intent, ownership, fault, or complete coverage. It does not show that an anchored line contains missing behavior, that line 1 caused a workspace or container condition, or that an unavailable span means no evidence exists. The examples here are synthetic and cite only checked-in public contracts; see the site limitations for the product-wide boundaries.

This article includes no private repository, employer, customer, application, service, database, machine, user, or object identity, and no absolute path, source snippet, raw diagnostic, command output, log, or configuration value. TraceMap's scanner and reducer contain no LLM calls, embeddings, vector databases, or prompt-based classification; the Access container story continues in reverse engineering Access without running it.