Before runtime review
Name the surface, scan scope, commit SHA, rule IDs, evidence tiers, coverage labels, and known gaps so runtime owners know what static context is being handed over.
Static evidence beside telemetry
Static repository evidence and runtime observability answer different questions.
TraceMap provides deterministic static repository evidence from a repository snapshot: rule IDs, evidence tiers, file paths, line spans, commit SHA, extractor versions, coverage labels, and limitations. Runtime observability remains the source for live behavior, traffic, performance, alerts, timelines, and operational interpretation.
Public claim level: concept. No public conclusion without evidence. TraceMap shows static dependency evidence and limitations; runtime tools show observed behavior. Neither replaces the other. This page explains boundaries; it does not describe a TraceMap runtime agent, telemetry ingestion path, live dashboard, incident automation, or observability replacement.
Different questions
Use static evidence for code context; use runtime systems for observed behavior.
| Static question | TraceMap evidence shape | Runtime question | Runtime owner or system | Limitation | Handoff |
|---|---|---|---|---|---|
| Where is this surface visible in the scanned commit? | Repository snapshot, commit SHA, route or endpoint reference, file path, line span, rule ID, evidence tier, and coverage label. | Which requests actually ran in production? | Runtime telemetry, logs, traces, metrics, dashboards, alerts, and service-owner interpretation. | Static references are review input, not traffic proof. | Hand static context to the runtime owner with the scan identity and limitation attached. |
| Which contract, package, config, project, or SQL-facing references are nearby? | Deterministic facts, extractor version, artifact family, limitation, and analysis-gap rows when proof is partial. | How did the endpoint perform under load, and did requests error? | APM, production metrics, trace sampling, error monitoring, tests, and the owning team. | TraceMap does not prove endpoint performance, runtime errors, or operational safety. | Pair the static path with the runtime system of record and ask for owner review. |
| What should reviewers inspect next? | Static path, nearby evidence, gap label, public-safe proof path, and follow-up owner field in the handoff note. | What happened during the incident timeline? | Incident dashboards, alert history, logs, traces, incident command, release records, and human review. | TraceMap does not determine outage cause, incident root cause, priority, service ownership, or release approval. | Assign the unresolved runtime, test, service-owner, or release-process question without upgrading the static evidence. |
How to use both
Keep the static packet useful without turning it into runtime proof.
During handoff
Separate static references from operational questions. Ask runtime owners to check logs, traces, metrics, dashboards, alerts, tests, request behavior, and service context.
After runtime review
Attach runtime conclusions to their own systems of record, then use TraceMap static evidence for follow-up code inspection, not for production certainty.
Reading a static evidence packet
Read the packet as bounded static evidence.
rule idWhich deterministic rule produced the fact, and where are the rule limitations documented?evidence tierWas the finding semantic, structural, syntax/textual, or an explicit unknown?file spanWhich public-safe file path and line span locate the static reference without publishing source snippets?scan identityWhich commit SHA and extractor version produced the row?coverage labelIs the scan complete for the stated scope, reduced, partial, syntax-only, or unavailable?follow-up ownerWho owns the next runtime, test, service-owner, incident-response, or release-process question?Non-claims
The static packet does not become operational certainty.
- TraceMap does not prove runtime behavior, production traffic, endpoint performance, outage cause, release safety, operational safety, incident root cause, service ownership, production dependency understanding, test sufficiency, or complete product coverage.
- TraceMap does not replace logs, traces, APM, telemetry, incident dashboards, production metrics, tests, service-owner review, incident response, release approval, governance, or human judgment.
- TraceMap does not perform AI impact analysis, LLM analysis, prompt-based classification, embedding search, or vector database analysis in the scanner or reducer.
- TraceMap should not use impact wording for a surface unless reducer-backed public-safe evidence supports that wording; otherwise use static reference, static path, surface, nearby evidence, review input, gap, or needs review.
Proof paths and limitations
Public examples stay summarized and public-safe.
Safe summary layerArtifact families, public-safe summaries, proof-path pages, rule IDs, evidence tiers, coverage labels, limitations, commit SHA, line spans, and extractor versions when a public proof path backs them.
Local-only materialDo not publish raw fact streams, local SQLite indexes, analyzer logs, source excerpts, database query text, configuration values, secrets, local paths, repository remotes, generated scan directories, private sample identities, telemetry payloads, incident timelines, customer data, service names, or production identifiers.
Concept examplesRuntime examples on this page are generic. Missing proof paths remain visible limitations rather than evidence-backed examples.