Limitations
TraceMap keeps the claim narrow.
The useful part of TraceMap is not that it claims certainty. It is that it names the evidence, the rule, the coverage, and the places where the analysis cannot prove a conclusion.
Non-claims
What TraceMap does not prove.
- No runtime traffic or production usage is inferred.
- No deployment state, release approval, or operational safety is inferred.
- No failed or partial scan is reported as clean.
- No absence-of-impact claim is made under reduced coverage.
- No raw source snippets are stored by default.
- No LLM calls, embeddings, vector databases, or prompt-based classification are used in the scanner or reducer.
Web Forms setup keeps execution gates visible.
The Web Forms guided setup distinguishes paused state, explicit build consent, Windows-required legacy builds, external projectless publication, verified retained reports, and partial results. None of those states proves runtime behavior, publication success, compatibility, migration parity, or safety.
Use the demo runbook when public demo wording is in play.
The public demo runbook routes demo sharing decisions back to summaries, proof paths, validation, and these limitations. It does not loosen the non-claims on this page.
Partial analysis is still useful.
When semantic loading fails, TraceMap can still scan syntax, config, project, package, and SQL evidence. Those rows route review, but reports must label the reduced coverage. The reduced coverage playbook shows the row labels, owners, safe wording, and stop conditions for that handoff.
Incident-adjacent use does not relax these limits.
The incident review orientation concept uses static evidence to route code questions. It does not infer runtime traffic, endpoint performance, deployment state, production cause, release safety, or approval.
SQL handoff evidence keeps execution and runtime state outside the claim.
The SQL operator handoff and synthetic proof packet show expected categorical context and static prerequisite candidates. They cannot observe the active database client, effective permissions, scheduled execution, validation results, or rollback completion.
Checked-in refactor intent is not applied database state.
The SQL project refactor-intent proof can surface supported static table renames, column renames, and schema moves. It cannot prove project build, DACPAC content, deployment planning, target refactor-log state, compatibility, successful application, reversibility, approval, or execution safety.
A Web Forms source-to-DLL path is not a runtime request.
The public synthetic Web Forms proof preserves source, compiled IL, review-candidate, and gap tiers across getter, constructor, provider, and database API evidence. It cannot prove page reachability, branch selection, property state, provider dispatch, command execution, database success, returned rows, or deployment identity.
A repeatable Web Forms corpus is still bounded to its tested tree.
The reproducible local demo keeps exact commit, platform, counts, Windows publication status, caps, gaps, and failure preservation visible. Repeat success does not prove an earlier intermittent failure was fixed, and a non-Windows skip is never an authentic ASP.NET publication pass.