endpoint-adjacent static paths
List the nearby routes, handlers, callers, contracts, and source paths. Separate direct evidence from structural evidence and syntax-only evidence.
Endpoint review playbook
Review endpoint-adjacent evidence before choosing the next step.
This engineer-facing playbook helps a reviewer decide whether an endpoint review candidate deserves review because a static packet shows coupling, dependency surfaces, analysis gaps, or repeated review friction.
Public claim level: concept. No public conclusion without evidence. Endpoint review starts with static evidence, not certainty.
Review question
Ask whether the packet supports inspection, a gap, or a follow-up.
Bound the subjectName the endpoint review candidate and the source context for the reviewed packet.
Read the supportTraceMap evidence can show static coupling, dependency surfaces, analysis gaps, or repeated review friction only when those cues remain attached to public-safe evidence.
Keep the boundaryThis workflow is a pre-review inspection aid, not a production diagnostic, release gate, incident analysis, runtime verification guide, service ownership system, or product coverage claim.
Stop unsupported claimsIf the packet lacks rule IDs, evidence tiers, coverage labels, limitations, source context, or a public-safe summary, route the statement to limitations or a gap outcome.
Evidence packet
Six dimensions keep endpoint review grounded.
packages
Inspect package and framework surfaces as static dependency cues. Do not turn package references into deployed-usage or runtime-behavior claims.
config surfaces
Record public-safe config surface names and gaps without publishing configuration details or environment-specific material.
SQL-facing surfaces
Note database-facing code areas or adapters only as review cues. Do not publish database query text or connection material.
coverage labels
Keep complete, partial, reduced, unavailable, and gap-labeled coverage visible so uncertainty does not become a stronger conclusion.
limitations
Carry documented limitations beside each review cue, especially when semantic analysis, language coverage, or public-safe summary detail is missing.
Verification
Repeat only what the evidence packet can support.
rule IDsVerify the rule ID before repeating any conclusion. If the rule is only a placeholder, keep the wording as authored concept copy.evidence tiersCheck whether the row is Tier1Semantic, Tier2Structural, Tier3SyntaxOrTextual, or Tier4Unknown.source contextVerify file paths, line spans, commit/source context, extractor versions, coverage labels, and limitations when those fields exist in the public-safe packet.gap labelsKeep partial or unknown coverage visible instead of rewriting it as complete evidence.source excerptsAvoid source snippets by default. Use public-safe path and line-span descriptions or snippet hashes when source context is needed.Workflow
Move from static packet to bounded review output.
1. State the review question
Ask whether the endpoint deserves review because the packet shows coupling, dependency surfaces, gaps, or repeated review friction.
2. Sort static paths
List endpoint-adjacent static paths and mark each as direct, structural, syntax-only, or gap-labeled evidence.
3. Inspect package surfaces
Review package and framework surfaces as repository evidence without implying runtime behavior, endpoint performance, or deployed usage.
4. Inspect config surfaces
Use names and safe summaries only. Redact detailed values and environment-specific details before public discussion.
5. Inspect SQL-facing surfaces
Keep database-facing clues at the surface level. Query details and connection material stay outside public copy.
6. Read coverage and limitations
Decide whether the packet supports a bounded conclusion, a gap, or a follow-up question before writing any public-safe summary.
Decision outputs
The useful result is a next review step, not certainty.
deeper code reviewUse when rule-backed static paths or dependency surfaces justify human inspection of nearby source.
targeted testsUse when static evidence names a surface that should be exercised by deterministic tests or an existing test gap.
telemetry questionUse when the claim requires runtime data outside TraceMap's static packet. Treat it as a question for runtime systems and owners, not as TraceMap proof.
owner follow-upUse when ownership authority, release policy, incident context, production deployment facts, customer traffic, or source expertise is needed before a conclusion can be made.
Authored concept example
Review packet for Endpoint A: static evidence suggests a review candidate. A safe note might say, "rule ID <rule-id>, Tier2Structural, partial coverage," or "gap-labeled packet: review question remains open." The example is authored concept copy; it is not a real endpoint finding and does not make an impact conclusion.
Artifact boundary
Public summaries are reviewed; local artifacts stay local.
Public-safe summariesShare reviewed reports, proof paths, rule IDs, evidence tiers, file paths, line spans, snippet hashes, commit/source context, extractor versions, coverage labels, and limitations only when derived from checked-in public or explicitly reviewed public-safe material.
Local-only artifactsDo not publish raw facts, raw SQLite, analyzer logs, raw source snippets, raw SQL, config values, secrets, local paths, raw remotes, generated scan directories, private sample names, connection strings, credentials, table dumps, or database contents.
Artifact family namesFamilies such as facts.ndjson, index.sqlite, report.md, scan-manifest.json, and logs/analyzer.log are useful when explaining the boundary, but raw contents and machine-local paths stay out of public material.
Claim-safe language
Use careful wording when the packet is partial.
safe wordingUse phrases such as static evidence suggests a review candidate, rule ID <rule-id>, Tier2Structural, partial coverage, and gap-labeled packet: review question remains open.red flagsAvoid runtime behavior, production traffic, endpoint performance, outage cause, release safety, operational safety, AI impact analysis, LLM analysis, complete product coverage, team blame, vendor blame, consultant blame, and scare framing.static limitsStatic evidence can route inspection, but cannot approve a release, diagnose an outage, prove endpoint performance, prove production usage, assign fault, or certify operational safety.escalation ruleWhen a claim requires runtime telemetry, customer traffic, production deployment facts, incident context, ownership authority, or release policy, route to limitations or the appropriate human review process.Related routes