Engineering managers
What proof do we have, what is only partial, and which review decision still needs a person?
Manager packet
TraceMap gives teams an evidence conversation before the claim.
The manager view is simple: TraceMap turns repository scans into deterministic static evidence so a team can discuss what is known, what is reduced, and where proof stops before saying a change is safe or impacted.
Public claim level: demo. This page summarizes public demo evidence from checked-in samples. It does not claim runtime behavior, production traffic, deployment state, endpoint performance, release safety, incident root cause, or AI impact analysis.
What it solves
It replaces prose-only certainty with an inspectable trail.
Before the review claimTeams can see which static dependencies, changed surfaces, rule IDs, evidence tiers, and coverage labels support the conversation.
Before the safety claimManagers can ask whether gaps, partial analysis, generated summaries, and limitations are visible enough for human review.
Before the escalation claimIncident follow-up can use static evidence to orient questions without saying TraceMap proves production cause or runtime behavior.
Before the handoffReviewers get paths back to public-safe reports, capability status, roadmap gates, and known non-claims.
Incident follow-up stays an orientation story.
The incident review orientation concept shows how managers and reviewers can use static evidence to ask better code questions after an event without claiming TraceMap proved runtime cause, production behavior, or release safety.
Reader questions
Different leaders can use the same packet without changing the evidence.
Reviewers
Which rule IDs, evidence tiers, file spans, supporting IDs, and limitations explain this finding?
Architects
Which static paths, packages, endpoints, SQL surfaces, config surfaces, or gaps point to coupling?
Engineering leads
Which teams need more context before a change is described as safe, risky, or needing review?
Tool owners
Which generated summaries are public-safe, and which raw artifacts must stay local or private?
Future reviewers
Can they follow the same source paths and limitations without reconstructing the story from memory?
Evidence ingredients
The useful parts are concrete, small, and named.
rule IDsEvery public conclusion should stay attached to the rule or status framing that produced it.evidence tiersReaders can separate semantic, structural, syntax/textual, and unknown evidence instead of treating all findings alike.coverage labelsPartialAnalysis, reduced coverage, gaps, and unavailable sections stay part of the packet.generated summariesMarkdown and JSON summaries help humans read the evidence without replacing source facts and local indexes.proof pathsPublic pages point back to checked-in demos, reports, capability rows, roadmap gates, and limitations.Proof path
Start with the summary, then follow the links to the evidence ledger.
The checked-in public demo can generate public-safe summaries for combined reports, paths, reverse lookup, portfolio, diff, impact, and release review. Raw fact streams, SQLite files, scan folders, and analyzer logs remain local-only. Choose an ignored output directory when you run it.
git clone https://github.com/joefeser/tracemap.git
cd tracemap
./scripts/demo-public.sh .tracemap-demo
# Read the public-safe summary first.
sed -n '1,220p' .tracemap-demo/demo-summary.mdHow to use it
The packet narrows the conversation without approving the release.
Use it in reviewAsk which static evidence supports a concern, which gaps remain, and whether the summary is enough for the next human decision.
Use it in planningIdentify repeated dependency surfaces, package or config surfaces, and coverage limits that should shape follow-up work.
Use it in incident follow-upOrient code questions after an event without claiming TraceMap proved the production cause.
Use it in handoffGive managers and reviewers the same bounded evidence map instead of separate verbal summaries.
Non-claims
The page is intentionally not a runtime or approval story.
- TraceMap does not replace Dynatrace, telemetry, logs, traces, incident response, ownership, tests, human review, or release approval.
- TraceMap does not prove production traffic, deployment state, endpoint performance, runtime reachability, P1 root cause, or that an endpoint is bad.
- TraceMap does not validate a release or turn partial static evidence into a safety decision.
- TraceMap does not use LLM calls, embeddings, vector databases, or prompt-based classification in the scanner or reducer.
Public-safe boundary
Share the summary, not the raw internals.
Safe to summarizePublic routes, checked-in demo paths, generated report families, rule/status framing, evidence tiers, coverage labels, gap counts, and limitations.
Keep localRaw source snippets, raw SQL, config values, secrets, local absolute paths, raw remotes,
facts.ndjson, index.sqlite, combined SQLite files, scan directories, analyzer logs, and private sample identities.Keep visibleLimitations, reduced coverage, unavailable evidence, and human-review requirements should stay next to any conclusion.
Detailed proof